It VPN-sertifikaat beskermet it LDAP-skakel net

In VPN-oanmelding dy’t bewiisstikken tsjin in gids kontrolearret, omfettet twa aparte netwurkferbinings. De ferbining fan ’e brûker nei de gateway wurdt beskerme troch it eigen sertifikaat fan ’e VPN en de protokolynstelling. De ferbining fan ’e gateway nei it gids is in oare sesje mei syn eigen TLS-ynstellingen, syn eigen trust store en syn eigen flaterwizen. Neat oan it earste garandearret neat oer it twadde.

Dy asymmetry is it meganisme efter in oanmelding dy’t fersifere liket en dochs in bind-wachtwurd iepen ferstjoert.

Twa ferbinings, twa fertrouwensbesluten

De bûtenste sesje is wat de brûker sjocht: in sertifikaat bûn oan de VPN-hostnamme, falidearre troch de kliïnt, dat de autentikaasje-útwikseling draacht. De binnenste sesje heart by de gidskliïnt yn ’e gateway, dy’t syn eigen ferbining iepenet en óf TLS ûnderhannelet óf net. Eltse kant falidearret de tsjinpartij dêr’t er mei praat, mei materiaal út in oar konfiguraasjebestân. In ferkeard ynstelde binnenste skakel bliuwt ûnsichtber fan ’e kant fan ’e brûker, om’t de bûtenste skakel krekt sa wurket as bedoeld.

Dêrom is de flater stil ynstee fan lûd. In gateway dy’t nea it sertifikaat fan it gids kontrolearret, autentisearret brûkers dochs korrekt; hy autentisearret se inkeld oer in kanaal dat er net ferifearre hat.

StartTLS en LDAPS, bewust keazen

StartTLS iepenet as gewoane LDAP en wurdt op syn plak opwurdearre, gewoanlik op poarte 389. LDAPS start TLS mei de ferbining, gewoanlik op 636. Beide binne legitime en de adapter moat passe by wat it gids oanbiedt. StartTLS easkje is oars as it besykje en trochgean as de opwurdearring mislearret, en krekt yn dat ferskil kin in bind-wachtwurd útbrekke. Konfigurearje de strange modus, en lit gjin ûnbeskerme weromfal ta foar in wachtwurdbind.

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

De -ZZ-opsje is it hiele punt: de fraach mislearret ynstee fan stil troch te gean sûnder de opwurdearring. Nammen en akkounts yn dy rigel binne foarbylden. De OpenLDAP TLS-dokumintaasje behannelet de fertrouwensynstellingen dêr’t it op rêst.

Hokker trust store lêst de LDAP-kliïnt?

De OpenLDAP-kliïntbibleteek lêst syn eigen fertrouwenskonfiguraasje, itsij út it systeembestân itsij út in tafoegingspesifike ynstelling. De CA-rigel fan ’e VPN jildt foar VPN-peers en is gjin bewiis dat de LDAP-bibleteek itselde bestân lêst. Brûk de gids-hostnamme dy’t it sertifikaat eins beslacht, plus de útjaanrigel dêr’t de bibleteek op fertrout. Yn Active Directory, set in gidsstjinstsertifikaat yn mei it krekte gebrûk foar serverautentikaasje ynstee fan te riddenearjen út in werjefte namme.

Elke failover-bestimming moat oan itselde identiteitsbelied foldwaan. In omjouwing dêr’t it primêre falidearre wurdt en it sekundêre net, is slimmer as ien sûnder failover, om’t it swakkere paad pas by in steuring ûntdutsen wurdt.

It bind-akkount bliuwt in apart probleem

It beskermjen fan it ferfier ferminderet net wat it bind-akkount dwaan mei. Gidssykberik, groepsautorisaasje en de privileezjes fan it tsjinstakkount binne aparte besluten, en in breed bind-akkount bliuwt breed neidat TLS ynskeakele is. Brûk it smelste tsjinstakkount en sykbase dat de yntegraasje nedich hat, en registrearje it einpunt, TLS-modus, fertrouwenseigner en fernijingsproses by de VPN-konfiguraasje.

As der in sertifikaatôfwiking opkomt, set dan it krekte sertifikaat of de krekte rigel yn. It útskeakeljen fan ferifikaasje feroaret in sichtbere ôfwiking yn in ûnsichtbere en lit de twadde fertrouwensrelaasje ûntest.

Twa ferbinings, twa eigners, twa fernijingsdatums. Se apart hâlde yn ’e dokumintaasje hâldt de oanmelding earlik.