Zwei getrennte Datensätze entscheiden, welche Gruppenrichtlinie eine AnyConnect-Sitzung erhält, und sie liegen an verschiedenen Stellen der Konfiguration mit unterschiedlichen Fehlermodi. Eine LDAP-Attributzuordnung übersetzt während der Authentifizierung einen Verzeichniswert in ein ASA-Autorisierungsattribut; ein DAP-Datensatz wertet danach Bedingungen aus und kann Attribute hinzufügen oder überschreiben. Beide können beim selben Richtliniennamen enden, daher sagt ein funktionierender Login nichts darüber aus, welcher Mechanismus ihn erzeugt hat. Der Sinn des Vergleichs ist, bewusst einen zu wählen, statt den zweiten den ersten still überstimmen zu lassen.

Zwei Mechanismen, zwei Entscheidungspunkte

Die Wahl läuft auf drei Fragen hinaus. Hängt die Entscheidung von einem einzigen Verzeichnisattributwert ab, braucht sie mehr als diesen Wert, und welcher Mechanismus darf gewinnen, wenn beide passen?

Ist die Gruppenzugehörigkeit die einzige Eingabe, ist die Attributzuordnung das kleinere Werkzeug und das leichter zu prüfende: eine Zuordnung, an einen AAA-Server gebunden, mit einer Zeile pro Gruppe. Muss die Auswahl Posture, Endpoint-Identität, ein zweites Attribut oder ein Zeitfenster berücksichtigen, gehen der Zuordnung die Eingaben aus, und DAP ist der Mechanismus, der die Regel ausdrücken kann. Sind beide im Spiel, klären Sie die Vorrangregel in Ihrer Version, bevor Sie eines von beiden schreiben, denn eine Sitzung, die auf einen DAP-Datensatz passt, behält möglicherweise nicht die Richtlinie, die die Zuordnung geliefert hat. Alles andere ist Buchhaltung.

Der Weg der Attributzuordnung, in Konfigurationsreihenfolge

Der Weg der Zuordnung beginnt bei der AAA-Serverdefinition. Die Attributzuordnung muss an den LDAP-Servereintrag gebunden sein, den das Verbindungsprofil tatsächlich nutzt; eine Zuordnung, die in der laufenden Konfiguration existiert, aber von diesem Server nicht referenziert wird, ändert nichts. Genau diese Bindungszeile macht den Rest der Konfiguration wirksam. Der ASA-LDAP-Zuordnungsleitfaden ist die Referenz für die Zuordnungssyntax in den Versionen 9.x.

Innerhalb der Zuordnung benennt eine Anweisung das Verzeichnisattribut und das ASA-Attribut, das es speist, weitere Anweisungen übersetzen konkrete Werte. map-name memberOf Group-Policy gefolgt von map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly ist die Form: links steht, was das Verzeichnis zurückgegeben hat, rechts der Name einer Gruppenrichtlinie, die bereits existieren muss. Ein Distinguished Name und ein Anzeigename einer Richtlinie sind nicht austauschbar, und ein Fast-Treffer in einer der beiden Zeichenketten erzeugt beim Login keinen Fehler.

Zwei Details beißen hier: memberOf liefert jede Gruppe, zu der das Konto gehört, sodass ein Benutzer in zwei zugeordneten Gruppen der Zuordnung zwei Kandidatenwerte gibt, und die alphabetische Regel im Leitfaden ist der einzige Gleichstandsentscheid, auf den Sie sich verlassen können, statt auf Ihre eigene Prioritätsreihenfolge. Ein nicht zugeordneter Wert liefert gar nichts, was still auf die Standardrichtlinie des Profils zurückfällt.

Der DAP-Weg und was er hinzufügt

DAP wertet Bedingungen aus und wendet Attribute zusätzlich zum AAA-Ergebnis an. Ein Datensatz trägt eine Priorität, eine Aktion und eine Menge von Bedingungen; Datensätze werden in Prioritätsreihenfolge ausgewertet, und die Aktion entscheidet, ob die Auswertung weiterläuft oder stoppt. Das ist ein anderes Ausführungsmodell als ein Wertnachschlagen, und genau deshalb kann es Regeln ausdrücken, die die Zuordnung nicht kann.

