Seite wählen

NETWAYS Blog

Nochmal Apache und Active Directory

von | Feb 11, 2013 |

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.
Lies mehr von Lennart und triff unser Team

Apache 2: Authentifizierungsmethoden über Source-IP steuern

von | Nov 15, 2011 | , ,

Mit den normalen Bordmitteln des Apache2 ist es aktuell nicht möglich, zwei verschiedene Authentifizierungsmethoden zu verwenden. Gebrauchen kann man das aber beispielsweise sehr gut, wenn man einen webbasierten Dienst hat, welchen man für das interne Firmennetzwerk gegen LDAP und von extern über MOTP authentifizieren lassen möchte. Vorteil ist dabei, dass die nach außen offene Seite nicht durch Bruteforce-Attacken „gehackt“ werden kann.
Um diese Unterscheidung der Netze zu realisieren, wird eine iptables-Regel eingerichtet, welche alle Anfragen einer bestimmten Quelle auf einen anderen Port umleitet. Zusätzlich muss noch ein VHost angelegt werden, welcher auf diesem Port lauscht und die gewünschte Authentifizierung anbietet.
Ein kleines Praxisbeispiel:
Ich möchte, dass alle Anfragen, welche von extern kommen, gegen MOTP authentifiziert werden. Dafür lege ich einen VHost an, der auf Port 80 lauscht und MOTP als Authentifizierung anbietet.
Mein internes Netz, welches durch NAT nur eine IP (1.2.3.4) nach außen besitzt, soll sich gegen LDAP authentifizieren. Dafür lege ich ebenfalls einen VHost an, der auf Port 81 lauscht.
Nun leite ich den Verkehr, der von meinem Router des internen Netzes (IP 1.2.3.4) kommt auf Port 81 um. Da ich nicht will, dass alle Anfragen umgeleitet werden, weil ich noch mehrere Seiten auf meinem Server betreibe, habe ich zusätzlich den „LDAP-VHost“ auf die IP 127.0.0.2 gebunden.
Jetzt richte ich meine iptables-Regel ein:

iptables -t nat -A PREROUTING -s 1.2.3.4 -d 127.0.0.2 \
                -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 81

Nun werden alle Anfragen wie gewünscht umgeleitet. Mit iptables-save kann ich mir die aktuellen Einstellungen ausgeben lassen und sie später per init-Skript wieder mit aufnehmen. Somit sind die Einstellungen auch „rebootfest“. Wichtig sei noch zu erwähnen, dass pro VHost eine eigene, externe IP benötigt wird.

Trainings

Web Services

Events