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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 312154
Url: https://administrator.de/contentid/312154
Ausgedruckt am: 26.11.2024 um 09:11 Uhr
10 Kommentare
Neuester Kommentar
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
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
Hier ein Skript, das dir (fast) alle Verwendungen des Domänenadministrators bzw. Lokaler Administratoren auflistet
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.
$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;
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?
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?
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. 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?
Dadurch kann man wunderbar unautorisierte Anmeldungen erfassen. (Vorausgesetzt der DC gilt noch als Vertrauenswürdig)
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.
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".
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 meinstIch 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".