penetrator
Goto Top

Projekt: Automatisierter Passwortwechsel aller administrativen Benutzerkonten

Hallo zusammen,

nach längerer Zeit melde ich mich mal wieder mit einen Problem, bzw. würde gerne meine geplante Vorgehensweise diskutieren.

Beschreibung:

Bei uns Serverumgebung am Standort (ca. 80 Server), ist es nun an der Reihe aufzuräumen. Es geht darum, dass alle Benutzer, welche mit Administrativen Rechten in unserer AD OU liegen hinterfragt werden müssen. (Getreu dem Motto: Nur so viel wie nötig, aber so wenig wie möglich). Darüber hinaus muss sichergestellt werden, dass bei einem Passwortwechsel mir nicht die ganze Umgebung um die Ohren fliegt. Weiter sollen Adminzugänge welche aus Bequemlichkeit "einfach mal so" unbedacht genommen wurden durch Service-User ersetzt werden. Mit Service User ist gemeint, das für den Backupdienst ja nicht umbedingt gleich der OU Admin genommen werden soll, sondern ein eigens dafür erstellter User.

Mein geplantes Vorgehen:
1. Auslesen sowie Auflisten aller administrativen User an alles Servern. (Vieleicht per PS Script)
2. Entscheidungsfindung welcher User kann durch einen Service-User ersetzt werden
3. Ersetzen von Dom Admin Usern durch die entsprechenden (sinnvoll benannten) Service User.
4. Erruierten der Notwendigkeit eines Dienstart als OU Admin (Kann der Dienst vieleicht auch unter SYSTEM ausgeführt werden, ohne das es eine Beeinträchtigung gibt) sowie Umstellung
5. Änderung des Passwortes eines OUAdmins und hoffen das alles trotzdem funktioniert!!!

Wie würdet Ihr ein solches Projekt angehen?

Ich bin über jeden Tipp dankbar!

Vieleicht gibt es ja den einen oder anderen unter euch, die soetwas schon mal umgesetzt haben.

Viele Grüße

Penetrator

Content-ID: 312154

Url: https://administrator.de/contentid/312154

Ausgedruckt am: 26.11.2024 um 09:11 Uhr

129813
129813 09.08.2016 aktualisiert um 17:04:34 Uhr
Goto Top
Hi,
for service accounts you can use Managed Service Accounts where regular password for these service accounts are automated by your AD. These ar available since Server2008R2.

Regards
agowa338
Lösung agowa338 09.08.2016 um 17:40:50 Uhr
Goto Top
Hier ein Skript, das dir (fast) alle Verwendungen des Domänenadministrators bzw. Lokaler Administratoren auflistet
$User = "*Administrator*";  
$OutFile = ".\AdmUsed.csv";  
$SearchBase = "OU=Servers,DC=$CONTOSO,DC=COM";  

$credential = Get-Credential;
$computers = $(Get-ADComputer -Filter * -SearchBase $SearchBase -Credential $credential).DNSHostName;

$AdmUsed = New-Object -TypeName PSObject -Property @{
    Name = "";  
    Caption = "";  
    State = "";  
    User = "";  
    TaskName = "";  
    TaskPath = "";  
    ComputerName = "";  
    Type = "";  
    ErrorMessage = "";  
};

ForEach ($computer in $computers) {
    # Services
    try {
        $ErrorActionPreference = "Stop";  
        [Array]$AdmUsed += Get-WmiObject Win32_Service -Credential $credential -ComputerName $computer | Where-Object StartName -Like $User | Select-Object Name,Caption,State,@{Name="User";Expression={$_.StartName}},@{Name="ComputerName";Expression={$computer}},@{Name="Type";Expression={"Service"}};  
    } catch {
        [Array]$AdmUsed += New-Object -TypeName PSObject | Select-Object @{Name="ErrorMessage";Expression={$($_.Exception.Message)}},@{Name="State";Expression={"Error"}},@{Name="ComputerName";Expression={$computer}},@{Name="Type";Expression={"Service"}};  
        Write-Warning "$computer - $($_.Exception.Message)";  
    };

    # Tasks
    $path = "\\" + $computer + "\c$\Windows\System32\Tasks"  
    if (Test-Path $path)
    {
        $tasks = Get-ChildItem -Path $path -File; # TODO: Implement Recursion
        if ($tasks)
        {
            Write-Verbose -Message "I found $($tasks.count) tasks for $computer";  
        };
        foreach ($item in $tasks)
        {
            $AbsolutePath = $path + "\" + $item.Name;  
            $task = [xml] (Get-Content $AbsolutePath);
            [STRING]$check = $task.Task.Principals.Principal.UserId;
            if ($check.StartsWith("S-"))  
            {
                [STRING]$check = ([wmi]"Win32_SID.SID='$check'").ReferencedDomainName + "\" +([wmi]"Win32_SID.SID='$check'").AccountName  
            }
            if ($task.Task.Principals.Principal.UserId)
            {
                Write-Verbose -Message "Writing the log file with values for $computername";  
                [Array]$AdmUsed += New-Object -TypeName PSObject | Select-Object @{Name="TaskName";Expression={$item}},@{Name="State";Expression={$task.Task.Settings.Enabled}},@{Name="TaskPath";Expression={$AbsolutePath}},@{Name="User";Expression={$check}},@{Name="ComputerName";Expression={$computer}},@{Name="Type";Expression={"Scheduled Tasks"}};  
            };
        };
    }else{
        [Array]$AdmUsed += New-Object -TypeName PSObject | Select-Object @{Name="ErrorMessage";Expression={"Unsupported OS, must be checked manually."}},@{Name="State";Expression={"Error"}},@{Name="ComputerName";Expression={$computer}},@{Name="Type";Expression={"Scheduled Tasks"}};  
        Write-Warning "$computer - Unsupported OS or offline, must be checked manually.";  
    };

};

