Bli med i et domene over en bruker-VPN, og overlev omstarten

Du kan kjøre en domenetilkobling over en punkt-til-site-VPN. Det den forbindelsen vanligvis ikke klarer, er å holde seg oppe gjennom omstarten som følger, når den første domenebrukeren prøver å logge på. Jeg tar nå tilkoblingen i tre faser: bevise stien og oppdagelsen mens en lokal administrator er pålogget, kjøre tilkoblingen og deretter teste den første domenepåloggingen før jeg overlater maskinen. Hver fase har en test som feiler på et annet sted.

Å skille disse fasene er det som hindrer prosjektet i å ende med en maskin som ble tilkoblet og ikke kan brukes.

Før du kobler til: utgave, lokal administrator, DNS

Maskinen trenger en utgave som støtter domenetilkobling og en lokal administrator som er autorisert til å utføre den. VPN-en må være oppe i samme økt, fordi tilkoblingen kjører i sikkerhetskonteksten du bruker.

Pek klienten mot organisasjonens katalog-DNS, ikke mot en offentlig resolver og ikke mot en oppføring i hosts-filen. Tilkoblingen må finne tjenestepostene og deretter nå vertene som postene peker på. Et utdatert suffiks eller en offentlig resolver sender oppdagelsen et helt annet sted.

Sjekk klokka også. Kerberos tolererer ikke tidsavvik, og en maskin som har vært frakoblet i en måned er en vanlig kilde til forvirrende tilkoblingsfeil.

Bekreft at domenet kan oppdages, ikke bare pinges

Slå opp domenets LDAP SRV-post før du prøver tilkoblingen. For et illustrerende enkeltdomene-miljø med navnet ad.corp.example er spørringen:

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

En returnert post er nødvendig, men ikke tilstrekkelig. Slå opp hvert DC-navn den lister opp, og bekreft at du når de nødvendige tjenestene gjennom tunnelen. En ping mot domenenavnet beviser nesten ingenting om oppdagelse.

Tillat de dokumenterte AD-avhengighetene: autentisering, SMB- og RPC-trafikk samt tidssynkronisering. Kontroller hver av dem mot brannmurreglene du faktisk har rullet ut. Å publisere domenekontrollerens porter på internett er ikke en snarvei som er verdt å vurdere.

Kjør tilkoblingen og les feilen

Bruk den støttede tilkoblingskommandoen eller systemdialogen, og ta vare på den nøyaktige feilteksten. «Det angitte domenet finnes enten ikke eller kunne ikke kontaktes» peker på oppdagelse eller tilgjengelighet, ikke på påloggingsinformasjon.

Hvis det allerede finnes et objekt med samme navn, må du ikke slette det på refleks. Det kan være en forhåndsklargjort konto, og netjoin-herding begrenser enkelte gjenbrukstilfeller etter eierskap og policy. Be katalogseieren undersøke eller rette objektet.

En vellykket tilkobling er midtpunktet, ikke målstreken. Det neste trinnet er det brukeren faktisk tester.

Planlegg den første domenepåloggingen

En fullført tilkobling lager ikke bufrede påloggingsdata for hver domenebruker. På den første påloggingsskjermen trenger maskinen en sti til en DC før noen bruker har logget på. Hvis bruker-VPN-en din starter først etter pålogging, mangler den stien. Det er et hull i designet, ikke en klientfeil.

Bruk en støttet arbeidsflyt før pålogging eller en enhetstunnel, en eksisterende nettstedssti eller et godkjent alternativ for den første påloggingen. Test deretter hele sekvensen: start på nytt, kom til påloggingsskjermen, logg på som den tiltenkte domenebrukeren, og bekreft at tunnelen oppfører seg som designet.

Brukerbytte og VPN-vedvarenhet varierer fra klient til klient. Ikke anta at en forbindelse som er startet som lokal administrator, overlever inn i en annen brukers økt.

Behold lokal gjenopprettingstilgang

Bevar en godkjent lokal gjenopprettingssti før du overlater maskinen. Hvis den første domenepåloggingen feiler, vil du ha en vei tilbake som ikke avhenger av den samme tunnelen som nettopp feilet.

Skriv ned hva du beviste: SRV-oppslag, DC-tilgjengelighet, tilkoblingsfeilen, metoden for første pålogging og gjenopprettingskontoen. Den registreringen er forskjellen mellom et repeterbart bygg og en maskin som bare virker på kontoret.