Veel gebruikers horen van systeembeheerders dat ze ‘het wel even’ binnen Active Directory (AD) zullen regelen of dat AD eerst gesynchroniseerd moet worden voordat wijzigingen zijn doorgevoerd. Maar wat is Active Directory eigenlijk en hoe werkt dat?

Domeinen en controllers

Voor veel mkb’ers geldt dat ze een op Microsoft Windows Server gebaseerd netwerk hebben. Binnen dat netwerk is een zogenaamd Windows-domein aangemaakt. Een Windows-domein is een database met beschrijvingen van alles wat zich binnen het netwerk bevindt en een relatie met elkaar heeft. Denk hierbij aan de gebruikers, de printers, de servers en bijvoorbeeld de laptops, maar ook aan de wifi access points of nassen. Al deze zaken kun je onderdeel laten uitmaken van het Windows-domein. Het heeft dus niets met domeinnamen of websites te maken.

Iets een onderdeel laten uitmaken van een domein kan handig zijn. Dat wat onderdeel is bevindt zich als het ware samen in hetzelfde huis met de andere onderdelen. Ze kunnen daardoor onderling gemakkelijker afspraken maken en er is standaard een bepaalde mate van vertrouwen, je woont immers samen. In een huis waar je samenwoont moet je er wel voor zorgen dat de voor– en achterdeur goed dicht zitten en af te sluiten zijn, maar de slaapkamerdeuren hoeven misschien niet allemaal op slot. Dat maakt toegang tot elkaar krijgen wel een stukje gemakkelijker en daarmee vriendelijker.

Om te weten te komen wie en wat zich allemaal in het domein bevindt, wordt een centrale database bijgehouden. Deze database staat op een Windows Server die een Domain Controller wordt genoemd. De database zelf wordt Active Directory genoemd.

Wil men inloggen op het netwerk, dan zal de pc de inloggegevens aan de Domain Controller aanbieden en aan hem vragen of de gebruiker toestemming krijgt om in te loggen. De Domain Controller kijkt daarvoor in zijn database (Active Directory) en als hij daar de account van de gebruiker vindt en tot de conclusie komt dat het password klopt, dan laat hij die gebruiker toe.

Het gaat verder

In Active Directory (AD) staan veel meer gegevens dan de inloggegevens alleen. Bepaalde extra toegangsfaciliteiten of –eisen kunnen ook een onderdeel van AD uitmaken. Hierdoor kan ingesteld worden dat iemand alleen op bepaalde machines mag inloggen, dat alleen bepaalde machines op het netwerk mogen komen, dat men alleen binnen bepaalde tijden en op bepaalde dagen mag inloggen of dat dubbele authenticatie nodig is om in te loggen.

Ook de apparaten binnen het netwerk staan in Active Directory en deze kunnen allerlei gegevens bij AD opvragen. Op een apparaat kan bijvoorbeeld een map zijn aangemaakt waarvan bepaald is dat alleen bepaalde gebruikers daar toegang toe krijgen. Het zou onhandig zijn om dit voor iedere gebruiker apart op te geven. Daarom maken systeembeheerders zogenaamde groepen aan. Ze kunnen een groep het recht geven om in een bepaalde map te komen en binnen AD bepalen ze welke accounts onderdeel van die groep zijn.

Als nu iemand in een bepaalde map wil komen, vraagt de machine die deze map beheert aan AD of deze account eigenlijk wel lid is van de desbetreffende groep. Zo niet, dan wordt de toegang geweigerd.

Op deze manier worden niet alleen dit soort rechten bepaald. Met behulp van AD kunnen ook diensten worden toegewezen. Via AD kan bijvoorbeeld bepaald worden dat iedereen die zich in de groep “Administratie” bevindt een bepaald softwarepakket kan gebruiken en dat iedereen die zich in de groep “Marketing” bevindt tussen 09:00 en 17:00 uur naar het buitenland mag bellen met hun VoIP telefoon.

Aan de onderdelen binnen Active Directory kunnen zogenaamde policies worden gehangen. Men zou bijvoorbeeld een policy kunnen maken voor de groep “Werkvoorbereiders” waardoor iedereen die daar lid van is automatisch bepaalde netwerkschijven krijgt of printers krijgt toegewezen. Ook zou men een policy kunnen maken voor een groep medewerkers waarvan het bureaublad wordt aangepast met iconen voor bepaalde softwarepakketten of een waarbij de instellingen van Google Chrome worden bepaald.

Een domain controller kan men hierdoor beschouwen als de plek waar authenticatie plaatsvindt voor mensen en machines en een omgeving waarmee rechten worden uitgedeeld en instellingen kunnen worden doorgegeven. De domain controller speelt hierdoor een cruciale rol binnen een Windows netwerk. Valt de domain controller uit, dan ligt het netwerk plat. Vandaar dat veel systeembeheerder minimaal twee domain controllers installeren. Hierdoor hebben ze een fall-back gecreëerd voor het geval een van deze apparaten onverhoopt uit zou vallen.

