Powershell: Passwort ohne Komplexität funktioniert nicht!

Hallo Zusammen

Für die MAC-AUthentifikation benötige ich als Benutzername und Passwort eine MAC-Adresse, die exakt 1 zu gleich sein muss und sie muss gleich geschrieben werden. Habe ich eine kleine Testumgebung, auf der sonst nichts weiteres läuft, deswegen habe ich in der Default-Policy alles bezüglich Kennwortkomplexität abgestellt und auch extra in einer Organisationseinheit die Kennwortrichtlinien erneut in einer GPO definiert. Nun habe ich folgendes Problem

Ich möchte gerne per Powershell das Passwort auf die MAC-Adresse ändern, leider kriege ich immer noch die Meldung, dass das Passwort nicht komplex genug sei. In der Oberfläche von Microsoft funktioniert das Zurücksetzen aber problemlos.

Gibt es da noch eine Powershell-Bezogene einstellung? Folgendes habe ich schon versucht:

-Server neustarten
-gpupdate /force in der Selben Konsole wie auch der Set-ADAccountPasswort-Befehl gemacht wurde

Und da wüsste ich jetzt auch nicht, was ich sonst noch tun könnte. Ich habe noch einen zweiten DC, aber der übernimmt ja einfach die Einstellungen, die ich auf dem ersten treffe und alle Befehle habe ich auch auf meinem HauptDC ausgeführt.

Danke für eure Antworten

Gruss

gabeBU

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 232953

Url: https://administrator.de/contentid/232953

Ausgedruckt am: 26.11.2024 um 10:11 Uhr

9 Kommentare

Neuester Kommentar

Hi,

