9
Profil-Konto-Credentials eines Domänen Administrators auf Clients löschen
Hallo Zusammen,
hintergrund meiner Frage ist, dass ich in unserem Betrieb gängige Sicherheitsstandards einführen möchte.
Einer der Schritte betrifft die Verwendung von Domänen-Admin-Konten zur tägl. Administration. Als ich eingestellt wurde, habe ich meinen persönlichen Domänenadministrator Account erhalten und diesen seither für alle möglichen Aufgaben verwendet. ->Lokal angemeldet, Programme installiert etc. Noch treffen meine Vorschläge auf Wiederstand der anderen Admins, aber ich möchte zumindest meine persönliche Arbeitsweise anpassen.
Ich würde dann zur Administration nur noch ein Lokales Admin Konto verwenden? und für Domänengeschichten (Netzwerkdrucker hinzufügen, Domänen-Benutzer anlegen, GPOs verwalten) meine Rechte einschränken.
Gibt es eine Möglichkeit mein Profil (Credentials) von allen Clients zu löschen, ohne das ich mich an jedem Gerät persönlich anmelden muss?
Für Tipps wäre ich wirklich dankbar, da ich sonst niemanden habe den ich Fragen könnte.
hintergrund meiner Frage ist, dass ich in unserem Betrieb gängige Sicherheitsstandards einführen möchte.
Einer der Schritte betrifft die Verwendung von Domänen-Admin-Konten zur tägl. Administration. Als ich eingestellt wurde, habe ich meinen persönlichen Domänenadministrator Account erhalten und diesen seither für alle möglichen Aufgaben verwendet. ->Lokal angemeldet, Programme installiert etc. Noch treffen meine Vorschläge auf Wiederstand der anderen Admins, aber ich möchte zumindest meine persönliche Arbeitsweise anpassen.
Ich würde dann zur Administration nur noch ein Lokales Admin Konto verwenden? und für Domänengeschichten (Netzwerkdrucker hinzufügen, Domänen-Benutzer anlegen, GPOs verwalten) meine Rechte einschränken.
Gibt es eine Möglichkeit mein Profil (Credentials) von allen Clients zu löschen, ohne das ich mich an jedem Gerät persönlich anmelden muss?
Für Tipps wäre ich wirklich dankbar, da ich sonst niemanden habe den ich Fragen könnte.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 74053282755
Url: https://administrator.de/contentid/74053282755
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo Gabrielo
Was evtl. funktionieren könnte ist falls du ein RMM verwendest ein PowerShell Skript auszuführen, falls das möglich ist? Sonst weiss ich leider auch gerade nichts.
Gruss bjoern
Was evtl. funktionieren könnte ist falls du ein RMM verwendest ein PowerShell Skript auszuführen, falls das möglich ist? Sonst weiss ich leider auch gerade nichts.
Gruss bjoern
Hi,
die Idee mit unterschiedlichen Benutzern für die Administration ist gut.
Was willst du mit Credentials löschen erreichen? Wenn du das Passwort deines Domänenadmin-Accounts änderst, kann mit den Credentials im Cache der Clients keiner mehr was anfangen, wenn sich die Kisten regelmäßig am DC melden.
Alternativ kannst du dir einen oder mehrere neue ADM Accounts anlegen und den alten komplett deaktivieren und aus den Admingruppen entfernen. Dann kann man auch lokal damit nichts mehr anfangen.
Gruß
Drohnald
die Idee mit unterschiedlichen Benutzern für die Administration ist gut.
Was willst du mit Credentials löschen erreichen? Wenn du das Passwort deines Domänenadmin-Accounts änderst, kann mit den Credentials im Cache der Clients keiner mehr was anfangen, wenn sich die Kisten regelmäßig am DC melden.
Alternativ kannst du dir einen oder mehrere neue ADM Accounts anlegen und den alten komplett deaktivieren und aus den Admingruppen entfernen. Dann kann man auch lokal damit nichts mehr anfangen.
Gruß
Drohnald
1
Vielen Dank für die Antwort,
an das löschen/deaktivieren meines bisherigen Admin Accounts habe ich auch schon gedacht. Allerdings habe ich gerade folgende Vorstellung die natürlich auch völlig falsch sein könnte:
Angenommen ich deaktiviere/lösche meinen bisherigen Admin Zugang. Das Profil bleibt ja weiter auf den Rechnern. Wenn ein Angreifer die Verbindung zur Domäne temporär trennt (z.B. Netzwerkverbindung für 5 Minuten unterbrechen), könnte er dann nicht das immer noch hinterlegte Profil verwenden um lokal erhöhte Rechte zu erlangen oder wird mit der Deaktivierung des Accounts im AD auch die weitere verwendung am Client komplett verhindert?
an das löschen/deaktivieren meines bisherigen Admin Accounts habe ich auch schon gedacht. Allerdings habe ich gerade folgende Vorstellung die natürlich auch völlig falsch sein könnte:
Angenommen ich deaktiviere/lösche meinen bisherigen Admin Zugang. Das Profil bleibt ja weiter auf den Rechnern. Wenn ein Angreifer die Verbindung zur Domäne temporär trennt (z.B. Netzwerkverbindung für 5 Minuten unterbrechen), könnte er dann nicht das immer noch hinterlegte Profil verwenden um lokal erhöhte Rechte zu erlangen oder wird mit der Deaktivierung des Accounts im AD auch die weitere verwendung am Client komplett verhindert?
Vielen Dank für die Antworten.
Ich werde morgen noch mal meinen AL ansprechen und versuchen ihn zur Durchsetzung des Tier Models zu bewegen.
Damit ich nichts falsches erzähle bräuchte ich eine bestätigung meiner Gedankengänge:
Aber wie werden dann Domänen-Arbeiten ausgeführt? Also welche Rechte/Gruppenmitgliedschaften sollten die Tier2 Accounts der Administratoren haben, bzw wie werden diese gesetzt?
Bisher handhaben wir es so, dass wir uns, z.B. für die Benutzerwaltung, am DC anmelden. Dort wären dann Tier 0 Accounts notwendig. Für diese Accounts wäre dann eine eigene Gruppe zu erstellen, die Rechte zum Bearbeiten von Benutzerobjekten/Computerobjekten/Gruppenmitgliedschaften/ GPOs gewährt.
(Wir sind ein kleines IT-Team von 4 Personen, wobei alle von uns, (zeitweise) alle Aufgaben übernehmen)
Ich werde morgen noch mal meinen AL ansprechen und versuchen ihn zur Durchsetzung des Tier Models zu bewegen.
Damit ich nichts falsches erzähle bräuchte ich eine bestätigung meiner Gedankengänge:
- Keine Domänenadministratoren mehr verwenden. Es bleibt nur noch das standard Administrator Konto Mitglied der Gruppe der Domänenadministratoren.
- Für die normale Administration werden lokale Konten verwendet. Deren Passwörter werden mit Windows LAPS zufällig vergeben.
Aber wie werden dann Domänen-Arbeiten ausgeführt? Also welche Rechte/Gruppenmitgliedschaften sollten die Tier2 Accounts der Administratoren haben, bzw wie werden diese gesetzt?
- Grundsätzlich sollten Verwaltungsaccounts Mitlgieder der Gruppe Protected Users sein?
- Um Netzwerkdrucker zu installieren wird die Mitgliedschaft in Druckoperatoren erteilt?
- um feste IPs zu vergeben usw. Mitgliedschaft in Netzwerkkonfigurations-Operatoren
- Wie werden die Rechte vergeben ein neues Gerät in die Domäne aufzunehmen?
- Welche rechte werden sonst noch für die tägl. Aufgaben benötigt?
Bisher handhaben wir es so, dass wir uns, z.B. für die Benutzerwaltung, am DC anmelden. Dort wären dann Tier 0 Accounts notwendig. Für diese Accounts wäre dann eine eigene Gruppe zu erstellen, die Rechte zum Bearbeiten von Benutzerobjekten/Computerobjekten/Gruppenmitgliedschaften/ GPOs gewährt.
(Wir sind ein kleines IT-Team von 4 Personen, wobei alle von uns, (zeitweise) alle Aufgaben übernehmen)
Angenommen ich deaktiviere/lösche meinen bisherigen Admin Zugang. Das Profil bleibt ja weiter auf den Rechnern. Wenn ein Angreifer die Verbindung zur Domäne temporär trennt (z.B. Netzwerkverbindung für 5 Minuten unterbrechen), könnte er dann nicht das immer noch hinterlegte Profil verwenden um lokal erhöhte Rechte zu erlangen oder wird mit der Deaktivierung des Accounts im AD auch die weitere verwendung am Client komplett verhindert?
Richtig, das spielt in deinem Fall aber eine eher geringe Rolle denn es gibt nur 2 Möglichkeiten:
1. Der Computer hat Verbindung zum DC -> Dann ist es egal ob du das Profil löscht, deaktivierst oder PW änderst
2. Der Computer hat keine Verbindung zum DC -> Dann kannst du höchstens mit deinem alten Admin drauf, einen neuen lokalen anlegen, die mich diesem neuen anmelden und dann das alte Adminprofil löschen.
1
Moin.
Es scheint dringend nötig, dass Ihr einiges ändert. Ich würde damit beginnen, die Trägheit zu hinterfragen: Warum kommt erst jetzt diese Initiative, wo schon seit vielen Jahren klar geworden ist, wie gerne Angreifer diese fahrlässig eingesetzten Domänenadminkonten nutzen.
Aus der Antwort darauf könnte folgen, dass es einigen Admins nicht reell erscheint bzw. dass einige keine Bereitschaft haben, Komfort gegen Sicherheit einzutauschen. Wenn man sich auf eine einheitliche Linie einigen könnte, wäre man ein gutes Stück weiter, denn wenn deine Bemühungen nur bei dir fruchten, ist nicht viel gewonnen.
Wenn Du dir ein AD Tiering in der Praxis ansehen willst, nimm diesen Leitfaden: https://www.experts-exchange.com/articles/29515/Active-Directory-Simple- ...
Wenn Du etwas wie LAPS einführen willst, frage Dich zunächst, ob für deine Arbeiten lokale Admins reichen. Mit meinem Ansatz, der schon verlinkt wurde, hättest Du lokale Admins, die aber auch Domänenressourcen nutzen können. Ich finde LAPS unpraktisch.
Für das Löschen der Credentials: wie schon gesagt: sobald Du das Kennwort änderst, kann der gecachte Logon im Netzwerk nichts mehr reißen. Natürlich ist er bei Offline-Anmeldung noch lokaler Admin, aber wie sollte ein Nichtadmin diesen Logon überhaupt ausführen? Er müsste das Kennwort per Angriff auf den Hash rausfinden und das ist ohne lokale Adminrechte gar nicht möglich.
Es scheint dringend nötig, dass Ihr einiges ändert. Ich würde damit beginnen, die Trägheit zu hinterfragen: Warum kommt erst jetzt diese Initiative, wo schon seit vielen Jahren klar geworden ist, wie gerne Angreifer diese fahrlässig eingesetzten Domänenadminkonten nutzen.
Aus der Antwort darauf könnte folgen, dass es einigen Admins nicht reell erscheint bzw. dass einige keine Bereitschaft haben, Komfort gegen Sicherheit einzutauschen. Wenn man sich auf eine einheitliche Linie einigen könnte, wäre man ein gutes Stück weiter, denn wenn deine Bemühungen nur bei dir fruchten, ist nicht viel gewonnen.
Wenn Du dir ein AD Tiering in der Praxis ansehen willst, nimm diesen Leitfaden: https://www.experts-exchange.com/articles/29515/Active-Directory-Simple- ...
Wenn Du etwas wie LAPS einführen willst, frage Dich zunächst, ob für deine Arbeiten lokale Admins reichen. Mit meinem Ansatz, der schon verlinkt wurde, hättest Du lokale Admins, die aber auch Domänenressourcen nutzen können. Ich finde LAPS unpraktisch.
Für das Löschen der Credentials: wie schon gesagt: sobald Du das Kennwort änderst, kann der gecachte Logon im Netzwerk nichts mehr reißen. Natürlich ist er bei Offline-Anmeldung noch lokaler Admin, aber wie sollte ein Nichtadmin diesen Logon überhaupt ausführen? Er müsste das Kennwort per Angriff auf den Hash rausfinden und das ist ohne lokale Adminrechte gar nicht möglich.
1
Vielen Dank für die Antwort und die Links.
Also die Bereitschaft für Änderungen scheint doch da zu sein, zumindest hat sich der Wiederstand gelegt, nachdem ich das Thema noch ein mal angesprochen habe. Wenn ich die Sachen selbständig Umsetzten kann hat wohl doch niemand was gegen Änderungen. Ich schätze der anfängliche Wiederstand lag daran, das wir mit dem Tagesgeschäft auch so schon genug zu tun haben und kaum dazu kommen Neuerungen umzusezten.
Ich bin noch relativ grün hinter den Ohren und versuche mich (selbstständig, über Fachliteratur) in die Richtung IT-Security weiterzubilden .
Am liebsten würde ich ein Praktikum in einem Unternehmen machen, bei denen alles Vorbildhaft konfiguriert ist. Allerdings glaube ich kaum das jemand ein Praktikum anbieten würde, bei dem es darum geht seine Sicherheitsvorkehrungen Preiszugeben ;)
Zum Thema LAPS, das habe ich einfach als Empfehlung gelsen und angenommen, dass dieses vorgehen der Standard sei.
Was das AD tiering angeht, so stellt sich mir die Frage, wie ich den erstellten Tier-Administratoren-Gruppen die spezifischen berechtigungen (z.B. Recht zum installieren von Netzwerkdruckern, Aufnahme in die Domäne oder Benutzerverwaltung im AD) vergeben kann.
Oder fügt man die Tier-Gruppen zur Gruppe "Administratoren" hinzu und beschränkt nur wo sich die einzelenen Gruppen einloggen dürfen? Denn dass die Rechte zum Einloggen beschnitten werden sollen habe ich oft gelesen, allerdings nirgends welche Rechte die einzelnen Tier-Gruppen haben sollen (und wie diese Konfiguriert werden).
Also die Bereitschaft für Änderungen scheint doch da zu sein, zumindest hat sich der Wiederstand gelegt, nachdem ich das Thema noch ein mal angesprochen habe. Wenn ich die Sachen selbständig Umsetzten kann hat wohl doch niemand was gegen Änderungen. Ich schätze der anfängliche Wiederstand lag daran, das wir mit dem Tagesgeschäft auch so schon genug zu tun haben und kaum dazu kommen Neuerungen umzusezten.
Ich bin noch relativ grün hinter den Ohren und versuche mich (selbstständig, über Fachliteratur) in die Richtung IT-Security weiterzubilden .
Am liebsten würde ich ein Praktikum in einem Unternehmen machen, bei denen alles Vorbildhaft konfiguriert ist. Allerdings glaube ich kaum das jemand ein Praktikum anbieten würde, bei dem es darum geht seine Sicherheitsvorkehrungen Preiszugeben ;)
Zum Thema LAPS, das habe ich einfach als Empfehlung gelsen und angenommen, dass dieses vorgehen der Standard sei.
Was das AD tiering angeht, so stellt sich mir die Frage, wie ich den erstellten Tier-Administratoren-Gruppen die spezifischen berechtigungen (z.B. Recht zum installieren von Netzwerkdruckern, Aufnahme in die Domäne oder Benutzerverwaltung im AD) vergeben kann.
Oder fügt man die Tier-Gruppen zur Gruppe "Administratoren" hinzu und beschränkt nur wo sich die einzelenen Gruppen einloggen dürfen? Denn dass die Rechte zum Einloggen beschnitten werden sollen habe ich oft gelesen, allerdings nirgends welche Rechte die einzelnen Tier-Gruppen haben sollen (und wie diese Konfiguriert werden).
Hi.
Zum Tiering: mir reicht die Trennung Clientadmin - ServerAdmin - DCadmin. Im jeweiligen Tier dann nur ein Adminkonto zu haben, halte ich für unbedacht und würde pro Client und pro Memberserver mindestens einen Admin einrichten. Nur auf den DCs nehme ich einen Admin, der (da logischerweise Domänenadmin) auf allen DCs Admin ist.
Die Admins können auf den Maschinen alles.
Zum Thema LAPS, das habe ich einfach als Empfehlung gelsen und angenommen, dass dieses vorgehen der Standard sei.
Microsoft hat LAPS vorgeschlagen und für einige Admins reicht das vollkommen. Will man aber bei der Clientadministration auf Domänenressourcen rauf (und das ist ja gängig), reicht das alleine nicht und man baut neue Krücken. Deshalb bevorzuge ich meinen eigenen Ansatz.Zum Tiering: mir reicht die Trennung Clientadmin - ServerAdmin - DCadmin. Im jeweiligen Tier dann nur ein Adminkonto zu haben, halte ich für unbedacht und würde pro Client und pro Memberserver mindestens einen Admin einrichten. Nur auf den DCs nehme ich einen Admin, der (da logischerweise Domänenadmin) auf allen DCs Admin ist.
Die Admins können auf den Maschinen alles.
