VPN-vottorðið verndar ekki LDAP-hlutann

VPN-innskráning sem athugar skilríki gegn skrá felur í sér tvær aðskildar netengingar. Tenging notandans við gáttina er vernduð með eigin vottorði VPN og stillingum samskiptareglunnar. Tenging gáttarinnar við skrána er annar seta með eigin TLS-stillingum, eigin traustgeymi og eigin bilunaraðferðum. Ekkert í þeirri fyrri ábyrgist neitt um þá seinni.

Þetta misræmi er séreinkennið í innskráningu sem lítur dulkóðuð út og sendir samt bind-lykilorð í opnu.

Tvær tengingar, tvær traustákvarðanir

Ytri setan er það sem notandinn sér: vottorð sem bundið er við VPN-vistfangið, staðfest af biðlaranum og flytur sannvottunarskiptin. Innri setan tilheyrir skrárbiðlaranum inni í gáttinni, sem opnar eigin tengingu og semur annaðhvort um TLS eða ekki. Hvor hlið staðfestir mótaðilann sem hún talar við með efni úr annarri stillingarskrá. Rangstilltur innri hlutur er ósýnilegur frá hlið notandans, því ytri hluturinn virkar nákvæmlega eins og til var ætlast.

Þess vegna er bilunin hljóðlát frekar en hávær. Gátt sem athugar aldrei vottorð skrárinnar sannvottar notendur samt rétt; hún sannvottar þá einfaldlega um rás sem hún staðfesti ekki.

StartTLS og LDAPS, valin af ásetningi

StartTLS opnast sem venjulegt LDAP og uppfærist á staðnum, venjulega á gátt 389. LDAPS byrjar TLS með tengingunni, venjulega á 636. Bæði eru lögmæt og millistofninn verður að passa við það sem skráin býður. Að krefjast StartTLS er annað en að prófa það og halda áfram þegar uppfærslan mistekst, og einmitt í þeim mun getur bind-lykilorð sloppið út. Stilltu strangt ham og leyfðu enga óvarða varaleið fyrir bind með lykilorði.

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-valkosturinn er allt málið: fyrirspurnin mistekst í stað þess að halda hljóðlaust áfram án uppfærslunnar. Nöfnin og reikningarnir í þeirri línu eru dæmi. TLS-skjöl OpenLDAP fjalla um trauststillingarnar þar að baki.

Hvaða traustgeymir er lesinn af LDAP-biðlaranum?

OpenLDAP-biðlarasafnið les eigin trauststillingu, hvort sem hún kemur úr kerfisskránni eða stillingu sem er sértæk fyrir viðbót. CA-tilskipun VPN gildir fyrir VPN-jafningja og er ekki sönnun þess að LDAP-safnið lesi sömu skrá. Notaðu vistfangsnafn skrárinnar sem vottorðið nær í raun yfir, auk útgáfukeðjunnar sem safnið treystir. Í Active Directory skaltu dreifa skráarþjónustuvottorði með réttri notkun fyrir þjónsannvottun í stað þess að rökstyðja út frá skjánarni.

Hver failover-áfangastaður verður að uppfylla sömu auðkennisstefnu. Umhverfi þar sem aðaltengingin er staðfest en varatengingin ekki er verra en slíkt án failovers, því veikari leiðin uppgötvast aðeins meðan á truflun stendur.

Bind-reikningurinn er áfram sérstakt vandamál

Vernd flutningsins dregur ekki úr því sem bind-reikningurinn má gera. Leitarsvið skrár, hópaheimild og forréttindi þjónustureikningsins eru aðskildar ákvarðanir, og víður bind-reikningur er áfram víður eftir að TLS er virkjað. Notaðu þrengsta þjónustureikning og leitargrunn sem samþættingin þarf, og skráðu endapunktinn, TLS-ham, traust eigandann og endurnýjunarferlið ásamt VPN-stillingunni.

Þegar vottorðamisræmi kemur fram skaltu dreifa rétta vottorðinu eða keðjunni. Að slökkva á staðfestingu breytir sýnilegu misræmi í ósýnilegt og lætur annað traustsambandið óprófað.

Tvær tengingar, tveir eigendur, tveir endurnýjunardagar. Að halda þeim aðskildum í skjölunum er það sem heldur innskráningunni heiðarlegri.