$AdmUsed | Sort-Object -Property User, Type, Caption | Export-Csv -Encoding UTF8 -Delimiter ";" -NoTypeInformation -Path $OutFile;  


Und hier ein Skript, das dir alle Anmeldungen einer speziellen SID (bzw. User) anzeigt, braucht Zugriff auf das Sicherheits Eventlog eines Domaincontrollers (kurz als Administrator am DC ausführen). Warnung, treibt die Auslastung etwas hoch und kann sehr lange dauern, je nachdem, welchen Zeitraum du einstellst.

$filtersid = "S-1-5";  
Set-Location $(Split-Path $MyInvocation.MyCommand.Path)
$xmlEvent = @(); $xmlEvents = @();
$filter = @{
    Logname   = "Security";  
    ID        = 4624;
    StartTime = (Get-Date).AddDays(-10);
}

Get-WinEvent -FilterHashtable $filter | ForEach-Object {
    $xmlEvent = ([XML]$_.ToXml()).Event.EventData.Data;
    $xmlEvents += [psCustomObject][Ordered] @{
        TargetUserSid = [String]($xmlEvent | Where-Object {$_.Name -eq 'TargetUserSid'}).'#text';  
        TargetUserName = [String]($xmlEvent | Where-Object {$_.Name -eq 'TargetUserName'}).'#text';  
        TargetDomainName = [String]($xmlEvent | Where-Object {$_.Name -eq 'TargetDomainName'}).'#text';  
        IpAddress = [String]($xmlEvent | Where-Object {$_.Name -eq 'IpAddress'}).'#text';  
        LogonProcessName = [String]($xmlEvent | Where-Object {$_.Name -eq 'LogonProcessName'}).'#text';  
        AuthenticationPackageName = [String]($xmlEvent | Where-Object {$_.Name -eq 'AuthenticationPackageName'}).'#text';  
    };
};
$xmlEvents | ConvertTo-Csv -Delimiter ';' | Out-File .\LogonEvents.csv;  
$xmlEvents | Where-Object {$_.TargetUserSid -eq $filtersid} | ConvertTo-Csv -Delimiter ';' | Out-File .\filteredLogonEvent.csv;  
DerWoWusste
DerWoWusste 09.08.2016, aktualisiert am 10.08.2016 um 13:07:35 Uhr
Goto Top
Hi.

Ich reiß mal ein paar Punkte dazu an:

Ich würde das Projekt noch aufweiten und mir zunächst Gedanken machen, wo man welche Art von Rechten benötigt, denn es sieht schwer danach aus, als hättet ihr bislang kein Konzept verfolgt/gehabt.

Auf Workstations: keine globalen Admins verwenden, denn das ist gefährlich. Für Supportkonten besser etwas wie hier beschrieben umsetzen: Sicherer Umgang mit Supportkonten

Auf Servern: je nachdem, welcher Admin was sehen soll/dürfen soll, Rollenadmins verwenden - hier keine anonymen Admins, die von mehreren verwendet werden, nutzen. Die Domänenadmins sollten hier nicht genutzt werden, sondern lediglich auf DCs.

Dienst- und Taskkonten: wir nutzen fast ausschließlich das lokale Systemkonto. Dieses kann in Domänen im Netzwerk handeln und somit Jobs wie Backups wunderbar erledigen. Sein Kennwort wird automatisch durch das AD geändert, kein Wartungsaufwand.

