동일한 RedOS 이미지(CentOS 7 기반)로 구성된 "31"개의 서버가 있습니다. LDAP 삼바 도메인으로 이동하고 LDAP 사용자 그룹을 기반으로 SSH를 통해 인증하도록 구성됩니다. 이를 위해 다음과 같은 변경이 이루어졌습니다.
루트로 생성
echo "Domain admins" > /etc/ssh/access_groups.conf && chmod 600 /etc/ssh/access_groups.conf
/etc/pam.d/sshd 수정
____missed default____
account required pam_nologin.so
account sufficient pam_localuser.so
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/ssh/access_groups.conf
account include password-auth
_______ missed default____
visudo /etc/sudoers.d/01-domain-user
#sudo admin users LDAP auth
"%mydomain.local\Domain admins" ALL=(ALL) NOPASSWD:ALL
systemctl sshd 다시 시작
이 구성은 약 30여 대의 서버에 성공적으로 적용되어 실행되고 있습니다. 서버 31에서는 이 구성이 작동하지 않습니다. 로그인을 시도하면 클라이언트는 서버에 의해 연결이 종료되었음을 표시합니다.
debug3: failed to open file:C:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
t1_rushao@ruyansvap38's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
Connection closed by 10.65.201.61 port 22
서버 측에서
sshd[18238]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.65.90.176 user=t1_rushao
sshd[18238]: pam_listfile(sshd:account): Refused user t1_rushao for service sshd
sshd[18238]: Failed password for t1_rushao from 10.65.90.176 port 59786 ssh2
sshd[18238]: fatal: Access denied for user t1_rushao by PAM account configuration [preauth]
내가 댓글을 달면"계정 pam_listfile.so가 필요합니다..."도메인 사용자로 SSH를 통해 연결할 수 있지만 sudo도 작동하지 않습니다. 동시에,
id t1_rushao
uid=1006007868(t1_rushao) gid=1006000513(domain users) groups=1006000513(domain users),1006000512(domain admins)
sssd 서비스가 작동되고 있고 서버의 도메인 사용자 인증도 작동하는 것 같아서 kinit, net Ads Join을 몇번 시도했습니다. /etc/security/access.conf는 기본적으로 완전히 주석 처리되어 있습니다.
이 구성이 이 서버에서 작동하지 않는 이유를 모르겠습니다. 문제가 도메인 그룹 어딘가에 있고 시스템이 사용자 그룹을 설정과 일치시킬 수 없다는 것을 알고 있는데, 그 이유는 무엇입니까?
답변1
가능한 문자 대소문자 문제: id명령은 그룹을 domain admins모두 소문자로 보고하지만 사용자 /etc/ssh/access_groups.conf와 /etc/sudoers.d/01-domain-users둘 다 그룹을 Domain admins초기 대문자로 지정했습니다.
pam_listfile.soUnix/Linux 시스템은 일반적으로 대소문자를 구분하므로 이것이 규칙의 예외라고 믿을 이유가 없습니다 . 나는 이것이 sudo확실히 대소 문자를 구분한다는 것을 알고 있습니다.
access_groups.conf일치하도록 sudoers 구성에서 그룹 이름을 모두 소문자로 변경해 보세요 id.
sssd( /etc/sssd/sssd.conf및 모든 파일) /etc/sssd/conf.d/*.conf에는 도메인의 구성이나 설정 등에서 full_name_format약간의 use_fully_qualified_names차이가 있을 수 있습니다 case_sensitive.
귀하의 작업 서버에는 분명히 이것이 있어야 합니다 case_sensitive = false. 이것은 sssd의 기본 설정이 아닌 것 같습니다. 어쩌면 작동하지 않는 서버에 일부가 누락되었을 수도 있습니다.
답변2
통신회사, 정확히! 실제로 작동한다. 마지막 서버에서는 sssd.conf한 줄만 추가하면 다른 서버와 다릅니다.
re_expression = (?P<name>[a-z0-9._-]+)
다른 서버에는 그런 줄이 없습니다. 모든 서버에 sssd.conf 설정이 있습니다case_sensitive = False
분석을 했는데 이 파일은 join-to-domainRedOS 개발팀의 스크립트 패키지에 의해 자동으로 구성되어 서버를 LDAP 도메인에 추가합니다. 불과 며칠 전에 새로운 버전의 스크립트가 출시되었는데, 이 서버(며칠 전에 생성됨)에서는 sssd가 다른 서버와 다르게 구성되어 있습니다.
결과적으로 Domain admins공백으로 구분되고 sssd 구성은 대소문자를 구분하는 두 가지 조건이 모두 충족됩니다. 간단히 이름이 지정된 그룹을 테스트하고 소문자로 구성된 그룹 이름을 확인한 결과 작동합니다. 모든 것을 비활성화했으며 모든 것이 그룹 및 대소 문자를 구분하지 않는 구성 re_expression에서 작동합니다 . Domain admins개발자에게 왜 이런 일을 했는지 물어볼 필요가 있습니다.