AD-platser och domänkontrollanter

14
AD-platser och domänkontrollanter
AD-plats//site är ett nytt begrepp för domäner – bekant i Exchange Server
AD-plats//site är ett nytt begrepp för domäner. Microsofts officiella översättning av det egna begreppet »site« är »plats«. Eftersom ordet »plats« på
svenska låter så allmängiltigt föredrar jag att kalla dessa platser för Active
Directory-plats eller AD-plats. Det finns ingen motsvarighet till AD-platser i
Windows NT-domäner varför det kan vara ett helt nytt begrepp för många.
Microsoft Exchange Server har arbetat med ett platsbegrepp sedan flera år,
men det är litet annorlunda än i Active Directory-fallet. Enligt Microsoft
skall alla deras produkter så småningom använda samma platsbegrepp som
Active Directory, alltså AD-platser.
Min tanke med att använda ordet »AD-plats« är att leda tankarna mot det
faktum att AD-platser har allt med Active Directory att göra, men kom ihåg
att Microsoft alltid använder ordet »plats« eller »site«.
Microsofts definition av AD-plats
Windows 2000 Server Deployment Planning Guide i Microsoft Windows 2000
Server Resource Kit har denna förklaring av AD-plats//site:
site
A location in a network that holds Active Directory servers. A site
is defined as one or more well-connected TCP/IP subnets.
(“Well-connected” means that network connectivity is highly reliable and fast.) Because computers in the same site are close to
each other in network terms, communication among them is reliable, fast, and efficient. Defining a site as a set of subnets allows
administrators to configure Active Directory access and replication topology to take advantage of the physical network. When
users log on to the network, Active Directory clients find Active
Directory servers in the same site as the client.
Letar vi i Microsoft TechNet finner vi en förklaring hämtad från kapitel 4 i
MCSE Training Kit – Upgrading to Microsoft Windows 2000:
A site is a combination of one or more Internet Protocol (IP)
subnets, which should be connected by a high-speed link.
Typically, a site has the same boundaries as a local area network
(LAN). When you group subnets on your network, you should
combine only those subnets that have fast, cheap, and reliable
network connections with one another. “Fast” network connections are at least 512 kilobits per second (Kbps). An available
203
14 DC-platser och domänkontrollanter
bandwidth of 128 Kbps and higher is sufficient. Defining sites as
a set of subnets allows you to configure the Active Directory
directory services access and replication topology to take
advantage of the physical network.
You create sites for two primary reasons:
‰ To optimize replication traffic
‰
To enable users to connect to a domain controller by using a
reliable, high-speed connection
Sammanförs dessa båda förklaringar finner vi att en AD-plats utmärks av
följande egenskaper:
‰
Det finns klientdatorer med Active Directory-klientprogramvara eller
klientdatorer från vilka man loggar in till domänen (Windows 95/98datorer utan Active Directory-klientprogramvara)
‰
Det finns ett eller flera IP-subnät med snabba förbindelser inom ADplatsen, åtminstone 512 kilobit/s med 128 kbit/s tillgängligt
‰
AD-platser har namn som bestäms av administratörer
Nu till något mycket viktigt, som inte framgår av Microsofts definitioner:
‰
Det kan finnas en eller flera domänkontrollanter som använder Windows
2000 Server, någon av dess storasystrar, eller Windows Server
Med andra ord: man kan tänka sig att upprätta AD-platser som endast innehåller klientdatorer och vanliga servrar (Windows 2000/XP/Server och andra Windows-varianter med Active Directory-klientprogramvara), utan domänkontrollanter. Det är nämligen möjligt att låta en viss domänkontrollant
(om den använder Windows 2000/Server) hantera klientdatorer och domäninloggning från fler än en AD-plats. Detta görs genom ett enkelt och
smärtfritt ingrepp i Registret på domänkontrollanten.
DC1
DC2
DC1
DC2
DC3
DC3
Figur 14-1: Två AD-platser, två olika lösningar.
204
DC4
Administratörer bestämmer vilka IP-nät (subnät) som tillhör vilka AD-platser
I den övre figurhalvan har båda AD-platserna egna domänkontrollanter, i
den undre har DC2 och DC3 ansvar för båda AD-platserna.
Det är inte något krav på olika IP-subnät för att kunna dela in nätverket i
olika AD-platser. Men, om vi inte använder olika IP-subnät så kan vi endast
styra replikering mellan domänkontrollanter med hjälp av AD-platser, vi kan
inte styra inloggning.
Vilket ses i den andra förklaringen ovan är AD-platser till för att möta ett
eller båda av dessa behov:
‰
Styrbar replikeringstrafik mellan domänkontrollanter
‰
Styrning av klientdatorer och användarinloggning till de närmaste domänkontrollanterna
För att det skall vara möjligt att styra replikeringstrafiken mellan domänkontrollanter måste de använda Windows 2000/Server eller någon av dess
storasystrar. Det duger alltså inte med de reservdomänkontrollanter som använder Windows NT Server 4.0 i Active Directory-domänen. Reservdomänkontrollanter med Windows NT Server 4.0 kan fungera i en Active Directory-domän så länge domänen använder körläget blandat läge//mixed mode.
Klientdatorer och användarinloggning kan styras till närmaste domänkontrollant när Active Directory-klientprogramvara är installerad på datorn.
Självklart är denna inbyggd i Windows 2000/XP Professional och andra
Windows 2000/XP/Server-versioner. Active Directory-klientprogramvaran
för Windows 95 och Windows 98 följer med på cd:n med installationsfiler
för Windows 2000 Server. För Windows NT 4.0 gäller att Active Directoryklientprogramvaran kan hämtas hos Microsoft (http://www.eu.microsoft
.com/windows2000/server/evaluation/news/bulletins/adextension.asp).
Administratörer bestämmer vilka IP-nät (subnät) som tillhör vilka AD-platser
Mer om IP-nät senare i detta kapitel, men låt mig redan nu slå fast att det är
administratörerna som bestämmer kopplingen mellan IP-nät (subnät) och
AD-platser. Två IP-nät på 1 000 kilometers avstånd kan mycket väl ingå i
samma AD-plats, likväl som IP-nät i samma fastighet kan ingå i olika ADplatser.
Min definition av Active Directory-plats, AD-plats
Med Active Directory-plats, AD-plats, menar jag:
‰
Ett eller flera IP-subnät som innehåller Active Directory-domänmedlemmar och/eller datorer från vilka man kan logga in med domänkonton till
Active Directory
Jag är alltså inte särskilt intresserad av nätverkshastighet – funktion går före!
Exempel på Active Directory-platser, AD-platser
En Active Directory-plats, AD-plats, kan alltså innehålla datorer med många
olika operativsystem. Kom ihåg att det vanligaste är att AD-platser innehåller domänkontrollanter med Windows 2000/Server, med det är fullt tillåtet
205
14 DC-platser och domänkontrollanter
med AD-platser som inte innehåller några domänkontrollanter. Några
exempel på båda slagen:
AD-platser med domänkontrollanter (med Windows 2000/Server)
1. Ett, eller flera, IP-subnät med Windows Net Server som domänkontrollanter, medlemsservrar med Windows Server och klientdatorer med Windows XP
2. Ett, eller flera, IP-subnät med Windows 2000/Server som domänkontrollanter, medlemsservrar med Windows NT/2000/Server, klientdatorer
med Windows 95/98/NT (med och utan Active Directory-klientprogramvara) och klientdatorer med Windows 2000/XP Professional
3. Samma som 2, med tillägg av Linux-, Unix- och Macintosh-datorer från
vilka man kan logga in med domänkonton till Active Directory
Utan överdrift kan man väl säga att exempel 1 nog endast förekommer i
Microsoft-chefers önskedrömmmar. Gissningsvis är nog ändå exempel 2
ganska vanligt hos Microsofts kunder.
AD-platser utan domänkontrollanter (med Windows 2000/Server)
4. Ett, eller flera, IP-subnät med NetWare-servrar som innehåller filer,
skrivare och annat för användare med Active Directory-domänkonton
5. Ett, eller flera, IP-subnät som endast innehåller Linux-, Unix- och
Macintosh-datorer från vilka man kan logga in med domänkonton till
Active Directory
Med dessa exempel vill jag framhålla att man kan tänka sig att upprätta ADplatser även utan att ställa dit domänkontrollanter. De blir då ett sätt att
styra inloggningstrafiken dit man vill.
AD-platsers namn
AD-platser finns alltid när vi har Active Directory-domäner. Skulle vi välja
att helt strunta i allt vad AD-platser heter så upprättas det ändå en AD-plats
med namnet Namn-plats-1//Default-First-Site-Name. (I Windows Server
heter den i stället Default-First-Site.) Det står administratörer fritt att när
som helst byta namn på AD-platserna. Namnsättningen är mycket fri och
påverkar endast just AD-platser. Eftersom det handlar om fysiska nätverk
och driftställen kan det vara idé att återanvända de namn som ändå givits
dessa ställen. Man bör undvika att använda annat än engelska bokstäver och
siffror. Det går visserligen att kalla en AD-plats »Skånevägen«, men när
något händer och andra verktyg måste plockas fram så får man själv
översätta de svenska tecknen åt verktygen.
206
IP-adresser är tudelade
Namn-Plats-1//Default-FirstSite-Name
Figur 14-2: En nyinstallerad domän finns alltid på en AD-plats med namnet Namn-plats1//Default-First-Site-Name (lång-kort är Morsekoden för »A«, som i AD-plats).
IP-adresser är tudelade
Att dela in sitt nätverk i olika IP-subnät är ett vanligt sätt att dela upp nätverket. Active Directory använder just IP-subnät som ett sätt att upprätta
AD-platser. IP-subnätet knyts till en viss AD-plats av organisationens egna
administratörer. Vad är då IP-subnät? Ett IP-subnät kallas ett IP-nät som
delats upp i flera delar. Det är ingen teknisk skillnad mellan ett IP-nät och
ett IP-subnät, endast en logisk. Alla datorer som använder nätverksprotokollet TCP/IP finns i ett visst IP-nät. Vilket IP-nät de finns i bestäms av hur
många binära siffror i subnätmasken som är satta till 1 (binära siffror kan
endast anta värdet 1 eller 0).
Varje dator som använder TCP/IP-protokollet måste på något sätt tilldelas en egen IP-adress och tillhörande subnätmask. Datorn kan inte fungera
om den inte får både och. IP-adresser är 32-bitars heltal och det samma
gäller subnätmasken. För att bli lättare att hantera skrivs IP-adresser med ett
särskilt format, ex. 10.55.11.17, alltså som fyra heltal med punkt mellan dem.
Vart och ett av de fyra heltalen kan anta värden mellan 0 och 255.
Inom det egna nätverket är det vanligt att man använder ett av tre IP-nät:
10.0.0.0, 172.16.0.0 eller 192.168.0.0. Just dessa tre IP-nät rekommenderas
för privat användning i ett av dokumenten, Address Allocation for Private Internets (RFC 1918), i dokumentsamlingen Request for Comments, RFC, som
finns på http://www.rfc-editor.org. Anledningen till att de är tre är helt
enkelt att de skall kunna användas av olika stora organisationer.
Låt oss se hur IP-nät 10.0.0.0 kan användas. För det första kommer alla
datorer i det nätverket att få en IP-adress som börjar med 10. Därefter är det
fritt fram för administratörer att tilldela datorer lämpliga IP-adresser. Vilken
subnätmask skall då användas med detta IP-nät? I ovan nämna dokument,
RFC 1918, står det att subnätmasken 255.0.0.0 skall användas i IP-nätet
10.0.0.0. Då vet vi allt som behövs: datorer tilldelas en IP-adress som börjar
med 10, kanske 10.55.11.17 och subnätmasken 255.0.0.0.
För att se vilka datorer som finns i samma IP-nät/subnät undersöker
man deras IP-adress och subnätmask. När subnätmasken är antingen 255
.0.0.0, 255.255.0.0 eller 255.255.255.0 är det enkelt att avgöra om datorers
207
14 DC-platser och domänkontrollanter
IP-adress tillhör samma IP-nät. Om subnätmasken är 255.0.0.0 så innebär
det alla datorer som har samma första del, av fyra, tillhör samma IP-subnät.
I vårt fall innebär det alla IP-adresser som börjar på 10 och där subnätmasken är 255.0.0.0 tillhör samma IP-nät/subnät. Skulle vi sätta ytterligare åtta binära siffror i subnätmasken till 1 så fås 255.255.0.0. Då hamnar
alla IP-adresser där de två första leden är lika i samma subnät. Ex. finns IPadresserna 10.55.11.17 och 10.55.12.14 i samma IP-nät om båda använder
subnätmasken 255.255.0.0. Men, IP-adressen 10.54.7.27 är inte i samma subnät som 10.55.11.17 och 10.55.12.14, förutsatt att alla tre använder subnätmasken 255.255.0.0.
Det är alltså omöjligt att uttala sig om IP-nättillhörighet om man inte
känner både IP-adressen och subnätmasken. Den lilla övning vi gjorde ovan,
att öka antalen ettor i subnätmasken är alltid tillåtet. Genom att öka antalet
ettor i subnätmasken upprättar vi flera IP-subnät. I vårt fall fick vi 256
subnät som kan användas för att dela in vårt nätverk i lika många delar. För
att uppdelningen skall fungera måste vi nu använda routrar mellan de olika
subnäten, annars kan inte nätverkstrafik flöda mellan dem.
Det är just IP-nät/subnät, som kan användas för att dela in nätverket i
olika AD-platser. Det är inget krav på att använda olika IP-nät, det går att
göra flera AD-platser i samma IP-nät/subnät. Detta blir då mer ett sätt att
styra replikeringstrafiken mellan domänkontrollanter än ett sätt att låta
klientdatorer kontakta närmaste domänkontrollant.
Ingen given koppling mellan IP-nät och AD-plats
Som redan nämnts kan en AD-plats omfatta flera IP-nät och det kan även
finnas flera AD-platser i samma IP-nät.
simplex.se
simplex.se
teraplex.se
sales.simplex.se
Figur 14-3: Till vänster en domän som finns på tre AD-platser, till höger en AD-plats som
omfattar tre domäner (två domänskogar).
Hur vet en klient vilken AD-plats den tillhör?
I Active Directory-domäner finns »allt« i katalogtjänsten, där finns information om användarkonton och datorkonton; där finns digitala certifikat för
användare och dator; där kan finnas DNS-poster; där finns delar av gruppprinciper, o.s.v. För AD-platserna gäller att nästan all information om dem
208
Hur vet en klient vilken AD-plats den tillhör?
finns i Active Directory. I katalogtjänsten finns denna information för ADplatser:
‰
AD-platsens namn
‰
En lista över de domänkontrollanter som är knutna till AD-platsen
‰
En lista över de IP-subnät, ett eller flera, som är knutna till AD-platsen
Det finns ingen information i katalogtjänsten om vilken AD-plats som klientdatorer tillhör. Samtidigt behövs information just om AD-platstillhörighet för att klientdatorer skall kunna kontakta de egna domänkontrollanterna,
de som finns på samma AD-plats som klientdatorn. Microsofts lösning på
detta »problem« är att undersöka AD-platstillhörighet varje gång datorn startar och loggar in till domänen, om det är en Windows NT/2000/XP/Server-dator, annars när användaren loggar in till domänen. Denna information
sparas sedan i Registret på datorn.
Active Directory-klienter finner en domänkontrollant genom att ställa en
DNS-fråga till sin DNS-server. Den första domänkontrollanten som kontaktas fastställer klientdatorns IP-nätadress. Med hjälp av listan över vilka
IP-nät som är knutna till olika AD-platser samt listan över vilka domänkontrollanter som är knutna till olika AD-platser kan domänkontrollanten avgöra
vilka domänkontrollanter som finns närmast klientdatorn.
AD-platstillhörighet är avgörande för grupprinciper
Förutom att underlätta kontakt med närmaste domänkontrollant används
även AD-platstillhörighet för att avgöra om en grupprincip knuten till en
AD-plats skall användas på en viss klientdator. Detta gör att grupprinciper
för AD-platser en smula speciella. För att kunna avgöra om en grupprincip
knuten till en viss AD-plats kommer att användas av en viss dator måste
man alltså veta vilket IP-nät som datorn finns i samt vilken AD-plats detta
IP-nät är knutet till.
Grupprinciper knutna till AD-platser har en annan intressant egenskap:
de kan användas av flera domäner i samma domänskog. Om, delar av, flera
domäner, i samma domänskog, finns på samma AD-plats kan samma ADplatsgrupprincip användas i samtliga domäner.
För grupprinciper knutna till domän eller organisationsenhet behöver
man ju endast ta reda på var någonstans i katalogtjänsten som användarkontot och datorkontot finns för att kunna räkna ut vilka grupprinciper som
kommer att användas. Om en dator flyttas från ett IP-nät till ett annat påverkar på intet sätt dessa grupprinciper, till skillnad från hur AD-platsgrupprinciper fungerar.
Det fungerar likadant för alla datorer som inte är domänkontrollanter
Ovan har jag endast nämnt klientdatorer, men samma tillvägagångssätt gäller
för alla datorer i en Active Directory-domän som antingen använder Windows 2000/XP/Server eller har Active Directory-klientprogramvara installerad.
209
14 DC-platser och domänkontrollanter
AD-platser används vid installation av Active Directory
Om vi delat in nätverket i AD-platser med hjälp av olika IP-subnät så finns
med andra ord möjlighet att avgöra vilken AD-plats en dator finns på genom att undersöka dess IP-nätadress. Detta används vid installation av domänkontrollantdelen av Active Directory på Windows 2000/Server. Den
nya domänkontrollanten registrerar sig helt enkelt på rätt AD-plats med ledning av sin egen IP-adress och den lista över kopplingar mellan AD-platser
och IP-nät som finns i katalogens innehåll.
Nästan alla domänkontrollanter har ändringsbar kopia av kontodatabasen
I Active Directory-domäner har domänkontrollanter en ändringsbar kopia
av domänens kontodatabas. Detta gäller dock endast de domänkontrollanter
som använder Windows 2000/Server. Om Active Directory-domänen tillkommit genom uppgradering av en Windows NT-domän så kan det finnas
reservdomänkontrollanter med Windows NT Server 4.0. Dessa fortsätter att
fungera som tidigare, d.v.s. de kontaktar vad de tror vara en primär domänkontrollant när kontodatabasen skall ändras och när de skall hämta uppdateringar. Den domänkontrollant som de kontaktar är alltid den dator med
Windows 2000/Server som tilldelats rollen att vara PDC-emulator, den härmar alltså en primär domänkontrollant i en Windows NT-domän.
För domänkontrollanter med Windows 2000/Server gäller alltså att de
alla har en ändringsbar kopia av domänens kontodatabas. När en användare
skall ändra sitt kontos lösenord står det hennes dator fritt att kontakta lämplig domänkontrollant. Det tar oss inte lång tid att inse att de lämpligaste domänkontrollanterna för detta är de som finns på samma AD-plats som användarens dator. Om AD-platser bildats genom att sammanföra IP-nät så är
det enkelt att avgöra vilka domänkontrollanter som finns på samma ADplats som klientdatorn: domänkontrollanten stämmer helt enkelt av klientdatorns IP-nättillhörighet mot tabellen över AD-platser och IP-nät. Utan
koppling mellan IP-nät och AD-plats finns det ingen möjlighet att avgöra
vilken domänkontrollant som är på samma AD-plats som en viss dator.
Klientdatorn kommer i detta fall att koppla sig till en domänkontrollant utan
att ge någon enskild särskild företräde.
Endast Windows 2000/XP Professional och Windows 95/98 med Active Directory-klienten kontaktar närmaste domänkontrollant för att ändra
lösenord. Microsoft klarade inte av att göra detta i Active Directory-klienten
för Windows NT Workstation.
Byte av lösenord sker på olika sätt
Domänmedlemmar med Windows 2000/XP/Server, alltså de som har en
inbyggd Active Directory-klient, kontaktar de närmaste domänkontrollanterna även vid lösenordsbyte. De uppräknade operativsystemen byter alla lösenord på sitt datorkonto en gång vart 30:e dygn. Vid detta tillfälle kontaktas
alltså den närmaste domänkontrollanten. Likaså kontaktas den närmaste
domänkontrollanten när en användare på en sådan dator ändrar lösenordet
för sitt domänkonto.
Windows NT-datorer med Active Directory-klienten kommer att byta
lösenord för sitt datorkonto på samma sätt som i Windows NT-domäner:
210
Replikeringstrafik inom AD-plats: ändringsstyrd, kan även schemaläggas
genom att kontakta en enda, utvald, domänkontrollant. I Active Directorydomäner är det PDC-emulatorn som kontaktas av Windows NT-datorer.
Windows NT-datorer byter sitt lösenord vart sjunde dygn, vilket gör det
mindre lämpligt att slå samman många Windows NT-domäner till färre
Active Directory-domäner. Även användares lösenordsbyte styrs till PDCemulatorn.
För Windows 95/98 gäller att de inte har några datorkonton, så ingen sådan trafik uppstår. Användare på Windows 95/98 byter dock sina lösenord
på den närmaste domänkontrollanten, när datorn utrustats med Active Directory-klienten.
Replikeringstrafik inom AD-plats: ändringsstyrd, kan även schemaläggas
Replikeringstrafik mellan domänkontrollanter på samma AD-plats styrs alltid av ändringar i kontodatabasen. Förvalt värde, av Microsoft, är att replikeringen börjar fem minuter efter första ändring. Alltså, om en användare
byter lösenord på sitt konto kommer den domänkontrollant som mottagit
ändringsbegäran att upplysa sin närmaste domänkontrollantgranne om detta
fem minuter efter ändringen.
Utöver denna ändringsstyrda replikering används också schemalagd
replikering. Microsoft har valt att låta domänkontrollanterna kontakta sina
närmaste grannar en gång i timmen. Även denna inställning står det administratörer fritt att ändra.
När en domänkontrollant kontaktar sina replikeringspartner sker den
första kontakten fem minuter efter ändring i den egna kontodatabasen. Därefter väntar den trettio sekunder innan den kontaktar nästa replikeringspartner. Denna tid är ändringsbar genom att ändra ett värdes innehåll i Registret.
Både väntetid efter ändring och den schemalagda kontakten kan ändras
från Microsofts förval. För att ändra replikeringsstart från fem minuter efter
ändring så ändras ett värdes innehåll i Registret. Detta görs på varje domänkontrollant för sig. Schemaläggningen är enklare att styra, det görs från administrationsverktyget Active Directory - platser och tjänster//Active Directory Sites and Services.
Ändringar rör sig mellan domänkontrollanter genom att alla ändringar i
kontodatabasen behandlas på samma sätt. Det spelar ingen roll om en ändring uppstått genom att en användare eller administratör ansluter till en viss
domänkontrollant och ändrar på den eller om en annan domänkontrollant
skickat ändringen. Oavsett hur ändringen uppstått så startar domänkontrollanten sitt eget replikeringstidur och börjar skicka vidare till sina egna replikeringspartner efter fem minuter. För att undvika att ändringar åker runtrunt mellan domänkontrollanterna så håller de reda på vilken domänkontrollant som objektet först ändrades på och avböjer uppdateringar som de redan
fått.
Domänkontrollanter har oftast två favoritgrannar
Med en ändringsbar kopia av Active Directory-domänens kontodatabas på
varje domänkontrollant måste arbetet med att hålla kontodatabasen upp-
211
14 DC-platser och domänkontrollanter
daterad vara noga genomtänkt. I Active Directory försöker Microsoft lösa
problemet genom att varje domänkontrollant håller reda på vilka andra domänkontrollanter som finns på samma AD-plats. De kommer överens om
att bilda dubbla langningskedjor så att varje domänkontrollant endast skickar
vidare till två av sina närmaste grannar. Att kedjorna görs dubbla är en
säkerhetsåtgärd för att ändringsinformation skall kunna skickas vidare även
om en domänkontrollant plötsligt skulle bryta kedjan, sluta fungera.
DC5
DC4
DC3
DC6
DC1
DC2
Figur 14-4: Med upp till sex domänkontrollanter på samma AD-plats har varje domänkontrollant två replikeringsgrannar.
Inom varje AD-plats har Microsoft satt som mål att alla domänkontrollanter
skall vara uppdaterade inom femton minuter. Med upp till sex domänkontrollanter på samma AD-plats kan målet klaras med två dubbla langningskedjor och två replikeringspartner för varje domänkontrollant. Behövs det
fler domänkontrollanter än sex så kommer de att bilda extra langningskedjor
så att det aldrig tar mer än femton minuter för en ändring att nå alla domänkontrollanter på samma AD-plats. Nu skall vi inte stirra oss blinda på
uppgiften femton minuter. I själva verket är Microsofts mål att en viss ändring inte skall transporteras med fler än tre hopp. Med förvalda inställningar
blir tre hopp just femton minuter.
Replikering mellan AD-platser
Det finns flera stora skillnader mellan replikering inom en AD-plats och
mellan AD-platser:
212
‰
Mellan AD-platser sker ingen uppdatering utlöst av ändring i kontodatabasen (detta kan ändras av administratörer)
‰
Mellan AD-platser sker uppdatering enligt schema som bestäms av administratörer
‰
Mellan AD-platser är det endast utvalda domänkontrollanter som
kontaktar domänkontrollanter på andra AD-platser
AD-platser kan hjälpa varandra
DC2
DC3
DC7
DC6
DC1
DC4
DC5
Figur 14-5: Replikering mellan två AD-platser.
Om administratörer inte ändrar förvalda inställningar så sker replikering
mellan AD-platser var tredje timme. Det innebär att en ändring på en ADplats i genomsnitt tar en och halv timme innan den är känd av domänkontrollanter på andra AD-platser. Vad som händer om en användare byter
lösenord för sitt eget konto på »sina« domänkontrollanter och sedan försöker komma åt servrar på andra AD-platser är inte svårt att räkna ut: åtkomst
nekas. Här visar sig Microsofts kungstanke med Active Directory-domäner:
tanken är att användare helt enkelt aldrig skall behöva komma åt något som
inte finns på samma AD-plats som hennes egen dator.
Schemat för replikering mellan AD-platser kan styras så att tiden mellan
två replikeringar är från femton minuter till sju dygn. Femton minuter är det
minsta tidssteget, så man kan ange femton minuter, trettio minuter, o.s.v.,
upp till 10 080 minuter (sju dygn).
Domänkontrollanterna väljer själva en kollega att sköta trafiken mellan
AD-platser. Valet kan också göras av administratörer. Den domänkontrollant som utför denna viktiga uppgift kallas brohuvudserver//Bridgehead
Server.
Låt oss använda bilden ovan som ett exempel på hur det blir med
förvalda inställningar. Antag att något ändras på domänkontrollant DC3.
Efter fem minuter kontaktar den DC1 och efter fem och halv minut DC2.
DC2 råkar vara brohuvudsserver och den som faktiskt kontaktar andra ADplatser. Vi antar att den schemalagda kontakten råkar ske direkt efter att
DC2 blivit uppdaterad. Ändringen finns alltså på DC7 fem och en halv
minut efter ändringen på DC3. Efter att DC7 själv uppdaterat DC4 och
DC6 kommer DC7 att vara uppdaterad femton och en halv minut efter den
första ändringen på DC3.
Förmodligen är inte ert eget nätverk lika idealiskt som Microsoft tänkt
sig. Av den anledningen är det möjligt att låta också replikeringen mellan
AD-platser styras av att kontodatabasen ändrats på en domänkontrollant.
Då får vi alltså ungefär samma replikeringsmönster som inom AD-platser.
AD-platser kan hjälpa varandra
Microsoft har gjort de kopplingar som förbinder brohuvudservrar//Bridgehead Servers, AD-platskopplingar (platslänk//site link), sådana att om en
försvinner så kan andra användas i dess ställe.
213
14 DC-platser och domänkontrollanter
DC2
DC3
DC7
DC6
DC4
DC5
DC1
Figur 14-6: Tre AD-platser med tre AD-platskopplingar.
Med AD-platser som i figuren ovan kan två av kopplingarna ersätta den
tredje. Antag att förbindelsen från den vänstra AD-platsen direkt till den
mittersta bryts. Då kan replikeringen i stället ske från den vänstra ADplatsen till den högra och sedan från den högra till den i mitten. Microsoft
kallar detta AD-platslänksbrygga//Site Link Bridge. De upprättas automatiskt, men kan även styras av administratörer.
Domänkontrollanter är snackiga
Jag har genomfört ett intressant experiment med domänkontrollanter som
använder Windows 2000 Server. Den aktuella domänen innehöll fyra domänkontrollanter och jag var nyfiken på att se hur mycket trafik som utväxlades mellan dem. Först fick de stå i två dygn utan minsta ändring av kontodatabasens innehåll. Sedan spelades all nätverkstrafik mellan dem in under
en timme. Det visade sig att domänkontrollanterna skickade några tiotal
kilobyte till varandra under denna timme. Så fast de inte har något att säga
varandra är det en hel del snack mellan dem.
Styra replikeringstrafiken med hjälp av AD-platser
Ett sätt att använda AD-platser är alltså för att styra replikeringstrafik. Inom
AD-platser är det i praktiken så att ändringar i kontodatabasen utlöser replikering. Detta kan självklart ändras genom att sätta väntetiden efter ändring
till en timme eller mer och låta den schemalagda ändringen bli den styrande.
Mellan AD-platser kan vi välja mellan att enbart använda schemalagd
uppdatering eller både schemalagd och ändringsstyrd, så som det fungerar
inom AD-platser.
För att kunna använda AD-platser för att styra replikering behöver inte
AD-platsen knytas till ett eller flera IP-nät. Samtliga AD-platser kan finnas i
samma IP-nät. Det räcker att upprätta de AD-platser man behöver och flytta
domänkontrollanter till lämplig AD-plats.
Styra inloggning till närmaste domänkontrollant
För att kunna styra inloggning till närmaste domänkontrollant, en som finns
på samma AD-plats som klientdatorn gäller att ett grundvillkor måste vara
uppfyllt: AD-platser måste knytas till IP-nät. Detta beror på det enkla faktum att domänkontrollanter som mottar en inloggningsbegäran från en klient jämför klientdatorns IP-adress med listan över AD-platser och IP-nät.
Om den därvid finner att det finns domänkontrollanter i samma IP-nät eller
i ett annat IP-nät som är kopplats samma AD-plats så skickas klientdatorn
vidare till en av de domänkontrollanterna.
214
AD-platser med IP-nät påverkar DHCP-servern
Utöver detta grundvillkor gäller att:
‰
Datorn måste använda Windows 2000/XP Professional eller ha Active
Directory-klientprogramvaran installerad
‰
Domänkontrollanterna måste använda Windows 2000/Server
AD-platser med IP-nät påverkar DHCP-servern
Använder vi möjligheten att knyta IP-nät till olika AD-platser måste vi även
hantera uppgifter om DNS-servrar för klienterna. Med den DHCP-servertjänst som är inbyggd i Windows 2000/Server kan man upprätta IP-adressområden för ett flertal IP-nät. Har man valt att lösa DNS-funktionen
genom att låta DNS-databasen bli en del av Active Directory-databasen så
blir alla domänkontrollanter därmed DNS-servrar (glöm inte att installera
DNS-servertjänsten). I detta fall måste varje IP-adressområde på DHCPservern utformas så att klientdatorer på en viss AD-plats får domänkontrollanten på denna AD-plats som DNS-server. Utan denna inställning kommer
Windows 2000/XP/Server-datorer att gå utanför sin egen AD-plats för att
hitta DNS-servrar. Med flera domänkontrollanter på samma AD-plats bör
man fördela DNS-serveruppgifterna så att de olika klienterna använder olika
domänkontrollanter som första och andra DNS-server.
Windows 2000/XP/Server-datorer registrerar sig själva hos DNS-servern
Det finns ytterligare en pusselbit i detta med AD-platser: dynamisk DNS.
När Windows 2000/XP/Server-datorer som är medlemmar i en Active Directory-domän startar så registrerar de själva sina DNS-poster i DNS-servern. Denna registrering kan väljas bort genom att ändra i Registret på datorerna. Skulle administratörer så önska kan DHCP-servern registrera DNSposter för samtliga DHCP-klienter i stället.
Innan vi överväger vilket som är det bästa sättet att göra detta kanske vi
skall fundera på varför Windows 2000/XP/Server-datorer skall finnas i
DNS-databasen över huvud taget. I grunden ersätter DNS i Windows 2000/
XP/Server NetBIOS som namnhanteringsmetod. Namn används ex. när
man från en dator vill koppla sig till en utdelad resurs på en server, man skriver »net use x: \\server\resursnamn«. Om det är enda behovet skulle vi endast
behöva registrera serverarna i DNS-databasen, inte klientdatorerna. Med serverdatorerna i DNS-databasen kan man göra samma anslutning om ovan
med denna kommandorad: »net use x: \\server.organisation.se\resursnamn«. En
annan metod är att fortsätta använda NetBIOS även för Windows 2000/
XP/Server-datorer. Då faller behovet att registrera dem i DNS-databasen.
Antag att vi låter klientdatorerna med Windows 2000/XP/Server själva
registrera och underhålla egna DNS-poster i DNS-databasen. Vid systemstart kommer de då att kontakta sin DNS-server för att få IP-adressen till
den DNS-server som är huvudserver, Primary Master, för DNS-domänen.
Därpå kontaktas just huvudservern och posterna registreras eller uppdateras.
Nu finns det flera möjligheter: om man använder den inbyggda DNS-servern i Windows 2000/Server kan DNS-databasen vara fristående eller en del
av Active Directory-databasen. När den är en del av Active Directory-databasen så kommer alla domänkontrollanter också att vara DNS-servrar.
215
14 DC-platser och domänkontrollanter
Lämpligen har då alla Windows 2000/XP/Server-datorer på en viss ADplats fått uppgift om att deras domänkontrollanter också är deras DNS-servrar. Det finns inget hemligt i detta, det är bara att på vanligt sätt ange IP-adress till DNS-servrarna. När klientdatorn kontaktar DNS-servern vid systemstart för att få IP-adressen till huvudservern kommer domänkontrollanten helt fräckt påstå att den själv är huvudserver. På så sätt blir det den närmaste domänkontrollanten som mottar registreringen/uppdateringen av
DNS-posterna. Med denna metod kommer alltså även denna DNS-trafik att
hålla sig på samma AD-plats som klientdatorn.
Skulle man istället låta DHCP-servern uppdatera DNS-poster för sina
klienter blir det oftast samma DNS-server som kontaktas. DNS-klienter kan
ha flera DNS-servrar angivna i IP-inställningarna, men den kontaktar alltid
den första så länge den är tillgänglig. I detta fall är ju DHCP-servern att
betrakta som en DNS-klient.
Minst en domänkontrollant bör ha tillgång till den globala katalogen
Den globala katalogen används flitigt i Active Directory-domäner. Dess
största användning är vid sökning efter utdelade skrivare och information
om användarkonton. Därtill kommer uppgiften att hjälpa till vid inloggning i
domäner som arbetar i enhetligt läge//native mode.
För att klara denna uppgift samlar den globala katalogen information
från alla domäner i samma domänskog.
Vill vi hålla även trafik mellan användarnas datorer och den globala katalogen inom samma AD-plats så bör minst en, helst två, av domänkontrollanterna på AD-platsen även härbärgera den globala katalogen.
Detta gäller inte Windows NT Server!
Allt det ovan sagda om AD-platser och domänkontrollanter gäller endast
domänkontrollanter med Windows 2000/Server, inte reservdomänkontrollanter med Windows NT Server när Active Directory-domänen kör i blandat
läge//mixed mode.
Är långsamma förbindelser det allena avgörande?
Microsoft anger att om olika nätverksdelar är sammankopplade med förbindelser som klarar minst 512 kbit/s, varav 128 kbit/s ledigt, så behöver
man inte upprätta AD-platser mellan dem. Hur blir det om vi vänder på
steken? Hur skall det se ut för att man faktiskt skall upprätta ytterligare en
AD-plats och ställa dit domänkontrollanter?
Till grund för detta beslut måste vilket ger minst nätverkstrafik: att placera en domänkontrollant, eller två, på andra sidan en långsam förbindelse
eller att låta inloggningstrafiken passera den långsamma förbindelsen. Med
en bild ser det ut så här:
216
Är långsamma förbindelser det allena avgörande?
DC1
DC2
DC1
DC2
DC3
DC4
Figur 14-7: Två olika sätt att hantera en långsam nätverksförbindelse.
En del eftertanke ger vid handen att det är flera olika saker som påverkar.
Om man avser att upprätta en AD-plats på den långsamma sidan, som i den
undre halvan av bilden, så måste man tänka på detta:
‰
Körläge för de olika domänerna i domänskogen. Om minst en domän
använder enhetligt körläge//native mode så måste domänkontrollanter
på den långsamma AD-platsen härbärgera den globala katalogen.
‰
Domänskogens storlek, all den stund att domänkontrollanterna på den
långsamma AD-platsen också har den globala katalogen. Ju mer innehåll
i de ingående domänerna desto mer replikeringstrafik.
‰
Den egna domänens storlek. Alla domänkontrollanter, oavsett vilken
AD-plats de finns på, har alltid en kopia av hela innehållet i katalogen för
den egna domänen. Ju fler objekt och ju fler attribut och ju oftare dessa
ändras desto mer nätverkstrafik.
‰
Domänkontrollanters »snackighet«. Jag har i mina undersökningar kommit fram till att domänkontrollanter snackar med varandra mycket oftare
än som verkar nödvändigt. Om detta sker även mellan AD-platser kan
det leda till ökade kostnader (om man ex. förlitar sig på ISDNförbindelser).
Överväger man i stället att inte upprätta ytterligare en AD-plats så måste
detta betänkas:
‰
Resursbehov vid inloggning. Windows NT/2000/XP/Server-datorer
loggar in med datorkontot vid start, användare loggar in till domänen
och loggar även in vid besök på servrar som inte är domänkontrollanter.
‰
Resursbehov vid byte av lösenord. Windows NT-datorer byter lösenord
för sitt datorkonto vart sjunde dygn, Windows 2000/XP/Server-datorer
byter vart 30:e dygn. Användare byter lösenord med intervall som anges
av administratörer.
217
14 DC-platser och domänkontrollanter
‰
Hur mycket utnyttjar användarna den globala katalogen? Varje gång den
används kommer deras datorer att koppla sig till en domänkontrollant
med den globala katalogen. Denna trafik förekommer endast om användarnas datorer är Active Directory-klienter.
Domänkontrollanter kan hantera flera AD-platser – »site coverage«
Tar vi med i beräkningen möjligheteten för domänkontrollanter att hantera
fler än en AD-plats så har vi tre möjligheter. Dels kan vi strunta i att upprätta en ny AD-plats och låta klienter i nätverksdelar utan AD-platser (och därmed utan domänkontrollanter) bli inloggade av slumpvist valda domänkontrollanter. Vi kan också upprätta fullständiga AD-platser överallt där det finns
AD-klienter eller användare som loggar in med AD-konton. Den tredje möjligheten är det som Microsoft kallar »site coverage«, d.v.s. man låter utvalda
domänkontrollanter på en AD-plats även serva klienter på annan AD-plats
(en eller flera). De AD-platser som får hjälp kan själva innehålla domänkontrollanter eller de kan vara helt utan, era behov avgör.
DC1
DC2
Figur 14-8: Ingen styrning av inloggning i det högra nätverket.
DC1
DC2
DC3
DC4
Figur 14-9: En AD-plats för varje nätverksdel, med domänkontrollanter på samtliga ADplatser.
DC1
DC2
DC3
Figur 14-10: Utvalda domänkontrollanter i den vänstra AD-platsen servar klienter i den
högra AD-platsen (som inte har egna domänkontrollanter).
218