Intentamos configurar un servidor Active Directory para la autenticación en toda la empresa.
Algunos de los servidores que deberían autenticarse contra AD están ubicados en una DMZ, por lo que pensamos en usar un servidor LDAP como proxy, de modo que solo 1 servidor en la DMZ tenga que conectarse a la LAN donde está ubicado el servidor AD. ).
Con un poco de búsqueda en Google, no hubo problema para configurar slapd (ver slapd.conf a continuación) y parecía funcionar cuando se usaba la herramienta ldapsearch, así que intentamos usarlo en apache2 htaccess para autenticar al usuario a través del proxy LDAP.
Y aquí viene el problema: descubrimos que el nombre de usuario en el AD está almacenado en el atributo 'sAMAccountName', así que lo configuramos en .htaccess (ver más abajo) pero el inicio de sesión no funcionó.
En el syslog descubrimos que el filtro para ldapsearch no era (como debería ser) '(&(objectClass=*)(sAMAccountName=authtest01))' pero '(&(objectClass=*)(?=indefinido))' que descubrimos es la forma en que slapd muestra que el atributo no existe o que el valor es sintácticamente incorrecto para este atributo.
Pensamos en un esquema que faltaba y encontramos elmicrosoft.esquema(y los .std/.ext) e intenté incluirlos en slapd.conf. Lo cual no funciona. No encontramos ningún esquema funcional, por lo que simplemente seleccionamos la parte sobre sAMAccountName y creamos un microsoft.minimal.schema (ver más abajo) que incluimos. Ahora obtenemos el registro más preciso en el syslog:
Jun 16 13:32:04 breauthsrv01 slapd[21229]: get_ava: illegal value for attributeType sAMAccountName
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SRCH base="ou=xxx,dc=int,dc=xxx,dc=de" scope=2 deref=3 filter="(&(objectClass=\*)(?sAMAccountName=authtest01))"
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SRCH attr=sAMAccountName
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Sin embargo, usar nuestro htaccess de Apache directamente con AD a través de LDAP funciona. ¿Alguien tiene una configuración que funcione? Gracias por cualquier ayuda de antemano:
slapd.conf:
allow bind_v2
include /etc/ldap/schema/core.schema
...
include /etc/ldap/schema/microsoft.minimal.schema
...
backend ldap
database ldap
suffix "ou=xxx,dc=int,dc=xxx,dc=de"
uri "ldap://80.156.177.161:389"
acl-bind bindmethod=simple binddn="CN=authtest01,ou=GPO-Test,ou=xxx,dc=int,dc=xxx,dc=de" credentials=xxxxx
.htaccess:
AuthBasicProvider ldap
AuthType basic
AuthName "AuthTest"
AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?sAMAccountName?sub"
AuthzLDAPAuthoritative On
AuthLDAPGroupAttribute member
AuthLDAPBindDN CN=authtest02,OU=GPO-Test,OU=xxx,DC=int,DC=xxx,DC=de
AuthLDAPBindPassword test123
Require valid-user
microsoft.minimal.schema:
attributetype ( 1.2.840.113556.1.4.221
NAME 'sAMAccountName'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
Respuesta1
Necesita agregar asignaciones a su archivo slapd.conf:
moduleload rwm
...
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixGroup group
rwm-map objectClass posixAccount person
rwm-map objectClass memberUid member
Luego puedes buscar elfluidoatributo en lugar desAMAnombredecuentaatributo en su archivo .htaccess:
AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?uid?sub"
Respuesta2
Estás viendo este mensaje de error:
get_ava: valor ilegal para atributoType sAMAccountName
Lo cual se debe a que su definición del sAMAccountNameatributo microsoft.minimal.schemacarece de una regla de coincidencia. En pocas palabras, las definiciones de esquema de OpenLDAP le permiten decir qué tipo de búsquedas están permitidas (presencia, coincidencia exacta, coincidencia de subcadena, etc.), y esta definición no tiene ninguna.
Prueba esto:
attributetype ( 1.2.840.113556.1.4.221
NAME 'sAMAccountName'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
Respuesta3
La respuesta de Jonathan me indicó la dirección correcta y me ayudó a superar:
additional info: sAMAccountName: attribute type undefined
problema. Pero me di cuenta de que es necesario definir este atributo como un valor legal para la entrada de una persona, y es necesario darle a cada persona la clase de objeto que puede tener ese atributo. Al igual que todos los atributos que puedes darle a inetOrgPerson.
Mi archivo microsoft.minimal.schema ahora es:
attributetype ( 1.2.840.113556.1.4.221
NAME 'sAMAccountName'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
attributetype ( 1.2.840.113556.1.4.146
NAME 'objectSid'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.40'
SINGLE-VALUE )
objectclass ( 1.2.840.113556.1.5.6
NAME 'securityPrincipal'
SUP top
AUXILIARY
MUST (objectSid $ sAMAccountName )
MAY () )
# MAY (nTSecurityDescriptor $ securityIdentifier $ supplementalCredentials $
# rid $ sAMAccountType $ sIDHistory $ altSecurityIdentities $ tokenGroups $
# tokenGroupsNoGCAcceptable $ accountNameHistory $
# tokenGroupsGlobalAndUniversal))
Estoy reemplazando los atributos opcionales de MS con nada para no tener que definirlos.
Una entrada de usuario de ejemplo es como:
dn: uid=user2,ou=example,dc=aa,dc=ad,dc=example,dc=gov
uid: user2
sAMAccountName: user2
objectSid: user2
cn: User Two
displayName: User Two
givenName: User2
sn: One
objectClass: inetOrgPerson
objectClass: securityPrincipal
mail: [email protected]
# password from slappasswd is 'user2'
userPassword: {SSHA}sjB5fmIIPTrUUammtmonP+6DdC93+P4L