Nochmal Apache und Active Directory

von Lennart Betz | Feb 11, 2013 | NETWAYS

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

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.

Lies mehr von Lennart und triff unser Team

Weekly Snap: Update on Updian, SSO in Apache and Perl compilation with PAR::Packer

von Amanda Mailer | Okt 31, 2011 | WeeklySnap

24 – 28 October looked at the latest version of Updian and shared tips for compiling Perl as well as SSO in Apache.
To begin, Ronny brought us up to scratch on Updian’s latest release. As previously introduced, Updian is a simple update engine for Debian. Compared to v0.2, the new v0.3 has a slicker interface, with sorted lists and generally clearer display of large lists and views. SSH connections can now be specified where the standard port 22 doesn’t apply, and different ports can be used on different servers. To top it off, users of ‘debian-goodies’ can try ’checkrestart’ for a colour-coded view of services for libs that need to be restarted.
Gunnar then introduced the handy PAR::Packer Perl module that compiles Perl scripts with their dependencies linked into a single binary. Platform independent, he showed how to install PAR::Packer on Windows with the help of CPAN and Strawberry Perl. For more info, he recommended http://search.cpan.org/dist/PAR/lib/PAR/Tutorial.pod
Last but not least, Lennart showed how to use ‘single sign on’ (SSO) in Apache with group-specific authentication in an Active Directory environment. Put otherwise, he set out to authenticate a web server via Kerberos ticket and check downstream, whether a user is in a group whose members may access a website. He began by creating a user in Active Directory, and generating a key on the domain controller to which the user is given a principal name. Then he copied the apache2.keytab file to the web server and used kinit to check the apache2.keytab for accuracy, and klist to determine the principal name in advance. Finally, he loaded mod_ldap, mod_authnz_ldap and mod_auth_kerb and configured the browser for SSO access.

SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory

von Lennart Betz | Okt 27, 2011 | Technology

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

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.

Lies mehr von Lennart und triff unser Team