Discussion:
"Benutzer kann Kennwort nicht ändern" wird immer wieder überschrie
(zu alt für eine Antwort)
mg_it
2006-07-04 09:55:01 UTC
Permalink
Hi,

habe folgendes Problem:

Umgebung:
2 Windows Server 2003 Domänencontroller
1 Domäne
alles in einem Standort
Domänenfunktionslevel: Windows Server 2003

Wenn ich im AD bei einem Benutzer die Option "Benutzer kann Kennwort nicht
ändern" aktiviere, wird diese Einstellung ohne Probleme auf meinen anderen
Domänencontroller repliziert.

Nun wird jedoch immer 9 Minuten nach jeder vollen Stunde diese Einstellung
wieder zurückgesetzt.

In der Default Domain Policy habe ich nun schon alle Passwort-Richtlinien
auf "nicht konfiguriert" gesetzt, genauso auch in der Default Domain
Controller Policy. Weitere Richtlinien die auf die Domäne oder die
Domänencontroller wirken, sind nicht vorhanden.

Woran kann das liegen, das stündlich meine Einstellung wieder
"überschrieben" wird?

Hat jemand eine Lösung für mich?

Danke!
Norbert Fehlauer [MVP]
2006-07-04 10:03:28 UTC
Permalink
mg_it wrote:
Hi,
Post by mg_it
Nun wird jedoch immer 9 Minuten nach jeder vollen Stunde diese
Einstellung wieder zurückgesetzt.
In welchen Gruppen ist dieser User denn Mitglied?

Bye
Norbert
mg_it
2006-07-04 11:17:02 UTC
Permalink
Post by Norbert Fehlauer [MVP]
In welchen Gruppen ist dieser User denn Mitglied?
Dieser User ist Mitglied der Administratorengruppe, hab das Problem aber
auch bei allen anderen Benutzern, auch die die kein Mitglied der
Administratorengruppe sind.
Norbert Fehlauer [MVP]
2006-07-04 11:34:37 UTC
Permalink
mg_it wrote:
Hi,
Post by mg_it
Post by Norbert Fehlauer [MVP]
In welchen Gruppen ist dieser User denn Mitglied?
Dieser User ist Mitglied der Administratorengruppe,
OK.
Post by mg_it
hab das Problem
aber auch bei allen anderen Benutzern, auch die die kein Mitglied der
Administratorengruppe sind.
Also bei allen?

Bye
Norbert
mg_it
2006-07-04 11:55:03 UTC
Permalink
Post by Norbert Fehlauer [MVP]
Hi,
Post by mg_it
Post by Norbert Fehlauer [MVP]
In welchen Gruppen ist dieser User denn Mitglied?
Dieser User ist Mitglied der Administratorengruppe,
OK.
kann man diese Einstellung bei Mitgliedern der Administratorengruppe nicht
setzen?
Post by Norbert Fehlauer [MVP]
Post by mg_it
hab das Problem
aber auch bei allen anderen Benutzern, auch die die kein Mitglied der
Administratorengruppe sind.
Also bei allen?
ja, bei allen,
(entschuldige für die missverstädnliche Beschreibung meines Problems)
egal bei welchem Benutzer ich diese Einstellung setze, wird diese wieder
zurückgesetzt
unknown
2006-07-04 11:28:09 UTC
Permalink
Moin,
Post by mg_it
Woran kann das liegen, das stündlich meine Einstellung wieder
"überschrieben" wird?
führe an einem Client bei angemeldeten User ein GPRESULT
durch. Danach siehst Du welche Policys an diesem Client
auf diesem angemeldeten User wirken, danach kontrollierst
Du die Policys.
--
Regards from Mainz/Germany
Yusuf Dikmenoglu
http://www.faq-o-matic.net
mg_it
2006-07-04 11:49:01 UTC
Permalink
Post by unknown
führe an einem Client bei angemeldeten User ein GPRESULT
durch. Danach siehst Du welche Policys an diesem Client
auf diesem angemeldeten User wirken, danach kontrollierst
Du die Policys.
hatte ich schon gemacht, es wirkt nur die "Default Domain Policy"

