OpenVPN-LDAP-Authentifizierung funktioniert, die Gruppenprüfung scheitert: wo man nachsieht

Die Authentifizierung kann gelingen, während die Gruppenprüfung alle ablehnt. Gehen Sie den Authorization-Block, das Mitgliedschaftsattribut und den Verzeichnis-Endpunkt der Reihe nach durch.

Die Zugangsdaten werden akzeptiert, der Tunnel beginnt sich aufzubauen, und dann scheitert die Sitzung mit einer Meldung über die Gruppe statt über das Passwort. Diese Kombination verortet den Fehler in der zweiten Hälfte der Arbeit des LDAP-Plugins: Bindung und Passwortprüfung waren erfolgreich, die darauffolgende Mitgliedschaftsentscheidung nicht. Beide Hälften lesen aus demselben Konfigurationsblock, weshalb eine Korrektur an einer Stelle die andere unberührt lassen kann. Beginnen Sie bei der Logzeile, die den Schritt benennt, nicht bei dem Konto, mit dem Sie zufällig testen.

Behandeln Sie die Ablehnung als Autorisierungsantwort

Das Plugin führt eine Dienstbindung aus, sucht das Konto, prüft das übergebene Passwort und fragt dann, ob dieses Konto zu einer erlaubten Gruppe gehört. Das sind vier getrennte Vorgänge, und nur der letzte betrifft Gruppen. Eine Ablehnung nach erfolgreicher Bindung sagt daher nichts über das Passwort aus, selbst wenn der Client einen allgemeinen Authentifizierungsfehler anzeigt. Die Protokollebene des Plugins vor der Konfigurationsänderung anzuheben ist das, was die vier in der Ausgabe trennt.

Suchen Sie die Gruppenauswertung selbst. Wenn gar keine Gruppenabfrage erscheint, wird der Autorisierungsblock nicht erreicht, was meist bedeutet, dass eine Direktive außerhalb des Blocks steht, dem sie gehört, oder eine erforderliche Option fehlt. Wenn die Abfrage erscheint und nichts zurückgibt, beantwortet der Endpunkt oder der Filter eine andere Frage als die, die Sie gemeint haben.

Entscheiden Sie, ob die Mitgliedschaft im Filter oder in einem Gruppenblock lebt

Es gibt zwei unterstützte Formen, und sie zu mischen ist der Weg, auf dem eine funktionierende Konfiguration aufhört zu funktionieren. Die erste schiebt die Mitgliedschaft in die Benutzersuche, indem sie ein Attribut am Benutzerobjekt abfragt; die zweite lässt die Benutzersuche unangetastet und lässt das Plugin danach das Gruppenobjekt nachschlagen. Wählen Sie eine pro Bereitstellung und notieren Sie, welche Sie gewählt haben.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Bei dieser Form entscheidet der Filter alles, also muss RequireGroup false sein, sonst sucht das Plugin ein Gruppenobjekt, das der Filter nie erwähnt hat. Das Attribut im Filter muss am Benutzerobjekt existieren und gefüllt sein, was nicht garantiert ist, sobald Gruppen verschachtelt sind.

Die andere Form hält die Suche einfach und fügt danach eine Gruppensuche hinzu. Das Gruppenobjekt wird ausdrücklich benannt, und das Plugin vergleicht den Benutzer mit den Mitgliedern, die das Verzeichnis dafür zurückgibt. Am Benutzerfilter ändert sich nichts, was diese Form leichter prüfbar macht, wenn ein anderes Team die Gruppe verwaltet.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

Der blinde Fleck ist gemeinsam: ein einfacher Mitgliedschaftsvergleich löst verschachtelte Gruppen nicht auf, daher scheitert ein Konto, dessen Zugang über eine übergeordnete Gruppe kommt, während die Konsole die Mitgliedschaft weiterhin anzeigt. Active Directory stellt member an der Gruppe bereit, andere Schemata verwenden uniqueMember, und auf das falsche Attribut zu zeigen liefert ein leeres Ergebnis statt eines Fehlers.

Wählen Sie einen Endpunkt, der das Gruppenobjekt enthält

