La VPN-atestilo ne protektas la LDAP-parton

VPN-ensaluto, kiu kontrolas identigilojn kontraŭ dosierujo, enhavas du apartajn retajn konektojn. La konekto de la uzanto al la enirejo estas protektata de la propra atestilo de la VPN kaj de la protokola agordo. La konekto de la enirejo al la dosierujo estas alia sesio kun propraj TLS-agordoj, propra fido-tenejo kaj propraj malsukcesmanieroj. Nenio pri la unua garantias ion pri la dua.

Tiu asimetrio estas la mekanismo malantaŭ ensaluto, kiu ŝajnas ĉifrita kaj tamen sendas bind-pasvorton malkaŝe.

Du konektoj, du fiddecidoj

La ekstera sesio estas tio, kion la uzanto vidas: atestilo ligita al la VPN-gastnomo, validigita de la kliento, portanta la aŭtentiginterŝanĝon. La interna sesio apartenas al la dosieruja kliento ene de la enirejo, kiu malfermas sian propran konekton kaj aŭ intertraktas TLS aŭ ne. Ĉiu flanko validigas la kontraŭulon, al kiu ĝi parolas, uzante materialon el alia agorda dosiero. Misagordita interna parto restas nevidebla de la flanko de la uzanto, ĉar la ekstera parto funkcias ĝuste laŭintence.

Tial la malsukceso estas silenta anstataŭ laŭta. Enirejo, kiu neniam kontrolas la atestilon de la dosierujo, tamen aŭtentigas uzantojn ĝuste; ĝi simple aŭtentigas ilin tra kanalo, kiun ĝi ne kontrolis.

StartTLS kaj LDAPS, konscie elektitaj

StartTLS malfermiĝas kiel simpla LDAP kaj plibonigas surloke, kutime ĉe pordo 389. LDAPS startigas TLS kun la konekto, kutime ĉe 636. Ambaŭ estas legitima kaj la adaptilo devas kongrui kun tio, kion la dosierujo proponas. Postuli StartTLS malsamas de provi ĝin kaj daŭrigi, kiam la plibonigo malsukcesas, kaj ĝuste tiu diferenco estas kie bind-pasvorto povas eskapi. Agordu la striktan reĝimon, kaj ne permesu neprotektitan returndan vojon por pasvorta 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

La flago -ZZ estas la tuta punkto: la demando malsukcesas anstataŭ silente daŭrigi sen la plibonigo. Nomoj kaj kontoj en tiu linio estas ekzemploj. La OpenLDAP-TLS-dokumentaro kovras la fidagordojn malantaŭ ĝi.

Kiun fido-tenejon legas la LDAP-kliento?

La klienta biblioteko OpenLDAP legas sian propran fidan agordon, ĉu el la sistema dosiero ĉu el aplikaĵ-specifa agordo. La CA-direktivo de la VPN validas por VPN-kunuloj kaj ne estas pruvo, ke la LDAP-biblioteko legas la saman dosieron. Uzu la dosierujan gastnomon, kiun la atestilo efektive kovras, plus la eldonan ĉenon, kiun la biblioteko fidas. En Active Directory, enkonduku dosierujan servan atestilon kun la ĝusta servila aŭtentigo-uzo anstataŭ rezonadi el montra nomo.

Ĉiu failover-celo devas plenumi la saman identecpolitikon. Medio, kie la ĉefa estas validigita kaj la sekundara ne, estas pli malbona ol tiu sen failover, ĉar la pli malforta vojo malkovriĝas nur dum interrompo.

La bind-konto restas aparta problemo

Protekti la transporton ne malpliigas tion, kion la bind-konto rajtas fari. Dosieruja serĉamplekso, grupa rajtigo kaj la privilegioj de la serva konto estas apartaj decidoj, kaj larĝa bind-konto restas larĝa post kiam TLS estas ŝaltita. Uzu la plej mallarĝan servan konton kaj serĉbazon, kiujn la integriĝo bezonas, kaj registru la finpunkton, TLS-reĝimon, fidan posedanton kaj renovigan procezon kune kun la VPN-agordo.

Kiam aperas atestila neakordo, dislokigu la ĝustan atestilon aŭ ĉenon. Malŝalti kontroladon konvertas videblan neakordon en nevideblan kaj lasas la duan fidan rilaton netestita.

Du konektoj, du posedantoj, du renovigaj datoj. Teni ilin aparte en la dokumentaro estas tio, kio tenas la ensaluton honesta.