Mapowanie grup LDAP w ASA a DAP dla polityki grup VPN

Dwa osobne rekordy decydują, jaką politykę grupy otrzymuje sesja AnyConnect, i znajdują się w różnych częściach konfiguracji, z różnymi trybami awarii. Mapa atrybutów LDAP tłumaczy wartość z katalogu na atrybut autoryzacji ASA podczas uwierzytelniania; rekord DAP ocenia warunki później i może dodawać lub nadpisywać atrybuty. Oba mogą zakończyć się tą samą nazwą polityki, więc udane logowanie nic nie mówi o tym, który mechanizm je wytworzył. Sens porównania polega na świadomym wyborze jednego, zamiast pozwalania drugiemu na ciche nadpisanie pierwszego.

Dwa mechanizmy, dwa punkty decyzyjne

Wybór sprowadza się do trzech pytań. Czy decyzja zależy od jednej wartości atrybutu z katalogu, czy potrzebuje czegoś więcej niż ta wartość, i który mechanizm może wygrać, gdy oba pasują?

Jeśli jedynym wejściem jest przynależność do grupy, mapa atrybutów jest mniejszym narzędziem i łatwiejszym do audytu: jedna mapa, przypięta do jednego serwera AAA, z jednym wierszem na grupę. Jeśli wybór musi uwzględniać stan urządzenia, tożsamość punktu końcowego, drugi atrybut lub okno czasowe, wejścia mapy się kończą i DAP jest mechanizmem, który potrafi wyrazić regułę. Jeśli używane są oba, poznaj pierwszeństwo w swojej wersji, zanim napiszesz którykolwiek z nich, ponieważ sesja pasująca do rekordu DAP może nie zachować polityki zwróconej przez mapę. Cała reszta to księgowość.

Ścieżka mapy atrybutów, w kolejności konfiguracji

Ścieżka mapy zaczyna się przy definicji serwera AAA. Mapa atrybutów musi być przypięta do wpisu serwera LDAP, którego profil połączenia faktycznie używa; mapa istniejąca w działającej konfiguracji, ale nie wskazana przez ten serwer, niczego nie zmienia. Właśnie ten wiersz przypięcia ożywia resztę konfiguracji. przewodnik po mapowaniu LDAP w ASA jest referencją dla składni mapy w wersjach 9.x.

Wewnątrz mapy jedna instrukcja nazywa atrybut katalogu i atrybut ASA, który zasila, a kolejne instrukcje tłumaczą konkretne wartości. map-name memberOf Group-Policy po którym następuje map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly to kształt: lewa strona to to, co zwrócił katalog, prawa strona to nazwa polityki grupy, która musi już istnieć. Nazwa wyróżniająca i nazwa wyświetlana polityki nie są wymienne, a prawie-dopasowanie w którymkolwiek z ciągów nie daje żadnego błędu przy logowaniu.

Dwa szczegóły tu gryzą: memberOf zwraca każdą grupę, do której należy konto, więc użytkownik w dwóch zmapowanych grupach daje mapie dwie wartości kandydujące, a reguła alfabetyczna z przewodnika jest jedynym rozstrzygnięciem remisu, na którym można polegać zamiast własnej kolejności priorytetów. Niezmapowana wartość nie daje nic, co po cichu wraca do domyślnej polityki profilu.

Ścieżka DAP i co ona dodaje

DAP ocenia warunki i stosuje atrybuty na wierzchu wyniku AAA. Rekord niesie priorytet, akcję i zestaw warunków; rekordy są oceniane w kolejności priorytetów, a akcja decyduje, czy ocena trwa dalej, czy się zatrzymuje. To inny model wykonania niż wyszukiwanie wartości i właśnie dlatego potrafi wyrazić reguły, których mapa nie potrafi.

To, co DAP dodaje, to wejścia. Warunki mogą odwoływać się do atrybutów katalogu, atrybutów punktu końcowego i stanu urządzenia, a pasujący rekord może nieść ACL, listy URL lub filtry dla tej sesji. Dzięki temu reguła, że personel pomocy na zarządzanym laptopie dostaje politykę tylko do odczytu, a ten sam personel na niezarządzanym urządzeniu politykę ograniczoną, jest wyrażalna w DAP, a nie w mapie atrybutów. Mapa ma dokładnie jedno wejście: wartość, którą katalog zwrócił dla wskazanego atrybutu.

DAP dodaje też drugie miejsce do sprawdzenia, gdy sesja trafi do niewłaściwej polityki. Rekord pasujący z akcją kontynuowania nie kończy oceny, a późniejszy rekord wciąż może zmienić wynik, więc to, co obserwujesz, jest produktem sekwencji, a nie pojedynczego wyszukiwania. Czytaj numery priorytetów po kolei i pamiętaj, że to rekord zapasowy może wykonywać pracę. Mapa natomiast nie ma sekwencji: jeden atrybut, jedna wartość, jedna odpowiedź.

Gdzie oba się nie zgadzają

Pierwszeństwo to część, która psuje projekty. Gdy sesja pasuje zarówno do wpisu mapy, jak i do rekordu DAP, wynik zależy od wersji i od akcji rekordu, więc sprawdź to na własnym ASA, zamiast zakładać, że wynik należy do jednego z mechanizmów.

Trzy tryby awarii wyjaśniają większość zamieszania. Mapa zdefiniowana, ale nigdy nie przypięta do znacznika serwera używanego przez profil, daje politykę domyślną bez żadnego błędu nigdzie. Ciąg warunku DAP różniący się od wartości katalogu wielkością liter lub spacjami nigdy nie pasuje, a rekord zapasowy stosuje się po cichu. A polityka grupy, która jeszcze nie istnieje, jest akceptowana przez mapę, ponieważ mapa zwraca tylko nazwę, więc sesja nie dostaje żadnych z zamierzonych uprawnień i w logu nie ma nic, co wskazywałoby na brakujący obiekt. Sprawdź wszystkie trzy, zanim dotkniesz przynależności do grup.

Odczyt dowodów z żywej sesji

Czytaj odpowiedź z nowej sesji, a nie z konfiguracji. show vpn-sessiondb detail anyconnect filter name jdoe wypisuje politykę grupy, którą sesja faktycznie otrzymała, a show running-config ldap attribute-map potwierdza, jakie wartości mapa mogła zwrócić. Po stronie katalogu test aaa-server authentication LDAP-AD username jdoe password <password> pokazuje atrybuty, które ASA otrzymała z powrotem, a debug ldap 255 pokazuje wymianę, gdy test nie zgadza się z tym, czego oczekiwałeś.

Następnie uzgodnij cztery rekordy na piśmie: wartość z katalogu, skonfigurowaną mapę lub warunek DAP, lokalną politykę grupy i zasób, do którego użytkownik faktycznie dotarł. Jeśli pierwsze trzy się zgadzają, a czwarty nie, problem jest w treści polityki, a nie w wyborze. Jeśli sesja pokazuje właściwą nazwę polityki, ale zły ACL, przestań całkowicie patrzeć na LDAP. Zmieniaj jeden rekord naraz i sprawdzaj nową sesję, ponieważ ponownie podłączona sesja jest jedynym dowodem odzwierciedlającym konfigurację, którą właśnie napisałeś.