OpenLDAP vs mecanismos de autenticação do Active Directory

Question

Eu consigo fazer login em um Active Directory usando o atributo userPrincipalName de user objectClass; (por exemplo, [email protected] )

Também configurei uma instância do servidor OpenLDAP para a qual só posso autenticar usando dn , por exemplo

"cn=somecn,cn=anothercn,ou=someou,dc=mydomain,dc=com"

Como é possível autenticar em OpenLDAP usando outro campo, por exemplo? o atributo mail do inetOrgPerson por exemplo?

Além disso, mesmo se tal coisa fosse possível , como alguém garantiria a exclusividade do campo? (uma funcionalidade que eu assumo é oferecida pelo AD em termos do campo userPrincipalName )

    

Answer 1

O OpenLDAP suporta dois métodos de autenticação ( simple e SASL ), enquanto SASL é o método padrão para ldap-utils como ldapsearch .

Quando você está autenticando usando o DN, você faz a chamada "ligação simples".

ligação simples

O método simple tem três modos de operação:

• anônimo
• não autenticado
• usuário / senha autenticados

Por exemplo:

# ldapwhoami -x
anonymous

ou:

# ldapwhoami -x -D uid=rda,ou=people,dc=phys,dc=ethz,dc=ch -w secret1234
dn:uid=rda,ou=people,dc=phys,dc=ethz,dc=ch

SASL

Clientes e servidores OpenLDAP são capazes de autenticar através da estrutura SASL (Simple Authentication and Security Layer), que é detalhada em RFC4422 . O SASL suporta vários mecanismos de autenticação. Os mecanismos mais comuns com o OpenLDAP são EXTERNAL e GSSAPI .

O mecanismo EXTERNAL faz uso de uma autenticação realizada por um protocolo de nível inferior: geralmente TLS ou Unix IPC. Por exemplo, usando o Unix IPC como usuário root:

# ldapwhoami -Y EXTERNAL -H ldapi://
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

O usuário autenticado é mapeado para um DN na árvore cn=peercred,cn=external,cn=auth .

O mecanismo GSSAPI geralmente significa Kerveros 5. Se você tiver uma infra-estrutura Kerberos 5 implantada, poderá usar os Princípios Kerberos para autenticação.

Primeiro autentique-se contra o KDC e obtenha um TGT:

# kinit rda
Password for [email protected]: secret1234

Em seguida, você pode usar o GSSAPI para autenticação no OpenLDAP:

# ldapwhoami
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
dn:uid=rda,cn=gssapi,cn=auth

O principal [email protected] é mapeado para um DN na árvore cn=gssapi,cn=auth .

Agora você pode mapear esse DN autenticado para um DN real no banco de dados usando uma expressão regular com a configuração olcAuthzRegexp em cn=config :

dn: cn=config
objectClass: olcGlobal
cn: config
olcAuthzRegexp: {0}uid=([^,/]*),cn=phys.ethz.ch,cn=gssapi,cn=auth uid=$1,ou=people,dc=phys,dc=ethz,dc=ch
...

Esta linha olcAuthzRegexp mapeia qualquer entidade principal do usuário no território PHYS.ETHZ.CH para uma entrada posixAccount correspondente em ou=people,dc=phys,dc=ethz,dc=ch que tenha o mesmo nome de usuário no atributo uid .

Por exemplo, com a seguinte entrada posix

# ldapsearch uid=rda
dn: uid=rda,ou=people,dc=phys,dc=ethz,dc=ch
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: krbPrincipalAux
objectClass: krbTicketPolicyAux
uid: rda
krbPrincipalName: [email protected]
...

ldapwhoami será exibido:

# ldapwhoami
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
dn:uid=rda,ou=people,dc=phys,dc=ethz,dc=ch

O mapeamento usando olcAuthzRegexp deve corresponder a uma entrada exclusiva no DIT. Isso deve ser assegurado pelo administrador ou pelo software de gerenciamento.