Adminkonten sollten eine eigene, härtere Kennwortpolicy bekommen (externes Produkt wie Anixis PPE oder PSO). Je nach Schutzbedarf sollte man über 2-Faktor-Authentifizierung nachdenken.

Zu guter Letzt bleibt die Frage: "was wäre, wenn es bereits zu spät ist und die wenig vorsichtige Verwendung dieser starken Konten bereits ausgenutzt wurde?". Welche Kontrollmöglichkeiten bleiben dann, um das festzustellen?
agowa338
agowa338 09.08.2016 um 18:50:05 Uhr
Goto Top
Zitat von @DerWoWusste:
Zu guter Letzt bleibt die Frage: "was wäre, wenn es bereits zu spät ist und die wenig vorsichtige Verwendung dieser starken Konten bereits ausgenutzt wurde?". Welche Kontrollmöglichkeiten bleiben dann, um das festzustellen?
Da würde mein Skript zur Eventlog Auswertung helfen. face-wink
Dadurch kann man wunderbar unautorisierte Anmeldungen erfassen. (Vorausgesetzt der DC gilt noch als Vertrauenswürdig)
DerWoWusste
DerWoWusste 09.08.2016 um 19:31:58 Uhr
Goto Top
Welche Anmeldung wäre denn aus Sicht deines Skriptes unautorisiert? Wir sprechen von aktiven, gültigen, aber kompromittierten Konten.
agowa338
agowa338 09.08.2016 um 19:40:05 Uhr
Goto Top
Ja, es ist nicht perfekt, das Skript liest beides aus, sowohl autorisiert als auch unautorisiert, aber man kann die "LogonEvents.csv" z. B. mittels Excel manuell auswerten (z. B. Nach Server Sortieren und die User durchgehen oder alle Anmeldungen außerhalb der Geschäftszeiten)...
Penetrator
Penetrator 10.08.2016 um 12:52:53 Uhr
Goto Top
@129813: Very interessting. Thank you for this.
Penetrator
Penetrator 10.08.2016 um 12:58:01 Uhr
Goto Top
@agowa883:

Sehr sehr interessant. Das wird auf jeden Fall angepasst und getestet. Auf dem in unseren Standort stehenden RODC muss ich mal schauen, ob mir meine OUAdmin Rechte ausreichen um Anmeldungen eines Benutzers auszuwerten.
Penetrator
Penetrator 10.08.2016 um 13:37:03 Uhr
Goto Top
@DerWoWusste:

ermal vielen Dank für Deine Ausführung.

Ich würde das Projekt noch aufweiten und mir zunächst Gedanken machen, wo man welche Art von Rechten benötigt, denn es sieht schwer danach aus, als hättet ihr bislang kein Konzept verfolgt/gehabt.

Auf Workstations: keine globalen Admins verwenden, denn das ist gefährlich. Für Supportkonten besser etwas wie hier beschrieben umsetzen: Sicherer Umgang mit Supportkonten


Da stimme ich Dir uneingeschränkt zu. Allerdings betrifft dies jediglich Serverdienste und Anwendungen die auf Servern laufen.

Für Workstations ist es unverzichtbar sehr restriktiv mit Administrativen Rechten umzugehen und dies wird bei uns auch sehr schön gelebt. (GPO gesteuerte Passwortänderungen mit entsprechender Richtlinie bezogen auf komplexität; nur für spezielle Anwendungsfälle und auch nur temporär gestattete lokale Admin Rechte; speziell vom Anwendungseigner zu gestattende AD Berechtigungsgruppenzugehörigkeiten etc.).

Allein nur wegen dem Alptraum eines jeden Admins RandomTrojaner!

Auf Servern: je nachdem, welcher Admin was sehen soll/dürfen soll, Rollenadmins verwenden - hier keine anonymen Admins, die von mehreren verwendet werden, nutzen. Die Domänenadmins sollten hier nicht genutzt werden, sondern lediglich auf DCs.

An diesem Punkt weiss ich nicht genau was Du meinst. Wir haben verbunden durch die große Struktur von der Berechtigungsstufe AD Gruppen, welche jediglich Rechte auf entsprechende AD Organisationseinheiten haben. Dementsprechend haben wir nur Rechte in unserer eigenen kleinen Welt als Administratoren.

Dienst- und Taskkonten: wir nutzen fast ausschließlich das lokale Systemkonto. Dieses kann in Domänen im Netzwerk handeln und somit Jobs wie Backups wunderbar erledigen. Sein Kennwort wird automatisch durch das AD geändert, kein Wartungsaufwand.

