Een account representeert een gebruiker, computer of proces en maakt het mogelijk deze deel te laten namen aan een identificatie (wie ben ik) en authenticatie (bewijzen wie ik zeg dat ik ben) proces. Een account kan worden geautoriseerd om toegang te verkrijgen tot objecten. Een account kan gelokaliseerd zijn in de lokale account database of in active directory. Elk account krijgt een zogenaamde SID (security identifier) toegekend. Elke groep kent tevens ook een SID. SID’s worden gebruikt bij het toekennen van rechten. Een organisational unit die een dergelijke SID niet bezit kan daarom ook niet mee doen in het beveiligings systeem. Een SID ziet er uit als een lang getal ongeveer in de vorm van ‘S---- ‘ voor een gebruiker in Active Directory. Windows gebruikt als revisie nummer altijd nummer ‘1’. Het authoriteitsnummer is wisselend. Meestal is het nummer 5, de NT authority.
Hierna volgt een domain identifier en uiteindelijk een relatieve identifier of RID. Windows kent een aantal zogenaamde ‘Well-known SIDS’ Dit zijn speciale security principals zoals het administrator account. In bepaalde gevallen is de SID over alle systemen ter wereld gelijk zoals die van ‘administrators’. Soms is de RID hetzelfde, zoals bij een domain administrator account. Tabel 2 geeft een aantal voorbeelden van dergelijke Well-known SID’s. Wanneer een security principal zich aanmeld wordt er een access token gegenereerd. Hierin bevinden zich de SID van het account en alle SID’s van de groepen waar de gebruiker lid van is. Het token wordt gebruikt wanneer de toegang tot een bepaald object nodig is.

Tabel 1: Well-known SID’s
SID Name Description
S-1-1-0 Everyone Een groep met daarin alle gebruikers, anonymous gebruikers en gasten. Windows vult deze groep automatisch. In Windows 2003 is everyone in de praktijk gelijk aan users.
S-1-5-1 Dialup Gebruikers aangemeld via inbelverbindingen. Wordt gevuld door Windows.
S-1-5-2 Network Gebruikers aangemeld via het netwerk. Door Windows gecontroleerde groep.
S-1-5-80-<> Vista Service SID van een specifieke service in vista
S-1-5-< domain >-500 Administrator Het administrator account
S-1-5-< domain >-501 Guest Het gast account. Standaard is deze uitgeschakeld.
S-1-5-32-551 Backup Operators De backup operatoes groep is een ingebouwd account wat alleen lokaal werkt.

Dit toelaten of juist weigeren gebeurd op basis van Access Control Lists, meestal afgekort als ACL (uit te spreken als akkel). Een proces of persoon wat probeert toegang te krijgen bezit een token welke wordt vergeleken met de lijst om te bepalen of dit toegestaan kan worden of juist niet. Windows kent 2 typen ACL’s namelijk Discretionary ACL’s ofwel een DACL en System ACL’s ofwel een SACL. In de literatuur wordt ook wel het begrip Mandatory ACL gebruikt. MACL’s gaan over toegangscontrole op basis van data classificatie, denk aan publiek, vertrouwelijk en top secret. Het systeem controleert deze toegang, zelfs een beheerder kan hier niets aan veranderen. Discretionary ACL’s worden bepaald onder de verantwoordelijkheid (discretie) van de eigenaar (of beheerder). De eigenaar bepaald een lijst van toegangen die we Access Control Entries noemen. Een ACL is daarom een lijst van ACE’s. Een ACE geeft een account of groep een bepaalde vorm van toegang (administrators: Full Control) of ontzegt deze juist (users:Deny Write). Een ACE werkt op basis van een SID (security identifier), het is daarmee niet de naam van de groep administrators of users maar de SID van de groep of account wat in de ACE genoemd wordt. Vandaar ook dat in Windows vrij triviaal een groep of accountnaam kan worden gewijzigd zonder gevolgen voor de beveiliging.
In een ACL worden de ACE’s zo geplaatst dat deny ACE’s hoger in de lijst staan dan de allow ACE’s. De reden hiervoor is dat zodra bepaald wordt of toegang wordt toegestaan of geweigerd de volgende ACE’s niet meer worden gecontroleerd.
Sinds Windows 2003 (en XP) kunnen we overerving toepassen van rechten en dit heeft de zaken wel wat gecompliceerder gemaakt. Windows hanteert de regel dat allereerst de expliciete rechten worden geëvalueerd waarbij eerst de deny en dan de allow ACE’s worden bekeken. Na de expliciete rechten worden allereerst de overerfde rechten van de map erboven bekeken, wederom eerst deny dan allow. Vervolgens de map erboven enzo verder tot het hoogste niveau.

Figure 1 : Permissies op een map

Een SACL welke in opbouw gelijkwaardig is aan een DACL gaat niet over het verlenen van toegang maar het vastleggen ervan, een proces wat we auditing noemen. Everyone Full control zou elke activiteit die plaatsvind op het object wat wordt benadert vastleggen in het beveiligings logboek van Windows wanneer is vastgelegd dat auditing is ingeschakeld op systeem niveau.

Tabel 2: Objecten die kunnen worden beveiligd met ACL’s
Files or folders on an NTFS file system
Active Directory objects
Registry keys
Network shares
Local or remote printers
Windows services
Named pipes
Anonymous pipes
Processes
Threads
File-mapping objects
Access tokens
Window-management objects
Interprocess synchronization objects
Job objects
Distributed Component Object Model (DCOM) objects

