Wir versuchen, einen Active Directory-Server für die unternehmensweite Authentifizierung einzurichten.
Einige der Server, die sich gegenüber dem AD authentifizieren sollen, befinden sich in einer DMZ. Daher haben wir uns überlegt, einen LDAP-Server als Proxy zu verwenden, sodass nur ein Server in der DMZ eine Verbindung zum LAN herstellen muss, in dem sich der AD-Server befindet.
Mit etwas Googeln war es kein Problem, den slapd zu konfigurieren (siehe slapd.conf unten) und es schien bei Verwendung des ldapsearch-Tools zu funktionieren, also haben wir versucht, es in Apache2 htaccess zu verwenden, um den Benutzer über den LDAP-Proxy zu authentifizieren.
Und hier kommt das Problem: Wir haben herausgefunden, dass der Benutzername im AD im Attribut „sAMAccountName“ gespeichert ist, also haben wir ihn in .htaccess konfiguriert (siehe unten), aber die Anmeldung hat nicht funktioniert.
Im Syslog haben wir festgestellt, dass der Filter für die LDAP-Suche nicht (wie er sein sollte) war.(&(objectClass=*)(sAMAccountName=authtest01))' Aber '(&(Objektklasse=*)(?=nicht definiert))', was, wie wir herausgefunden haben, die Art und Weise von slapd ist, um anzuzeigen, dass das Attribut nicht existiert oder der Wert für dieses Attribut syntaktisch falsch ist.
Wir dachten an ein fehlendes Schema und fanden dasmicrosoft.schema(und die .std / .ext davon) und versucht, sie in die slapd.conf einzubinden. Was aber nicht funktioniert. Wir haben keine funktionierenden Schemata gefunden, also haben wir einfach den Teil über den sAMAccountName herausgepickt und ein microsoft.minimal.schema (siehe unten) erstellt, das wir eingebunden haben. Jetzt erhalten wir das genauere Protokoll im 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=
Die direkte Verwendung unseres Apache htaccess mit dem AD über LDAP funktioniert jedoch. Hat jemand ein funktionierendes Setup? Vielen Dank im Voraus für jede Hilfe:
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 )
Antwort1
Sie müssen Ihrer Datei slapd.conf Zuordnungen hinzufügen:
moduleload rwm
...
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixGroup group
rwm-map objectClass posixAccount person
rwm-map objectClass memberUid member
Dann können Sie suchen nach demBenutzerkennungAttribut anstelle dessAMAccountNameAttribut in Ihrer .htaccess-Datei:
AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?uid?sub"
Antwort2
Sie sehen diese Fehlermeldung:
get_ava: ungültiger Wert für Attributtyp sAMAccountName
Das liegt daran, dass Ihrer Definition des sAMAccountNameAttributs microsoft.minimal.schemaeine Übereinstimmungsregel fehlt. Einfach ausgedrückt: Mit den Schemadefinitionen von OpenLDAP können Sie angeben, welche Art von Suchvorgängen zulässig sind (Vorhandensein, exakte Übereinstimmung, Teilzeichenfolgenübereinstimmung usw.), und diese Definition hat keine.
Versuche dies:
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 )
Antwort3
Jonathans Antwort hat mich in die richtige Richtung gelenkt und mir geholfen, Folgendes zu überwinden:
additional info: sAMAccountName: attribute type undefined
Problem. Aber ich habe festgestellt, dass Sie dieses Attribut als gültigen Wert für den Eintrag einer Person definieren müssen und dass Sie jeder Person die Objektklasse zuweisen müssen, die dieses Attribut haben darf. Genau wie alle Attribute, die Sie einer inetOrgPerson zuweisen können.
Meine Datei microsoft.minimal.schema lautet jetzt:
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))
Ich ersetze die optionalen MS-Attribute durch nichts, damit ich sie nicht definieren muss.
Ein Beispiel für einen Benutzereintrag sieht wie folgt aus:
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