Tentamos configurar um servidor do Active Directory para autenticação em toda a empresa.
Alguns dos servidores que devem ser autenticados contra o AD são colocados em um DMZ, então pensamos em usar um servidor LDAP como um proxy, para que apenas 1 servidor no DMZ tenha que se conectar à LAN onde o AD- servidor é colocado).
Com alguns googling não foi problema para configurar o slapd (veja o slapd.conf abaixo) e ele pareceu funcionar ao usar a ferramenta ldapsearch, então tentamos usá-lo no apache2 htaccess para autenticar o usuário através do proxy LDAP .
E aí vem o problema: Descobrimos que o nome de usuário no AD é armazenado no atributo 'sAMAccountName', portanto, o configuramos em .htaccess (veja abaixo), mas o login não funcionou.
No syslog nós descobrimos que o filtro para o ldapsearch não era (como deveria ser) ' (& (objectClass = *) (sAMAccountName = authtest01)) ' mas ' (& (objectClass = *) (? = undefined)) 'que descobrimos é a maneira de slapd mostrar que o atributo não existe ou o valor está sintaticamente errado para este atributo.
Pensamos em um esquema ausente e encontramos o microsoft.schema (e os arquivos .std / .ext) e tentou incluí-los no slapd.conf. Que não funciona. Não encontramos nenhum esquema de trabalho, então escolhemos a parte sobre o sAMAccountName e construímos um microsoft.minimal.schema (veja abaixo) que incluímos. Agora nós temos o log mais preciso no 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=
No entanto, usando o nosso Apache htaccess diretamente com o AD via LDAP funciona. Alguém tem uma configuração de trabalho? Obrigado por qualquer ajuda antecipadamente:
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 )
Você precisa adicionar mapeamentos ao seu arquivo 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
Então você pode procurar o atributo uid em vez do atributo sAMAccountName no seu arquivo .htaccess:
AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?uid?sub"
Você está vendo esta mensagem de erro:
get_ava: illegal value for attributeType sAMAccountName
O que é causado por sua definição do atributo sAMAccountName em microsoft.minimal.schema sem uma regra de correspondência. Simplificando, as definições de esquema do OpenLDAP permitem que você diga que tipo de buscas são permitidas (presença, correspondência exata, correspondência de substring, etc), e essa definição não possui nenhuma.
Tente isto:
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 )
A resposta de Jonathan me apontou na direção certa, me colocando em cima do:
additional info: sAMAccountName: attribute type undefined
problema. Mas eu percebi que você precisa definir esse atributo como um valor legal para a entrada de uma pessoa, e você precisa dar a cada pessoa a objectClass que tem permissão para ter esse atributo. Assim como todos os atributos que você pode dar uma inetOrgPerson.
Meu arquivo microsoft.minimal.schema é agora:
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))
Estou substituindo os atributos opcionais do MS por nada, então não preciso defini-los.
Uma entrada de usuário de exemplo é 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