none
Lokales Adminkonto gesperrt RRS feed

  • Frage

  • Guten Tag miteinander

    Für unsere Windows 10 Laptops im Unternehmen erstellen wir bei der Einrichtung ein lokales Adminkonto ausserhalb der Firmendomäne und des Activ Directorys, welches der Benutzer jedoch nicht benutzt.

    In letzter Zeit ist nun öfters passiert, dass genau dieses lokale Adminkonto gesperrt/deaktiviert wurde. 

    Ich gehe nicht davon aus, dass das Konto durch zu viele fehlgeschlagene Loginversuchen durch den Nutzer gesperrt wurde, da das Konto dem Arbeiter nicht bekannt ist.

    Ich habe bereits versucht, die Ereignisanzeige auszuwerten (Nach den EreignisIDs 4740 und 4725 => Habe ich in sonstigen Foren gefunden), jedoch war nichts vorhanden und die Ereignisanzeige protokolliert nur ca. 2 Monate zurück.

    Ausserdem habe ich versucht, mich mit diversen Tools von Microsoft zu behelfen, jedoch ebenfalls erfolglos.

    (https://www.microsoft.com/en-us/download/details.aspx?id=18465 und https://www.microsoft.com/en-us/download/details.aspx?id=15201)

    Hat jemand noch eine Idee, was ich prüfen könnte, um die Ursache der Kontosperrung auf den Grund zu gehen?

    Vielen Dank für eure Hilfe und noch einen schönen Tag!

    Freundliche Grüsse

    Tobias Wüst

    Donnerstag, 15. Februar 2018 07:31

Alle Antworten

  • Hallo Tobias,

    per GPO kann eingestellt werden, dass die lokale Kennung "Administrator" immer aktiv ist. Er sollte sich dann nicht sperren. Zudem sollte definiert werden, dass das vordefinierte Kennwort niemals abläuft. Das sollte eigentlich schon helfen.

    Oder erstellt ihr einen komplett eigenen Benutzer welcher lokale Adminrechte hat? Wie genau (GPO / Skript) wird der eingerichtet?

    Wenn du zum Beispiel einen Benutzer per Skript einrichtest, kannst du per GPO (ab Server 2008 R2) ja ein paar Definitionen dazu mitgeben. Siehe Screenshot.

    GPO Einstellung für lokalen Benutzer

    Gruß


    Ben


    • Bearbeitet Ben.IT Donnerstag, 15. Februar 2018 09:41 Screenshot eingefügt
    Donnerstag, 15. Februar 2018 09:35
  • Dass Du in den Event Logs keine fehlgeschlagenen Versuche findest, könnte daran liegen, dass das Auditing nicht aktiviert ist. Da es sich um ein lokales Konto handelt, muss das Auditing auf den Workstations selbst hochgedreht werden.

    Ohne die von Dir zitierten Events wirst Du vermutlich nicht hinter die Ursache kommen, denn alle Tools machen genau davon Gebrauch.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 15. Februar 2018 10:54
  • Guten Morgen Ben

    Vielen Dank für deine Hilfe.

    Unser Adminuser ist das original, voreingestellte Adminkonto von Windows, welches wir lediglich unbenannt haben. Die Einstellungen wie sie du beschrieben hast (Konto läuft nie ab usw.) sind bereits richtig hinterlegt.

    Montag, 19. Februar 2018 07:08
  • Guten Morgen Evgenij

    Vielen Dank für den Hinweis!

    Dieses Windows Auditing ist jedoch nur auf Serverebene, oder?
    Also ich meine, dass sich das nur auf Konten bezieht, welches im Active Directory hinterlegt sind und nicht wie in diesem Fall auf ein lokales Konto?

    Auf was sollte ich achten, wenn ich das Auditing korrekt einrichten will?


    Montag, 19. Februar 2018 07:23
  • Guten Morgen,

    die "neuen" GPO Einstellungen und die "alten" kommen sich manchmal in die Quere. Das bedeutet wenn unter Computerkonfig -> Windows Einstellung -> Sicherheitseinstellung -> Lokale Richtlinien / Sicherheitsoptionen das Feld "Konten: Administratorkontenstatus" auf "deaktiviert" steht passieren genau das was dein Problem ist. Mal wird die eine Richtlinie vorgezogen, mal die andere. So ist es bei uns. Erst bei einem gpupdate /force (bei verbundenen Systemen) hatte sich dann das lokale Adminkonto aktiviert.

    Ich empfehle dir mal die o. a. Einstellung zusätzlich zu definieren, also Administratorkonto auf "Aktiviert" zu setzen. Und zwar in einer Richtlinie, die von der Reihenfolge zuletzt vom Client verarbeitet wird (falls es eine andere dazwischen ggf. falsch definiert wurde). Beachte dass die GPO Verknüpfungsreihenfolge von unten nach oben abgearbeitet wird.

    Gruß


    Ben

    Montag, 19. Februar 2018 10:00