Active Directory 에 도메인 조인을 시도하면 Insufficient permissions to join the domain 으로 끝나고, SSSD 를 재시작하면 기동에 실패한다. 로그에는 keytab 을 찾을 수 없다는 메시지가 반복된다.
Key table file '/etc/krb5.keytab' not found while getting initial credentials
Failed to start System Security Services Daemon
/etc/krb5.keytab 은 도메인 조인이 성공한 뒤에 생기는 파일이다. 조인이 실패한 상태에서 SSSD 를 기동하면 id_provider = ad 도메인이 머신 계정으로 KDC 인증을 시도하다가 keytab 이 없어 실패한다. 따라서 keytab 을 수동으로 만들어 넣는 것은 해법이 아니고, 조인 실패 원인을 먼저 없애야 한다.
조인이 끝나지 않은 서버라면 SSSD 를 먼저 멈춰 두고 진단하는 편이 로그가 깨끗하다.
메시지는 권한 문제를 가리키지만, 실제로는 조인 과정에서 쓰이는 Kerberos 인증이 깨진 경우가 대부분이다. 확인 순서는 다음과 같다.
조인에 쓰는 계정이 해당 OU 에 컴퓨터 객체를 만들 권한이 있는지 본다. 도메인 관리자가 아니라면 대상 OU 를 명시해야 한다.
realm join --verbose -U adminuser ad.example.com --computer-ou="OU=Linux,OU=Servers,DC=ad,DC=example,DC=com"
시간 차이를 확인한다. Kerberos 는 기본적으로 5분을 넘는 시각 차를 거부한다.
chronyc sources
chronyc tracking
이름 해석이 양방향으로 맞는지 본다. 정방향만 맞고 역방향이 다른 이름을 돌려주면 클라이언트가 만든 서비스 주체 이름이 KDC 의 것과 달라져 인증이 깨진다.
dig +short ad.example.com
dig +short -x 192.0.2.10
realm discover ad.example.com
역방향 조회가 KDC 의 정식 이름과 다른 이름을 돌려줄 때, Kerberos 클라이언트는 그 이름으로 서비스 주체를 만들었다가 "그런 주체가 없다"는 응답을 받는다. 겉으로는 권한 오류처럼 보인다.
krb5.conf 에서 역방향 조회를 끄면 클라이언트가 입력한 이름을 그대로 쓰므로 문제가 사라진다.
[libdefaults]
default_realm = AD.EXAMPLE.COM
rdns = false
dns_canonicalize_hostname = false
dns_lookup_realm = true
dns_lookup_kdc = true
nslookup 이 양방향으로 잘 된다고 해서 이 설정이 필요 없다는 뜻은 아니다. 로드밸런서 뒤의 도메인 컨트롤러나 별칭(CNAME)으로 접근하는 구성에서는 조회가 성공하면서도 정식 이름이 달라진다. 실무에서는 AD 연동 서버에 rdns = false 를 기본값처럼 두는 경우가 많다.
realm list
klist -k /etc/krb5.keytab | head
systemctl restart sssd && systemctl status sssd
id adminuser@ad.example.com
realm list 에 도메인이 보이고 keytab 에 HOST/<호스트이름> 과 머신 계정(<호스트이름>$) 주체가 들어 있으면 정상이다.
다시 조인해야 한다면 남은 상태를 먼저 지운다. 이전 조인의 캐시가 남아 있으면 같은 오류가 반복된다.
realm leave ad.example.com
rm -f /etc/krb5.keytab
rm -f /var/lib/sss/db/*
kdestroy -A
SSSD 자체 진단은 포그라운드 실행이 가장 빠르다.
systemctl stop sssd
sssd -i -d 6
도메인별 상세 로그가 필요하면 sssd.conf 의 해당 절에 debug_level = 6 을 주고 /var/log/sssd/ 아래 파일을 본다. 로그를 켠 채로 두면 디스크를 빠르게 먹으므로 진단이 끝나면 되돌린다.