Heel soms maken mkb’ers niet gebruik van Active Directory maar van een zogenaamde ‘Workgroup’ omgeving. Voor een Workgroup zijn geen centrale domain controllers nodig omdat binnen een Workgroup iedere machine zijn eigen database bijhoudt. Qua beheer en veiligheid is dit echter iets wat je niet de voorkeur zou moeten geven en wat eerder voor thuissituaties gebruikt moet worden dan voor zakelijke omgevingen.

Sommige systeembeheerders plaatsen onderdelen van de ICT omgeving niet binnen het domein. Ze vinden het niet zo nodig, menen zij. Maar een onderdeel zoals een pc die zich niet in het domein bevindt, is niet goed controleerbaar en te beheren vanuit het domein. Er kunnen nauwelijks eisen aan worden gesteld, moeilijk centrale instellingen voor worden uitgerold en de gebruiker zal aan deze situatie  meestal ook niet echt voordeel hebben omdat hij vaker zal moeten inloggen en dat soort zaken. Ook niet iets om aan te bevelen dus.

Active Directory

Kortom, het AD binnen een netwerk is dus te beschouwen als een database waarin gebruikers en machines van een organisatie samen zijn gebracht. Het biedt authenticatie, instellingsmogelijkheden en toegang voor bestanden, software en bijvoorbeeld printers. Om AD te kunnen gebruiken worden protocollen zoals Kerberos en NTLM voor de authenticatie gebruikt terwijl men met LDAP de gegevens uit de Active Directory database kan opvragen en bewerken.

Wanneer met Kerberos wordt gewerkt, dan wordt een label aan dat account toegekend zodra een account inlogt. Dit label blijft bestaan zolang het account is ingelogd. Alle onderdelen binnen het netwerk die Kerberos ondersteunen herkennen het label en vertrouwen het account die dit met zich meeneemt. Het werkt daarom als een soort paspoort. Het is wel een tijdelijk paspoort omdat als het account uitlogt, het label wordt vernietigd.

NTLM is vergelijkbaar met Kerbebos, het zorgt namelijk voor de authenticatie binnen het netwerk. Zodra de account is ingelogd krijgt hij een soort single sign-on mogelijkheid toegekend doordat de account een ‘uitdaging’ toegestuurd krijgt. Een uitdaging (challenge) is een wiskundige berekening die uitgevoerd moet worden met een unieke code die ieder onderdeel van het netwerk toegewezen krijgt wanneer het wordt toegevoegd aan het domein. Als het antwoord op de uitdaging goed is, krijgt de account toegang tot het netwerk, anders niet.

Maar of nu gewerkt wordt met Kerbebos of NTLM, het idee is hetzelfde: controleren of een account toegang mag hebben en op een of andere manier krijgt dat account daar een bewijs van mee tijdens zijn verblijf. Als een account toegang heeft, dan moet hij natuurlijk nog wel gegevens uit de Active Directory database kunnen halen en eventueel bewerken. Daarvoor wordt LDAP gebruikt.

LDAP (Lightweight Directory Access Protocol) kan beschouwd worden als een set opdrachten die je kunt gebruiken om dit te doen. Maar je kunt dus niet met LDAP aan de slag voordat je toegang hebt gekregen. Eerst authenticeren met behulp van bijvoorbeeld Kerbebos of NTLM om vervolgens met behulp van LDAP met AD te kunnen werken.

En Azure AD dan?

Azure AD heeft veel overeenkomsten met Active Directory binnen het eigen netwerk, maar er zijn ook grote verschillen. Azure AD moet namelijk worden beschouwd als de autorisatieplek en rechtentoekenning in de cloud van Microsoft. Voor veel mensen betekent dit: Microsoft 365. Oftewel, Azure AD wordt gebruikt om in te kunnen loggen op bijvoorbeeld de email van Microsoft die zich in de cloud bevindt.

Als we Azure AD zouden beschrijven als de autorisatie tool voor Microsoft 365, dan zouden we het veel te kort doen. Je kunt dit namelijk ook gebruiken voor inmiddels talloze andere cloud diensten zoals Facebook en Google. Met behulp van Azure AD wordt daarom de mogelijkheid gecreëerd om met een enkele, goed beveiligde account, toegang te krijgen tot veel verschillende cloud diensten.

Veel van deze clouddiensten laten een account wel toe na autorisatie, maar hebben geen eigen mogelijkheid om iets aan dit account te veranderen. Dit betekent dat iemand zijn password alleen in Azure AD kan aanpassen, en niet bij Facebook. Dat geeft natuurlijk belangrijke voordelen omdat we er van uit mogen gaan dat Microsoft het beheer en de beveiliging van Azure AD heel hoog op haar prioriteitenlijst heeft staat. Het is maar de vraag of iedere clouddienst waar men gebruik van wil kunnen maken, dat ook heeft. Naast het gemak van een enkele account kan het dus ook veiliger zijn om het Azure AD account voor clouddiensten te gebruiken.

