Deltag i et domæne over en bruger-VPN, og overlev genstarten

Du kan køre en domænetilslutning over en punkt-til-site-VPN. Det, forbindelsen normalt ikke kan, er at holde sig oppe gennem den genstart, der følger, hvor den første domænebruger forsøger at logge på. Jeg tager nu tilslutningen i tre faser: bevise stien og opdagelsen, mens en lokal administrator er logget på, køre tilslutningen og derefter teste det første domænelogin, før jeg overdrager bærbaren. Hver fase har en test, der fejler et andet sted.

Adskillelsen af disse faser er det, der forhindrer projektet i at ende med en bærbar, der er tilsluttet korrekt og ikke kan bruges.

Før du forbinder: udgave, lokal administrator, DNS

Maskinen skal have en udgave, der understøtter domænetilslutning, og en lokal administrator, der er autoriseret til at udføre den. VPN'en skal være oppe i samme session, fordi tilslutningen kører i den sikkerhedskontekst, du bruger.

Ret klienten mod organisationens katalog-DNS, ikke mod en offentlig resolver og ikke mod en post i hosts-filen. Tilslutningen skal finde tjenesteposter og derefter nå de værter, som posterne peger på. Et forældet suffiks eller en offentlig resolver sender opdagelsen et helt andet sted hen.

Tjek også uret. Kerberos tillader ikke tidsafvigelse, og en bærbar, der har været offline i en måned, er en hyppig kilde til forvirrende tilslutningsfejl.

Bekræft, at domænet kan opdages, ikke bare pinges

Slå domænets LDAP SRV-post op, før du forsøger tilslutningen. For et illustrativt enkeltdomænemiljø med navnet ad.corp.example er forespørgslen:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

En returneret post er nødvendig, men ikke tilstrækkelig. Slå hvert DC-navn op, som den angiver, og bekræft, at du kan nå de nødvendige tjenester gennem tunnelen. En ping til domænenavnet beviser næsten intet om opdagelse.

Tillad de dokumenterede AD-afhængigheder: godkendelse, SMB- og RPC-trafik samt tidssynkronisering. Kontrollér hver af dem mod de firewallregler, du faktisk har udrullet. Det er ikke en genvej værd at overveje at eksponere domænecontrollerens porte på internettet.

Kør tilslutningen, og læs fejlen

Brug den understøttede tilslutningskommando eller systemdialogen, og noter den præcise fejltekst. »Det angivne domæne findes enten ikke, eller også kunne det ikke kontaktes« peger på opdagelse eller tilgængelighed, ikke på legitimationsoplysninger.

Hvis der allerede findes et objekt med samme navn, må du ikke slette det automatisk. Det kan være en forudklargjort konto, og netjoin-hærdning begrænser nogle genbrugstilfælde efter ejerskab og politik. Bed katalogejeren om at undersøge eller rette objektet.

En vellykket tilslutning er midtpunktet, ikke målstregen. Det næste trin er det, brugeren faktisk tester.

Planlæg det første domænelogin

En gennemført tilslutning opretter ikke cachelagrede legitimationsoplysninger for hver domænebruger. På den første loginskærm skal den bærbare have en sti til en DC, før nogen bruger har logget på. Hvis din bruger-VPN først starter efter login, mangler den sti. Det er et hul i designet, ikke en klientfejl.

Brug et understøttet for-login- eller enhedstunnelworkflow, en eksisterende stedsti eller et godkendt alternativ til det første login. Test derefter hele sekvensen: genstart, kom til legitimationsskærmen, log på som den tilsigtede domænebruger, og bekræft, at tunnelen opfører sig som designet.

Brugerskift og VPN-persistens varierer fra klient til klient. Antag ikke, at en forbindelse startet som lokal administrator overlever ind i en anden brugers session.

Bevar lokal gendannelsesadgang

Bevar en godkendt lokal gendannelsessti, før du overdrager den bærbare. Hvis det første domænelogin fejler, vil du have en vej tilbage, der ikke afhænger af den samme tunnel, som netop fejlede.

Skriv ned, hvad du beviste: SRV-opslag, DC-tilgængelighed, tilslutningsfejlen, metoden til første login og gendannelseskontoen. Den registrering er forskellen mellem et reproducerbart build og en bærbar, der kun virker på kontoret.