[W2K AD] Opnieuw inloggen na groepswijziging

[Verwijderd]

Een tijd geleden hebben we 2 domains aan elkaar gekoppeld d.m.v Trusting. Mogelijk hebben we daar een aantal instellingen veranderd ofzo, maar nu zit ik met het volgende irritante probleem.
Als ik een gebruiker aan een AD groep toevoeg moet deze user opnieuw inloggen voordat hij herkent wordt in deze groep en rechten krijgen op bepaalde folders.
Voorheen was dit realtime en dat werkt wel prettig. Toen kon ik een user aan een groep toevoegen en deze had direct rechten.
Nu dus niet meer. Ik zou niet weten waar ik moet beginnen met zoeken dus ik heb niets gevonden op google.

Weet iemand het probleem of een oplossing ?

Thanks

Server: windows 2000 + exchange 2000
Client: Windows XP

[ Voor 4% gewijzigd door Verwijderd op 24-04-2007 11:14 ]

[WaSteiL]

Als het goed is, is dit een normale manier.
Namelijk bij het inloggen haalt een gebruik al zijn informatie op die in zijn/haar security-token komt te staan. Een gebruiker kan nu met die security-token overal bijkomen waar hij/zij rechten heeft.

Indien je een gebruiker lid maakt van een groep terwijl die gebruiker ingelogd is, zal de informatie nog niet in zijn/haar token staan. Dit wordt pas geactualiseerd tijdens opnieuw inloggen.

Ik probeerde dit nog even te onderbouwen met externe website, maar kan zo snel even niet vinden.

[Verwijderd]

ok bedankt voor je reactie, maar wat ik dan niet snap is dat het eerst wel zo was ??

[ShellGhost]

Die trusts zijn 2-way en nog goed functioneel?

[Verwijderd]

yup

[ShellGhost]

Replicatie gaat ook goed?
Dat wil nog wel eens voor problemen zorgen.

[Question Mark]

Verwijderd schreef op dinsdag 24 april 2007 @ 13:05:
ok bedankt voor je reactie, maar wat ik dan niet snap is dat het eerst wel zo was ??

Lijkt me niet mogelijk, tenzij de lifetime van je Kerberos TGT erg klein was, waardoor vaker een nieuw TGT aangevraagd werd. Standaard is deze lifetime echter 10 uur.

[Verwijderd]

Ik heb op het moment maar 1 DC dus hij heeft niet veel te replicaten denk ik

en zover mijn geheugen gaat had ik het wel in die situatie, anders zou het me niet zo zijn opgevallen.

[ShellGhost]

Omdat je 2 domains aan elkaar geknoopt hebt ging ik er vanuit dat er aan de andere kant van de trust ook een domain controller staat.

[Question Mark]

ShellGhost schreef op dinsdag 24 april 2007 @ 14:53:
Omdat je 2 domains aan elkaar geknoopt hebt ging ik er vanuit dat er aan de andere kant van de trust ook een domain controller staat.

Er vindt geen replicatie plaats tussen DC's van verschillende domeinen bij een external trust. Er is enkel een secure channel waar authenticatie over plaatsvind.

[WaSteiL]

Verwijderd schreef op dinsdag 24 april 2007 @ 14:51:
Ik heb op het moment maar 1 DC dus hij heeft niet veel te replicaten denk ik

en zover mijn geheugen gaat had ik het wel in die situatie, anders zou het me niet zo zijn opgevallen.

Verwar je het niet dat als bijvoorbeeld aan een bepaalde map een groep gehangen werd dat dit wel werkte als de gebruiker reeds lid was van de betreffende groep?

[Verwijderd]

ja dat werkt wel dat weet ik.

maar volgens mij andersom vroeger ook

[Zwelgje]

Verwijderd schreef op dinsdag 24 april 2007 @ 15:57:
ja dat werkt wel dat weet ik.

maar volgens mij andersom vroeger ook

zoals questionmark al opmerkte, de lifetime van je kerberos tickets stonden waarschijnlijk erg laag (default 10 uur) alleen dan kan het

bij een renewal van dat ticket kijkt hij ook naar groepslidmaatschap.

_{of je moet al 10 uur hebben gewacht en dus 10 uur niet uitgelogged hebben}

[Verwijderd]

hmm nouja. Jullie zullen wel gelijk hebben
Zal ik iedereen moeten laten uitloggen bij een wijziging die meteen in moet gaan

[sanfranjake]

