post-thumb

Bij vrijwel elke Active Directory Healthscan is het raak. Er staan veel meer gebruikers- en computerobjecten in dan in werkelijkheid binnen de organisatie bestaan. Oude systemen worden vervangen, mensen gaan uit dienst, we testen eens wat, maar de oude accounts verwijderen gebeurt meestal niet. Zeker nu steeds meer Active Directory’s aan de cloud worden gekoppeld is het belangrijk ervoor te zorgen dat er geen vervuiling door onnodige objecten aanwezig is. Dit creëert overzicht en wat je uitschakelt veroorzaakt in ieder geval geen issues of beveiligingslekken meer.

Is het volgende op jouw Active Directory van toepassing?

  • Staan er ook (veel) meer objecten in je AD dan dat er medewerkers of werkplekken zijn?
  • Heb je ook het idee dat er accounts aan staan van mensen die allang weg zijn?
  • Voel je je wat ongemakkelijk bij een audit waarbij men checkt of bepaalde accounts zijn uitgeschakeld of verwijderd?
  • Heb je ook het idee dat er teveel Domain Admin accounts zijn?

 

Pak het gewoon eens aan met onderstaande tips. Het opschonen van onnodige ballast is een van de eenvoudige manieren om je beveiliging te verbeteren.

Oude gebruikersaccounts

Bij vrijwel elke security audit zal worden gevraagd om de status van accounts van mensen die uit dienst zijn….

Ik controleer altijd op de aanwezigheid van oude / inactieve computer- en useraccounts. Deze zijn te herkennen aan een oude last password change date. Dit kan eenvoudig met een tool als OldComp, de oude dsget, dsquery commando’s en natuurlijk PowerShell. (NB: Ik gebruik in dit artikel de oudere dsquery en dsget commando’s om de simpele reden dat die (in ieder geval tot 2012 R2) nog prima werken en ik nog niet de tijd en noodzaak heb gehad de PowerShell variant uit te werken. HIER meer info over bijvoorbeeld dsquery)

Afhankelijk van het type organisatie hou ik 180 of 400 dagen aan. Dan hou je rekening met zwangerschappen, parttimers, tijdelijke krachten, schoolvakanties e.d. Ik adviseer dringend om oude accounts nooit direct te verwijderen. Zet ze eerst op DISABLED (dan hebben ze geen toegang meer), stel vast dat er geen meldingen uit voortkomen en verwijder ze periodiek. Neem bij voorkeur dan ook gelijk profielen, homedrives etc. mee, dan schoon je dat ook meteen op.

Met het volgende commando vraag je useraccounts op met een password ouder dan 180 dagen, waarbij je het resultaat opslaat in een txt-bestand.

dsquery user  -limit 0 -stalepwd 180 | dsget user -samid -dn >nopasswordchange180days.txt

 

Met het volgende commando genereer je een txt file die je vervolgens in Excel kunt inlezen ter analyse, je achterhaalt hiermee ook accounts die bijvoorbeeld de erg onveilige Reversible Encryption nog (vanuit een ver, ver verleden) hebben aanstaan.):

dsquery user  -limit 0 | dsget user -samid -upn -pwdneverexpires -reversiblepwd -acctexpires >allinfo.txt

LET OP: Van Serviceaccounts en dergelijke verandert het wachtwoord (helaas) meestal niet. Als je een query doet op oude accounts, controleer dan altijd wat voor accounts het zijn voordat je ze uitschakelt, serviceaccounts hebben meestal een erg oud wachtwoord. (En bij voorkeur plan je direct een password change voor deze accounts in… doe dat gefaseerd en gestructureerd). Je zult de enige niet zijn die domweg een lijst accounts dichtzet, waarna e.e.a. omvalt.

Oude Computeraccounts

Voor Windows computeraccounts geldt dat domain members standaard elke 30 dagen hun computerpassword automatisch wijzigen. Objecten waarvan het password ouder is dan 30 dagen kunnen dus ongebruikt zijn (bijvoorbeeld doordat werkplekken worden vervangen of uitgefaseerd). Meestal hou ik zelf 90 of 180 dagen aan als eerste grens. In een Active Directory met veel domain member laptops kan het nodig zijn de periode wat langer te houden als deze niet regelmatig met het netwerk zijn verbonden. Als je de lijst genereert, dan zie je snel genoeg welke termijn voor jouw omgeving handig is. Disable ook hier eerst voordat je verwijderd, dan kun je het account weer snel enablen mocht er zich een issue voordoen.

OldComp begint nu echt oud te worden, maar genereert een HTML-weergave, je kunt het HIER downloaden. Hier geldt natuurlijk ook dat dit proma kan met PowerShell (of eventueel dsget / dsquery)

