Fundo
Estou tentando fazer login (via SSH, em uma instância do Amazon Linux EC2 em execução sssd) como usuários que criei em meu AWS Directory Services Simple AD. Estou autenticando com kerberos e identificando o usuário com LDAP (tudo por meio de sssd.)
Problema
Não consigo fazer login como usuários que criei com adtool, o que significa que é muito mais difícil para mim automatizar a adição de novos usuários ao meu Simple AD. Quando tento, o KDC diz que não suporta o tipo de criptografia (presumo que seja para a senha do usuário?) Consulte a seção "Mensagem de erro" abaixo.
No entanto, posso efetuar login como o usuário administrador interno e como usuários que criei por meio do Microsoft Management Console em uma instância do Windows Server 2008 EC2 ingressada no domínio. Portanto, minha configuração funciona, ou pelo menos funciona parcialmente.
Solução TL;DR necessária
Preciso saber o que estou fazendo de errado adtoolque me impede de fazer login como usuários criados com eles. Não é aparente o que estou fazendo de errado e acho que isso pode ser geralmente útil para pessoas que tentam fazer algo semelhante a mim. Detalhes abaixo.
Mensagem de erro
Esta é a saída sssdao tentar fazer login como o usuário criado com adtool:
(Thu Dec 31 15:35:35 2015) [[sssd[krb5_child[5459]]]] [sss_child_krb5_trace_cb] (0x4000): [5459] 1451576135.446649: Response was from master KDC
(Thu Dec 31 15:35:35 2015) [[sssd[krb5_child[5459]]]] [sss_child_krb5_trace_cb] (0x4000): [5459] 1451576135.446788: Received error from KDC: -1765328370/KDC has no support for encryption type
(Thu Dec 31 15:35:35 2015) [[sssd[krb5_child[5459]]]] [get_and_save_tgt] (0x0020): 996: [-1765328370][KDC has no support for encryption type]
(Thu Dec 31 15:35:35 2015) [[sssd[krb5_child[5459]]]] [map_krb5_error] (0x0020): 1065: [-1765328370][KDC has no support for encryption type]
(Thu Dec 31 15:35:35 2015) [[sssd[krb5_child[5459]]]] [k5c_send_data] (0x0200): Received error code 1432158209
Do lado do cliente dizPermission denied, please try again.
Arquitetura
Aqui está a aparência da minha arquitetura em torno do Simple AD:
Essa configuração me permite usar o LDAPS, mesmo que o Simple AD da AWS não o suporte.
O registro route53 para o ELB é directory.myteam.mycompany.com, mas o domínio que usei para o Simple AD é myteam.mycompany.internal.
Configuração na máquina rodando sssd
/etc/sssd/sssd.conf:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = myteam
[nss]
default_shell = /bin/bash
fallback_homedir = /home/%u
ldap_user_home_directory = unixHomeDirectory
[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
[domain/myteam]
enumerate = true
cache_credentials = TRUE
id_provider = ldap
ldap_uri = ldaps://directory.myteam.mycompany.com
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_default_bind_dn = CN=test-user,CN=users,DC=myteam,DC=mycompany,DC=internal
ldap_default_authtok = REDACTED_PASSWORD
ldap_id_use_start_tls = true
ldap_schema = AD
ldap_force_upper_case_realm = true
ldap_id_mapping = true
ldap_search_base = CN=users,DC=myteam,DC=mycompany,DC=internal
ldap_user_uuid = none
ldap_group_uuid = none
chpass_provider = krb5
auth_provider = krb5
krb5_server = directory.myteam.mycompany.com
krb5_realm = MYTEAM.MYCOMPANY.INTERNAL
krb5_changepw_principal = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15
krb5_canonicalize = True
/etc/sysconfig/authconfig:
IPADOMAINJOINED=no
USEMKHOMEDIR=yes
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=yes
USESHADOW=yes
USEWINBIND=no
PASSWDALGORITHM=sha512
FORCELEGACY=yes
USEFPRINTD=no
FORCESMARTCARD=no
USEDB=no
USELDAPAUTH=no
USEPASSWDQC=no
IPAV2NONTP=no
WINBINDKRB5=no
USELOCAUTHORIZE=yes
USEECRYPTFS=no
USECRACKLIB=yes
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELDAP=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=yes
USEPWQUALITY=yes
USEHESIOD=no
Além desses dois arquivos, certifiquei-me de habilitar a autenticação de senha sshd_confige habilitei o sssd nos módulos pam com sudo authconfig --updateall --enablesssd --enablesssdauth.
/etc/pam.d/system-auth:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet_success
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
Versões de software
uname -a:Linux ip-172-31-31-2 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linuxsssd1.12.2adtool1.3.3openldap-clients2.4.23-34.25.amzn1
Diferenças entre os usuários
Para mostrar como esses usuários diferem em meu diretório, aqui está a saída de consultá-los ldapsearchda instância em execução sssd.
Usuário criado com adtool(editar: você verá abaixo que o pwdLastSetvalor está presente, acredito que não estava presente anteriormente e sua presença é a chave para minha resposta):
$ ldapsearch -LLL -H ldaps://directory.myteam.mycompany.com -D CN=Administrator,CN=users,DC=myteam,DC=mycompany,DC=internal -x -W '(cn=test-user)'
Enter LDAP Password:
dn: CN=test-user,CN=Users,DC=myteam,DC=mycompany,DC=internal
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: test-user
instanceType: 4
whenCreated: 20151230204358.0Z
displayName: Test user
uSNCreated: 3532
name: test-user
objectGUID:: ZhfGzcqLd06x2UBU3UNiZQ==
codePage: 0
countryCode: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAHWfr9xoaXwKvEcuoUwQAAA==
accountExpires: 9223372036854775807
sAMAccountName: test-user
sAMAccountType: 805306368
userPrincipalName: [email protected]
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=myteam,DC=mycompany,DC
=internal
userAccountControl: 512
lockoutTime: 0
whenChanged: 20151231150317.0Z
uSNChanged: 3619
pwdLastSet: 130960477970000000
distinguishedName: CN=test-user,CN=Users,DC=myteam,DC=mycompany,DC=internal
Usuário criado através do Console de Gerenciamento Microsoft:
$ ldapsearch -LLL -H ldaps://directory.myteam.mycompany.com -D CN=Administrator,CN=users,DC=myteam,DC=mycompany,DC=internal -x -W '(sAMAccountName=test-windows-2008)'
Enter LDAP Password:
dn: CN=Test User,CN=Users,DC=myteam,DC=mycompany,DC=internal
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Test User
sn: User
givenName: Test
instanceType: 4
whenCreated: 20151230223533.0Z
whenChanged: 20151230223534.0Z
displayName: Test User
uSNCreated: 3563
uSNChanged: 3563
name: Test User
objectGUID:: 2cuynP3/9EeRIm1fCUJ9jA==
userAccountControl: 512
codePage: 0
countryCode: 0
pwdLastSet: 130959885340000000
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAHWfr9xoaXwKvEcuoVwQAAA==
accountExpires: 9223372036854775807
sAMAccountName: test-windows-2008
sAMAccountType: 805306368
userPrincipalName: [email protected]
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=myteam,DC=mycompany,DC
=internal
distinguishedName: CN=Test User,CN=Users,DC=myteam,DC=mycompany,DC=internal
A diferença entre o meu uso de
adtoole o MMC é que o MMC me incentivou a inicializar a senha do usuário, mas eu havia esquecido de fazer o mesmo com meu usuário criado comadtool. As etapas a seguir resolveram isso, e de forma reproduzível:Na minha pergunta inicial, eu havia consultado novamente o original
test-useresta manhã depois que um colega de trabalho havia feito as etapas acima para definir a senha, então a saída mostra que a senha foi definida, mas ontem à noite, quando eu estava tentando fazer login, não tinha definido, daí o problema. Quando tentei fazer login novamente hoje, funcionou e, depois de algumas investigações, descobri que é por isso.Agora, só posso especular por que a mensagem "KDC não tem suporte para tipo de criptografia" apareceu: como não havia senha, não havia um tipo de criptografia. Se eu estiver errado, adoraria ser corrigido.
TL;DR é preciso lembrar de desbloquear o usuário e definir sua senha ao usar
adtoolem vez do MMC.Já vi erros como esse antes causados por uma das opções de conta sendo definida (em um ambiente não AWS), mas não me lembro qual propriedade exata. Os usuários criados com
ADTooltêm alguma "opção" extra definida em comparação com os usuários criados com o MMC? Não tenho certeza de como mostrar essas opções comLDAPSearch. Dois métodos que eu sei usar são mostrados. Você também pode usar-prop *comGet-Aduserpara mostrar TODAS as propriedades.