Zit inderdaad niks anders op. Dit moet voorheen ook altijd zo geweest zijn zoals hierboven aangegeven
Misschien werden er in het verleden niet zo vaak ad hoc changes doorgevoerd?

[Verwijderd]

Volgens mij is dit heel normaal Windows Server gedrag. Het duurt gewoon een poosje voordat policy wijzigingen door de client worden meegenomen. Ik maak het reglematig mee in een 15.000 user domain. Gewoon ff "gpupdate /force" op de client, fingers crossed en laten herstarten en anders nog maar een uurtje wachten en nog eens proberen dan gaat het wel goed. Dat wijzigingen instant zijn heb ik nog nooit gezien. Zelfs niet op mijn laptop met virtual server en een paar clients waarbij alles lokaal is.

[Zwelgje]

Verwijderd schreef op dinsdag 24 april 2007 @ 20:37:
Volgens mij is dit heel normaal Windows Server gedrag. Het duurt gewoon een poosje voordat policy wijzigingen door de client worden meegenomen. Ik maak het reglematig mee in een 15.000 user domain. Gewoon ff "gpupdate /force" op de client, fingers crossed en laten herstarten en anders nog maar een uurtje wachten en nog eens proberen dan gaat het wel goed. Dat wijzigingen instant zijn heb ik nog nooit gezien. Zelfs niet op mijn laptop met virtual server en een paar clients waarbij alles lokaal is.

wie heeft het hier over een gpo

en die background refresh kan je met een policy weer instellen, moet je alleen wel even wachten tot ie die policy oppikt

[sanfranjake]

Dat zijn policies, nt-groepslidmaatschappen worden niet op de achtergrond opnieuw geladen, tenzij je expliciet van de standaard-vernieuwingsperiode afwijkt. Daardoor krijgen je domaincontrollers het natuurlijk wel drukker

[Zwelgje]

sanfranjake schreef op dinsdag 24 april 2007 @ 20:45:
Dat zijn policies, nt-groepslidmaatschappen worden niet op de achtergrond opnieuw geladen, tenzij je expliciet van de standaard-vernieuwingsperiode afwijkt. Daardoor krijgen je domaincontrollers het natuurlijk wel drukker

groeplidmaatschap worden dus wel op de achtergrond ge-refrehsed als je kerberos ticket verlopen is..... (waar we het de hele tijd over hebben)

...maar ik heb even niet goed gelezen, dat bedoelde je natuurlijk ook

[ Voor 8% gewijzigd door Zwelgje op 24-04-2007 21:36 ]

[sanfranjake]

Powershell schreef op dinsdag 24 april 2007 @ 21:26:
[...]


groeplidmaatschap worden dus wel op de achtergrond ge-refrehsed als je kerberos ticket verlopen is..... (waar we het de hele tijd over hebben)

Dat zeg ik

nt-groepslidmaatschappen worden niet op de achtergrond opnieuw geladen, tenzij je expliciet van de standaard-vernieuwingsperiode afwijkt

[Verwijderd]

Nu zit ik met het volgende. En dit keer weet ik het 100% Zeker.
Als ik een nieuwe user aanmaak en toegang geef tot een groep die op de ftp server mag komen. Kan hij niet inloggen. Als ik hem vervolgens handmatig in de ntfs rechten van de ftp root read rechten geef kan het wel. WTF is er aan de hand ? ik gooi hem in die groep dan moet ie dat zien toch ??
Zie ik iets over het hoofd ?

[Question Mark]

Verwijderd schreef op woensdag 25 april 2007 @ 13:22:
Als ik een nieuwe user aanmaak en toegang geef tot een groep die op de ftp server mag komen. Kan hij niet inloggen.

Kan niet inloggen op het domain of van "buitenaf" op de FTP-server met zijn NT-credentials?

Verwijderd schreef op woensdag 25 april 2007 @ 13:22:
Als ik hem vervolgens handmatig in de ntfs rechten van de ftp root read rechten geef kan het wel.

Kan wat wel?

Verwijderd schreef op woensdag 25 april 2007 @ 13:22:
ik gooi hem in die groep dan moet ie dat zien toch ??

Wie moet wat zien?

Wat heb je nu precies gedaan, hoe test je het en wat zijn de foutmeldingen in de eventlogs van zowel de client, DC en FTP-server?

[sanfranjake]

IIS default logondomain misschien: Error message in IIS: "530 User <Username> cannot log in. Login failed."

[Verwijderd]

Yep dat was het, uit het niets werkte het opeens. Zag later ook de error message in de event viewer.