Deprovisioning Serviceaccount

Service Accounts sind normale AD-Konten, die aber nicht durch "Menschen" sondern durch Dienste genutzt werden. Es ist sehr ungünstig Dienste als "Administrator" laufen zu lassen. Zum einen haben Sie zu viele Rechte und zum anderen ist eine KennwortÄnderung mit viel Nacharbeiten verbunden. Daher sollten Sie jeder Funktion ein eigenes Dienstkonto spendieren und diese nach dem Wegfall der Funktion auch wieder sauber entfernen. Wer aber nun einfach das Dienstkonto löscht, hat ein paar Dinge vergessen.

Auslöser

Es gibt immer "Veränderungen " in Firmen, die früher genutzte Konten überflüssig machen. Wer z.B. vom Blackberry Enterprise Server (BES) auf ActiveSync wechselt, braucht kein BES-Dienstkonto mehr. Auch wer z.B. von GroupWise oder Notes nach Exchange mit einem Dienstkonto migriert hat, welches in alle Zielpostfächer schreiben durfte, sollte das Konto später nicht zum Regelbetrieb verwenden sondern entfernen. Aber bitte nicht direkt löschen.

Tipp: Viele der folgenden Schritte können Sie sich sparen, wenn Sie genau wissen wo das Dienstkonto zum Einsatz kommt. Leider ist aber genau das in vielen Firmen das Problem: Es wird zu wenig dokumentiert und protokolliert und viele Dinge können nachträglich nur noch sehr schwer ermittelt erden.

Ich habe schon mehrfach wiederholt, dass sie das Konto nicht einfach unter Active Directory users & Computers löschen sollten. Ein solches Löschen entfernt das Benutzerobjekt auch aus allen AD-Gruppen aber in den verschiedenen ACLs bleibt dann ein Konto zurück, von dem Sie nur noch die SID sehen. Es ist kaum nachvollziehbar, wer hier einmal Berechtigt ist oder war. Es gibt Firmen, die aus dem Grund niemals ein AD-Konto oder eine Gruppe löschen sondern aus Revisionsgründen einfach deaktivieren und in eine OU verschieben.

Planung

Ehe wir also das Konto deaktiviere oder sogar komplett entfernen, sollten wir die Auswirkungen auf die Produktion minimieren. Daher verfahre ich in der Regel in mehreren Schritten:

  1. Migration und Umstellung
    Vielleicht können Sie anhand der Installationsdokumentation noch sehen, wozu das Dienstkonto noch alles genutzt wurde. Sofern ein Teil der Dienste weiter laufen soll aber das eigentliche Dienstkonto verschwinden muss, dann müssen Sie neue Dienstkonten entsprechend anlegen und konfigurieren. Oft ist es gerade bei Migrationen nicht unüblich, dass das anfangs angelegte Dienstkonto auch für "fremde" Tätigkeiten missbraucht wird, weil es ja so schön viele Rechte hat.
  2. Aufnahme der Berechtigungen und Mitgliedschaften
    Auch wenn Mitgliedschaften in Gruppen beim Löschen eines Kontos mit verschwinden, dokumentiere ich gerne die Mitgliedschaften für später. Auch die SID kann sicherheitshalber schon mal dokumentiert werden. Sie können das Konto nach dem Löschen zwar nicht mehr einfach zurück holen, aber wenn irgendwann später eine SID unaufgelöst irgendwo sichtbar wird, ist das leichter zu erklären.
  3. Überwachung auf „Anmeldungen“
    Sind sie sicher, dass Sie alle Dienste auf andere Konten umgestellt haben?. Sicherheitshalber kann man aus dem AD und Eventlog mehr erfahren.
  4. Deaktivieren des Kontos und „Ruhezeit“
    Ehe ich ein Konto lösche wird es erst einmal "deaktiviert". So kann man das Konto schnell wieder aktivieren, wenn doch was wichtiges übersehen wurde und eine Umstellung länger dauern würde. Diese Ruhezeit kann gerne auch ein paar Tage oder Wochen dauern, damit Sie auch Probleme nach einem Server Neustart oder sehr selten laufende Tasks eine Change auf Versagen haben
  5. Rückbau des Kontos
    Wenn alles auch ohne das Dienstkonto funktioniert, dann entferne ich erst die ACEs des Benutzers an den dokumentierten Stelle.
    Noch lösche ich das Konto nicht, sondern Ehe das Konto gelöscht wird, sollte es aus den ACLs entfernt werden, in denen es direkt berechtigt wurde. Dies geht leider nur, wo die Berechtigung bekannt ist. Mit dem Löschen des Kontos geht auch die SID etc. verloren.

