Супастаўленне груп LDAP у ASA і DAP для групавой палітыкі VPN

Два асобныя запісы вырашаюць, якую групавую палітыку атрымае сесія AnyConnect, і яны знаходзяцца ў розных частках канфігурацыі з рознымі рэжымамі адмоваў. Карта атрыбутаў LDAP пераўтварае значэнне з каталога ў атрыбут аўтарызацыі ASA падчас аўтэнтыфікацыі; запіс DAP ацэньвае ўмовы пазней і можа дадаваць або перакрываць атрыбуты. Абодва могуць скончыцца адным і тым жа імем палітыкі, таму працоўны ўваход нічога не кажа пра тое, які механізм яго стварыў. Сэнс параўнання ў тым, каб выбраць адзін свядома, а не дазволіць другому ціха перакрыць першы.

Два механізмы, дзве кропкі рашэння

Выбар зводзіцца да трох пытанняў. Ці залежыць рашэнне ад аднаго значэння атрыбута каталога, ці патрэбна нешта большае за гэтае значэнне, і які механізм мае права перамагчы, калі абодва супадаюць?

Калі адзіны ўваход — гэта членства ў групе, карта атрыбутаў — драбнейшы інструмент і той, які прасцей аўдытаваць: адна карта, далучаная да аднаго сервера AAA, з адным радком на групу. Калі ж выбар павінен улічваць стан прылады, ідэнтычнасць канчатковай кропкі, другі атрыбут або часавае акно, у карты сканчаюцца ўваходы, і DAP становіцца механізмам, здольным выказаць правіла. Калі задзейнічаны абодва, даведайцеся пра прыярытэт у сваёй версіі перш чым пісаць любы з іх, бо сесія, якая супала з запісам DAP, можа не захаваць палітыку, якую вярнула карта. Усё астатняе — справаздачнасць.

Шлях карты атрыбутаў, у парадку канфігурацыі

Шлях карты пачынаецца з азначэння сервера AAA. Карта атрыбутаў павінна быць далучана да запісу сервера LDAP, які фактычна выкарыстоўвае профіль злучэння; карта, якая ёсць у працоўнай канфігурацыі, але не спасылаецца гэтым серверам, нічога не змяняе. Менавіта гэты радок далучэння робіць астатнюю канфігурацыю дзейнай. Кіраўніцтва па супастаўленні LDAP у ASA — гэта даведнік па сінтаксісе карты ў выпусках 9.x.

Унутры карты адзін аператар называе атрыбут каталога і атрыбут ASA, які ён сілкуе, а далейшыя аператары пераўтвараюць пэўныя значэнні. map-name memberOf Group-Policy з наступным map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly — гэта форма: левы бок — тое, што вярнуў каталог, правы — імя групавой палітыкі, якая мусіць ужо існаваць. Адрознівальнае імя і адлюстраванае імя палітыкі не ўзаемазамяняльныя, і амаль супадзенне ў любым з радкоў не выдае памылкі пры ўваходзе.

Тут кусаюцца дзве дэталі: memberOf вяртае кожную групу, да якой належыць уліковы запіс, таму карыстальнік у дзвюх супастаўленых групах дае карце два кандыдаты, а алфавітнае правіла ў даведніку — адзінае вырашэнне нічыі, на якое можна спадзявацца замест уласнага парадку прыярытэтаў. Несупастаўленае значэнне не дае нічога і ціха вяртае да палітыкі па змаўчанні профілю.

Шлях DAP і што ён дадае

DAP ацэньвае ўмовы і ўжывае атрыбуты паверх выніку AAA. Запіс нясе прыярытэт, дзеянне і набор умоў; запісы ацэньваюцца ў парадку прыярытэту, а дзеянне вырашае, ці ацэнка працягваецца або спыняецца. Гэта іншая мадэль выканання, чым пошук значэння, і менавіта таму яна можа выказаць правілы, якіх карта не можа.

DAP дадае ўваходы. Умовы могуць спасылацца на атрыбуты каталога, атрыбуты канчатковай кропкі і стан прылады, а адпаведны запіс можа несці спісы ACL або URL, а таксама фільтры для гэтай сесіі. Таму правіла накшталт «супрацоўнікі падтрымкі на кіраваным ноўтбуку атрымліваюць палітыку толькі для чытання, а тыя ж супрацоўнікі на некіраванай прыладзе — абмежаваную» можна выказаць у DAP, але не ў карце атрыбутаў. У карты роўна адзін уваход: значэнне, якое каталог вярнуў для названага вамі атрыбута.

DAP таксама дадае другое месца для пошуку, калі сесія трапляе ў няправільную палітыку. Запіс, што супадае з дзеяннем «працягваць», не спыняе ацэнку, і наступны запіс можа яшчэ змяніць вынік, таму тое, што вы бачыце, — гэта здабытак паслядоўнасці, а не аднаго пошуку. Чытайце нумары прыярытэтаў па парадку і памятайце, што працу можа выконваць рэзервовы запіс. Карта ж не мае паслядоўнасці: адзін атрыбут, адно значэнне, адзін адказ.

Дзе яны разыходзяцца

Прыярытэт — гэта частка, якая ламае праекты. Калі сесія супадае і з запісам карты, і з запісам DAP, вынік залежыць ад версіі і ад дзеяння запісу, таму праверце гэта на сваёй ASA, замест таго каб меркаваць, што вынік належыць аднаму з механізмаў.

Тры рэжымы адмоваў тлумачаць большую частку блытаніны. Карта, якая вызначана, але ніколі не далучана да тэга сервера, што выкарыстоўвае профіль, дае палітыку па змаўчанні без памылкі дзе-небудзь. Радок умовы DAP, які адрозніваецца ад значэння каталога рэгістрам або прабеламі, ніколі не супадае, і рэзервовы запіс ціха ўжываецца. А групавая палітыка, якой яшчэ няма, прымаецца картай, бо карта вяртае толькі імя, таму сесія не атрымлівае патрэбных дазволаў, і ў журнале няма нічога, што паказвала б на адсутны аб'ект. Праверце ўсе тры, перш чым кранаць членства ў групах.

Чытанне доказаў з жывой сесіі

Чытайце адказ з новай сесіі, а не з канфігурацыі. show vpn-sessiondb detail anyconnect filter name jdoe друкуе групавую палітыку, якую сесія фактычна атрымала, а show running-config ldap attribute-map пацвярджае, якія значэнні магла вярнуць карта. На баку каталога test aaa-server authentication LDAP-AD username jdoe password <password> паказвае атрыбуты, якія ASA атрымала ў адказ, а debug ldap 255 паказвае абмен, калі тэст разыходзіцца з вашымі чаканнямі.

Затым узгадніце чатыры запісы пісьмова: значэнне каталога, наладжаная карта або ўмова DAP, лакальная групавая палітыка і рэсурс, да якога карыстальнік фактычна дабраўся. Калі першыя тры сыходзяцца, а чацвёрты не, праблема ў целе палітыкі, а не ў выбары. Калі сесія паказвае правільнае імя палітыкі, але няправільны ACL, цалкам спыніце глядзець на LDAP. Змяняйце адзін запіс за раз і пераправярайце новую сесію, бо перападключаная сесія — адзіны доказ, які адлюстроўвае канфігурацыю, якую вы толькі што напісалі.