Hieronder een voorbeeld van een OldComp commando om oude computerobjecten op te vragen, hij genereert automatisch een HTML-bestand in de map waarin je het commando uitvoert;

OldComp.exe -report - age 400 -sort pwage

 

LET OP: Niet alle systemen doen mee aan de password change. In de meeste omgevingen zijn er systemen die hun wachtwoord nooit gewijzigd hebben. Denk aan Linux, Apple, VMWare hosts, appliances etc. etc. Die hebben dan wel een computeraccount in AD, maar wijzigen hun computerpassword nooit. Gooi dus nooit zomaar computeraccounts weg, maar controleer (met name de objecten met een hoge password age) wat er weg kan en wat niet.

Check op accounts met hoge bevoegdheden

Heb je ook het idee dat er teveel accounts zijn met teveel rechten?

Dit is vaak een erfenis uit het verleden. Zo worden ServiceAccounts vaak Admin gemaakt ‘omdat het anders niet werkt’… Men is dan gewoon ‘vergeten’ om exact te bepalen wat voor rechten nodig zijn (of de leverancier is te beroerd om het je te vertellen). In de meeste gevallen volstaat het specifiek uitdelen van rechten op basis van ‘least privilege’ en dat is een stuk veiliger dan het domweg toevoegen aan de Domain Admin Group. Ga dus bij een implementatie niet zomaar akkoord met de mededeling dat Domain Admin rechten nodig zijn. Zoek uit of dit echt niet anders kan, in de meeste gevallen kom je met wat doorvragen tot een veel veiliger set van rechten. (En als een leverancier geen duidelijk antwoord kan geven, dan weet je ook genoeg over diens productkennis, zelf ben ik hier altijd scherp op).

Zelf controleer ik in ieder geval de standaard groepen in de OU BUILTIN en Users zoals Domain Admins, Administrators, Enterprise Administrators, Schema Administrators etc.. Ik bepaal dan samen met de klant welke accounts hier niet thuishoren. Zelf hanteer ik bijvoorbeeld een lijst als onderstaand om per groep te checken of er onnodige vervuiling aanwezig is;

Active Directory Default Groups

Hieronder een commando om een export te maken van een specifieke groep;

dsquery group -name "Domain Admins" | dsget group -members | dsget user -samid -upn -desc >DomainAdminMembers.txt

Niet inspirerend, soms gevoelig, maar wel noodzakeljk…

Ik geef toe, dit is niet het meest inspirerende werk, maar ik sta er regelmatig weer versteld van wat je aan onnodige (en vaak vergaande) bevoegdheden tegenkomt. Dit zijn flinke beveiligingsrisico’s. Ik snap heel goed dat je daar in de dagelijkse praktijk vaak niet aan toekomt, vandaar dat ze vaak hulp inroepen van mensen die zich kort hierop focussen, kritische vragen durven stellen en de boel even lekker opruimen.

Het ligt vaak gevoelig om mensen rechten ‘af te pakken’, maar veel IT-ers hebben echt niet elke dag hun admin rechten nodig. Zorg voor een standaard gebruikersaccount en een los admin account (duidelijk te herkennen aan de naamgeving). Wijs mensen er ook op dat het hebben van Admin rechten ook een verantwoordelijkheid betekent, immers; voor rechten die je niet hebt draag je ook geen verantwoording. Vaak is de combinatie van een persoonlijk Admin account dat alleen ingeschakeld wordt indien nodig al voldoende. De rechten zijn immers beschikbaar indien nodig zonder dat je continue met Admin rechten werkt.

Externen

Voor externen maak je ook een eigen (herkenbaar) account aan mét een verloopdatum. Een andere simpele oplossing is het gebruik van een account ‘Vandaag’ voor mensen die kort iets moeten doen waar admin rechten voor nodig zijn. Dat account blokkeert automatisch (expiration date instellen!) aan het eind van de dag. Als het nodig is schakel je het in met een nieuw wachtwoord. Dat voorkomt wellicht ook dat consultants zaken gaan inrichten onder hun eigen naam, hetgeen later weer issues veroorzaakt als je het account uitschakelt…

Je Active Directory hou je het liefst vrij van onnodige objecten, hiermee creëer je ook overzicht. Vaak loont het om ook eens te kijken naar een geautomatiseerde (de-)provisioning. Dat scheelt veel fouten bij het aanmaken en voorkomt dat vergeten wordt om accounts tijdig uit te schakelen. In ieder geval is het altijd lonend en geeft het voldoening om onnodige objecten en rechten te verwijderen. Dan kunnen die in ieder geval niet meer voor storingen en beveiligingsissues zorgen.