Сертыфікат VPN не абараняе звяно LDAP

Уваход праз VPN, які правярае ўліковыя даныя па каталогу, уключае два асобныя сеткавыя злучэнні. Злучэнне карыстальніка са шлюзам абаронена ўласным сертыфікатам VPN і наладамі пратаколу. Злучэнне шлюза з каталогам — гэта іншая сесія з уласнымі наладамі TLS, уласным сховішчам даверу і ўласнымі рэжымамі адмовы. Нішто ў першым не гарантуе нічога ў другім.

Менавіта гэтая асіметрыя — механізм, які стаіць за ўваходам, што выглядае шыфраваным і ўсё ж адпраўляе пароль прывязкі адкрытым тэкстам.

Два злучэнні, два рашэнні пра давер

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

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

StartTLS і LDAPS: выбар з разуменнем

StartTLS адкрываецца як звычайны LDAP і паляпшаецца на месцы, звычайна на порце 389. LDAPS пачынае TLS разам са злучэннем, звычайна на 636. Абодва варыянты законныя, і адаптар павінен адпавядаць таму, што прапануе каталог. Патрабаваць StartTLS — гэта не тое ж, што паспрабаваць яго і працягнуць, калі паляпшэнне не ўдалося, і менавіта ў гэтай розніцы можа выцячы пароль прывязкі. Наладзьце строгі рэжым і не дазваляйце неабаронены запасны шлях для прывязкі з паролем.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

Сцяг -ZZ — гэта ўся сутнасць: запыт не ўдаецца, а не працягваецца моўчкі без паляпшэння. Імёны і ўліковыя запісы ў гэтым радку — прыклады. Дакументацыя OpenLDAP па TLS апісвае налады даверу, што за гэтым стаяць.

Якое сховішча даверу чытае кліент LDAP?

Кліенцкая бібліятэка OpenLDAP чытае ўласную канфігурацыю даверу — ці з сістэмнага файла, ці з налады пэўнага плагіна. Дырэктыва CA у VPN датычыцца аднарангавых вузлоў VPN і не сведчыць, што бібліятэка LDAP чытае той жа файл. Выкарыстоўвайце імя хоста каталога, якое сертыфікат сапраўды пакрывае, плюс ланцужок выпуску, якому давярае бібліятэка. У Active Directory разгортвайце сертыфікат службы каталога з належным прымяненнем для аўтэнтыфікацыі сервера, а не рабіце высновы з адлюстраванага імя.

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

Уліковы запіс прывязкі застаецца асобнай праблемай

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

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

Два злучэнні, два ўладальнікі, дзве даты абнаўлення. Менавіта адасобленасць іх у дакументацыі трымае ўваход сумленным.