7
Im AD Konten mit leeren Kennwörtern finden
Hallo,
gibt es eine Möglichlkeit im ActiveDirectory unter Win2003 nach User zu suchen die ein leeres Kennwort besitzen?
Oder kann man Domänennutzern mit leerem Kennwort das anmelden an einem PC innerhalb der Domäne verweigern oder die vergabe eine Kennworts fordern?
mfg
Jim
gibt es eine Möglichlkeit im ActiveDirectory unter Win2003 nach User zu suchen die ein leeres Kennwort besitzen?
Oder kann man Domänennutzern mit leerem Kennwort das anmelden an einem PC innerhalb der Domäne verweigern oder die vergabe eine Kennworts fordern?
mfg
Jim
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: 35293
Url: https://administrator.de/contentid/35293
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
7 Kommentare
Neuester Kommentar
moin,
dies kannst du mit den Gruppenrichtlinien definieren.
maximale Länge, dauer und noch diverse andere Einstellungen wie komplexität usw.
grüsse Shaby
dies kannst du mit den Gruppenrichtlinien definieren.
maximale Länge, dauer und noch diverse andere Einstellungen wie komplexität usw.
grüsse Shaby
Das müßte ich auf alle Benutzer anwenden da ich ja immer noch nicht weiß wer KEIN Kennwort vergeben hat. Das will ich aber nicht(da einfach zu viele Benutzer), sondern ich möchte wissen wer kein sprich ein leeres Kennwort hat. Mit DSGET und DSQUERY bin ich nicht weitergekommen.
Hallo,
tja, da hast du leider Pech.
Da wird Dir wohl nichts anderes übrigbleiben als alle User im ADS zu markieren und über die Eigenschaften dann auswählen, das die User beim nächsten Anmelden ein neues Lennwort eingeben müssen.
Hierbei aber nicht die Kennwortrichtlinieneinstellungen vergessen.
Gruss
tja, da hast du leider Pech.
Da wird Dir wohl nichts anderes übrigbleiben als alle User im ADS zu markieren und über die Eigenschaften dann auswählen, das die User beim nächsten Anmelden ein neues Lennwort eingeben müssen.
Hierbei aber nicht die Kennwortrichtlinieneinstellungen vergessen.
Gruss
Hallo Jim,
schau dir mal diesen Thread an:
http://groups.google.de/group/microsoft.public.windows.server.scripting ...
Ich denke mit ein wenig Handarbeit sollte es hinzubekommen sein, dass die Benutzer
mit "leeren" Kennwörtern in eine txt-Datei oder ähnliches geschrieben werden.
Poste es ggf. mal hier ins Skript-Forum, da kann dir bestimmt jemand helfen!
Gruß aus dem Badischen
Patrick
schau dir mal diesen Thread an:
http://groups.google.de/group/microsoft.public.windows.server.scripting ...
Ich denke mit ein wenig Handarbeit sollte es hinzubekommen sein, dass die Benutzer
mit "leeren" Kennwörtern in eine txt-Datei oder ähnliches geschrieben werden.
Poste es ggf. mal hier ins Skript-Forum, da kann dir bestimmt jemand helfen!
Gruß aus dem Badischen
Patrick
Moin jimmi,
ich verstehe an zwei, drei Stellen nicht, wie es überhaupt zu dieser Situtation kommen konnte...
Bei Einrichtung eines neues Benutzers (auf welchem Weg auch immer) werden dem Admin/der Admine unter anderem die Einstellungen abverlangt:
- Passwort erforderlich (für den neuen User) ?
- Ablaufdatum des Passworts / wie oft muss der User es ändern?
- (Passwort-Kriterien, ~-Komplexität, ~-Wiederverwendbarkeit..)
Meine Verständnisfragen:
a) Wenn angegeben wurde "Passwort erforderlich", dann kann doch kein User ein "leeres Passwort" haben, oder doch?
b) wenn der Benutzer mit leerem Passwort (oder auf Deutsch: ohne Passwort) eingerichtet wurde, dann ist es demnach immer noch leer, wenn es nie geändert wurde/werden musste.
Dann solltest Du die beiden Fälle mit einem Batch/einem WSH-Skript doch so erwischen können:
(Beispiel für EINEN Usernamen UserXYZ vom als Batch-Skizze)
... Soll nur die Strategie verdeutlichen, aber inhaltllich wären das IMHO die einzigen beiden Kriterien, mit denen Du so etwas implizit prüfen kannst.
Gruß
Biber
[Edit]
Jepp... oder als dreiste dritte Möglichkeit die von Patrick gepostete... einfach mal testen, ob sich das Userpasswort von leer auf "irgendwas" ändern lässt.... wenn kein Fehler kommt, dann war es leer...
[/Edit]
ich verstehe an zwei, drei Stellen nicht, wie es überhaupt zu dieser Situtation kommen konnte...
Bei Einrichtung eines neues Benutzers (auf welchem Weg auch immer) werden dem Admin/der Admine unter anderem die Einstellungen abverlangt:
- Passwort erforderlich (für den neuen User) ?
- Ablaufdatum des Passworts / wie oft muss der User es ändern?
- (Passwort-Kriterien, ~-Komplexität, ~-Wiederverwendbarkeit..)
Meine Verständnisfragen:
a) Wenn angegeben wurde "Passwort erforderlich", dann kann doch kein User ein "leeres Passwort" haben, oder doch?
b) wenn der Benutzer mit leerem Passwort (oder auf Deutsch: ohne Passwort) eingerichtet wurde, dann ist es demnach immer noch leer, wenn es nie geändert wurde/werden musste.
Dann solltest Du die beiden Fälle mit einem Batch/einem WSH-Skript doch so erwischen können:
(Beispiel für EINEN Usernamen UserXYZ vom als Batch-Skizze)
REM Englisches Windows:
(NET USER userXYZ /DOMAIN ¦ FIND /I "Password last set" |find /i "Never ) && call :NeverSet userXYZ
REM --- wenn es ein deutschsprachiges Fensters ist
(NET USER userXYZ /DOMAIN ¦ FIND /I "Letztes Setzen" |find /i "Nie" ) && call :NeverSet userXYZ
REM ...analog mit "Passwort erforderlich" - nur bei wem es nicht erforderlich ist, der hat keins
(NET USER userXYZ /DOMAIN ¦ FIND /I "Password required" |find /i "No" ) && call :PwRequired userXYZ
(NET USER userXYZ /DOMAIN ¦ FIND /I "Kennwort erforderlich" |find /i "Nein" ) && call :PwRequired userXYZ
goto :eof
:NeverSet
@echo User %1 hat noch NIE sein PW gesetzt!
REM..... Aktionen....
goto :eof
:PwRequired
@echo Bei User %1 ist kein PW erforderlich!
REM..... Aktionen....
goto :eof... Soll nur die Strategie verdeutlichen, aber inhaltllich wären das IMHO die einzigen beiden Kriterien, mit denen Du so etwas implizit prüfen kannst.
Gruß
Biber
[Edit]
Jepp... oder als dreiste dritte Möglichkeit die von Patrick gepostete... einfach mal testen, ob sich das Userpasswort von leer auf "irgendwas" ändern lässt.... wenn kein Fehler kommt, dann war es leer...
[/Edit]
Alla guut,
hier ist die Lösung:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct05/hey ...
hier ist die Lösung:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct05/hey ...
@24213
Dieser Artikel ist allein schon deshalb lesenswert, weil dort M$ wahrscheinlich erstmals diese mistige Fehlernummer -2147023569 dokumentiert:
Danach haben schon Hunderte von Usern in -zig Newsgroups gesucht...
Danke für den Link.
Biber
Dieser Artikel ist allein schon deshalb lesenswert, weil dort M$ wahrscheinlich erstmals diese mistige Fehlernummer -2147023569 dokumentiert:
Alternatively, Err might be equal to -2147023569; that means the method would have
succeeded except that, due to local policy, not enough time has elapsed since the last password change.
succeeded except that, due to local policy, not enough time has elapsed since the last password change.
Danach haben schon Hunderte von Usern in -zig Newsgroups gesucht...
Danke für den Link.
Biber
