lokaler admin sperrt domain admin

[Zettelmcp 10]

Hallo zusammen,

 

ich konnte folgenden Fall jetzt auf mehreren clients nachstellen. Wir haben auf clients einen lokalen admin, der genauso heißt wie der domain admin, natürlich mit einem anderen pw. Seltsamerweise haben wir seit einem Monat das Problem, dass sobald sich der lokale admin 3 x falsch anmeldet, die AD mir die Mitteilung sendet, dass mein domain admin locked out ist, später dann gesperrt. Event log bringt mir lokal und am DC nichts, außer eben, dass er locked out ist. Mir ist das absolut rätselhaft. ich habe sowas in 20 Jahren IT Erfahrung noch nicht erlebt. An den clients wird ganz sicher beim Aufsetzen ein admin user mit dem selben Namen in der ARbeitsgruppe angemeldet.

 

Ideen?

 

Zettel

[magheinz 100]

und bei der Anmeldung am client nutzt die welche Schreibweise für den Anmeldenamen? Gib mal ein Beispiel.

Von welchen Windowsversionen reden wir eigentlich?

[MurdocX 904]

Lokal kannst du dich mit ".\<Account>" oder "<Computername>\<Account>" anmelden.

[magheinz 100]

Deswegen würde ich gerne mal sehen wie er das macht. Nicht das er die ganze zeit das Domain-Konto nutzt ohne es zu Wissen.

 

Abgesehen davon: Hier sieht man schön warum man ein Konto nicht einfach wegen zu vieler falscher Loginversuche sperren sollte. Das ist eine Einladung für einen DOS-Angriff.

[Zettelmcp 10]

Lokal kannst du dich mit ".\<Account>" oder "<Computername>\<Account>" anmelden.

 

ach echt? :-D

 

im ernst, wer so doof ist, soll seinen Beruf wechseln.

 

 

es wird die gleiche Schreibweise verwendet nbcadmin local und domain. Mein nächste Vermutung, dass eine Fremdsoftware (lenovo oder HP) cached, ich erinnere mich an einen Fall in einer newsgroup, technisch weiß ichs aber nicht mehr.

 

Serverlandschaft: 3 DC w2k8 und 1 DC 2k12 mit w7prof clients

[magheinz 100]

Welche Schreibweise wird jetzt genau genutzt. Zeig doch mal ein Beispiel bitte. Bei exakt gleicher Schreibweise vermute ich nämlich das du das Domänenkonto nutzt womit dein Problem einfach zu erklären wäre.

Also bitte Beispiele. Zur Not mit screenshot.

[testperson 1.539]

Um gar nicht erst in diese Situation zu kommen, keine lokalen Konten nutzen. Bzw. den lokalen Admin umbenennen (nach Möglichkeit nicht gleich dem von euch genutzten Dom-Admin), mit Kennwort versehen, deaktivieren und einen AD Benutzer erstellen, der für die lokale Administration am Client genutzt werden kann.

[Zettelmcp 10]

Welche Schreibweise wird jetzt genau genutzt. Zeig doch mal ein Beispiel bitte. Bei exakt gleicher Schreibweise vermute ich nämlich das du das Domänenkonto nutzt womit dein Problem einfach zu erklären wäre.

Also bitte Beispiele. Zur Not mit screenshot.

 

pc-202\nbcadmin -> loggt ein, lokal angemeldet, Arbeitsgruppe     |     <domain>\nbcadmin  -> Domänenanmeldung. Wird auch in beiden Fällen korrekt geloggt, zudem sieht der lokale nbcadmin rein gar nichts (also echter lokaler admin). Echt strange... den ganzehrlich, wie viele Millionen lokale Administrator accounts gibt es die genauso geschrieben werden und dazu dann der domain admin auch Administrator heißt? 

Um gar nicht erst in diese Situation zu kommen, keine lokalen Konten nutzen. Bzw. den lokalen Admin umbenennen (nach Möglichkeit nicht gleich dem von euch genutzten Dom-Admin), mit Kennwort versehen, deaktivieren und einen AD Benutzer erstellen, der für die lokale Administration am Client genutzt werden kann.

 

dann hast du ein Problem, nimm nur mal an du verlierst die Vertrauensstellung, dann wars das mit der domain Anmeldung mit dem client. Wenns dann schnell gehen soll und du hast deine lokalen accounts deaktiviert...hmmm...schnell biste dann nicht mit einer Lösung

[testperson 1.539]

Schonmal in den abgesicherten Modus gebootet? ;)

[zahni 521]

Die Empfehlung ist, keine lokalen Admins zu verwenden und dem Builtin-Admin per GPO ein Sinnlos-Passwort zu vergeben und dann zu deaktivieren.

Gleichzeitig sollte das Caching von Domain-Konten auf Geräte beschränkt werden, deren HDD verschlüsselt ist (z.B. mit Bitlocker)

Die lokal gespeicherten Passwörter (auch gecachte) lassen sich leider immer noch mit entsprechenden Tools auslesen, sobald man physischen Zugriff auf die Geräte hat.

 

Wenn Du darauf nicht verzichten willst: nimm Lokal einfach ein anderes Konto.

bearbeitet 26. September 2015 von zahni

[DocData 85]

Öffne einen Support Case bei Microsoft. Das Problem ist mir in der Praxis nie über den Weg gelaufen. Und eine Root Cause Analyse per Forum ist nahezu unmöglich.

[testperson 1.539]

...dem Builtin-Admin per GPO ein Sinnlos-Passwort zu vergeben und dann zu deaktivieren...

Dafür würde ich die Local Administrator Password Solution (LAPS) einsetzen ;)

[NorbertFe 1.809]

Wieso benennt man denn den lokalen Admin auch wie den domadmin wenn man beides sowieso umbenennt?

[ChrisRa 42]

Abgesehen davon: Hier sieht man schön warum man ein Konto nicht einfach wegen zu vieler falscher Loginversuche sperren sollte. Das ist eine Einladung für einen DOS-Angriff.

Gewagte Aussage. Hast du einen vernünftigen Mechanismus, bei dem du merkst, wann ein Bruteforce-Angriff stattfindet? Wenn ja, kannst du es natürlich deaktivieren. Wenn nicht, würde ich persönlich jedenfalls nicht machen.

bearbeitet 26. September 2015 von ChrisRa

[NorbertFe 1.809]

Na jedenfalls nicht bei 3 fehleingaben