Parece que é um problema de configuração do PAM. Eu tenho uma configuração semelhante em nossos servidores Linux - autenticação Kerberos contra nossos AD DCs.
Abaixo estão os arquivos relevantes do PAM para comparação.
Primeiro, system-auth
configuração do PAM da qual o sudo
config depende:
# cat /etc/pam.d/system-auth
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_krb5.so
Como você pode ver, isso inclui o módulo pam_krb5.so
usado para o Kerberos.
Os arquivos de configuração sudo
PAM incluem system-auth
e são assim:
# cat /etc/pam.d/sudo
#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
# cat /etc/pam.d/sudo-i
#%PAM-1.0
auth include sudo
account include sudo
password include sudo
session optional pam_keyinit.so force revoke
session required pam_limits.so
O PAM pode ser muito poderoso, mas eu levei um pouco para colocar minha cabeça em volta dele. A documentação da Red Hat me ajudou muito ao lidar com com problemas de PAM.