[Win2000] - Passwordprobleem bij aanmaken AD account

[Verwijderd]

Hoi,

Als ik in Active Directory van een Windows2000 server van een klant een account wil aanmaken (of het password van een bestaand account wil wijzigen) krijg ik de volgende foutmelding in de Security event log.

Failure Audit - Account Management eventid 628

Event Type: Failure Audit
Event Source: Security
Event Category: Account Management
Event ID: 628
Date: 13-1-2003
Time: 14:57:08
User: xxxxxx\administrator
Computer: BWD-05
Description:
User Account password set:
Target Account Name: ditiseentest
Target Domain: xxxxxx
Target Account ID: %{S-1-5-21-3968629548-2024130574-2585201755-4118}
Caller User Name: Administrator
Caller Domain: xxxxxx
Caller Logon ID: (0x0,0x1111F4E0)

Voor deze melding komen er allemaal Success Audits in de eventlog, het aanmaken van het account enzo in AD gaat goed, alleen bij het password invoeren (of wijzigen) gaat het mis.

Ik heb zojuist nog gechecked, er staat geen Local policies of Domain policies in die bepaalde eisen aan het wachtwoord stellen (zoals minimum lengte ofzo).

Ik kan deze melding ook niet terugvinden in de Microsoft KB of Google nieuwsgroepen.

Wie weet hoe ik dit oplos? Mijn dank is groot!

PS. heb de domeinnaam hierboven ff verborgen met xxxxxx

[ Voor 3% gewijzigd door Verwijderd op 13-01-2003 15:04 ]

[Qui-Gon Jinn]

mischien maak ik nu wel een hele domme opmerking maar moet het password nog aan bepaalde criteria voldoen? Ik bedoel dus... moet het minimaal 6 karakters etc...etc...????

En zoniet dan heb ik geen flauw idee.. ik werk best veel met user accounts en dergelijke maar deze ben ik nog nooit tegen gekomen.

[sh4d0wman]

password must meet complexity requirements, is uit neem ik aan? (zowel in de domain als domain controller policy) volgens mij krijg je dan ook een andere melding.

hoe ben je aangemeld? op de server zelf? met standaard admin account? of anders?

[Reptile209]

Je moet denk ik verder gaan zoeken op event ID 627: een user verandert zijn password. 628 verschijnt als de admin het doet. Wat gebeurt er na dit event trouwens? Kan de user met het nieuwe password inloggen? Krijgt de admin nog een foutmelding?

[Verwijderd]

sh4d0wman schreef op 13 January 2003 @ 15:30:
password must meet complexity requirements, is uit neem ik aan? (zowel in de domain als domain controller policy) volgens mij krijg je dan ook een andere melding.

hoe ben je aangemeld? op de server zelf? met standaard admin account? of anders?

Yep, die staat uit, Local Policy, Domain Security Policy en Domain Controller Policy.

Ik ben aangemeld met het Administrator account en probeer daarmee rechtstreeks in Active Directory een password te wijzigen, desondanks krijg ik deze melding:

Reptile209 schreef op 13 januari 2003 @ 15:48:
Je moet denk ik verder gaan zoeken op event ID 627: een user verandert zijn password. 628 verschijnt als de admin het doet. Wat gebeurt er na dit event trouwens? Kan de user met het nieuwe password inloggen? Krijgt de admin nog een foutmelding?

De foutmelding hierboven krijg ik als Administrator dus als ik een password van een bestaande user wil wijzigen in Active Directory, ook het aanmaken van een nieuw account lukt niet omdat hij het password niet wil 'setten'.

Weet iemand nog wat? Mijn dank is wederom groot!

[Verwijderd]

er bestaat ook nog een ou policy check die ook ff...

[sh4d0wman]

toch lijkt het er op dat 1 of andere password policy actief is. nog een paar vraagjes dan:

- heb je dit probleem sinds de allereerste install van de server?
- is er nog replicatie of trust met deze AD en andere servers/domeinen?

[Verwijderd]

