*** UPDATE *** nieuwe versie van dit artikel op www.ginsys.be/windows-active-directory-en-dns-namespaces

Microsoft Windows Active Directory. Afgekeken van Novel Netware. Ldap en kerberos met extra netwerk beheers mogelijkheden.

De eerste grote nieuwigheid, toen Microsoft dit eind 1999 introduceerde in Windows 2000, was dat een “NT domeinnaam” niet langer één woordje was (à la WORKGROUP) maar samenhing met een dns domeinnaam (à la contoso.com). Over DNS zelf – iets dat eigenlijk héél eenvoudig is, maar waar velen het toch moeilijk mee hebben, omdat ze zich beperken tot de clickety-click kennis die men in Windows dienaangaande opdoet – zal ik het later nog wel eens hebben, maar vandaag wil ik even uitweiden over wat een goede naamkeuze is bij het kiezen van een domeinnaam voor je Active Directory.

Typisch wordt er gemakkelijkheidshalve als Active Directory domeinnaam hetzelfde gekozen als de geregistreerde internet dns domeinnaam van het bedrijf, company.com. Om meerdere redenen is het evenwel aan te raden om een aparte dns namespace te gebruiken.

Vanuit de algemene dns topologie: dns dient voor een stuk de fysische (maar daarom nog niet geografische) topologie weer te geven. Het meest evidente voorbeeld hiervan is het verschil tussen externe of publieke en interne of private ip adressen.

Gebruik van dezelfde domeinnaam intern en extern verplicht tot een opzet van “split brain” dns, wat betekent dat je eenzelfde zone hebt op uw interne server als op uw publieke server bij uw dns hoster (zeg maar bij Belgacom of Openminds om er 2 op te noemen.) Met als typisch gevolg dat als men niet oplet de interne gebruikers niet kunnen surfen op hun eigen website, want men is vergeten om een record “www” extra aan te maken die naar het juiste ip verwijst.

Bij de implementatie van Exchange 2000 merkt men een aantal voordelen: default wordt dat interne Active Directory domein gebruikt voor het aanmaken van emailadressen. Voor objecten die extern bereikbaar moeten zijn (bvb. gebruikers uiteraard maar er zijn nog voorbeelden) is dit uiteraard onzinnig en voor die gevallen kan men best de default creatie van emailadressen aanpassen. Doch in deze setup krijgen alle public folders, system folders en distributielijsten een intern adres. Dit heeft als voordeel dat ze niet van buitenaf bereikbaar zijn, wat meestal niet nodig is en soms zelfs ongewenst, maar bijkomend heeft men alzo een meer diverse mogelijkheid om mailaliassen te creëren. Voorbeeld: de dienst verkoop beschik over een public folder “sales” voor interne communicatie en moet ook van buitaf bereikbaar zijn via een andere public folder of via een distributielijst!

Men kan er over discussiëren welke benaming men nu intern gaat gebruiken. De mogelijkheden zijn aldus:
(“company” staat voor een domeinnaam die verwijst naar de bedrijfsnaam, “foobar” staat voor een domeinnaam die geen verband heeft met het bedrijf.)

Een nietszeggende of generieke (“foo”) second level domeinnaam is aan te bevelen indien er niet dadelijk een link is tussen het interne netwerk en het publieke aanzicht (denk localwan), of als de kans groot en reël is dat men geconfronteerd wordt met een nieuwe bedrijfsnaam.

In een KMO omgeving zal men meestal veilig kunnen kiezen voor een AD benaming zoals lan.company.com of company.local. Deze laatste is ook de standaard die Microsoft in zijn SBS setup wizard aanbiedt. In het ergste geval zou Windows 2003 een uitkomst bieden als men nood zou hebben om de zaak te hernoemen, doch als je de procedure even naleest, dan weet je alvast dat je dat niet wil doen ;-).