Schauen wir uns ein paar Werkzeuge an, mit denen die Entfernung eines Dienstkontos vorbereitet werden kann.

Auflistung der AD Gruppenmitgliedschaften

Mit den Windows 2008 Active Directory-Modul ist es relativ einfach die Gruppen anzuzeigen, in der ein Benutzer Mitglied ist. Klar geht das auch in der MMC für AD Benutzer und Computer aber eine Textversion ist deutlich einfacher zu Protokoll zu bringen.

[PS] C:\>(Get-adUser dienstkonto -Properties memberof).memberof

CN=RTCComponentUniversalServices,CN=Users,DC=msxfaq,DC=net
CN=CSUserAdministrator,CN=Users,DC=msxfaq,DC=net
CN=Domain Administratoren,CN=Users,DC=com,DC=msxfaq,DC=net
CN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=msxfaq,DC=net
CN=Server Management,OU=Microsoft Exchange Security Groups,DC=msxfaq,DC=net
CN=Discovery Management,OU=Microsoft Exchange Security Groups,DC=msxfaq,DC=net
CN=Records Management,OU=Microsoft Exchange Security Groups,DC=msxfaq,DC=net
CN=Recipient Management,OU=Microsoft Exchange Security Groups,DC=msxfaq,DC=net
CN=Public Folder Management,OU=Microsoft Exchange Security Groups,DC=msxfaq,DC=net
CN=Organization Management,OU=Microsoft Exchange Security Groups,DC=msxfaq,DC=net

Wenn Sie bei Gruppen und anderen Objekten das Feld "ManagedBy" verwenden, also den "Manager" um darüber andere Prozesse zu steuern, dann sollten Sie vielleicht auch eine LDAP-Suche danach machen, wo der DN es Kontos hinterlegt ist

Auflistung von AD-Rechten

Dienstkonten, die auch zur Provisioinierung von Benutzer, Gruppen etc. oder zur Migration von Postfächern und damit erforderlichen Zugriffen auf AD-Objekte genutzt wurden, haben oft auch Berechtigungen im Active Directory. Ideal wäre es, wenn solche Rechte nie an Benutzer sondern immer über Gruppen vergeben werden. Zudem sollte die Vergabe von Berechtigungen immer dokumentiert werden. Die Realität sieht natürlich anders aus. Leider erlaubt es Windows aber keine Rückwärtssuche. Ich kann also nicht nachfragen, wo eine SID überall auftaucht. Ich müsste jede ACL (AD, NTFS, Registry, COM+  etc.) rekursiv prüfen. Es gibt kommerzielle Programme für diese Aufgaben (Stichwort Auditing, Revision etc). Hier muss ein vereinfachtes Verfahren reichen. Per PowerShell lassen Sich durchaus solche Rechte ermitteln