es kann ja nur an einer Sicherheitsrichtlinie liegen, die auf einen der DC's
wirkt, da die Benutzereinstellung auch zurückgesetzt wird, wenn sich der
Benutzer gar nicht angemeldet hat

daher kommt nur die "Default Domain Policy" und die "Default Domain
Controllers Policy" in Frage, doch in beiden Richtlinien habe ich sämtliche
Richtlinien, die das Benutzerpasswort betreffen mal auf "nicht konfiguriert
gesetzt"

habt ihr vielleicht noch eine Idee welche Richtlinieneinstellung die
Einstellung "Benutzer kann Kennwort nicht ändern" wieder überschreiben könnte?
unknown
2006-07-04 12:08:21 UTC
Permalink
Post by mg_it
hatte ich schon gemacht, es wirkt nur die "Default Domain Policy"
Dann führe doch mal ein dcgpofix aus.
https://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/48872034-1907-4149-b6aa-9788d38209d2.mspx?mfr=true
Danach sind die GPOs so eingestellt,
wie bei einer Erstinstallation (Werkseinstellung).
--
Regards from Mainz/Germany
Yusuf Dikmenoglu
http://www.faq-o-matic.net
Norbert Fehlauer [MVP]
2006-07-04 12:51:42 UTC
Permalink
Yusuf Dikmenoglu wrote:
Hi,
Post by unknown
Dann führe doch mal ein dcgpofix aus.
Falls Exchange 200x im Einsatz ist, danach dann nochmal /domainprep. Sonst
hält der Exchangeserver an. ;)

Bye
Norbert
mg_it
2006-07-04 13:40:02 UTC
Permalink
hab jetzt mal 2 testuser angelegt, wobei Testuser1 nur Mitglied in der Gruppe
DomainUser ist und Testuser2 zusätzlich in die Gruppe der Administratoren
aufgenommen wurde

bei Testuser2 war nach kurzer Zeit die Einstellung wieder weg
bei Testuser1 blieb die Einstellung bestehen

aber wieso bleibt die Einstellung "Benutzer kann Passwort nicht ändern"
nicht bei den anderen Benutzern auch bestehen, die sich nicht in der
Administartorengruppe befinden? (Die anderen Benutzer sind Mitglieder anderer
Sicherheitsgruppen die ich selbst erstellt habe.)

muss ich bei den Gruppenmitgliedschaften auf irgendetwas besonders aufpassen?
ob es sich um eine lokale, globale oder universelle Sicherheitsgruppe oder
Verteilergruppe handelt sollte doch für diese Einstellung irrelevant sein,
oder liege ich da falsch??

Kann es vielleicht auch daran liegen, dass die Benutzerkonten von einer
NT4-Domäne migriert wurden???
Norbert Fehlauer [MVP]
2006-07-04 21:49:20 UTC
Permalink
mg_it wrote:
Hi (kompletter Name wäre übrigens nett ;)),
Post by mg_it
hab jetzt mal 2 testuser angelegt, wobei Testuser1 nur Mitglied in
der Gruppe DomainUser ist und Testuser2 zusätzlich in die Gruppe der
Administratoren aufgenommen wurde
bei Testuser2 war nach kurzer Zeit die Einstellung wieder weg
bei Testuser1 blieb die Einstellung bestehen
OK.
Post by mg_it
aber wieso bleibt die Einstellung "Benutzer kann Passwort nicht
ändern" nicht bei den anderen Benutzern auch bestehen, die sich nicht
in der Administartorengruppe befinden? (Die anderen Benutzer sind
Mitglieder anderer Sicherheitsgruppen die ich selbst erstellt habe.)
Sind die Gruppen eventuell geschachtelt in andere Gruppen?
Post by mg_it
Kann es vielleicht auch daran liegen, dass die Benutzerkonten von
einer NT4-Domäne migriert wurden???
Nö eigentlich nicht. Btw deine ?-Taste klemmt.

