Innledning
Siden Windows 2000 Server ble først utgitt nesten 15 år siden, har domenekontrollere vært den absolutte grunnlaget for enhver Active Directory-miljø. De håndterer autentisering av brukerkontoene og enheter. De innvilge eller nekte brukere tilgang til slike ting som delte mapper, skrivere og andre ressurser på nettverket. De kan også lagre informasjon om alle kontoene og ressurser i miljøet og gjøre det mulig for brukere å lete opp de ressursene de trenger. De lar deg lage og distribuere Group Policy Objects (GPOer) som lar deg administrere, kontrollere og låse ned mange aspekter av miljøet.
Men siden domenekontrollere i utgangspunktet administrere sikkerheten til Active Directory-miljø, de representerer en høy verdi mål for de som ønsker å angripe din organisasjon. Sikre den fysiske sikkerheten til domenekontrollere er viktig fordi hvis noen var i stand til å stjele en av dine domenekontrollere, kunne de ha tilgang til hemmelighetene om hvordan bedriften opererer. På grunn av dette, Microsoft introduserte en ny type domenekontroller som begynner med Windows Server 2008 kalles en skrivebeskyttet domenekontroller (RODC). I motsetning til en skrivbar (normal) domenekontroller, opprettholder en RODC en skrivebeskyttet kopi av Active Directory-katalog database. Det replikerer også katalogforandringer i bare én retning (inngående) som betyr at hvis en RODC ble kompromittert, vil eventuelle endringer i sin database ikke bli replikert til resten av skogen. RODCs inkluderer også flere sikkerhetsfunksjoner, blant annet i hvordan de cache legitimasjon. Disse funksjonene RODCs gjør dem til et godt valg for når du trenger å distribuere en domenekontroller på en liten filial eller annet eksternt område som ikke har samme nivå av fysisk sikkerhet som sentrale kontor gjør.
hvor du skal begynne
Din utgangspunkt for å lære hvordan RODCs fungerer og hvordan de skal distribueres er planlegging og utbygging av Read-Only Domain Controllers whitepaper som er tilgjengelig i .doc format fra Microsoft Download Center. Ikke la deg skremme av det faktum at dette whitepaper ble publisert tilbake i 2008 fordi det har vært vesentlige ingen endringer i hvordan RODCs fungere siden Windows Server 2008. Med andre ord, Windows Server 2012 R2 RODCs fungerer på samme måte som Windows Server 2008 RODCs gjøre. Eventuelle endringer i RODCs siden 2008 har i utgangspunktet bare vært feilrettinger. Du kan også være lurt å ta en titt på hvordan Les Only Domain Controllers og DNS fungerer på TechNet Wiki for noen ytterligere informasjon om hvordan RODCs samspill med DNS infrastruktur som undergirds Active Directory-miljø.
Når du har lese ovenfor whitepaper og wiki artikkel, neste ressursen bør du sannsynligvis anmeldelse vil være Read-Only Domain Controller (RODC) Branch Til Kontor som er tilgjengelig her fra Download Center. Dette .doc er datert 2009, men det er fortsatt ganske mye nøyaktig i forhold til distribusjon av Windows Server 2012 RODCs på avdelingskontorer.
Hvis du har planer om å utplassere en RODC i DMZ (perimeter nettverk) av miljøet, ditt utgangspunkt for lesing skal være Active Directory Domain Services i Perimeter Network (Windows Server 2008) whitepaper som er tilgjengelig her fra Download Center. Det er også en TechNet Wiki side om dette temaet, men foreløpig er det bare en spire.
Når du har lastet ned og lese alle de ovennevnte dokumenter, kan du fortsatt komme over problemer eller scenarier som ikke dekkes av dem. Det er hva denne aktuelle artikkelen er ment å løse. Med andre ord, vil vi se på noen tips og feller om RODCs som ikke er dekket i disse docs, eller i det minste de ikke er dekket veldig tydelig.
RODCs og dine forretningsapplikasjoner
< p> Et viktig spørsmål du bør undersøke før du begynner å distribuere RODCs i miljøet er om alle dine forretningsapplikasjoner vil jobbe med RODCs. Hvis du har noen virksomhetskritiske applikasjon som ikke fungerer med RODCs og du går videre og distribuere RODCs, kan du plutselig finne virksomheten plutselig sliping stoppet opp.
Alle Microsoft ser ut til å ha å tilby i denne hensyn er denne Read-Only Domain Controllers Application Compatibility Guide i TechNet Library. Dessverre som guide ble sist oppdatert i 2007, så det er nok ikke nok til å svare på alle dine spørsmål angå RODC kompatibilitet for dine viktige forretningsapplikasjoner. Når jeg diskutert dette problemet mine Active Directory kontakter på Microsoft de sa de ikke holde en mester liste over programmer som ikke er kompatible med RODCs fordi det er jobben av applikasjonseiere, ikke Active Directory-teamet, for å finne ut om sine programmer fungerer med RODCs eller ikke. Jeg gjorde bekrefte det åpen men for eksempel at Microsoft SQL Server ikke kan installeres på en RODC, som Microsoft Exchange ikke kan spørre mot en RODC, og så videre.
Så er det spørsmål om tredjepartsprogrammer og kompatibiliteten med RODCs. For dette selvfølgelig kan du ikke spørre Microsoft - de kan ikke forventes å opprettholde en sentral kompatibilitet register over alle de forretningsapplikasjoner i verden. Du må kontakte programvareleverandøren i stedet og spørre dem direkte om RODC kompatibilitet for sine applikasjoner. Men ikke forvent en nyttig respons fra leverandører. Jeg spurte en gang en leverandør om dette, og deres svar var "Hva er en RODC?"
Så i utgangspunktet den beste måten å tilnærme seg problemet med programkompatibilitet med RODCs er å bygge et testmiljø som har alle dine forretningskritisk applikasjonene. Deretter introdusere noen RODCs på testnettverk, legger hvert program gjennom sine skritt, og observere hva som skjer. Husk at hvis du ikke har et testmiljø deretter produksjonsmiljøet * er * testmiljøet. Og du definitivt ikke ønsker det.
RODCs og PDC Emulator rolle
Jeg tror ikke det er godt dokumentert på TechNet, men fra diskusjoner med mine kolleger synes det kan være en direkte avhengighet av RODCs i et domene på domenekontrolleren holder rollen PDC Emulator i det domenet. PDC Emulator er den autoritative domenekontroller for et domene, og det er nødvendig for å synkronisere tiden i miljøet så Kerberos-godkjenning kan fungere. Jeg hørte en stund tilbake fra en kollega at han kjente noen som brukes IPsec å segmentere sine omgivelser på en slik måte at en RODC ikke kunne kommunisere direkte med PDC Emulator for single-domene skogen. En bivirkning som ble lagt merke til i denne situasjonen var at når en brukerkonto ble slettet fra Active Directory, var endringen ikke kopiert til katalogen database av RODC. En annen bivirkning var at når en endring ble gjort til en av de brukerrettigheter via Group Policy, endringen ble heller ikke brukt til sikkerhetspolitikk for RODC. Når en IPsec regelen ble innført som tillot RODC å direkte snakke med PDC Emulator ble imidlertid slike endringer påføres som forventet av RODC. Jeg har ikke bekreftet dette i min lab ennå, men det tyder på at du bør utvise forsiktighet når Brannmur interne nettverket med IPsec tunneler som du kan ende opp med å bryte Active Directory som kan føre til autentiseringsfeil og andre relaterte spørsmål.
< p> Da jeg sa at ovennevnte problemet ikke er godt dokumentert på TechNet, er det noen tips rundt at problemer kan oppstå hvor RODC ikke kan kommunisere direkte med PDC Emulator. For eksempel, se emnet "Løse en konto lockout problem i et avdelingskontor med en RODC" i artikkelen Administrere RODCs i avdelingskontorer. Tråden med tittelen Replication tidslinjer med RODC i fjern AD nettstedet på TechNet Forums drøfter også noen problemer som synes knyttet til denne saken.
Vi vil undersøke noen flere potensielle problemer som involverer RODCs i neste artikkel i denne serien .
Fikk spørsmål om Active Directory?
Hvis du har spørsmål om bruk av skrivebeskyttede domenekontrollere, det beste stedet å spørre dem er Active Directory Domain Services forum på TechNet. Hvis du ikke får den hjelpen du trenger det, kan du prøve å sende spørsmålet ditt til [email protected] slik at vi kan publisere den i English våre lesere delen av vårt nyhetsbrev og se om noen av de nesten 100 000 IT pro abonnenter av vårt nyhetsbrev har noen forslag angående problemet. Anmeldelser