Ich hatte bereits angekündigt oder viel mehr angedroht mich mit dem Thema Benutzermanagement auseinander zu setzen. Anfangen möchte ich damit zu erläutern was ich darunter verstehe bzw. was meine Ziele hierbei sind. Ein Benutzer soll meiner Definition eines guten Benutzermanagement nach eindeutig identifiziert werden und sich mit möglichst viel Komfort und Sicherheit dort anmelden können, wo er berechtigt ist und eben nur dort.
Klingt ja eigentlich ganz einfach, aber als Einstieg denkt nun bitte jeder mal zurück an seinen ersten Arbeitstag und überlegt wie viele Kennungen/Passwort-Briefe er damals bekommen hat. Die wenigsten werden die Frage wohl damit beantworten können genau eine Kennung mit zugehörigem Passwort erhalten zu haben. Nun denkt weiter an die ersten Arbeitswochen und überlegt wie oft noch fehlende Berechtigungen oder lokale Benutzerkonten und Passwörter nachträglich erstellt werden mussten. Und nun einfach mal wie oft am aktuellen Arbeitstag eine Passworteingabe erforderlich war oder den letzten Tag an dem eine Passwortänderung fällig war. Wenn ich damit schon das persönliche Horrorszenario von jemand beschrieben habe, dann versetzt sich derjenige bitte in die Rolle des Consultants, denn mir geht es üblicherweise jede Woche so.
mehr lesen…
NETWAYS Blog
Nochmal Apache und Active Directory
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
SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory
ktpass -out apache2.keytab \
-mapuser www@NETWAYS.DE \
-princ HTTP/www.netways.de@NETWAYS.DE \
-pass login123 \
-ptype KRB5_NT_PRINCIPAL \
-crypto RC4-HMAC-NT \
[libdefaults]
default_realm = NETWAYS.DE
[realms]
NETWAYS.DE = {
kdc = dc.netways.de
default_domain = netways.de
ktpasswd_server = dc.netways.de
}
[domain_realm]
.netways.de = NETWAYS.DE
a2enmod auth_kerb
a2enmod ldap
a2enmod authnz_ldap
AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm NETWAYS.DE
KrbServiceName HTTP
Krb5Keytab /etc/apache2/apache.keytab
KrbMethodK5Passwd on
KrbMethodNegotiate on
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.netways.de/dc=netways,dc=de?userPrincipalName"
AuthLDAPBindDN "cn=ads,cn=Users,dc=netways,dc=de"
AuthLDAPBindPassword ********
Require ldap-group cn=ApacheAccess,cn=Users,dc=netways,dc=de
network.negotiate-auth.trusted-uris .netways.de
Weitere Artikel zum Thema:
LDAP-Filter zur Autorisierung bei rekursiven Gruppen
Nochmal Apache und Active Directory