Verwijderd schreef op 14 januari 2003 @ 11:01:
er bestaat ook nog een ou policy check die ook ff...

Wat bedoel je precies?

sh4d0wman schreef op 14 januari 2003 @ 11:01:
toch lijkt het er op dat 1 of andere password policy actief is. nog een paar vraagjes dan:

- heb je dit probleem sinds de allereerste install van de server?
- is er nog replicatie of trust met deze AD en andere servers/domeinen?

Het probleem bestond eerst niet, het was eerst goed.

Er is geen trust maar wel replicatie met andere AD servers in 1 domein, ik heb dit probleem op 2 verschilllende domaincontrollers, beide exact hetzelfde probleem.

Het lijkt inderdaad dat er nog ergens (somehow) een domain policy actief is, maar waar dan?

Wederom hartelijk dank!

[Verwijderd]

in de user manager kunnen ou's gemaakt zijn... (lijkt op een "normale" folder met een tekentje erop) hierop kunnen ook policies gedefinieerd zijn... (en deze zijn overrulend volgens local site domain ou volgorde)

edit:
let op machine policy gelden alleen als de machine in die ou hangt...
user policies alleen als de user in die ou hangt...

[ Voor 28% gewijzigd door Verwijderd op 14-01-2003 12:27 ]

[sh4d0wman]

Verwijderd schreef op 14 January 2003 @ 12:26:
in de user manager kunnen ou's gemaakt zijn... (lijkt op een "normale" folder met een tekentje erop)

ter aanvulling: is een gewone gele map met het AD icoontje er in (dat wat op een boekje lijkt)
zou idd nog wel een mogelijkheid kunnen zijn!!

ik ben overigens even in een testomgeving aan het kijken op welke manieren ik jou fout kan reproduceren

[Verwijderd]

Verwijderd schreef op 14 januari 2003 @ 12:26:
in de user manager kunnen ou's gemaakt zijn... (lijkt op een "normale" folder met een tekentje erop) hierop kunnen ook policies gedefinieerd zijn... (en deze zijn overrulend volgens local site domain ou volgorde)

edit:
let op machine policy gelden alleen als de machine in die ou hangt...
user policies alleen als de user in die ou hangt...

Ja, ik snap wat je bedoeld maar dat is hier niet het geval, er is geen aparte organizational unit en ook geen aparte policy. Er zijn wel Group Policies maar die heb ik net gechecked, stond niks bij over Password's of password must meet complexity requirements.

Alvast wederom bedankt voor alle moeite.

[Verwijderd]

zat er in .net (xp met .net adminpak?) niet een policy checker?
daarmee kan je zien wat de policy wordt nadat alles verschillende stukjes (local site domain ou) gedraaid zijn. dan kan je iig het totaal resultaat van je policies zien... waar het dan staat is weer iets anders

edit: nog een oplossing maak een ou (verplaats de gebruikers daarheen hehe)... zet de paswoordpolicy zoals je denkt dat tie moet zijn (verder niets).

[ Voor 23% gewijzigd door Verwijderd op 14-01-2003 13:31 ]

[Verwijderd]

Verwijderd schreef op 14 januari 2003 @ 13:28:
zat er in .net (xp met .net adminpak?) niet een policy checker?
daarmee kan je zien wat de policy wordt nadat alles verschillende stukjes (local site domain ou) gedraaid zijn. dan kan je iig het totaal resultaat van je policies zien... waar het dan staat is weer iets anders

edit: nog een oplossing maak een ou (verplaats de gebruikers daarheen hehe)... zet de paswoordpolicy zoals je denkt dat tie moet zijn (verder niets).

Policy checker zou handig zijn ja, het is nu erg ondoorzichtig allemaal. Heb jij dat ding toevallig niet?

Je andere tip was een goeie, een aparte OU aanmaken, heb ik gedaan, 1 user daarheen verplaatst en toen password willen wijzigen maar helaas, zelfde foutmelding als screenshot hierboven.

Voor de zoveelste keer, mijn dank is groot.

[Verwijderd]