Was DAP hinzufügt, sind Eingaben. Bedingungen können Verzeichnisattribute, Endpoint-Attribute und Posture-Zustand referenzieren, und ein passender Datensatz kann ACLs, URL-Listen oder Filter für diese Sitzung tragen. Eine Regel wie: Support-Mitarbeiter auf einem verwalteten Laptop erhalten die Nur-Lese-Richtlinie, dieselben Mitarbeiter auf einem nicht verwalteten Gerät eine eingeschränkte, ist daher in DAP ausdrückbar und nicht in einer Attributzuordnung. Die Zuordnung hat genau eine Eingabe: den Wert, den das Verzeichnis für das von Ihnen benannte Attribut zurückgegeben hat.

DAP fügt außerdem eine zweite Stelle hinzu, an der man nachsieht, wenn eine Sitzung in der falschen Richtlinie landet. Ein Datensatz, der mit der Aktion Fortsetzen passt, beendet die Auswertung nicht, und ein späterer Datensatz kann das Ergebnis noch ändern, sodass das Beobachtete das Produkt einer Sequenz und nicht eines einzelnen Nachschlagens ist. Lesen Sie die Prioritätsnummern der Reihe nach, und denken Sie daran, dass ein Fallback-Datensatz derjenige sein kann, der die Arbeit macht. Die Zuordnung hat dagegen keine Sequenz: ein Attribut, ein Wert, eine Antwort.

Wo die beiden sich widersprechen

Die Vorrangregel ist der Teil, der Designs zerbricht. Wenn eine Sitzung sowohl auf einen Zuordnungseintrag als auch auf einen DAP-Datensatz passt, hängt das Ergebnis von der Version und von der Aktion des Datensatzes ab, also prüfen Sie es auf Ihrer eigenen ASA, statt anzunehmen, dass einer der Mechanismen das Ergebnis besitzt.

Drei Fehlermodi erklären den größten Teil der Verwirrung. Eine Zuordnung, die definiert, aber nie an das Server-Tag gebunden wurde, das das Profil nutzt, erzeugt die Standardrichtlinie ohne irgendeinen Fehler. Eine DAP-Bedingungszeichenkette, die sich vom Verzeichniswert in Groß- und Kleinschreibung oder Leerzeichen unterscheidet, passt nie, und der Fallback-Datensatz greift still. Und eine Gruppenrichtlinie, die noch nicht existiert, wird von der Zuordnung akzeptiert, weil die Zuordnung nur einen Namen zurückgibt, sodass die Sitzung keine der beabsichtigten Berechtigungen erhält und im Protokoll nichts auf das fehlende Objekt zeigt. Prüfen Sie alle drei, bevor Sie die Gruppenzugehörigkeit anfassen.

Die Belege aus einer laufenden Sitzung ablesen

Lesen Sie die Antwort aus einer frischen Sitzung ab, nicht aus der Konfiguration. show vpn-sessiondb detail anyconnect filter name jdoe gibt die Gruppenrichtlinie aus, die die Sitzung tatsächlich erhalten hat, und show running-config ldap attribute-map bestätigt, welche Werte die Zuordnung hätte zurückgeben können. Auf der Verzeichnisseite zeigt test aaa-server authentication LDAP-AD username jdoe password <password> die Attribute, die die ASA zurückbekommen hat, und debug ldap 255 zeigt den Austausch, wenn der Test nicht zu Ihrer Erwartung passt.

Dann gleichen Sie vier Datensätze schriftlich ab: den Verzeichniswert, die konfigurierte Zuordnung oder DAP-Bedingung, die lokale Gruppenrichtlinie und die Ressource, die der Benutzer tatsächlich erreichen konnte. Wenn die ersten drei zusammenpassen und die vierte nicht, liegt das Problem im Richtlinienkörper und nicht in der Auswahl. Wenn die Sitzung den richtigen Richtliniennamen, aber die falsche ACL zeigt, hören Sie ganz auf, auf LDAP zu schauen. Ändern Sie jeweils einen Datensatz und prüfen Sie eine neue Sitzung, denn eine neu verbundene Sitzung ist der einzige Beleg, der die Konfiguration widerspiegelt, die Sie gerade geschrieben haben.

Ähnliche Artikel