Аўтэнтыфікацыя OpenVPN праз LDAP працуе, але праверка групы не праходзіць: дзе шукаць

Аўтэнтыфікацыя можа прайсці, а праверка групы адхіляе ўсіх. Разгледзьце блок Authorization, атрыбут членства і канчатковы пункт каталога па чарзе.

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

Разглядайце адмову як адказ пра аўтарызацыю

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

Шукайце самую ацэнку групы. Калі запыт пра групу не з’яўляецца зусім, блок аўтарызацыі не дасягаецца, што звычайна азначае, што дырэктыва стаіць па-за секцыяй, якая ёй валодае, або адсутнічае абавязковы параметр. Калі запыт з’яўляецца і вяртае пуста, канчатковы пункт або фільтр адказвае на іншае пытанне, чым тое, што вы мелі на ўвазе.

Вырашыце, ці жыве членства ў фільтры або ў блоку групы

Ёсць дзве падтрыманыя формы, і змешванне іх — гэта тое, як працоўная канфігурацыя перастае працаваць. Першая штурхае членства ў пошук карыстальніка, запытваючы атрыбут на аб’екце карыстальніка; другая пакідае пошук карыстальніка нязменным і дазваляе плагіну пасля гэтага знайсці аб’ект групы. Выберыце адну на разгортванне і запішыце, якую вы выбралі.

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

У такой форме ўсё вырашае фільтр, таму RequireGroup павінен быць false, інакш плагін пойдзе шукаць аб’ект групы, пра які фільтр ніколі не згадваў. Атрыбут у фільтры павінен існаваць на аб’екце карыстальніка і быць запоўнены, што не гарантавана, калі групы ўкладзены адна ў адну.

Другая форма трымае пошук простым і дадае пошук групы пасля яго. Аб’ект групы называецца яўна, і плагін параўноўвае карыстальніка з членамі, якія каталог вяртае для яго. У фільтры карыстальніка нічога не змяняецца, што робіць гэтую форму прасцейшай для аўдыту, калі групай кіруе іншая каманда.

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

Сляпое пляма агульная: простае параўнанне членства не разгортвае ўкладзеныя групы, таму запіс, доступ якога прыходзіць праз бацькоўскую групу, не праходзіць, пакуль кансоль усё яшчэ паказвае членства. Active Directory паказвае member на групе, іншыя схемы выкарыстоўваюць uniqueMember, а паказ на няправільны атрыбут вяртае пусты вынік замест памылкі.

Выберыце канчатковы пункт, які ўтрымлівае аб’ект групы

URL вырашае, які каталог запытвае плагін, а кантролер дамена на порце 389 адказвае толькі за свой уласны кантэкст імёнаў. Глабальны каталог на порце 3268 адказвае за ўвесь лес, толькі для чытання і з частковым наборам атрыбутаў. Калі запісы знаходзяцца ў адным дамене, а група VPN — у іншым, запыт да аднаго дамена можа знайсці карыстальніка і ўсё ж прапусціць членства. Гэта выпадак, калі перанос URL на порт каталога вырашае адмову, і гэта таксама выпадак, калі людзі абагульняюць занадта далёка.

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

Трымайце стан запісу і ахоп пошуку ў сваіх полях

Сцяг адключэння належыць фільтру, а не праверцы групы. У Active Directory гэта другі біт userAccountControl, і без гэтай умовы адключаны запіс з сапраўдным паролем аўтэнтыфікуецца, а затым не праходзіць на кроку групы, што выглядае як памылка аўтарызацыі. Ахоп пошуку належыць базаваму DN, бо пачатак з кораня дамена павольнейшы і можа супаставіць аб’екты па-за арганізацыйным падраздзяленнем, якое вы мелі на ўвазе.

Трымайце правы ўліковага запісу прывязкі вузкімі. Шырокія правы каталога ператвараюць няправільна настроены фільтр у паспяховы запыт і хаваюць дэфект, пакуль хтосьці не прааўдытуе запіс. Змяняйце членства ў самім каталозе, ніколі ў лакальным спісе выключэнняў, каб адключэння запісу было дастаткова для выдалення доступу. Калі групай кіруе іншая каманда, дамовіцеся пра атрыбут, які яны запаўняюць, перш чым пісаць на яго фільтр.

Дакажыце вынік трыма ўліковымі запісамі

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

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

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

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

Падобныя артыкулы