Active Directory, pfSense und OpenVPN – manchmal liegt der (Denk-)Fehler im Detail

Als zentrale Benutzerverwaltung wurde ein Active Directory (AD) mit einer relativ einfachen Struktur eingerichtet: Gruppen für die verschiedenen Testnetze und somit auch VPN-Verbindungen, die einzelnen User-Accounts, spezielle Admin-Accounts und Accounts für das Binden an das AD. Ganz am Anfang wurde ein Test-Account erstellt, womit die geplanten Funktionstests später durchgeführt werden sollten:

• Anzeigename: testuser
• Loginname: testuser

Danach sollten die verschiedenen pfSensen, welche im IT-Labor-Netz für die weitere Trennung der unterschiedlichen Netze bzw. deren Internetanbindung sorgen, mit dem AD verbunden werden, sodass die VPN-User künftig darüber authentifiziert werden können. Da ich zuvor noch nie mit LDAP-Filter gearbeitet habe, musste ich mich erst einmal in das Thema einlesen. So schwer schien dies jedoch nicht zu sein: Bei Authentication containers den Ordner, wo alles zu finden ist, angeben, sprich:

„OU=CoCo-Testlab,DC=meineTestlabDomäne,DC=local“

Im Query angeben, wonach gefiltert werden soll, also:

„memberOf=CN=Testnetz1,OU=Gruppen,OU=CoCo-Testlab,DC=meineTestlabDomäne,DC=local“

und dann wurde auch schon getestet. Der Benutzer „testuser“ war zuerst Mitglied der Gruppe Testnetz1 und konnte die VPN-Verbindung erfolgreich aufbauen. Nach dem Entfernen aus der Gruppe war kein Zugriff mehr möglich. Auch diverse andere Kombinationen wurden ausprobiert und das Query weiter eingeschränkt: Alle Tests verliefen erfolgreich. Es funktionierte alles so, wie sein sollte. Die User-Anleitung mit Bildern und ausführlichen Erklärungen wurde geschrieben und einem Auszubildenden zur Verständnis-Kontrolle gegeben. Mit gutem Wissen und Gewissen konnte man also alles liveschalten.

Der Tag kam und schnell waren die ersten Meldungen der User da: „Ich kann mich nicht mit dem VPN verbinden“. Natürlich habe ich dann noch mal alle Einstellungen geprüft und auch mit dem Account „testuser“ diverse Tests durchgeführt. Es funktionierte alles, also warum nicht bei den Kollegen? Was war der Unterschied zwischen dem Testuser und den anderen Usern? Es hat zwar etwas Zeit in Anspruch genommen, aber die Ursache lag beim Attribut distinguishedName der jeweiligen User-Accounts. Die User-Accounts wurden zum Beispiel mit dem Anzeigenamen „Chantal Haidl“ und dem Loginnamen „ch-user“ erstellt. Dementsprechend hat das distinguisedName-Attribut den Wert „CN=Chantal Haidl,OU=User,OU=CoCo-Testlab,DC=meineTestlabDomäne,DC=local“. Im OpenVPN-Client hat man jedoch versucht, sich mit ch-user einzuloggen und so geprüft, ob der Account CN=ch-user,… Mitglied der Gruppe Testnetz1 ist. Es gab jedoch keinen Account mit dem Anzeigenamen ch-user, und dementsprechend ist die Authentifizierung fehlgeschlagen. Wenn man versucht hätte, sich direkt mit „Chantal Haidl“ einzuloggen, dann hätte alles einwandfrei funktioniert.

Und kann man aus der Geschichte etwas lernen? Für Funktionstests sollte man einen Account nehmen, bei dem der Anzeigename nicht identisch mit dem Loginnamen ist.  Hätte ich das am Anfang eingehalten, dann wäre der Start in die neue Testumgebung nicht so chaotisch geworden. Wie sagt man so schön: Im Nachhinein ist man immer schlauer.