Ik vond nog wat foutmeldingen in mijn security event log:

Event Type: Failure Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 565
Date: 14-1-2003
Time: 10:10:02
User: xxxxxx\BWD-05$
Computer: BWD-07
Description:
Object Open:
Object Server: DS
Object Type: container
Object Name: %{43ead4ea-bad4-47bd-8674-ea8d074846ca}
New Handle ID: -
Operation ID: {0,81373485}
Process ID: 280
Primary User Name: BWD-07$
Primary Domain: xxxxxx
Primary Logon ID: (0x0,0x3E7)
Client User Name: BWD-05$
Client Domain: xxxxxx
Client Logon ID: (0x0,0x4D8FAC5)
Accesses List Contents

Privileges -

Properties:

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 677
Date: 14-1-2003
Time: 11:12:05
User: NT AUTHORITY\SYSTEM
Computer: BWD-07
Description:
Service Ticket Request Failed:
User Name: Administrator
User Domain: xxxxxx
Service Name: krbtgt/xxxxxx
Ticket Options: 0x2
Failure Code: 0x20
Client Address: 200.1.4.6

Ik heb de domeinnaam even vervangen door xxxxxx overal.

Als ik die dingen eens opzoek (http://www.eventid.net/display.asp?eventid=676&source=) lijkt het een Kerberos probleem te zijn, zou goed kunnen natuurlijk. Maar hoe fix ik dit? Van Kerberos heb ik erg weinig kennis eerlijk gezegd.

[ Voor 10% gewijzigd door Verwijderd op 14-01-2003 14:44 ]

[sh4d0wman]

ik heb (helaas) nog niet veel verstand van Kerberos. probeer anders even een MCSE boek ergens vandaan te trekken. heb ze thuis staan en daar staat het zeker in.

Ik zie wel: ticket request failed staan. zou proberen uit te zoeken of waarom dit geweigerd word, client onbekend? gebruiker geweigerd? encryptie vereist? dat soort dingen.

heb je deze servers trouwens zelf opgezet? of is er ook nog een collega die hier misschien meer vanaf weet?

ik zal iig dit topic in de gaten houden maar weet zo even geen oplossing helaas

[Verwijderd]

sh4d0wman schreef op 14 January 2003 @ 15:01:
ik heb (helaas) nog niet veel verstand van Kerberos. probeer anders even een MCSE boek ergens vandaan te trekken. heb ze thuis staan en daar staat het zeker in.

Ik zal eens kijken, dat moet te regelen zijn.

Ik zie wel: ticket request failed staan. zou proberen uit te zoeken of waarom dit geweigerd word, client onbekend? gebruiker geweigerd? encryptie vereist? dat soort dingen.

Idd, zoiets lijkt het mij ook, ik denk dat er somehow iets misgaat met de encryptie.

heb je deze servers trouwens zelf opgezet? of is er ook nog een collega die hier misschien meer vanaf weet?

Ik heb zelf alles opgezet...

ik zal iig dit topic in de gaten houden maar weet zo even geen oplossing helaas

Iig hartelijk dank tot zover.

[sh4d0wman]

ook al eens de Kerberos policies nagelopen? just to be sure

Edit: staan er toevallig ook IP Security Policies aan? dan zal er waarschijnlijk 1 tussen zitten die Kerberos vereist. De client gebruikt dit waarschijnlijk automatisch niet.

(klein stukje uit MS 70-216 boek: Secure Server policy requires Kerberos trust for all IP packets sent, this policy does not allow unsecured communication with clients. Therefore any client who connect to a server with this policy must be IPSec aware)

[ Voor 78% gewijzigd door sh4d0wman op 14-01-2003 15:39 ]

[blackd]

-> PNS op verzoek

[Verwijderd]

Paswoord policies kunnen enkel op domain-level gezet worden, dus op OU level moet je het volgens mij niet gaan zoeken.

Wat met Kerberos nogal eens durft mis gaan is de tijd syncronisatie! Staan je klokken op je DC's en evt. client gelijk met elkaar? Als daar meer dan 5 min. tussenzit krijg je rare toestanden. Een gokje maar misschien het bekijken waard?

[Rudie_V]

Heb je ook al eens geprobeert(puur voor de test) om eens een gebruiker in bijv. de groep AD\Users aan te maken en kijken of je hiervan het wachtwoord kan resetten? Hierin heb je alleen de default domain policy over je heen en verder geen andere policies.

[Verwijderd]

Rudie_V schreef op 15 January 2003 @ 08:30:
Heb je ook al eens geprobeert(puur voor de test) om eens een gebruiker in bijv. de groep AD\Users aan te maken en kijken of je hiervan het wachtwoord kan resetten? Hierin heb je alleen de default domain policy over je heen en verder geen andere policies.

Ja, heb ik geprobeerd maar dit werkte helaas ook niet. Ik heb ook een nieuwe OU aangemaakt met daarin een nieuwe gebruiker maar ook hier gelijk die password foutmelding.

Tijd synch zal ik nog eens naar kijken maar op de 2 DC's waar ik het op heb getest stonden de tijden volgens mij gewoon gelijk.

Thanks iig.

Meer tips/suggesties zijn welkom!

[pbd]

Verwijderd schreef op 14 January 2003 @ 20:35:
Paswoord policies kunnen enkel op domain-level gezet worden, dus op OU level moet je het volgens mij niet gaan zoeken.

Dit klopt helemaal...alle experimenten met users in andere OU's kan je mee stoppen....account/password policy kun je alleen instellen op domein niveau...oftewel in de Default Domain Policy......die zou ik even goed doorspitten....

[Rudie_V]

Je typt dat je bezig ben voor een klant, zit je ook daadwerklijk achter een pc/server van die klant of doe je dit van afstand vanaf een ander domein?
Misschien eens in een test ou testen met block inheritance en geen policies op deze ou zetten, mits je dit nog niet gedaan heb?

[Verwijderd]

Rudie_V schreef op 15 januari 2003 @ 11:44:
Je typt dat je bezig ben voor een klant, zit je ook daadwerklijk achter een pc/server van die klant of doe je dit van afstand vanaf een ander domein?
Misschien eens in een test ou testen met block inheritance en geen policies op deze ou zetten, mits je dit nog niet gedaan heb?

Ik zit momenteel bij die klant maar zowel vanaf afstand (via terminal services) als daadwerkelijk op het netwerk zelf heb ik het probleem.

Ik ga vanmiddag weer even wat dingen nalopen en testen, wederom bedankt voor alle input, jullie horen van me.

[Verwijderd]

Rudie_V schreef op 15 January 2003 @ 11:44:
Je typt dat je bezig ben voor een klant, zit je ook daadwerklijk achter een pc/server van die klant of doe je dit van afstand vanaf een ander domein?
Misschien eens in een test ou testen met block inheritance en geen policies op deze ou zetten, mits je dit nog niet gedaan heb?

als je policies wil blokken zal je ze wel moeten definieren (anders worden de localpolicies toch gebruikt!!!)... en idd pw policies alleen op domain niveau...

maar als je nu eens zoiets gebruikt: N1euwP@sw00rd! (14 chars max toch?)

[ Voor 5% gewijzigd door Verwijderd op 15-01-2003 17:29 ]

[musiman]

Verwijderd schreef op 15 januari 2003 @ 17:27:
[...]


als je policies wil blokken zal je ze wel moeten definieren (anders worden de localpolicies toch gebruikt!!!)... en idd pw policies alleen op domain niveau...

maar als je nu eens zoiets gebruikt: N1euwP@sw00rd! (14 chars max toch?)

Geen 14, maar 128 karakters max. Maar er is een policy waarin je kunt zeggen dat er minimaal 14 karakters gebruikt moeten worden.
Dus op zich wel een goede zet om bovenstaand wachtwoord even te proberen (want deze voldoet ook aan de complexity requirements)

[Verwijderd]

musiman2 schreef op 16 January 2003 @ 23:21:
[...]


Geen 14, maar 128 karakters max. Maar er is een policy waarin je kunt zeggen dat er minimaal 14 karakters gebruikt moeten worden.
Dus op zich wel een goede zet om bovenstaand wachtwoord even te proberen (want deze voldoet ook aan de complexity requirements)

Jaa, tof. Deze doet het wel, als ik dit password van 14 tekens gebruik!

Er moet dus nog ergens een policy zijn die ervoor zorgt dat kortere passwords (en die uit puur letters bestaan, dus waarschijnlijk niet aan de complexity requirements voldoen) niet geaccepterd worden. Snap ik alleen niet want ik dacht echt dat ik alle policies (Domain Policy, Domain Controller Policy en Group Policy) had gechecked.

Wordt dus ff zoeken... tenzij iemand zo kan zeggen waar deze policy dan wel zit.

IIG bedankt voor de goeie tip! (had ik zelf kunnen bedenken ) We komen er wel.

[Verwijderd]

IIG bedankt voor de goeie tip! (had ik zelf kunnen bedenken ) We komen er wel.

[Verwijderd]

14 max ??? nee hoor volgens mij mag een password max 127 tekens zijn

[luckyme_]

Het _moet_ in een policy op domain niveau staan, dat is de enige plaats waar je zaken mbt password kunt regelen.

[Verwijderd]

Verwijderd schreef op 20 januari 2003 @ 03:13:
14 max ??? nee hoor volgens mij mag een password max 127 tekens zijn

14max is volgens mij voor NT 4 vandaar het vraagteken

[Verwijderd]

luckyme_ schreef op 20 januari 2003 @ 11:39:
Het _moet_ in een policy op domain niveau staan, dat is de enige plaats waar je zaken mbt password kunt regelen.

Klopt het dat daar 3 plaatsen voor kunnen zijn waar zo'n policy staat? Domain Security policy, Domain controller security policy en evt. Group policies? Of zijn er nog meer plaatsen?

[luckyme_]

Ik vrees dat je een aantal dingen door elkaar zit te halen. Het moet staan een van de policies die op je domain staan. In AD users en computers rechtsklikken op je domeinnaam. Daar staat minimaal de default domain policy en eventueel een toegevoegde custom policy.

[Zwelgje]

luckyme_ schreef op 20 januari 2003 @ 21:00:
Ik vrees dat je een aantal dingen door elkaar zit te halen. Het moet staan een van de policies die op je domain staan. In AD users en computers rechtsklikken op je domeinnaam. Daar staat minimaal de default domain policy en eventueel een toegevoegde custom policy.

niet dus, daar stel je dat niet in

start>uitvoeren>administrative tools>domain controller security policy & domain security policy, daar stel je zaken in mbt password requirements en complexity

[luckyme_]

Ik heb geen zin in een welles-nietes spelletje....
start | administartive tools | active directory users and comouters |
domein naam rechts klikken, group policy, daar staan de policies op domein niveau, password eisen worden op domein niveau gezet. (op jouw manier kom je _ook_ bij de domein policies, maar loop niet meteen te roepen dat iets niet zo is)

[Zwelgje]

luckyme_ schreef op 21 januari 2003 @ 10:14:
Ik heb geen zin in een welles-nietes spelletje....
start | administartive tools | active directory users and comouters |
domein naam rechts klikken, group policy, daar staan de policies op domein niveau, password eisen worden op domein niveau gezet. (op jouw manier kom je _ook_ bij de domein policies, maar loop niet meteen te roepen dat iets niet zo is)

nou nou, sorry hoor, kwist niet dat je kwaad werd

jouw manier is wel een beetje veel klikwerk ik doet het altijd op mijn manier.. naja ik geef toe mijn reactie was wat 'kortzichtig' (excuus daarvoor)

[luckyme_]

was niet kwaad hoor (wel gehaast, zie de typo's). Als je AD users en comps gebruikt kan je in een keer alle policies, (domain en ou, alleen niet site) zien. Trouwens, een beetje beheerder stelt toch een eigen mmc samen hiervoor.