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 е целата поента: барањето не успева наместо тивко да продолжи без надградбата. Имињата и сметките во тој ред се примери. Документацијата за TLS на OpenLDAP ги покрива поставките за доверба зад тоа.

Кое складиште за доверба го чита LDAP клиентот?

Клиентската библиотека OpenLDAP ја чита сопствената конфигурација за доверба, било од системската датотека или од поставка специфична за приклучок. Насоката CA на VPN важи за VPN партнери и не е доказ дека библиотеката LDAP ја чита истата датотека. Користете го името на домаќинот на директориумот што сертификатот навистина го покрива, плус издавачкиот синџир на кој библиотеката му верува. Во Active Directory, распоредете сертификат за директориумска услуга со точната намена за автентикација на серверот, наместо да заклучувате од прикажано име.

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

Сметката за bind останува одделен проблем

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

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

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