Anslut en dator till en domän via användar-VPN och överlev omstarten

Du kan köra en domänanslutning via ett punkt-till-plats-VPN. Det anslutningen vanligtvis inte klarar är att hålla sig uppe genom omstarten som följer, när den första domänanvändaren försöker logga in. Jag går nu igenom anslutningen i tre faser: bevisa sökvägen och upptäckten medan en lokal administratör är inloggad, köra anslutningen och sedan testa den första domäninloggningen innan jag lämnar över datorn. Varje fas har ett test som misslyckas på ett annat ställe.

Att skilja dessa faser åt är det som hindrar projektet från att sluta med en dator som anslöts och inte kan användas.

Innan du ansluter: utgåva, lokal administratör, DNS

Datorn behöver en utgåva som stöder domänanslutning och en lokal administratör som är behörig att utföra den. VPN:et måste vara uppe i samma session, eftersom anslutningen körs i den säkerhetskontext du använder.

Peka klienten mot organisationens katalog-DNS, inte mot en offentlig resolver och inte mot en post i hosts-filen. Anslutningen måste hitta tjänsteposterna och sedan nå de värdar som posterna pekar ut. Ett inaktuellt suffix eller en offentlig resolver skickar upptäckten någon helt annanstans.

Kontrollera klockan också. Kerberos tolererar ingen tidsavvikelse, och en dator som varit offline i en månad är en vanlig källa till förvirrande anslutningsfel.

Bekräfta att domänen kan upptäckas, inte bara pingas

Slå upp domänens LDAP SRV-post innan du försöker ansluta. För en illustrativ miljö med en enda domän som heter ad.corp.example är frågan:

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

En returnerad post är nödvändig men inte tillräcklig. Slå upp varje DC-namn som den listar och bekräfta att du når de nödvändiga tjänsterna via tunneln. En ping mot domännamnet bevisar nästan ingenting om upptäckt.

Tillåt de dokumenterade AD-beroendena: autentisering, SMB- och RPC-trafik samt tidssynkronisering. Kontrollera vart och ett mot de brandväggsregler du faktiskt har distribuerat. Att publicera domänkontrollantens portar på internet är ingen genväg värd att överväga.

Kör anslutningen och läs felet

Använd det stödda anslutningskommandot eller systemdialogen och fånga den exakta feltexten. ”Den angivna domänen finns antingen inte eller kunde inte kontaktas” pekar på upptäckt eller nåbarhet, inte på autentiseringsuppgifter.

Om det redan finns ett objekt med samma namn, ta inte bort det per reflex. Det kan vara ett förberett konto, och netjoin-härdning begränsar vissa återanvändningsfall beroende på ägarskap och policy. Be katalogägaren att granska eller rätta objektet.

En lyckad anslutning är mittpunkten, inte mållinjen. Nästa steg är det som användaren faktiskt testar.

Planera den första domäninloggningen

En slutförd anslutning skapar inte cachelagrade autentiseringsuppgifter för varje domänanvändare. På den första inloggningsskärmen behöver datorn en väg till en DC innan någon användare har loggat in. Om ditt användar-VPN startar först efter inloggning saknas den vägen. Det är en lucka i designen, inte en klientbugg.

Använd ett stött arbetsflöde före inloggning eller en enhetstunnel, en befintlig platsväg eller ett godkänt alternativ för den första inloggningen. Testa sedan hela sekvensen: starta om, nå inloggningsskärmen, logga in som den avsedda domänanvändaren och bekräfta att tunneln beter sig som designat.

Användarbyte och VPN-beständighet varierar mellan klienter. Anta inte att en anslutning som startats som lokal administratör överlever in i en annan användares session.

Behåll lokal återställningsåtkomst

Bevara en godkänd lokal återställningsväg innan du lämnar över datorn. Om den första domäninloggningen misslyckas vill du ha en väg tillbaka som inte beror på samma tunnel som just misslyckades.

Skriv ned vad du bevisade: SRV-uppslagning, DC-nåbarhet, anslutningsfelet, metoden för första inloggning och återställningskontot. Den anteckningen är skillnaden mellan ett repeterbart bygge och en dator som bara fungerar på kontoret.