Import-module ActiveDirectory
Get-ADOrganizationalUnit -Filter * `
    | %{ write-host $_.distinguishedname; get-acl "AD:$($_.distinguishedname)"} `
    | select access -expandproperty access  `
    | %{$_} `
    | where {(($_.IdentityReference -eq "domain\dienstkonto")-and ($_.IsInherited –eq $false))} `
    | ft ActiveDirectoryRights,InheritanceType,AccessControlType

So erhalten sie wenigstens einen einfachen Überblick, wo ein Konto explizit berechtigt worden ist.

Meist ist es weniger wahrscheinlich, dass explizit Rechte auf usern, Gruppen oder der Konfiguration Partition vergeben wurden, wobei es nie auszuschließen ist. Hier ist die Windows Plattform schlechter aufgestellt, als die frühere NetWare, bei der ein Administrator relativ einfach auch rückwärts suchen konnte, wo ein Benutzer berechtigt ist.

Exchange Postfachrechte

Eine Analyse des Active Directory liefert zwar die "SendAs"-Berechtigungen kostenfrei mit, aber kann natürlich nicht in den "msExchMailboxSecurityDescriptor" schauen. Das geht dann per Exchange PowerShell.

# FullMailbox Access ermitteln

get-mailbox `
| Get-MailboxPermission `
     -User domain\dienstuser `
| ?{!$_.isinherited} `
| select identity,AccessRights


#SendAs ermitteln
Get-Mailbox `
   -Resultsize unlimited `
| Get-ADPermission `
   -user domain\dienstuser`
| ?{($_.ExtendedRights -like "*send-as*") -and -not ($_.isinherited")} `
| ft Identity, user -auto 

So erhalten Sie eine Liste aller explizit vergebenen Rechte dieses Dienstusers auf alle Postfächer. Und so dieses Dienstkonto "SendAs" hat

Damit ist aber nicht abgedeckt, ob das Konto vielleicht noch Rechte auf einzelne Ordner im Postfach hat. Das können Sie natürlich auch mit get-mailboxfolderpermissions ermitteln aber bei Dienstkonten ist dies ein eher seltener Fall, so dass ich mir die Zeilen dazu erspare.

Auflistung der Exchange RBAC

Normalerweise werden Rechte in Exchange über Gruppen zugewiesen. Es kann aber auch sein, dass ein Konto direkt berechtigt wurde. Häufig wird dies z.B. für Impersonation gemacht

Get-ManagementRoleAssignment `
   -RoleAssignee dienstkonto `
   -RoleAssigneeType user

Name                     Role              RoleAssigneeName  RoleAssigneeType  AssignmentMethod
----                     ----              ----------------  ----------------  ----------------
Impersonation-EWS        ApplicationImp... Dienstkonto ... User              Direct            
Mailbox Import Export... Mailbox Import... Dienstkonto ... User              Direct            

Diese Rechte sollten später vor dem Löschen des Kontos entfernt werden, damit keine SID-Einträge in der Configuation Partition zurück bleiben.

Lokale Rechte und Einstellungen, Diensteinstellungen

Wenn Sie wissen, auf welchem Server oder Client Das Dienstkonto verwendet wurde, dann lohnt es sich durchaus hier noch einmal nachzuschauen. Ein Dienstkonto kann z.B. in einer lokalen Administratoren-Gruppe sein. Dies ist nicht im Active Directory zu erkennen. Auch könnte es sein, dass das Dienstkonto lokale Rechte hat.

Als Stichprobe wurden verschiedene Server auf lokale Rechte (z.B. lokaler Admin) geprüft und nichts gefunden.

Aktuelle Anmeldungen

Ehe Sie das Konto löschen oder deaktivieren, sollten Sie prüfen, ob es vielleicht nicht doch noch verwendet wird. Seit Windows 2008 ist das "LastLogon"-Feld im Active Directory ein relativ guter Indikator. Sie können es einfach per PowerShell auslesen

[DateTime]::FromFileTime((Get-ADUser dienstkonto -Properties lastLogon).lastlogon)

