UITDAGING-SSO+Cannot change password *

[Verwijderd]

Oke hier zijn een paar leuke problemen die ik heb met twee w2k Forests in trust. Dus non-transitive trust of ook wel NT4 trusts genoemd.

Wij gebruiken SSO (Single Sign On) certificaten om aan te loggen. Ik heb een trust relatie tussen DomainA en DomainB. Nieuwe users in DomainB die een SSO certificaat hebben kunnen niet aanloggen op een pc in DomainA. De Kerberos melding is dat de CRL niet gevonden kan worden. De eventid zegt echter iets anders. KerberosID 0x6 Principal_Unknown. Nu zie ik wel dat hij probeerd het account te verieferen in DomainA, terwijl het SSO is aangemaakt voor het account in DomainB.

Server Realm: DomainA.NL
Server Name: krbtg/DomainA.NL
Taget Name: Host/[e-mail]

Zoals je ziet komt DomainB hier helemaal niet in voor, terwijl hij daar wel geverifieerd moet worden! Ik heb ksetup.exe gebruikt in DomainA om kerberos.domainB.nl toe te voegen. Dit werkt niet. Kerberos blijft problemen hebben met de trust relatie. Of moet ik in de richting van de CA zoeken? Het domain certificaat is op het werkstation geinstalleerd.

In domainB heb ik nieuwe users aangemaakt. Hier moet het wachtwoord direct bij aanmelding gewijzigd worden. Een gebruiker die achter een werkstation zit in DomainA en inlogt met zijn nieuw account van DomainB, krijgt de melding om zijn wachtwoord te wijzigen. Zodra hij dit doet, krijgt hij de melding dat hij niet genoeg rechten heeft om dit te wijzigen.
Er bestaat een artikel dat de Everyone groep - change password rechten moet hebben op het user object, maar dit werkt helaas niet.
Echter voer ik de aktie nu andersom uit (dus vanuit DomainB een wachtwoord wijzigen van een account in DomainA) dan werkt het wel. Het is dus zoeken naar een speld in een hooiberg.
Als ik het werkstation omzet van DomainA naar DomainB en de user logt in met zijn DomainB account, dan kan hij het wachtwoord wijzigen.

De vraag is dus,... hoe werkt exact de procedure van het wijzigen van het wachtwoord na CTRL+ALT+DEL? Welk verificatie account gebruikt hij hiervoor? Ik zit te denken aan het werkstation en dus het system account.

Kent iemand trouwens ook deze meldingen?
EventID 676 Failure code 0x17

[ Voor 5% gewijzigd door Verwijderd op 02-10-2003 14:57 ]

[mutsje]

Ik zou zeggen ga bij de basis beginnen.

Is je non-transitive trust nog wel in orde? Wat voor trust heb je single dat domain A domain B vertrouwd of visa versa of een Full Trust? Dit speelt ook al mee. Verwijder de trust een en maak hem opnieuw aan.(je kunt namelijk het password van een trust niet resetten)

Is er sprake van groot tijdverschil tussen de domains(denk aan geldigheid kerberos ticket default 10 uur)

nog een vraag van marcus: Hoeveel domains heb je in beide forrest liggen en zijn deze allemaal middels een trust met elkaar verbonden(dit moet namelijk)


technet zegt over 676

Event ID: 676 (0x02a4)
Type: Failure Audit
Description: Authentication Ticket Request Failed
User Name: %1 Supplied Realm Name: %2
Service Name: %3 Ticket Options: %4
Failure Code: %5 Client Address: %6

Dus hij krijgt geen ticket.

[pondering]
kan nooit groot probleem zijn want TS reageert niet echt[/pondering]

[ Voor 60% gewijzigd door mutsje op 02-10-2003 19:02 ]

[Verwijderd]

Je zou het zeggen, maar niks helpt. Er is letterlijk geen touw aan vast te knopen. De tijd staat natuurlijk goed. Het is mij bekend van dit probleem. Ik heb afgelopen week uitvoerig getest en hier is naar boven gekomen dat het bij de ene client wel werkt (veranderen van wachtwoord), maar bij de andere niet. Er zijn geen verschillen in de client. Ook heb ik gemerkt dat wanneer ik de Domain Controller Policy disable, dat het op sommige clients werkt. Maar andere weer niet. Het is echt heel vreemd, want elke User rights optie heb ik geprobeerd. Ik ben nu zo ver dat ik alle policies heb gedisabled, maar dit helpt nog niet. Is het een rechten probleem? Geen idee. Het enige wat ik mij kan bedenken is idd de trust en voorlopig werkt 1 client! yeah!

