VPN сертификат не штити део LDAP

Пријава преко VPN-а која проверава акредитиве према директоријуму укључује две одвојене мрежне везе. Веза корисника са пролазом заштићена је сопственим сертификатом VPN-а и конфигурацијом протокола. Веза пролаза са директоријумом је друга сесија са сопственим TLS подешавањима, сопственим складиштем поверења и сопственим режимима отказа. Ништа у првој не гарантује ништа у другој.

Управо та асиметрија је механизам иза пријаве која изгледа шифровано, а ипак шаље лозинку за bind отвореним текстом.

Две везе, две одлуке о поверењу

Спољашња сесија је оно што корисник види: сертификат везан за име домаћина VPN-а, који је клијент проверио и који носи размену аутентификације. Унутрашња сесија припада клијенту директоријума унутар пролаза, који отвара сопствену везу и или преговара о TLS-у, или не. Свака страна проверава саговорника са којим разговара, користећи материјал из друге конфигурационе датотеке. Погрешно конфигурисани унутрашњи део остаје невидљив са корисникове стране, јер спољашњи део ради тачно онако како је предвиђено.

Зато је отказ тих, а не гласан. Пролаз који никада не проверава сертификат директоријума и даље исправно аутентификује кориснике; само их аутентификује преко канала који није проверио.

StartTLS и LDAPS, изабрани свесно

StartTLS се отвара као обичан LDAP и надграђује на месту, обично на порту 389. LDAPS покреће TLS заједно са везом, обично на 636. Оба су легитимна и адаптер мора да одговара ономе што директоријум нуди. Захтевати StartTLS је другачије од тога да га пробате и наставите када надградња не успе, и управо у тој разлици лозинка за bind може да исцури. Подесите строги режим и не дозволите незаштићен резервни пут за bind са лозинком.

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-ју примените сертификат услуге директоријума са исправном наменом за аутентификацију сервера, уместо да закључујете на основу приказаног имена.

Свако одредиште за пребацивање при отказу мора да задовољи исту политику идентитета. Окружење у ком је примарни проверен, а секундарни није, горе је од оног без пребацивања, јер се слабији пут открива само током прекида.

Налог за bind остаје одвојен проблем

Заштита транспорта не смањује оно што налог за bind сме да ради. Обим претраге у директоријуму, групна ауторизација и привилегије сервисног налога су одвојене одлуке, и широк налог за bind остаје широк и после укључивања TLS-а. Користите најужи сервисни налог и базу претраге који су интеграцији потребни, и забележите крајњу тачку, TLS режим, власника поверења и процес обнове заједно са конфигурацијом VPN-а.

Када се појави несагласност сертификата, примените исправан сертификат или ланац. Искључивање провере претвара видљиву несагласност у невидљиву и оставља други однос поверења непровереним.

Две везе, два власника, два датума обнове. Њихово одвајање у документацији је оно што пријаву држи искреном.