könnte es sein dass der 2. DC sich nicht aktualisiert (GPOs) und der Client
ausgerechnet auf den zugreift (mit noch "komplexer" PW-GPO ?

Schau mal CMD -> SET LOG welcher DC am Client angezeigt wird

Gruss
RS

Werde ich machen, aber ich arbeite direkt auf dem Server, trotzdem danke für den Tipp.

Hi,
poste mal bitte was Get-ADDefaultDomainPasswordPolicy ausgibt...
Und setze mal MinPasswordAge auf 0 Tage. Ist die minimale Passwortlänge auch nicht auf länger als eine MAC-Adresse lang ist gesetzt (17 Zeichen bei Verwendung von Trennzeichen / 12 ohne)?

Grüße Uwe

Die Mininmale Passwort länge habe ich auf "0" gesetzt....ich dachte ,das wäre sinnvoller...könnte das heissen, das ich gerade mir ein Eigentor geschossen habe, weil jetzt Passwörter keine länge mehr haben dürfen? Dann habe ich da wohl was falsch verstanden...

Ich muss die MAC-Adresse ohne Trennzeichen setzen, deswegen nur 12 Zeichen, aber ich werde es einstellen.

Das MinPasswordAge kann ich nur ändern, wenn ich auch das maxpasswordage ändere. Habe ich jetzt mal gemacht, diese Konfiguration nutze ich jetzt:

ComplexityEnabled           : False
DistinguishedName           : DC=IPA,DC=LOKAL
LockoutDuration             : 00:30:00
LockoutObservationWindow    : 00:30:00
LockoutThreshold            : 0
MaxPasswordAge              : 999.00:00:00
MinPasswordAge              : 00:00:00
MinPasswordLength           : 12
objectClass                 : {domainDNS}
objectGuid                  : 1dcbbaf6-29c7-49a7-a7bb-b72121f0a4de
PasswordHistoryCount        : 24
ReversibleEncryptionEnabled : True

Wie immer anschliessend eine Powershell auf dem Server geöffnet, als Administrator ausgeführt und per gpupdate /force auf dem eigenen Server die Gruppenrichtlinie aktualisiert, doch leider funktioniert es immer noch nicht.

Edit: Aaalso

Ich habe mal alle Gruppenrichtlinienobjekte gelöscht, die ich in letzter Zeit angelegt habe und habe den Server neugestartet. Das heisst, von den Gruppenrichtlinien her ist jetzt alles flach und es ist nur noch die Domain Policy da. Dort habe ich die Kennwortkomplexität deaktiviert und sonst alles undefiniert, funktioniert nicht.

Dann habe ich alle Werte auf "0" gestellt, kennwortkomplexität deaktiviert, funktioniert auch nicht und schlussendlich alles undefiniert, ging auch nicht.

Dann habe ich die Default Domain policy in jeder Organisationseinheit einzeln verknüpft, was auch nicht ging.

Langsam gehen mir die Ideen aus^^.

edit 2 : Okay, jetzt wird es wirklich seltsam...

ich habe es erneut versucht und beim Passwort zusätzlich zur MAC-Adresse eine "1" hinten angesetzt, dann klappte es. Soweit müsste das heissen, dass es bei der Powershell irgendwie eine regelung gibt, dass das Passwort 13 Zeichen lang sein muss, was mich verwirren würde.

EDIT 3: Gut, ich habe es rausgefunden. Es lag wohl daran, dass ich ein älterer MAC-Adressenbenutzer genommen habe, den ich vor diesen GPO-Änderungen genutzt habe. Die Benutzer habe ich neu angelegt und jetzt funktioniert auch das Passwort-setzen.

Zitat von @gabeBU:
Die Mininmale Passwort länge habe ich auf "0" gesetzt....ich dachte ,das wäre sinnvoller...könnte das
heissen, das ich gerade mir ein Eigentor geschossen habe, weil jetzt Passwörter keine länge mehr haben dürfen? Dann
habe ich da wohl was falsch verstanden...

Die minimale Passwortlänge sagt aus das ein Passwort minimal so lang sein muss.. du kannst sie also auch auf 8 setzen, auf 13 hätte sie nicht stehen dürfen, dann entspräche die MAC als Passwort nicht den Anforderungen.

klar Neustart gehört danach zur Pflicht ! ist ja eine Computer-Policy ...

Langsam gehen mir die Ideen aus^^.

dann ist bei dir was oberfaul, geh mal in die Kennwortverwaltung von Windows und lösche dort alle Hinterlegten Passwörter raus, dann meldest du dich ab und nochmal neu an ...manchmal gibt es dort mit Hinterlegten Adminpasswörtern Probleme die solche komischen Fehler in der Powershell verursachen.

dass es bei der Powershell irgendwie eine regelung gibt, dass das Passwort 13 Zeichen lang sein muss, was mich verwirren würde.

definitiv NEIN. Die Powershell macht hier keine Extrawurst !

Ich vermute eher dein Script hat eine Macke

Grüße Uwe

Also, alles funktioniert jetzt, ich musste nur den Nutzer neu anlegen, dann konnte ich auch sein Passwort anlegen.

Zudem muss ich wie es scheint immer in der Default Domain Policy die Kennwortrichtlinie deaktivieren und kann das Passwort setzen nicht später über eine GPO in der entsprechenden OU setzen, oder ich muss mich da noch weiter einlesen.

Jedenfalls danke für eure Tipps.

Zitat von @gabeBU:
Zudem muss ich wie es scheint immer in der Default Domain Policy die Kennwortrichtlinie deaktivieren

ähm, das hatte ich vorausgesetzt!

oder ich muss mich da noch weiter einlesen.

yip, Lesen ist immer gut:

    - Kennwortrichtlinien
    - Kontosperrungsrichtlinien
    - Kerberosrichtlinien 
Diese 3 Einstellungen sind nur auf Domänen Ebene möglich und sind zwingend bindend für alle Objekte, die im Active Directory verwaltet werden. Man kann keine unterschiedlichen Werten für verschiedene Benutzergruppen oder ähnliches definieren.

Jede an anderen Stelle konfigurierte Kennwortrichtlinie hat nur Auswirkungen auf die LOKALEN Benutzerkonten der betreffenden "Computer" in der OU, auf der diese Richtlinie wirkt.

Wenn mehere Richtlinien gefordert sind macht man das mit mehreren PSOs (Password Settings Objects):
http://technet.microsoft.com/de-de/library/cc754461%28v=ws.10%29.aspx

Hmm...ja, habe ich auch beim rumlesen herausgefunden...

nein, natürlich habe ich jetzt beim Testen die Kennwortrichltinie deaktiviert, nur habe ich gehofft, ich könnte es trotzdem noch in der OU definieren...das ist aber ärgerlich...

Naja, danke für die Tipps und dann kann ich so auch weiter arbeiten :3.

Zitat von @colinardo:

> Zitat von @gabeBU:
> Zudem muss ich wie es scheint immer in der Default Domain Policy die Kennwortrichtlinie deaktivieren
ähm, das hatte ich vorausgesetzt!

Räusper, bin ich auch von ausgegangen. Den User neu anlegen hättest Du Dir sparen können :O)

> oder ich muss mich da noch weiter einlesen.

ja sicher

aber wie immer: Hauptsache läuft, und zwar nicht das Bein runter :O)
Gruss
RS

gelöst Frage Microsoft Windows Server

Mehr von gabeBU

NGINX Loadbalancer leitet Anfrage nicht an VMWare Connection Server weitergabeBU - 4 Kommentare

Kein Zugriff auf SMB-Share über Windows 10 GerätgabeBU - 11 Kommentare

Update von Windows 7 Enterprise zu Windows 10 nicht möglichgabeBU - 25 Kommentare

Azure AD unattended Access: Contacts bearbeiten?gabeBU - 5 Kommentare

Heiß diskutiert