Letzte Woche hatte ich bei einem unserer Kunden bei der Apache-Konfiguration mit SSO und LDAP-Gruppen-Autorisierung ein Problem. Für meinen AD-Account funktionierte die Anmeldung. Für einen weiteren Account, mit der selben Gruppenzugehörigkeit, jedoch nicht. Die verwendete Apache-Konfiguration sah wie folgt aus:
AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate On KrbMethodK5Passwd On KrbServiceName HTTP KrbAuthRealms example.org Krb5KeyTab /etc/apache2/apache2.keytab Require valid-user AuthzLDAPAuthoritative on AuthLDAPURL "ldap://example.org/DC=example,DC=org?userPrincipalName?sub?" AuthLDAPRemoteUserAttribute "userPrincipalName" AuthLDAPBindDN "ldap@example.org" AuthLDAPBindPassword XXX Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=authorized_group,DC=example,DC=org
Das Problem war, dass das Kerberos-Realm nicht mit der Domäne im userPrincipalName übereinstimmte. Nach einem Update des Kerberos-Auth-Moduls auf Version 5.4, konnten wir mit der neuen Option KrbLocalUserMapping, das Realm abschneiden. Jetzt ließ sich bei der gruppenbezogenen Autorisierung via LDAP der sAMAccountName verwenden. Die funktionsfähige Konfiguration sieht dann abschließend so aus:
AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate On KrbMethodK5Passwd On KrbServiceName HTTP KrbAuthRealms example.org KrbLocalUserMapping On Krb5KeyTab /etc/apache2/apache2.keytab Require valid-user AuthzLDAPAuthoritative on AuthLDAPURL "ldap://example.org/DC=example,DC=org?sAMAccountName?sub?" AuthLDAPRemoteUserAttribute "sAMAccountName" AuthLDAPBindDN "ldap@example.org" AuthLDAPBindPassword XXX Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=authorized_group,DC=example,DC=org
Zum Schluss möchte ich noch darauf hinweisen, dass die verwendete Option weder auf der Projektseite, noch im README des Source-Tarballs dokumentiert ist, sondern lediglich im ChangeLog vermerkt ist.
Weitere Artikel zu diesem Thema sind:
LDAP-Filter zur Autorisierung bei rekursiven Gruppen
SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory
0 Kommentare