Things done wrong: Benutzermanagement

Homer Simpson
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 …)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

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

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory

Heute soll sich dieser Blogeintrag also um Single Sign On im Apache- und Active Directory-Umfeld drehen. Ziel ist es, sich an einem Webserver per Kerberos-Ticket zu authentifizieren und nachgelagert zu prüfen, ob der Benutzer sich ebenfalls in der Gruppe befindet, dessen Mitglieder Zugriff auf die Wibsite erhalten dürfen.
Zuerst muss ein Benutzer im Active Directory angelegt werden. Danach erzeugen wir auf unserem Domain Controller einen Schlüssel und fügen diesem Benutzer eine PrincipalName hinzu. Also Verschlüsselung wählen wir RC4-HMAC, da dies von Windows XP unterstützt wird. Die ab Windows Server 2008 hinzugekommenden Verschlüsselingen auf AES basierend werden erst von Windows Vista und Windows 7 unterstützt.
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 \
In unserem Beispiel haben wir den Benutzer www angelegt. Unsere NS-Domäne lauetet netways.de und unser Kerberos-Realm NETWAYS.DE. Mit dem Kommando ktpass weisen wir nun diesem Benutzer über die Option -mapusr und -princ den PrincipalName HTTP/www.netways.de@NETWAYS.DE zu. Der Schlüssel erhält das Passwort login123 mit +rndpass kann man diesen auch zufällig erzeugen lassen. Erzeugt man den Schlüssel jedoch zufällig, ist es dann aber leider nicht möglich den Schlüssel auf dem Linux-Serverauf Korrektheit zu überprüfen.
Nachdem wir nun den Schlüssel erzeugt haben, kopieren wir die Datei apache2.keytab auf sicherem Wege auf unseren Webserver.
Die Kerberos-Client-Konfiguration /etc/krb5.keytab auf unserem Linux-Server sieht wie folgt aus:
[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
Unsere apache2.keytab können wir nun mit kinit auf Korrektheit prüfen.
kinit -t /etc/apache2/apache2.keytab HTTP/www.netways.de
Der PrincipalName kann im Vorfeld auch schon mit klist ermittelt werden.
klist -t -k /etc/apache2/apache2.keytab
Für den Apache Webserver werden noch drei zusätzliche Module benötigt. Die Module mod_ldap und mod_authnz_ldap, im Gegensatz zu mod_auth_kerb sind diese beiden Module Bestandteil vom Apache-Paket. Das Module mod_auth_kerb muss nötigenfalls selbst übersetzt werden.
a2enmod auth_kerb
a2enmod ldap
a2enmod authnz_ldap
Für unser Beispiel  benötigen wir noch einen Active Directory Benutzer ads, um auf den LDAP-Server des DC zugreifen zu können. Außerdem die Gruppe ApacheAcces, deren Mitglieder auf unsere Website zu greifen dürfen.
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
Zu Abschuss nicht vergessen den Browser für den SSO-Zugriff zu konfigurieren. Beim Firefox geschieht dies durch den Aufruf der URL about:config.
network.negotiate-auth.trusted-uris     .netways.de

Weitere Artikel zum Thema:
LDAP-Filter zur Autorisierung bei rekursiven Gruppen
Nochmal Apache und Active Directory

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.