[mutsje]

Je kunt de trust met dommon.exe uit de nt4 resource monitoren of er wel een trusted domain is.

ALs je dommon opstart moet je eerst je eigen domain toe voegen daarna vink je bij options Monitor trusted domains aan. Dan domain > properties > krijg je Domain Controller status op domain "naam domain" Alleen zie je hier ook een venster met Links status "servername" to it's trusted domain.

[Verwijderd]

Oke het bleef bij 1 pc, want na een herstart werkte het niet meer. EN IK HEB GEEN VERANDERING aangebracht. Ik heb een two-way non-transitive trust. Dus twee forests zonder sub domain die elkaar vertrouwen. Geen poespas, gewoon standaard. Sjeez.. in NT4 was dit toch een stuk simpeler zonder problemen. Het is bekend dat Microsoft te weinig aandacht heeft besteed aan de trust relatie, maar dit gaat te ver. De clients zijn identiek en geen verschil.
Trouwens wat die ticket betreft. Die melding had ik ook gevonden, maar de Failure code 0x17 is nergens te vinden.

[mutsje]

Het klopt dat 0x17 nergens te vinden is maar er zijn 2 mogelijke oorzaken. Of je kerberos is over de zeik(dus kunnen mensen wel in hun eigen domain inloggen) of de trust moet je opnieuw aanmaken(deze kan soms omvallen)

[Verwijderd]

De trust heb ik nu al 3 keer opgebouwd. Helaas. Ik heb de client meerdere keren herstart en de ene keer werkt hij, de andere keer niet. De trust is in orde, want ik kan prima door beide ADS heen browsen en rechten geven op shares. Users kunnen ook prima aanloggen (zonder het wijzigen van het wachtwoord) op het nieuwe domein. Alleen gaan wij een probleem krijgen zodra dit wachtwoord verloopt.
In de Event zie ik geen melding. Een sniffer geeft ook al geen resultaat. De trust wordt initieel opgebouwd door een IPC$ connectie te maken. Dit werkt prima en wordt geaccepteerd door het andere domain.
Ik ben trouwens niet de enige persoon met dit probleem. Ook een collega van mij heeft exact hetzelfde. Zodra de gebruiker is aangelogd op het Trusted domain, kan hij zijn wachtwoord wijzigen aan de hand van CTRL+ALT+DELETE. Dat is de enige manier.

[Verwijderd]