Bye
Norbert
--
Dilbert's words of wisdom #10: I don't have an attitude problem. You
have a perception problem.
mg_it
2006-07-05 07:16:01 UTC
Permalink
Post by Norbert Fehlauer [MVP]
Post by mg_it
aber wieso bleibt die Einstellung "Benutzer kann Passwort nicht
ändern" nicht bei den anderen Benutzern auch bestehen, die sich nicht
in der Administartorengruppe befinden? (Die anderen Benutzer sind
Mitglieder anderer Sicherheitsgruppen die ich selbst erstellt habe.)
Sind die Gruppen eventuell geschachtelt in andere Gruppen?
Nein
Post by Norbert Fehlauer [MVP]
Post by mg_it
Kann es vielleicht auch daran liegen, dass die Benutzerkonten von
einer NT4-Domäne migriert wurden?
habe nochmal 3 Testuser und eine Testgruppe mit folgenden
Gruppenzugehörigkeiten erstellt:

Gruppenmitgliedschaft von Test1:
DomainUsers
Administratoren
globale Sicherheitsgruppe (von NT4 migriert)

Gruppenmitgliedschaft von Test2:
DomainUsers
globale Sicherheitsgruppe = Testgruppe (unter Windows Server 2003 neu
erstellt)

Gruppenmitgliedschaft von Test3:
DomainUsers
globale Sicherheitsgruppe (von NT4 migriert)
globale Sicherheitsgruppe (unter Windows Server 2003 neu erstellt)

bei den Benutzern "Test1" und "Test3" wurde die Einstellung "Benutzer kann
Kennwort nicht ändern" wieder zurückgesetzt

bei Test2 wurde die Einstellung beibehalten

liegt also anscheinend an den Sicherheitsgruppen, die noch in der NT4-Domäne
erstellt wurden
ist dieses Problem bekannt?
gibt es eine andere Möglichkeit, als alle Sicherheitsgruppen neu anzulegen?

wäre ja ein enormer aufwand, sämtliche Gruppenmitgliedschaften und
Berechtigungen neu anzulegen
Wolfgang Sauer
2006-07-05 19:04:34 UTC
Permalink
Hi Mr. mg_it
Post by mg_it
Post by Norbert Fehlauer [MVP]
Post by mg_it
aber wieso bleibt die Einstellung "Benutzer kann Passwort nicht
ändern" nicht bei den anderen Benutzern auch bestehen, die sich nicht
in der Administartorengruppe befinden? (Die anderen Benutzer sind
Mitglieder anderer Sicherheitsgruppen die ich selbst erstellt habe.)
Sind die Gruppen eventuell geschachtelt in andere Gruppen?
Nein
Post by Norbert Fehlauer [MVP]
Post by mg_it
Kann es vielleicht auch daran liegen, dass die Benutzerkonten von
einer NT4-Domäne migriert wurden?
habe nochmal 3 Testuser und eine Testgruppe mit folgenden
DomainUsers
Administratoren
globale Sicherheitsgruppe (von NT4 migriert)
DomainUsers
globale Sicherheitsgruppe = Testgruppe (unter Windows Server 2003 neu
erstellt)
DomainUsers
globale Sicherheitsgruppe (von NT4 migriert)
globale Sicherheitsgruppe (unter Windows Server 2003 neu erstellt)
bei den Benutzern "Test1" und "Test3" wurde die Einstellung "Benutzer kann
Kennwort nicht ändern" wieder zurückgesetzt
bei Test2 wurde die Einstellung beibehalten
liegt also anscheinend an den Sicherheitsgruppen, die noch in der NT4-Domäne
erstellt wurden
ist dieses Problem bekannt?
gibt es eine andere Möglichkeit, als alle Sicherheitsgruppen neu anzulegen?
wäre ja ein enormer aufwand, sämtliche Gruppenmitgliedschaften und
Berechtigungen neu anzulegen
das schreit förmlich nach dem AdminSDholder der alle Stunde aktiv wird. Nur,
dass der auch "user cannot change password" zurücksetzt war mir neu. Habe
das gerade nachgestellt, es ist tatsächlich so, durch die Mitgliedschaft in
einer der durch den AdminSDHolder geschützten Gruppen wird nicht nur die ACL
sondern auch das Attribut zurückgesetzt. Ist wohl ein Feature :-)
Ich hab dazu bei mir im Regkey der DC den Wert
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Internal Processing
auf 3 gesetzt. Dann erscheint im Eventlog unter Directory Services, nach ca.
einer Stunde, die EventID 1257/1258 die anzeigt, dass der AdminSDHolder
zugeschlagen hat.
Ich bin also davon überzeugt, dass der Benutzer über Gruppenschachtelung in
einer der schützenswerten Gruppen ist. Womöglich auch über die SID-History.
Du solltest also mal alle Gruppen "Server Operators, Administrators, Domain
Admins, Printer Ops, ..." abklappern und schauen ob da Gruppen drin sind
denen die Benutzer auch angehören.