Die URL entscheidet, welches Verzeichnis das Plugin fragt, und ein Domänencontroller auf Port 389 antwortet nur für seinen eigenen Namenskontext. Ein globaler Katalog auf Port 3268 antwortet für die gesamte Gesamtstruktur, schreibgeschützt und mit einem partiellen Attributesatz. Wenn die Konten in einer Domäne liegen und die VPN-Gruppe in einer anderen, kann eine Abfrage gegen eine Domäne den Benutzer finden und die Mitgliedschaft trotzdem verfehlen. Das ist der Fall, in dem der Umzug der URL auf den Katalogport die Ablehnung löst, und es ist auch der Fall, in dem Leute zu weit verallgemeinern.

Der partielle Attributesatz ist die Grenze: auf ein Attribut, das der Katalog nicht enthält, lässt sich nicht filtern, daher kann dieselbe Änderung eine Bereitstellung zum Laufen bringen und eine andere nichts zurückgeben lassen. Bestätigen Sie, was der Endpunkt für den echten Benutzer und die echte Gruppe tatsächlich zurückgibt, bevor Sie den Block umschreiben. Verweise und TLS sind wieder eigene Themen, denn einem Verweis muss gefolgt werden, und ein Endpunkt, der TLS verlangt, braucht die passenden Vertrauensdateien.

Halten Sie Kontostatus und Suchbereich in ihren eigenen Feldern

Das Deaktiviert-Flag gehört in den Filter, nicht in die Gruppenprüfung. In Active Directory ist es das zweite Bit von userAccountControl, und ohne diese Bedingung authentifiziert sich ein deaktiviertes Konto mit gültigem Passwort und scheitert dann beim Gruppenschritt, was wie ein Autorisierungsfehler aussieht. Der Suchbereich gehört in die Basis-DN, weil der Start an der Domänenwurzel langsamer ist und Objekte außerhalb der Organisationseinheit treffen kann, die Sie abdecken wollten.

Halten Sie auch die Rechte des Bind-Kontos eng. Weitreichende Verzeichnisrechte machen aus einem falsch konfigurierten Filter eine erfolgreiche Abfrage und verstecken den Fehler, bis jemand das Konto prüft. Ändern Sie die Mitgliedschaft im Verzeichnis selbst, nie in einer lokalen Ausnahmeliste, damit das Deaktivieren des Kontos ausreicht, um den Zugang zu entfernen. Wenn ein anderes Team die Gruppe verwaltet, verständigen Sie sich auf das Attribut, das dort gefüllt wird, bevor Sie einen Filter darauf schreiben.

Beweisen Sie das Ergebnis mit drei Konten

Führen Sie die Konfiguration gegen drei Identitäten aus: ein erlaubtes Mitglied, ein gültiges Konto außerhalb der Gruppe und ein Konto, das deaktiviert wurde. Wenn alle drei abgelehnt werden, sind Bindung oder Gruppenabfrage kaputt; wenn alle drei akzeptiert werden, wird überhaupt keine Gruppenbedingung angewandt. Ein gemischtes Ergebnis ist der einzige Ausgang, der beweist, dass die Konfiguration die Fälle unterscheidet, die Ihnen wichtig sind.

Lesen Sie dieselben drei Antworten direkt aus dem Verzeichnis, bevor Sie dem Plugin die Schuld geben. Die erste Abfrage zeigt das Gruppenattribut, von dem der Filter abhängt, und die zweite zeigt den Wert der Kontosteuerung. Setzen Sie Ihre eigene Basis-DN, Ihr Konto und Ihren Endpunkt ein:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Ein Benutzer, dessen memberOf leer zurückkommt, ist ein Verzeichnisfakt, kein Plugin-Fehler, und ein Konto, das sich nach der Deaktivierung noch authentifiziert, heißt, dass dem Filter die Bedingung der Kontosteuerung fehlt. Beheben Sie zuerst diesen Nachweis und führen Sie dann den Drei-Konten-Test erneut aus. Legen Sie die Logzeile, die den fehlgeschlagenen Schritt benannt hat, neben die Konfigurationsänderung, damit die nächste Person Autorisierung von Authentifizierung trennen kann, ohne die Suche zu wiederholen.

Ähnliche Artikel