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 mogelijkheden die de Microsoft “Windows” interface voorschotelt – 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 éénzelfde zone hebt op uw interne server als op uw publieke server bij uw dns hoster. (bijv. Openminds) 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. (In sommige gevallen, met name waar men een host in het DMZ wil benaderen, vanop het LAN, via diens publieke IP adres, kan dit handig zijn, meer bepaald waar de firewall de adrestranslatie vanop het LAN niet kan uitvoeren.)
    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 hieronder opgesomd.
(“company” staat voor een domeinnaam die verwijst naar de bedrijfsnaam, “foobar” staat voor een domeinnaam die geen verband heeft met het bedrijf.)

    ginsys.be
    Zoals hierboven beschreven af te raden
    locallan.local
    foobar.internal
    Een 100% private benaming aangezien het top-level domein niet officieel is. Daarenboven kiest men een nietszeggende naam voor het secundaire deel, los van het bedrijf.
    ginsys.local
    een mix van een onbestaande top level domein met een benaming die verwijst naar de firma. Een veelgebruikte oplossing, welke ook standaard in Microsoft “Small Business Server” door de installatie routine voorgesteld wordt.
    lan.ginsys.be
    Hier maken we een private subzone binnen de publieke domeinnaam. Een vergelijkbare oplossing als de vorige, met het voordeel dat men binnen één namespace blijft werken.
    localwan.net
    een nietszeggende naam die ook werd geregistreerd (bijvoorbeeld localwan.net)

In bovenstaande voorbeelden werd typisch .local gekozen als top level privaat domein. Technisch gezien kan eender welke niet reeds-bestaande lettercominatie gebruikt worden (.lan wordt vaak gekozen) doch het verdient de aanbeveling om hierin de richtlijnen van RFC 2606 Reserved Top Level DNS Names te volgen.

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.

Onze persoonlijke voorkeur gaat gewoonlijk uit naar de derde optie, lan.ginsys.be