LdapErr: DSID-0C0903AA, dados 52e: autenticando em relação ao AD '08 com pam_ldap

2

Tenho acesso total de administrador ao servidor do AD '08 que estou tentando autenticar.

O código de erro significa credenciais inválidas, mas eu gostaria que isso fosse tão simples quanto eu digitando a senha errada.

Primeiro de tudo, eu tenho uma configuração mod_ldap Apache trabalhando contra o mesmo domínio.

AuthType basic
AuthName "MYDOMAIN"
AuthBasicProvider ldap
AuthLDAPUrl "ldap://10.220.100.10/OU=Companies,MYCOMPANY,DC=southit,DC=inet?sAMAccountName?sub?(objectClass=user)"
AuthLDAPBindDN svc_webaccess_auth
AuthLDAPBindPassword mySvcWebAccessPassword
Require ldap-group CN=Service_WebAccess,OU=Groups,OU=MYCOMPANY,DC=southit,DC=inet

Estou mostrando isso porque funciona sem o uso de qualquer Kerberos, como muitos outros guias recomendam para autenticação do sistema no AD.

Agora eu quero traduzir isso para o pam_ldap.conf para uso com o OpenSSH.

A parte /etc/pam.d/common-auth é simples.

auth sufficient pam_ldap.so debug

Esta linha é processada antes de qualquer outra.

Eu acredito que o problema real é configurar o pam_ldap.conf.

host 10.220.100.10
base OU=Companies,MYCOMPANY,DC=southit,DC=inet
ldap_version 3
binddn svc_webaccess_auth
bindpw mySvcWebAccessPassword

scope sub
timelimit 30

pam_filter objectclass=User

nss_map_attribute uid sAMAccountName
pam_login_attribute sAMAccountName
pam_password ad

Agora, tenho monitorado o tráfego do ldap no host do AD usando o wireshark. Capturei uma sessão bem-sucedida do mod_ldap do Apache e a comparei a uma sessão com falha do pam_ldap.

A primeira requisição de ligação é um sucesso usando a conta svc_webaccess_auth, a solicitação de pesquisa é um sucesso e retorna um resultado de 1. A última solicitação de vinculação usando meu usuário é uma falha e retorna o código de erro acima.

Tudo parece idêntico, exceto por esta linha no filtro do pedido de pesquisa, que mostra mod_ldap.

Filter: (&(objectClass=user)(sAMAccountName=ivasta))

O segundo é o pam_ldap.

Filter: (&(&(objectclass=User)(objectclass=User))(sAMAccountName=ivasta))

Meu usuário se chama ivasta. No entanto, o pedido de pesquisa não retorna falha, ele retorna 1 resultado. Eu também tentei isso com o ldapsearch no CLI.

É o bindrequest que segue o pedido de pesquisa que falha com o código de erro 52e acima.

Aqui está a mensagem de falha do pedido final de vinculação.

resultcode: invalidcredentials (49)
80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 52e, v1772

Isso deve significar senha inválida, mas eu tentei com outros usuários e com senhas muito simples.

Alguém reconhece isso de suas próprias lutas com pam_ldap e AD?

Editar: Vale a pena notar que eu também tentei pam_password crypt e pam_filter sAMAccountName = User porque isso funcionava ao usar o ldapsearch.

ldapsearch -LLL -h 10.220.100.10 -x -b "ou=Users,ou=mycompany,dc=southit,dc=inet" -v -s sub -D svc_webaccess_auth -W '(sAMAccountName=ivasta)'

Isso funciona usando a senha da conta svc_webaccess_auth. Essa conta tem acesso de verificação a essa UO para uso com o mod_ldap do apache.

Edit2: Isso é tudo o que recebo nos registros do AD '08 quando não consigo fazer o login.

An account failed to log on.

Subject:
    Security ID:        SYSTEM
    Account Name:       WIN-DC02$
    Account Domain:     SOUTHIT
    Logon ID:       0x3e7

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       ivasta
    Account Domain:     SOUTHIT

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xc000006d
    Sub Status:     0xc000006a

Process Information:
    Caller Process ID:  0x264
    Caller Process Name:    C:\Windows\System32\lsass.exe

Network Information:
    Workstation Name:   WIN-DC02
    Source Network Address: 10.220.100.105
    Source Port:        44565

Detailed Authentication Information:
    Logon Process:      Advapi  
    Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested
    
por Stefan Midjich 10.07.2012 / 11:05

1 resposta

1
Cauda entre minhas pernas eu vou ter que responder a esta porque eu tenho a informação interna embaraçosa.

Eu não sabia que você tinha que criar um usuário Unix comum no sistema para poder fazer o login. Assim que eu criei um usuário combinando ivasta, consegui fazer o login com a senha do AD desses usuários.

A única coisa que não posso fazer é alterar a senha, mesmo com o anúncio pam_password, mas isso não importa, porque isso é apenas para fins de registro de nome de usuário.

    
por 11.07.2012 / 11:44