ldap / proxy do AD: não é possível ligar usando o sAMAccountName, mas o sobrenome e o primeiro nome são capazes de vincular

3

Eu estou tentando configurar um proxy de passagem para o Active Directory, usando o ldap no Debian Wheezy. O arquivo slapd.conf está abaixo. Eu posso ligar apenas encontrar usando o sobrenome, primeiro nome:

ldapsearch -x -h localhost -b "OU=Site-Users,DC=mycompany,DC=local" -D "cn=LaCroix\, Jay,OU=My Group,OU=Site-Users,DC=mycompany,DC=local" -W "(sAMAccountName=jlacroix)" cn sAMAccountName

E isso funciona:

result: 0 Success

Mas o que realmente queremos fazer é vincular por meio do nome de usuário (sAMAccountName):

ldapsearch -x -h localhost -b "OU=Site-Users,DC=mycompany,DC=local" -D "cn=jlacroix,OU=My Group,OU=Site-Users,DC=mycompany,DC=local" -W "(sAMAccountName=jlacroix)" cn sAMAccountName

e isso não funciona:

ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

Nota: Apesar desse erro, minhas credenciais estão corretas, como visto no primeiro exemplo onde a ligação funciona através do sobrenome, nome.

Eu tenho pesquisado através de exemplos há algumas semanas, e não importa o que eu tente, parece que não consigo vincular-se a sAMAccountName, apenas a Sobrenome, Nome.

Eu posso pesquisar sAMAccountName ao pesquisar diretamente no AD, mas não ao usar meu proxy ldap.

Aqui está meu /etc/ldap/slapd.conf:

# Import our schema
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/samaccountname.schema

moduleload      back_ldap
moduleload      back_bdb.la
moduleload      rwm 

# Support both LDAPv2 and LDAPv3
allow           bind_v2

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

loglevel        1   

# Our slapd-ldap back end to connect to AD

database        ldap
suffix          ou=Site-Users,dc=mycompany,dc=local
subordinate
rebind-as-user  yes 
uri             ldap://10.10.10.99:389
chase-referrals yes 
readonly        yes 
#protocol-version       3   

overlay         rwm 
rwm-map         attribute       uid     sAMAccountName
rwm-map         attribute       mail    proxyAddresses 

binddn cn=ADreader 
bindpw supersecretpassword

# Our primary back end 

database        bdb 
suffix          dc=mycompany,dc=local
rootdn          cn=admin,dc=mycompany,dc=local
rootpw          supersecretpassword 
directory       /var/lib/ldap

# Indexes for this back end 
index           objectClass                     eq,pres
index           ou,cn,mail,surname,givenname    eq,pres,sub
index           uid                             eq,pres,sub
    
por Jay LaCroix 11.11.2014 / 20:50

1 resposta

4

O exemplo "funciona" porque o DN do objeto é cn=LaCroix\, Jay,OU=My Group,OU=Site-Users,DC=mycompany,DC=local . O segundo não funciona porque o DN do objeto não é cn=jlacroix,OU=My Group,OU=Site-Users,DC=mycompany,DC=local .

Não é que você esteja vinculado ao "Sobrenome, Primeiro Nome", mas o CN do objeto está definido como "Sobrenome, Nome" e você está vinculado ao CN do objeto. Você não pode simplesmente colocar o sAMAccountName como CN e esperar que ele funcione. O CN do objeto é o CN do objeto.

Ligar diretamente ao AD com um DN de ligação de "DOMAIN \ sAMAccountName" funcionará bem. Eu não acho que o OpenLDAP lidará com isso, pensou. É provável que ele rejeite essa sintaxe, embora, do ponto de vista do Active Directory, funcione bem.

    
por 11.11.2014 / 21:31