Zuerst müssen Sie Get-ADUser anweisen auch das Feld "lastLogon" zu holen und dann das Format des Felds von "FileTime" in ein lesbares Format konvertieren. Wenn dieses Datum noch relativ jung ist, dann könnte es sein, dass irgendwo das Konto noch genutzt wird. Das kann auch eine "vergessene Terminalsitzung" sein, insbesondere wenn das Dienstkonto auch zum Administrieren missbraucht wurde.

Über das Windows Eventlog der Domänencontroller können Sie fast immer feststellen, auf welchem Client das Konto noch aktiv ist. Im Security Eventlog werden alle erfolgreichen und erfolglosen Anmeldungen protokolliert.

  • TrackLoginEvents
    Alte VBScript Version. Eine PowerShell-Variante ist fertig aber noch nicht dokumentiert.

So ein Analyse ist natürlich nie vollständig. Es kann durchaus sein, dass das Dienstkonto noch in einem Task hinterlegt ist, der nur einmal im Monat oder sogar nur auf Anforderung gestartet wird. Es bleibt also immer ein Restrisiko. Aber nun wissen Sie ja, wie sie fehlerhafte Anmeldungen ermitteln können und so diese Meldungen erfassen können.,

Deaktivierung und Ruhezeit

Nehmen wir an, wir haben gewissenhaft alle Stellen ermittelt und alle aktiven Prozesse auf neue Konten umgestellt oder abgebaut, dann sollte niemand mehr das zu entfernende Konto nutzen. Dann ist es an der Zeit das Konto zu deaktivieren. Die Deaktivierung des Kontos wirkt aber nicht zwingend sofort. Zwei Beispiele

  • Kerberos Tickets
    Die vom DC ausgestellten Kerberos-Tickets sind per Default bis zu 6h lang gültig. Wenn der Client auf ein Ziel zugreift, welches schon früher per Kerberos angesprochen wurde, dann kann der Zugriff noch einige Zeit möglich sein.
  • Lync Client Zertifikate
    Lync stellt seinen Clients bis zu 6 Monate gültige Zertifikate aus, die dann zur Anmeldung genutzt werden und auch bei einem deaktivierten Konto weiter gültig sind.
  • Lokale "offline" Anmeldung
    Es bringt nichts ein Konto in der Domäne zu sperren, wenn der Anwender unterwegs ohne Netzwerkverbindung auf seinem Notebook arbeitet. Er kann dies solange, bis der PC wieder eine Verbindung zum DC hat.
  • RMS-Tokens
    Wer Inhalte mit dem Rights Management Server schützt, holt sich beim Zugriff auf die Information vom RMS-Server ein "Token", welches eine gewisse (einstellbare) Gültigkeit hat. Ein Benutzer kann weiterhin lokale Dokumente öffnen und im Rahmen seiner Berechtigungen nutzen, solange diese Token noch gültig ist.

Eine Deaktivierung einer Person sollte also immer auch damit verbunden werden, die Endgeräte einzuziehen oder aus der Ferne zu löschen (RemoteWipe). Ansonsten ist es nicht sicher, dass ein Zugriff auf Daten noch einige Zeit möglich ist. Hier ein paar Beispiele

Dienst Ergebnis Beschreibung

Windows Desktop

Keine Neuanmeldung

Der Anwender kann sich an keinem PC mehr anmelden, es sei denn der PC ist nicht mit der Domäne "verbunden". Das ist aber eher ein Problem, wenn Sie einen Anwender abschalten wollen, aber keinen Zugriff auf dessen Notebook haben, der z.B. zu Hause steht. Solange der Mitarbeiter keine Verbindung aufbaut, kann er sich immer noch an dem Notebook anmelden.

Direct Access kann diese Lücke deutlich reduzieren, da die meisten Geräte heute sich automatisch z.B. mit einem WiFi-Netzwerk verbinden. Hier müsste der Anwender dann schon absichtlich die Verbindung zum Internet unterbinden

Exchange

Keine Neuanmeldung