Omdat Azure AD vooral als autorisatie tool is ontwikkeld, heeft het een aantal zaken niet zo maar gemeen met Active Directory op kantoor. In Azure AD worden bijvoorbeeld geen servers van kantoor geplaatst. Azure AD vervangt daarom ook niet het ‘gewone’ AD, maar is voor iets anders bedoeld. Voor mensen die zowel op kantoor dingen moeten kunnen doen als in ‘the cloud’, is het daarom nodig om zowel een lokale account te hebben op kantoor als een in Azure AD.

Synchronisatie

Voor gebruikers kan het hebben van verschillende accounts vervelend zijn. Microsoft heeft het daarom mogelijk gemaakt om de gegevens uit de Active Directory database op kantoor (eventueel deels) te synchroniseren met dit in Azure AD. Hierdoor wordt een password gebruikt voor de email in de cloud (en dus die via Azure AD wordt beheerd) aangepast doordat men op kantoor zijn password aanpast. De synchronisatie zorgt er voor dat wijzigingen in het lokale AD met enige regelmaat worden doorgezet naar Azure AD.

Om dit te kunnen doen maken systeembeheerders gebruik van een tool van Microsoft die Azure AD Connect wordt genoemd. De werking daarvan is eenvoudig: Het lokale account en het account in Azure AD worden aan elkaar gekoppeld als een paar dat bij elkaar hoort. Daarna wordt verteld dat wanneer er in het lokale account een wijziging optreedt, dat dit doorgevoerd moet worden in het account in Azure AD. Vanzelfsprekend worden de wijzigingen regelmatig en beveiligd doorgevoerd.

Wanneer, om welke reden dan ook, de synchronisatie wordt onderbroken, dan blijven beide accounts (lokaal en in Azure AD) gewoon bestaan. Er vindt dan alleen geen verdere synchronisatie meer plaats. Wijzigt men dan een password lokaal, dan zal het in Azure AD niet wijzigen en dus gelijk blijven.

De synchronisatie kan verder gaan dan alleen het bijwerken van gewijzigde passwords. Een systeembeheerder kan bijvoorbeeld hebben opgegeven dat alle accounts van een bepaalde AD groep moeten worden gesynchroniseerd en dat als een account uit de groep wordt verwijderd, de account ook meteen uit Azure AD moet worden verwijderd. Ook kan men, als een account zich in een bepaalde groep bevindt, daar automatisch een bepaalde licentie zoals Microsoft 365 aan koppelen. Hierdoor zal een nieuwe medewerker die in het lokale AD wordt geplaatst, automatisch een Microsoft 365 licentie toegewezen krijgen en daarmee meteen over een mailbox kunnen beschikken.

Waarom niet één account?

Het is geen vreemde vraag om te stellen: als Azure AD voor autorisatie zorgt, waarom gebruiken we dit dan niet ook om op het lokale netwerk terecht te komen? Je zou dan niet meer hoeven te synchroniseren en met dat enkele account alles kunnen doen wat nodig is.

Het is inderdaad mogelijk om de zogenaamde on-premise (op kantoor) zaken met behulp van de Azure AD autorisatie te gebruiken. Het is bijvoorbeeld mogelijk om een Windows 10 laptop aan te melden in Azure AD zodat deze toegang krijgt tot bijvoorbeeld de Microsoft 365 omgeving en tegelijkertijd toegang biedt tot mappen op de lokale server en printers.

Hoewel dit ideaal klinkt, zijn er wel wat overwegingen die gemaakt moeten worden. De policies zoals eerder beschreven die mogelijk in de on-premise domain controller zijn opgegeven, zullen niet meer worden uitgevoerd. Er zijn wel cloud policies beschikbaar voor bijvoorbeeld de Microsoft 365 omgeving, maar een groot aantal mogelijkheden die on-premise kunnen worden gebruikt, kunnen daar niet worden opgegeven. Is daar behoefte aan, dan is dit vooralsnog geen handige keuze.

Ook bestaat er relatief veel software dat de on-premise domain controller gebruikt om licenties te controleren of toegang te geven. Wordt Azure AD gebruikt, dan zal dat in een groot aantal gevallen niet meer werken omdat deze software daar nog niet op is aangepast.

Kortom, goed idee om met een enkele account alles te doen en het zal ook niet verbazen als wij zeggen dat het daar uiteindelijk wel heen zal gaan, maar zo ver zijn we nu nog lang niet.

Conclusie

Active Directory is een database die gebruikt wordt door een domain controller om toegang te verschaffen en rechten toe te kennen. Het is de spil van een op Windows Server gebaseerd netwerk. Ook in de cloud is er sprake van een Active Directory omgeving. Deze Azure AD is echter ontwikkeld om toegang te bieden tot diverse clouddiensten en is daarom niet een netwerk AD die in de cloud staat, maar een eigen omgeving. Sommige diensten maken gebruik van het ene, sommige van het andere systeem. Veel gebruikers hebben daarom beide systemen nodig en om het hen en de systeembeheerder gemakkelijker te maken kunnen deze twee omgevingen met elkaar worden gesynchroniseerd.