Rådgivning om Best Practices for Active Directory (AD)-domæne design i forhold til anvendelse af et registreret domænenavn som navnet på et AD-domæne. Levedygtige alternativer omfatter brug af et ikke-offentligt DNS-suffiks (f. eks. lokalt eller lokalnetværk) i ad-domænenavnet eller oprettelse af ad-domænet til et underdomæne for det registrerede domæne (f. eks.Corp.domain.com).
Du kan ikke altid vælge noget i sagen, men Du kan finde ud af, at du understøtter et AD-domæne, der har samme navn som virksomhedens registrerede domæne, og det er ikke sikkert, at det vil ændre nogen af navnene. Dette er kendt som en opdeling DNS (eller opdelt hjerne DNS) scenarie, hvor der er to særskilte DNS navneområder – det interne navneområde, der bruges af ad og det eksterne navneområde, der anvendes af den offentlige domæneregistrator-med det samme navn. Dette scenario kan præsentere nogle unikke udfordringer. Denne artikel omhandler nogle almindelige problemer, der opstår i forbindelse med et opdelt DNS miljø, og hvad du kan gøre for at afhjælpe dem.
I alle eksempler herunder er AD-domænet og det registrerede domæne begge navnet Domain.com, og der er et firma websted med navnet www.domain.com.
Problem 1: Ekstern tilknyttet virksomhedens websted er utilgængeligt fra kontoret
Dette er det mest almindelige problem i et opdelt DNS miljø: virksomhedens hjemmeside eller en anden virksomheds ejet ressource, der er forbundet til internettet, kan ikke nås fra kontoret af maskiner, der er tilsluttet AD-domænet, men maskiner uden for kontoret ikke har problemer med at nå hjemmesiden. Årsagen til dette sker, kan ses ved at undersøge, hvad der sker, når en intern bruger forsøger at gennemse virksomhedens websted:
Problemet opstår, fordi en DNS server, der har en bestemt opslagszone i sin database – Domain.com -zonen i dette eksempel ikke sender forespørgsler for poster i denne zone hvor som helst anden. det returnerer blot et "ikke fundet"-svar, hvis der ikke er nogen post, der matcher en given forespørgsel. I dette eksempel er der en anden DNS-server med den korrekte post: den DNS-server, der er vært for den offentlige Domain.com -zone, der tilhører domæne registratoren, som det fremgår klart af, at maskiner uden for Kontoret kan få adgang til hjemmesiden. Forespørgsler fra interne maskiner kommer aldrig i kontakt med denne server.
Løsningen på dette problem er enkel: Opret en værtspost med navnet www i Domain.com -zonen på domænecontrolleren, og giv denne post webstedets IP adresse. Maskiner, der forespørger, at DNS server derefter modtager den korrekte respons og kan surfe på webstedet.
Problem 2: Offentligt hosted offentlige websteder er utilgængeligt fra kontoret
Dette kan anses for en variant af problem 1 ovenfor. Forskellen i dette tilfælde er, at hjemmesiden er hosted internt, enten bagved en firewall på virksomhedens interne netværk eller i en DMZ. Det er formodes at være tilgængelig for både interne og eksterne brugere, men interne brugere er ikke i stand til at nå det, mens eksterne brugere ikke rapporterer noget problem.
Årsagen til problemet er magen til den i problem 1, men interne brugere i dette tilfælde er i stand til at løse webstedets navn korrekt til dets offentlige IP adresse. De er dog stadig ude af stand til at oprette forbindelse til webstedet pga. den måde, som firewallen er konfigureret på. Det forventer, at brugere på det interne netværk kan få adgang til webstedet vha. dens private adresse i stedet for dens offentlige adresse.
Der er en enkel Rettelse: Opret en værtspost med navnet www i Domain.com -zonen på domænecontrolleren, men denne gang gør det til at registrere webstedets private IP adresse. Interne maskiner oversætter webstedets navn til den private adresse, mens eksterne maskiner fortsat kan fortolke navnet på webstedets offentlige adresse.
Problem 3: Websteders belastninger er ufuldstændige eller vil stadig ikke blive indlæst, efter at ovenstående ændringer er foretaget
Dette kan ske, hvis webstedskoden omdirigerer webbrowsere fra www.domain.com til Domain.com , eller hvis interne links refererer til webstedet som Domain.com i stedet for www.domain.com. De samme symptomer er synlige på interne maskiner, uanset om webstedet er hosted internt eller eksternt:
Problemet i dette tilfælde er lidt mere kompleks. For at maskiner kan oversætte Domain.com til en IP adresse, skal der være en tom værtspost i Domain.com -zonen i DNS. Navnet på denne post vises som (samme som overordnet mappe) i Windows DNS-konsol. Der er dog et problem i dette tilfælde: Active Directory bruger tomme værts poster i Domain.com -zonen til at repræsentere dc'er for Domain.com -domænet. Domænemedlemmer bruger disse poster, når de finder en DC til godkendelse, og hvis der er ekstra blanke værts poster i Domain.com -zonen, kan der opstå forsinkelser eller godkendelsesproblemer.
Af ovenstående årsag kan problemet ikke løses i DNS alene. Oprettelse af en tom værtspost med webstedets IP adresse fortolker kun webstedets adgangs problem for interne brugere, fordi der allerede er andre blanke værts poster med IP adresserne på domænecontrollerne i domænet, og gør dette årsag til problemer med domænegodkendelse.
Den nemmeste måde at løse dette problem på er at ændre webstedets kode for enten at fjerne omdirigeringen eller rette de interne links, så alt henviser til webstedet som www.domain.com i stedet for Domain.com. Hvis det ikke er muligt at ændre koden, er den eneste anden mulighed for at løse problemet, at du omdøber AD-domænet. Dette kan være en kompleks opgave alt afhængigt af miljøets størrelse og kompleksitet.