Exchange authentifiziert jeden Anwender gegen das AD und ein deaktiviertes Konto kann sich nicht mehr anmelden

802.1x Radius

Keine Neuanmeldung

Die meisten Router lassen ein bereits authentifiziertes Geräte weiter arbeiten. Eine neue Authentifizierung schlägt dann aber fehl.

Lync

Bis zu 6 Monate

Lync nutzt die Anmeldung über das AD nur anfangs, um ein "Zertifikat" zu erhalten. Dieses ist bis zu 6 Monate gültig. Ein im AD deaktiviertes Konto muss in Lync auch noch "deaktiviert" oder die hinterlegten Zertifikat gelöscht werden.

FileServer

Keine Neuanmeldung

 

ADFS

Ticketlaufzeit

Wenn Sie auf Dienste zugreifen, die ein ADFS-Token erfordern, dann bekommt der Anwender nach der Deaktivierung natürlich kein neues ADFS-Token mehr aber das bereits ausgestellt Token zum Zugriff auf z.B. Office 365 ist noch einige Zeit gültig.

Cookies

Cookielaufzeit

Auch nutzen immer mehr Webseiten eine "Formularbasierte Anmeldung", bei der der Webserver die Anmeldedaten überprüft und dann die Berechtigung in einem Cookie hinterlegt. Der Cookie hat meist nur eine begrenzte Lebensdauer, die sich aber mit jedem neuen Request verlängern kann.

Es gibt sicher noch weitere Dienste, die vieleicht nicht sofort eine Rückfrage beim Active Directory vornehmen und daher verspätet erst den Zugriff verhindern.

Rückbau: Löschen oder Behalten

Ein länger deaktiviertes Konto kann nach einer selbst gewählten Karenzzeit irgendwann gelöscht werden. Es gibt aber auch Umgebungen, die solche Konten niemals löschen. Benutzer können an Dokumenten und Verzeichnissen als "Besitzer" eingetragen sein und man möchte auch später nachvollziehen, wer zu welcher SID gehört hat. Eine erneute Vergabe einer SID ist bei Windows nicht möglich. Bei Unix-Systemen oder mit NIS könnte aber die uID erneut vergeben werden.

Wenn Sie Konten nicht löschen, dann müssen Sie aber sicherstellen, dass Sie nicht "stören". Solange Sie in Mailverteilern sind und ein Postfach haben, wächst das Postfach. Benutzer mit einer Telefonnummer könnten bei LDAP-Suchen der Telefonanlage oder Lync weiterhin als Ergebnisse gelistet werden. Das Konto kann verbleiben aber die meisten Felder werden Sie doch leeren wollen.

Wenn Sie das Konto aber löschen dürfen, dann sollten Sie dies auch erst als letzten Schritt machen und alle Vorgänge bei der Einrichtung und zur Lebensdauer wieder zurück bauen, z.B.

  • Entfernen von direkt im AD vergebenen ACLS
    Nur relevant wenn Sie Benutzern erweiterte Rechte geben
  • Entfernen aus Gruppen
    Durch das Löschen des Benutzers wird dieser auch aus den Gruppen entfernt aber manchmal
  • Update des "Manager"-Felds
    AD-Objekte können einen "Manager" besitzen, der Berechtigungen erhält aber auch z.B. für Benachrichtigungen verwendet werden kann.
  • "Suche" auf vergessene Einträge
    Sie können vorab versuchen über eine LDAP-Suche oder einen LDAP-Export weitere Stellen zu erkennen, an denen der DN oder die SID des zu löschenden Benutzers hinterlegt ist.
  • SID dokumentieren
    Wenn Sie Konten löschen sollten Sie dennoch sich überlegen, die Zuordnung der SID irgendwo zu dokumentieren.

Letztlich werden Sie aber irgendwann das Objekt löschen und sind aber dennoch nicht sicher, ob Sie alle alte Einträge vorher umgestellt haben.

Weitere Links