intorduction

I forrige artikkel i denne serien begynte vi gjennomgå noen viktige ressurser på hvordan skrivebeskyttet domenekontrollere (RODCs) arbeid, hvorfor de er nyttige, og hvordan de kan tas i bruk. RODCs kan gi litt ekstra sikkerhet for Active Directory-miljø, spesielt hvis din bedrift har eksterne avdelingskontorer der fysisk sikkerhet er ikke opp til samme nivå som ved den sentrale filial. Jeg sa da at når du har lastet ned og lese alle de RODC dokumentasjonen som Microsoft har gitt, kan du likevel komme over noen problemer eller scenarier som ikke omfattes av disse docs eller i det minste ikke dekkes godt av dem. Vi så på to viktige hensyn som involverer RODCs:

RODCs og deres kompatibilitet med line-of-business-applikasjoner

RODCs må være i stand til å kommunisere direkte med domenekontroller beholdning PDC Emulator rolle

I denne artikkel vil vi undersøke noen flere ting du kanskje trenger å være klar over når du har planer om å distribuere RODCs i miljøet.

Sharepoint på RODCs

RODC Application kompatibilitetsveiledningen indikerer at Windows Sharepoint Services er kompatibel med RODCs men da kvalifiserer dette ved å si at det ikke kan fungere hvis det er montert direkte på en RODC. En kollega av meg tok en nærmere titt på dette som en av hans klienter insisterte på å prøve å distribuere Sharepoint Server 2010 i DMZ segmentet av deres nettverk. Kunden ønsket å enten installere Sharepoint direkte på RODC i DMZ hvis mulig, eller i det minste installert det på en annen server i DMZ. Den RODC selvfølgelig var den eneste domenekontroller i sin DMZ.

First off, det ville ikke engang være mulig å distribuere Sharepoint i DMZ. Det er fordi installasjonsprosessen Sharepoint 2010 må være i stand til å skrive til Active Directory for å fullføre installasjonen. Dette er forklart i artikkelen Track eller blokkere Sharepoint Server 2010 installasjoner i TechNet Library. Så rett utenfor toppen, ser det ut som dette scenariet er ubrukelig. Selvfølgelig kan du prøve å midlertidig innføre en skrivbar domenekontroller inn i DMZ for å fullføre Sharepoint installasjon og deretter fjerne skrivbar domenekontroller når oppsettet er ferdig, slik at bare RODC. Kanskje det fungere?

Før vi svare på dette, la oss først se på den andre utgaven av hva som skjer når du installerer Sharepoint på en RODC. Bill Baer, ​​Senior Product Marketing Manager for Sharepoint hos Microsoft, har et innlegg på sin blogg med tittelen Sharepoint og Read-Only Domain Controllers (RODC) som beskriver i detalj noen av de begrensningene som oppstår når du installerer Sharepoint på en RODC. Vi hopper rett til Bill konklusjon hvor han sier følgende:.

"I de fleste tilfeller en organisasjon skal ikke oppleve problemene nevnt ovenfor som en RODC implementering bør inneholde skriv partner replikeringsserverne I ekstranett og perimeter nettverk scenarier, vil forfatter operasjoner mislykkes, RODC er ikke en kandidat i slike scenarier, men hvor tilkobling eksisterer mellom og RODC og en partner replikering server, vil en skriveoperasjon returnere en henvisning til en skrivbar domenekontroller – hvis tilkobling til en skrivbar domenekontroller ikke er tilgjengelig, deretter Skriv operasjoner mislykkes uansett om programmet bruker LDAP eller ADSI. "

Så det virker best practice her er ikke å distribuere Sharepoint i en DMZ der bare RODCs er til stede og ingen skrivdomenekontrollere. Men hvis du bare har planer om å distribuere Sharepoint for å arrangere et eksternt vendt nettsted slik at ingen skrive ryggen til RODC er nødvendig, så er det sannsynligvis OK å gjennomføre noe sånt som dette.

Konfigurering passord caching på RODCs

Når du først distribuere en RODC i Active Directory-miljø, må du konfigurere Password Replication Regler på skrivbar domenekontroller som vil være den replikering partner for RODC. Denne politikken fungerer som en tilgangsliste som avgjør hvorvidt den RODC bør cache passord for bruker og datamaskin kontoer i Active Directory. Trinnene for å konfigurere Password Replication Policy for en RODC er forklart i denne artikkelen i TechNet Biblioteket.

En god del av problemene bedrifter ofte erfaring med RODCs skyldes feil konfigurert Passord Replication Politikk for sine RODCs. For eksempel ett selskap jeg kjenner utplassert RODCs på flere eksterne avdelingskontorer for bedre sikkerhet. Så på grunn av maskinvarefeil lenken WAN gikk ned for mer enn en uke mellom selskapets hovedkontor og en av sine eksterne nettsteder, og etter et par dager flere brukere på det eksterne stedet kunne ikke lenger tilgang til alle lokale ressurser på sitt eget nettsted fordi RODC ikke lenger ville godkjenne dem. Brukerne på eksterne området ble frustrert, lederen klaget, og IT-person fikk sint på Microsoft for å utforme RODCs så dårlig!

Selvfølgelig, det virkelige problemet var at IT-person ikke hadde stilt inn passord Replication Regler for RODCs på de eksterne nettsteder. Passord Replication Policy for en RODC inkluderer en innebygd sikkerhetsgruppe som heter tillatt RODC Passord Replication Group som by default tilskudd til medlemmene av denne gruppen muligheten til å cache passord på alle RODC i domenet der RODC ligger. Men det er ikke nok å bare legge brukerkontoene til brukere på det eksterne stedet til denne gruppen. Du bør også legge til datamaskinkontoer av datamaskinene på det eksterne stedet til denne gruppen. Som det står i vedlegg A i RODC Planlegging og Deployment Guide på TechNet:

"Forsiktig: For en RODC å godkjenne en pålogging forespørsel lokalt, både bruker- og data legitimasjon må bli lagret lokalt If. brukerens ’ s legitimasjon er lagret, men datamaskinen legitimasjon er ikke lagret, kan RODC ikke tilby en tjeneste billett for brukeren å logge seg på datamaskinen Hvis et nettverksbrudd hindrer RODC fra å kontakte en skrivbar domenekontroller som kjører Windows Server 2008. eller senere vil RODC ikke være i stand til å yte en tjeneste billett til datamaskinen konto og pålogging vil mislykkes. "

Det er også viktig å innse at bare fordi du har angitt en liste over bruker og datamaskin kontoer som får lov til å bli lagret av RODC betyr ikke at passordene for disse kontoene har faktisk blitt bufret. Veien rundt dette problemet er å manuelt forhånds fylle ut påloggingsinformasjon for bruker og datamaskin kontoer som du trenger den RODC å kunne godkjenning. Fremgangsmåten for å gjøre dette er beskrevet i avsnittet "Prepopulating passordet cache for en RODC" på denne siden i TechNet Library. Sørg også for å lese Note i slutten av dette avsnittet om ventetid mellom RODC og skrivbar domenekontroller etter PRP tillatelse endringer iverksettes.

Det er et par andre spørsmål angående RODCs at jeg har hørt om fra feltet, men vi vil utsette å undersøke disse før senere i denne serien.

Fikk spørsmål om Active Directory?

Hvis du har spørsmål om bruk av skrivebeskyttet domenekontrollere, den beste sted å spørre dem er Active Directory Domain Services forum på TechNet. Hvis du ikke får 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