De objecten genoemd in tabel 2 bezitten een zogenaamde security descriptor met daarin de eerder genoemde sacl en dacl alsmede informatie over wie eigenaar is van het bestand en hoe de overerving van rechten is geregeld. Hoewel al deze objecten een security descriptor bezitten kan het zijn dat dacl/sacl informatie niet is ingevuld of dat deze zelfs geheel afwezig is (een zogenaamde null dacl). In het laatste geval is het bestand ongelimiteerd toegankelijk voor iedereen. Er zijn een aantal security bulletins die problemen behandelden met systeem bestanden zonder dacl.

Windows vista bouwt het beveiligingsmodel verder uit. In deze aankomende versie van Windows zullen ook services een eigen SID bezitten waardoor er permissies aan een service kunnen worden gegeven of juist ontnomen. Deze verdere verfijning reduceert een aantal aanvalsmogelijkheden die nu nog wel op services kunnen worden uitgevoerd. Services zijn herkenbaar aan een SID die begint met “S-1-5-80-“.

Een andere nog meer revolutionaire feature is de introductie van mandatory integrity controls (MIC). Windows Vista kent 4 integriteits niveaus, low, medium, high en system. Wanneer een object wordt benadert wordt eerst het niveau van de gebruiker vergeleken met het niveau van het object.Wanneer de gebruiker hetzelfde of een hoger niveau heeft dan wordt, na controle van de DACL controle verleend. Internet explorer in Vista maakt onder meer gebruik van dit systeem, deze draait op een laag niveau en kan daardoor, zelfs in de contact van de gebruiker, betrekkelijk weinig kwaad.

Naast permissies op objecten kent Windows ook nog een aanvullende beveiliging, namelijk de zogenaamde user rights. In tegenstelling tot permissies zijn user rights gebonden aan een account en niet een object. Er zijn twee verschillende soorten van deze speciale rechten: Logon rights en privileges. Doordat deze rechten enigszins verborgen zitten in Windows kan dit tot rare situaties leiden wanneer men hier niet op bedacht is.
Logon rights gaat over het recht om te mogen aanmelden of benaderen van een machine. Zo is er het logon locally recht, het terminal server logon recht en het access this computer from the network recht. Deze rechten hebben ook weer tegenhangers die het omgekeerde bereiken (deny logon locally). Naast logon rechten bestaan er ook de privileges, het recht om te backuppen, het recht om werkstations aan het domein toe te voegen, het recht om een machine uit te schakelen. In sommige gevallen kunnen user rights zelfs boven de permissies op objecten staan. Denk bijvoorbeeld aan het backup recht. Zelfs als een account geen toegang heeft tot een object zal het toch in staat zijn om dit te backuppen. Omgekeerd, als een gebruiker full control heeft overal op het systeem maar deny logon locally zal deze nog steeds niet direct op de console kunnen aanmelden.

Hoe pakt dit nu uit in de praktijk? Iets simpels als het benaderen van een bestand op een fileserver blijkt eigenlijk helemaal niet zo simpel. Van buiten naar binnen en dan laten we firewalls en dergelijke buiten beschouwing dan zijn er de volgende stappen:
- De eerste grens waar we tegenaan lopen is een logon right en wel het ‘access this computer from the network (SeNetworkLogonRight). Daar bovenop komt nog dat je geen lid moet zijn van de deny versie anders wordt alsnog toegang geweigerd.
- De volgende limiet is share security. Eigenlijk een beetje vreemde constructie, de toegang tot gedeelde bestanden wordt bereikt door de toegang tot de share en dan pas de rechten tot de bestanden. We kunnen nooit meer rechten krijgen dan de rechten op de share, staat deze bijvoorbeeld op alleen lezen en hebben we volledige rechten op de bestanden dan hebben we toch alleen maar leesrechten. Vanwege de inherente complexiteit hiervan wordt vaak op de shares gewoon full control gegeven.
- Wanneer het bestand niet directe in de gedeelde map is geplaatst dan hebben we nog een aanvullende uitdaging. Als we rechten hebben op de hoofdmap en de onderliggende dan is er niets aan de hand maar het kan zijn dat we geen toegang hebben tot de hoofdmap maar wel de onderliggende. Als we er dan toch bij willen komen dan moeten we het recht hebben om bij die map te kunnen komen zonder rechten te hebben op de bovenste mappen. Om dit te kunnen moeten we beschikken over het ‘bypass traverse checking (SeChangeNotifyPrivilige)’ recht. Standaard staat dit aan maar in sommige highsecure omgevingen wordt dit nog wel eens uitgeschakeld met soms onverwachte resultaten.
- Om bij een bestand te komen moeten we ook in de map kunnen komen. De permissies van de map zijn daarmee mede bepalend voor het verlenen van de toegang.
- Uiteindelijk kunnen we het bestand benaderen, mits natuurlijk de juiste rechten zijn toegekend.

Dit voorbeeld maakt duidelijk dat het beveiligingssysteem van Windows erg complex is en de oorzaak van een toegangsprobleem niet altijd eenvoudig is op te sporen. Wanneer we rekening houden met de verschillende onderdelen en stap voor stap door de procedure heen lopen kunnen we echter de oorzaak altijd wel achterhalen.

W. Verveen is verbonden aan Ormer ICT dienstverlening als Consultant, daarnaast beheert hij Windows 2000 Wereld
E-mail: w.verveen@ormer.nl
Web: http://www.ormer.nl en http://www.win2kwereld.nl