Grüsse
Wolfgang
mg_it
2006-07-06 07:31:02 UTC
Permalink
Post by Wolfgang Sauer
das schreit förmlich nach dem AdminSDholder der alle Stunde aktiv wird. Nur,
dass der auch "user cannot change password" zurücksetzt war mir neu. Habe
das gerade nachgestellt, es ist tatsächlich so, durch die Mitgliedschaft in
einer der durch den AdminSDHolder geschützten Gruppen wird nicht nur die ACL
sondern auch das Attribut zurückgesetzt. Ist wohl ein Feature :-)
Ich hab dazu bei mir im Regkey der DC den Wert
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Internal Processing
auf 3 gesetzt. Dann erscheint im Eventlog unter Directory Services, nach ca.
einer Stunde, die EventID 1257/1258 die anzeigt, dass der AdminSDHolder
zugeschlagen hat.
Ich bin also davon überzeugt, dass der Benutzer über Gruppenschachtelung in
einer der schützenswerten Gruppen ist. Womöglich auch über die SID-History.
Du solltest also mal alle Gruppen "Server Operators, Administrators, Domain
Admins, Printer Ops, ..." abklappern und schauen ob da Gruppen drin sind
denen die Benutzer auch angehören.
Genau das wars!

Alle Benutzer waren Mitglied der Druckoperatoren.

Vielen Dank!
Norbert Fehlauer [MVP]
2006-07-06 07:51:40 UTC
Permalink
mg_it wrote:
Hi,
Post by mg_it
Alle Benutzer waren Mitglied der Druckoperatoren.
Ich frag mich, warum ich überhaupt frage, in welchen Gruppen die User
Mitglied sind. ;)
Dann wär das Problem schon deutlich früher gelöst.

Bye
Norbert
Wolfgang Sauer
2006-07-06 19:26:15 UTC
Permalink
Hi Norbert + mg_it
Post by Norbert Fehlauer [MVP]
Hi,
Post by mg_it
Alle Benutzer waren Mitglied der Druckoperatoren.
Ich frag mich, warum ich überhaupt frage, in welchen Gruppen die User
Mitglied sind. ;)
Dann wär das Problem schon deutlich früher gelöst.
jupp, das frag ich mich auch, vielleicht war ja nur noch ein bisschen
Überzeugungsarbeit notwendig :-) Aber immerhin wissen wir/ich jetzt, dass
der AdminSDHolder auch "user cannot change password" zurücksetzt.

Ciao
Wolfgang

Loading...