Dies ist genau was ich gerne hätte. Hier habe ich jedoch grossen Respekt vor Änderungen und keine Erfahrungen, was passiert wenn ich zum Beispiel in BackupExec in den Diensten den OUAdmin rausnehme und auf das lokale Systemkonto umstelle. Wobei in diesem Falle BackuExec ein denkbar schlechtes Beispiel ist, da die Dienstauthentifizierung im Programm selber festgelegt werden. Ich hoffe Du weisst worauf ich hinaus will.

Adminkonten sollten eine eigene, härtere Kennwortpolicy bekommen (externes Produkt wie Anixis PPE oder PSO). Je nach Schutzbedarf sollte man über 2-Faktor-Authentifizierung nachdenken.

Benutzer mit Admin Rechten haben jeweils ein zusätzliches Benutzerkonto welches sehr restriktiven und auch zeitnahen Passwortänderungsintervallen unterliegen. Selbst am eigenen Rechner ist es dem Administrator untersagt lokale Administrative Rechte dauerhaft zu verwenden. Dies wird gescannt und auch geahndet.

Zu guter Letzt bleibt die Frage: "was wäre, wenn es bereits zu spät ist und die wenig vorsichtige Verwendung dieser starken Konten bereits ausgenutzt wurde?". Welche Kontrollmöglichkeiten bleiben dann, um das festzustellen?

Dieser Einwand ist ebenfalls berechtigt, aber ich denke bei uns ist es noch nicht so weit. Wenn es mir gelingt die Linuxserver an einen vorhandenen Radiusserver anzukoppeln und die Windowsbasierenden Serverdienste vom OUAdmin Account zu trennen und Sie mit Serviceaccounts
zu ersetzten habe ich schon eine Menge erreicht. Hier denke ich wird viel zu testen haben. Es bleibe allerdings immer noch das Problem mit den automatisch sich zu Ändernden Passwörtern.
DerWoWusste
Lösung DerWoWusste 10.08.2016 um 14:29:58 Uhr
Goto Top
Ob Anwendungen/Tasks/Dienste als lokales Systemkonto arbeiten können, oder nicht, weiß nur der Hersteller selbst. Du kannst es natürlich auch ausprobieren, aber der Hersteller sollte gefragt werden. Als Augenöffner: manche Entwickler entwickeln auf Standalone-Rechnern. Die haben dann ein peer-to-peer-Netzwerk und keine Domäne und denken aus Erfahrung heraus: "das lokale Systemkonto ist auf Arbeiten auf dem eigenen System beschränkt, es kann nicht im Netzwerk handeln, somit kann ich es nicht für Netzwerkdienste nutzen". Diese Schlussfolgerung trifft jedoch auf Domänenrechner nicht zu, deren Systemkonto kann sehr wohl im Netzwerk handeln.
Dennoch empfehlen diese Entwickler dann unter Umständen mangels Erfahrung, ein "eigenes Konto für die Dienste", bzw. sie legen gleich automatisch eines an. Ich vermute stark, dass der Wechsel auf ein das lokale Systemkonto in den meisten Fällen problemlos wäre.

Ob man jedoch überhaupt immer das Systemkonto nehmen will, ist eine weitere Frage. Es ist das stärkste lokale Konto, wer also einen solchen "Systemdienst" dank einer Sicherheitslücke erfolgreich angreift, der darf fortan mit Systemrechten handeln! Nimmt man stattdessen ein managed Serviceaccount (siehe Highload), dann muss dies nicht zwingend ein starkes Konto (lokale Admingruppe) sein, aber ich fürchte, für sehr viele Dienste wird die Adminmitgliedschaft eh nötig sein.

Auf Servern: je nachdem, welcher Admin was sehen soll/dürfen soll, Rollenadmins verwenden - hier keine anonymen Admins, die von mehreren verwendet werden, nutzen. Die Domänenadmins sollten hier nicht genutzt werden, sondern lediglich auf DCs.
An diesem Punkt weiss ich nicht genau was Du meinst

Ich meine folgendes: vermeide Fehler wie diese:
-man hat ein Domänenadminkonto, dass man zur Administration aller Server nutzt
-man hat personalisierte Domänenadmins, die man für alle Server nutzt

Statt dessen lieber (z.B.): eine Domänengruppe "SQLAdmins", in der verschiedene, nicht anonyme Konten sind, die den Personen, die die SQL-Server administrieren sollen, zugeteilt werden. Diese Gruppe SQLAdmins wäre dann in der lokalen Admingruppe jedes SQL-Servers eingetragen. Das meine ich mit "Rollenadmins".