De reden van de trust is omdat a.s. maandag 160 man over gaan naar een nieuw netwerk (het trusted domainB). Dit doe ik geleidelijk, door eerst de gebruikers om te zetten. Daarna worden alle werkstations voorzien van nieuwe images. (ivm. vervuiling en software distributie).
Ik ga dus nu twijfelen of het wel zo verstandig is om eerst de gebruikers te doen. ;-(

[Verwijderd]

Heb je msn toevallig? Want dat gaat misschien wat makkelijker.

[e-mail]

[Verwijderd]

Ps...nog even een kleine opmerking de Everyone group heeft change password rechten in DomainB. (de clients hangen in DomainA)

[mutsje]

heb je al geprobeerd netwerk connecties naar andere shares te maken.
Hou er wel rekening mee met meerdere domain controllers dat ze allemaal een trust moeten hebben he!

[momania]

_{JackTheRipper, wil je de knop gebruiken als het laatste bericht nog van jezelf is. Wat je nu doet wordt gezien als het 'kicken' van je topic en dat mag pas na 24 uur
Zie : Algemene regels hoe je op het forum te gedragen (Netiquette)}

[Verwijderd]

momania... ja sorry... ik zal er op letten.

Mutsje...
De trust is natuurlijk een trust relationship tussen de twee GC's die de infrastructure FSMO role houden. Dus ik hoef maar op 2 GC's de connectie aan te maken. (GC in DomainA en GC in DomainB).

Ik kan prima netwerk connecties maken, want een aantal services worden al in het nieuwe domain gehost. Daar ligt het probleem ook niet. DNS werkt ook netjes, nadat ik DomainA in de DNS server van DomainB had toegevoegd en visa versa.
Resolven gaat prima. Dit is de basis voor de trust relatie.

Kerberos zou het probleem kunnen zijn. Maar een directe oplossing heb ik niet. De account verificatie wordt namelijk prima in DomainB afgevangen.

Oke stel het is het kerberos protocol. (gezien de eventlog 0x17) Wat dan?

[ Voor 74% gewijzigd door Verwijderd op 07-10-2003 11:56 ]

[mutsje]

0x17 wordt niet herkend door technet online ook niet door de laatste technet cd versie. ik denk dat je Microsoft moet gaan bellen in Nederland en het probleem voorleggen. Beter iets betalen voor een snel antwoord maar het lijkt me niet dat Microsoft snel een antwoord heeft want technet kent het ook niet 123. ook niet als "contact us to get hotfix blabla".

[Verwijderd]

Haha... ja ik weet het... Googlen geeft ook al geen resultaat. Ik heb al kerberos pre-authentication aangezet om even te kijken of dit iets opleverd, maar helaas.
Ik ga het intern even overleggen of dit een oplossing is.
We kunnen natuurlijk altijd nog over naar Xwindows met Open Office....

[Verwijderd]

Nieuwe ontwikkeling.........

Eventdump van de Client met Windows 2000 Pro NL.

EventID 1000: UserEnv
Het forest van de aangemelde gebruiker is een andere forest dan dat van de computer. De verwerking van groepsbeleid tussen forests is uitgeschakeld en in dit forest is loopbackverwerking verplicht gesteld voor deze gebruikersaccount.

Oeps... sorry Momania

[ Voor 4% gewijzigd door Verwijderd op 07-10-2003 12:12 ]

[mutsje]

hehehehe mutsje is weer goed bezig.
kerberos en 0x17
alleen nu event 676 niet

hier alle results

Ik denk toch dat je kerberos niet goed gaat nu. Heb je er firewall tussen staan?

[ Voor 16% gewijzigd door mutsje op 07-10-2003 12:15 ]

[Verwijderd]

Nope geen firewall. Ze hangen allen op dezelfde switch. Ik heb ook iets gevonden mbt. servicepack 4 (die ik op alle servers in DomainB heb geinstalleerd). Iemand kreeg dezelfde melding nadat hij SP4 had geinstalleerd. Ik denk dat ik een downgrade ga doen van SP4 naar SP3.

Mutsje... helaas geen event 676. Ik denk dat ik het moet zoeken in de EventID die ik boven heb beschreven.

[mutsje]

Zet loopback eens uit op je policies.

en daarna ff refresh van machine&user policie met /enforce uitvoeren.

[ Voor 50% gewijzigd door mutsje op 07-10-2003 12:57 ]

[Verwijderd]

Ja het probleem is dat het in de machine policy ingesteld staat. De servers van DomainA zitten nog op SP3 en hier hangen de clients. -> heb hier dus geen GPO met de loopback optie en Cross-forest instelling.
Ik heb zojuist SP4 van alle GC's in DomainB gedeinstalleerd. Ga nu ff testen wat het resultaat is. I'll let you know...Thanx....

---------------------------

Nou het werkt dus NIET. Heb een client meerdere keren herstart. De server gedowngrade naar SP3 en de clients naar SP4. Geen resultaat.
I'm lost.... Ga nu maar een andere zijstraat in en dat is de werkstations omzetten naar DomainB. Man... 160-200 clients omzetten in m'n eentje.... ff kijken of ik geen helpdeskmedewerkertje kan sturen.............

---------------------------
We zijn vandaag begonnen met het omzetten van de clients. Niet echt een mooie oplossing, maar noodzakelijk. Het is idd de trust relatie die het probleem gaf. Het ticket die Kerberos uitgeeft om over de trust relatie heen te gaan, wordt verkeerd afgegeven. Oplossing is er helaas niet, behalve dan alles in 1 keer te migreren.

[ Voor 61% gewijzigd door Verwijderd op 09-10-2003 11:15 ]