[Win2k8 R2 AD] Inloggen kan nog met oud ww na ww change

[Urk]

Ik heb iets vreemds in een netwerk van een klant: Ze draaien een netwerk met 2 x Win 2008 R2 server met AD rol en alleen Windows 7 x64 clients.
Ongeveer 2 tot 3 weken geleden hebben we het wachtwoord van het Domain Administrator account gewijzigd. Vandaag kwam ik erachter dat 1 gebruiker nog steeds het oude admin wachtwoord kon gebruiken om instellingen te wijzigen. Zowel op een laptop als werkstation.
Beide systemen zijn regelmatig met het netwerk verbonden en de servers verbonden en dus lijkt het me geen probleem van cached credentials.

Hoe kan dit? En hoe kan ik dit voorkomen (nu en in de toekomst)?
Iemand een idee?

Via Google kan ik soortgelijk verhaal niet echt vinden...

[ Voor 4% gewijzigd door Urk op 26-02-2014 00:32 ]

[Linke Loe]

Heb je de eventlogs al eens uitgepluisd of de replicatie tussen de domain controllers goed verloopt?

[Trommelrem]

Hoe lang speelt dit probleem al? Pas op dat je DC's niet de tombesteen des levens overschrijden. Als je een domein hebt dat gemaakt is voor Windows 2003 SP1, dan is de tombesteen des levens 60 dagen, ondanks alle upgrades daarna. Is je domein daarna aangemaakt met Windows 2003 SP1 of later, dan is je tombesteen des levens 180 dagen.

Ik zou allereerst kijken of je KCC z'n werk wel goed doet, maar analyseer eerst de schade voordat je replicatie weer start! Je wil niet dat je servers gaan repliceren met een verlopen tombesteen des levens!

[ Voor 78% gewijzigd door Trommelrem op 26-02-2014 08:21 ]

[Bor]

Tombstone bepaalt hoe lang een deleted item in AD opgeslagen blijft. Wat heeft dat met een niet gerelpiceerd wachtwoord te maken

Ook ik zit aan replicatieproblemen te denken. Dit zou je kunnen controleren middels de KCC idd of door aan te melden via de andere domain controller. Zijn beide global catalog servers trouwens?

[ Voor 42% gewijzigd door Bor op 26-02-2014 08:32 ]

[Paul]

Op het moment dat je het probeert, zit de pc / laptop dan aan het netwerk? Cached credentials worden afaik pas bijgewerkt op het moment dat je ze gebruikt.

[ Voor 3% gewijzigd door Paul op 06-03-2014 19:27 ]

[JeroenV_]

Misschien te simpel gedacht, maar was vroeger wellicht het domein admin wachtwoord hetzelfde als het local admin wachtwoord op pc's/laptops, en logt hij lokaal in ipv op het domein?
Als je op een windows 7 machine Administrator als usernaam invult, springt deze nl standaard naar de lokale machine ipv het domein.

[ Voor 6% gewijzigd door JeroenV_ op 26-02-2014 10:04 ]

[Urk]

Bor de Wollef schreef op woensdag 26 februari 2014 @ 08:30:
Tombstone bepaalt hoe lang een deleted item in AD opgeslagen blijft. Wat heeft dat met een niet gerelpiceerd wachtwoord te maken

Ook ik zit aan replicatieproblemen te denken. Dit zou je kunnen controleren middels de KCC idd of door aan te melden via de andere domain controller. Zijn beide global catalog servers trouwens?

Haha, dank je, ik begreep al niet wat hij bedoelde met Tombstone.
Ja, beide servers zijn Global Catalog Servers, zojuist nogmaals gecontroleerd.
Met KCC bedoel je neem ik aan Knowledge Consistency Checker? Dat zal ik later vandaag nog even checken en uitvoeren.

[Urk]

Trommelrem schreef op woensdag 26 februari 2014 @ 08:19:
Hoe lang speelt dit probleem al? Pas op dat je DC's niet de tombesteen des levens overschrijden. Als je een domein hebt dat gemaakt is voor Windows 2003 SP1, dan is de tombesteen des levens 60 dagen, ondanks alle upgrades daarna. Is je domein daarna aangemaakt met Windows 2003 SP1 of later, dan is je tombesteen des levens 180 dagen.

Ik zou allereerst kijken of je KCC z'n werk wel goed doet, maar analyseer eerst de schade voordat je replicatie weer start! Je wil niet dat je servers gaan repliceren met een verlopen tombesteen des levens!

Het probleem is alleen sinds de wijziging van het Domain Admin wachtwoord.
Nee, dit domein is opgezet met 2 nieuwe Windows Server 2008 R2 servers en zijn dus geen upgrades uitgevoerd. Ook is de Domain en Forest functional level momenteel Windows Server 2008 R2.
Ik zal eens in de replicatie duiken, maar beide servers zijn zelfs na het WW change nog 2 keer opnieuw opgestart.

[Trommelrem]

Controleer de KCC. Gebruik o.a. dcdiag. Worden nieuwe gebruikersaccounts (of testaccount/testgroepen) uberhaupt gerepliceerd naar de andere DC?

Als het een replicatieprobleem is, dan heb je het probleem ontdekt sinds de wijziging, maar dan bestaat het probleem waarschijnlijk al langer.

[Bor]

Urk schreef op donderdag 27 februari 2014 @ 10:58:
[...]

Ik zal eens in de replicatie duiken, maar beide servers zijn zelfs na het WW change nog 2 keer opnieuw opgestart.

Als de replicatie niet werkt hoeft een reboot dat natuurlijk niet op te lossen. Het een sluit het ander niet uit.

[Linke Loe]

Je kan dit natuurlijk eenvoudig checken door op beide servers in te loggen, met wat het administrator wachtwoord zou moeten zijn. Als de wijziging van het het wachtwoord niet goed gerepliceerd is, zou je op een van de servers een melding krijgen dat het wachtwoord niet klopt.

[Urk]

Linke Loe schreef op donderdag 27 februari 2014 @ 13:57:
Je kan dit natuurlijk eenvoudig checken door op beide servers in te loggen, met wat het administrator wachtwoord zou moeten zijn. Als de wijziging van het het wachtwoord niet goed gerepliceerd is, zou je op een van de servers een melding krijgen dat het wachtwoord niet klopt.

Precies, en dat was dus direct na de wachtwoord wijziging al niet het geval, ik kon op beide servers inloggen met het nieuwe wachtwoord, dus dat moet dan prima zijn.

[Urk]

JeroenV_ schreef op woensdag 26 februari 2014 @ 10:03:
Misschien te simpel gedacht, maar was vroeger wellicht het domein admin wachtwoord hetzelfde als het local admin wachtwoord op pc's/laptops, en logt hij lokaal in ipv op het domein?
Als je op een windows 7 machine Administrator als usernaam invult, springt deze nl standaard naar de lokale machine ipv het domein.

Dank voor je opmerking maar nee, dat is ook zeker niet het geval, sterker nog: Het lokale administrator account wordt op alle clients als tijden via een Group Policy hernoemd naar LocalAdmin en er wordt een wachtwoord aan dat account toegewezen, dus die is bij iedereen dus gelijk. Als je met username Administrator inlogt is het dus altijd het Domain Administrator account.

Hoe kan ik eigenlijk zien of er replicatie problemen zijn? Op server 01 is het Domain Admin wachtwoord gewijzigd, daar hoef ik dus niet te checken neem ik aan. Op server 02 kan ik ook met het nieuwe wachtwoord inloggen, dat was al na de change direct zo dus replicatie lijkt dan toch prima te werken?
De user die als enige het oude Administrator wachtwoord wist kon op zijn PC en laptop gewoon gebruik maken van het oude wachtwoord, ik heb het zelf gezien en ervaren op zijn laptop. Nadat ik op zijn laptop het nieuwe wachtwoord 1 of 2 keer had gebruikt werkte die opeens wel en het oude wachtwoord niet meer..

Heb zojuist ook nog de lokale user accounts gecontroleerd op het werkstation van de betreffende gebruiker. Dat klopt helemaal, er is een Gast account die uitgeschakeld is en een LocalAdmin account.
Ook zijn er geen Admin groepen waar de gebruiker bijv. aan toebehoort.

[ Voor 35% gewijzigd door Urk op 27-02-2014 14:55 ]

[Bor]

Cached credentials dus?

[Urk]

Bor de Wollef schreef op donderdag 27 februari 2014 @ 14:55:
Cached credentials dus?

Ja daar lijkt het op maar is toch bizar dat die na 2 weken nog steeds niet waren bijgewerkt?
Hoe kan ik dat nakijken? Iemand een idee?

[Wim-Bart]

Cached Credentials never Expire. Maar zodra een systeem netwerk verbinding heeft voor het aanloggen dan zal het nieuwe wachtwoord gebruikt moeten worden.

Je kan dus de boel voor de gek houden door netwerk te verbreken (kabel er uit) wanneer de PC start. Dan inloggen met cached credential en dan netwerk kabel er in. Maar het zal op een bepaald moment fout gaan voor die gebruiker.

Overigens, het Domain/Enterprise Admin password hoort in een kluis te liggen en men hoort werkzaamheden uit te voeren met named admin accounts. Zo voorkom je shit wanneer een beheerder uit dienst gaat.

[ Voor 5% gewijzigd door Wim-Bart op 27-02-2014 19:45 ]

[Question Mark]

Wim-Bart schreef op donderdag 27 februari 2014 @ 19:44:
Cached Credentials never Expire.

Dat nuanceer ik even... Er zit geen lifetime op cached credentials, er zit alleen een limiet op het aantal cached credentials wat "onthouden" wordt.

Bor de Wollef schreef op donderdag 27 februari 2014 @ 14:55:
Cached credentials dus?

Lijkt me niet... Daar krijg je nl. als gebruiker gewoon een melding van als die gebruikt worden:

Windows cannot connect to a server to confirm your logon settings. You have been logged on using previously stored account information. If you changed your account information since you last logged on to this computer, those changes will not be reflected in this session.

Zie ook: http://technet.microsoft....ry/cc755473(v=ws.10).aspx

[3DDude]

TS Wat heb je voor meldingen gevonden in eventviewer?
(je weet wel die security audit onderdeel /log ervan (logon succesvol?)
Op zowel client als server ?

[Wim-Bart]

Question Mark schreef op donderdag 27 februari 2014 @ 19:53:
[...]
Dat nuanceer ik even... Er zit geen lifetime op cached credentials, er zit alleen een limiet op het aantal cached credentials wat "onthouden" wordt.

1 cached credential is al genoeg. Maar aan de andere kant kan je met domein policy cached credentials uitschakelen of beperken tot 0. Dus kan hij een GPO aanmaken en dit zetten op de container waar de werkstations in zitten waardoor het cached credentials probleem is opgelost. En voor laptops kan hij cached credentials op 1 zetten waardoor alleen de actieve gebruiker onthouden wordt als deze thuis wil werken. Het is een kwestie van finetunen.

Maar tja, dan kan je ook gelijk het aantal bewaarde profielen beperken Dat scheelt ook weer, mits natuurlijk gebruik wordt gemaakt van Roaming Profiles en folder redirection

[Killah_Priest]

Wim-Bart schreef op donderdag 27 februari 2014 @ 19:44:
Overigens, het Domain/Enterprise Admin password hoort in een kluis te liggen en men hoort werkzaamheden uit te voeren met named admin accounts. Zo voorkom je shit wanneer een beheerder uit dienst gaat.

Dit gaat naar mijn idee wel erg ver, vaak kom je er niet onder uit om in ieder geval met een domain admin account te moeten werken (ok, ik doe zelf altijd gewoon "run as" ipv interactief inloggen met een domain admin account) ; je DSRM password moet je uiteraard wel goed opbergen.

[Paul]

Dat is ook niet het probleem, zolang jouw account (met domain admin rechten) maar 'Killah_Priest' heet en niet 'Administrator'

[Wim-Bart]

Killah_Priest schreef op vrijdag 28 februari 2014 @ 16:55:
[...]


Dit gaat naar mijn idee wel erg ver, vaak kom je er niet onder uit om in ieder geval met een domain admin account te moeten werken (ok, ik doe zelf altijd gewoon "run as" ipv interactief inloggen met een domain admin account) ; je DSRM password moet je uiteraard wel goed opbergen.

Ik snap het niet. Je kan toch gewoon een named administrator account aanmaken, bijvoorbeeld admin.pietje en deze domein admin maken waardoor er geen enkele reden is om met het default "Administrator" account in te loggen. En je kan het default domain admin account zelfs total dicht spijkeren tegen password changes door anderen, hoewel dat wel heel erg ver gaat.

Ik ben eigenlijk nog nooit tegen gekomen dat je het Administrator account nodig had en het niet met een kopie van het account.

[Paul]

Onder Windows niet, op een aantal andere zaken zijn er ooit dingen waarvoor je geen rechten kunt zetten. IBM SVC (en v7000) mag je niks wat met users / authenticatie te maken heeft als je niet als 'admin' bent ingelogd bijvoorbeeld.

[alt-92]

Dan nog is het de vraag of dat een user met domain administrative privileges is of 'the user with the sID ending in -500' .

[Wim-Bart]

Paul schreef op vrijdag 28 februari 2014 @ 17:13:
Onder Windows niet, op een aantal andere zaken zijn er ooit dingen waarvoor je geen rechten kunt zetten. IBM SVC (en v7000) mag je niks wat met users / authenticatie te maken heeft als je niet als 'admin' bent ingelogd bijvoorbeeld.

Maar dat houd niet in dat je onder Windows dat ook moet doen. Een applicatie die kijkt naar de sid van de current user en of die eindigd op -500 moet je gewoon negeren. Dat is gewoon brakke software.

Er zijn zelfs bedrijven welke werken met role based admins, dus net delegation of control waardoor je net jouw admin account niks kunt buiten je afgeschermde taakstelling.

Zelf heb ik als standaard dat sowieso het default administrator account met GPO hernoemd wordt op servers en werkstations en er een tweede backup backup administrator account aanwezig, evenals in het ad domein. Daarnaast heeft iedere beheerder een admin account voor admin taken en een werkaccount voor standaard kantoor werkzaamheden. Wanneer je op deze wijze werkt is het soms vervelend, maar aan de andere kant, heb te vaak meegemaakt dat en beheerder met te veel rechten in 1 simpele klik iets desastreus deed wat nooit had gehoeven. Tevens hebben named admin accounts een ander voordeel: met de juiste policies kunnen acties achterhaald worden....

[Turdie]

Weet je zeker dat de server na daar zelfde domein controllers verbind als waar jij de wachtwoord op heb gewijzigd?
Kun je nagaan met:

 echo %logonserver%

[Killah_Priest]

Wim-Bart schreef op vrijdag 28 februari 2014 @ 17:09:
[...]


Ik snap het niet. Je kan toch gewoon een named administrator account aanmaken, bijvoorbeeld admin.pietje en deze domein admin maken waardoor er geen enkele reden is om met het default "Administrator" account in te loggen. En je kan het default domain admin account zelfs total dicht spijkeren tegen password changes door anderen, hoewel dat wel heel erg ver gaat.

Ik ben eigenlijk nog nooit tegen gekomen dat je het Administrator account nodig had en het niet met een kopie van het account.

Ik had de eerdere post niet goed begrepen, ik log inderdaad nooit in met het "administrator" account, het is altijd een apart account met domain admin / enterprise admin rechten (bijv. adm.Killah_Priest).

[Paul]

Wim-Bart schreef op vrijdag 28 februari 2014 @ 19:55:

You're preaching to the converted

Een applicatie die kijkt naar de sid van de current user en of die eindigd op -500 moet je gewoon negeren. Dat is gewoon brakke software.

Welkom in de echte wereld, waar je het hebt te doen met de keuzes van anderen

[Urk]

Graag weer een beetje ontopic: dank voor alle reactie maar nog steeds heb ik geen idee wat de oorzaak kan zijn van dit euvel. Op enkele andere machine's na mijn bericht was het probleem net ter sprake...

[Paul]

Ik zie anders nog de nodige posts die je niet beantwoord hebt

[Question Mark]

Paul schreef op donderdag 06 maart 2014 @ 19:27:
Ik zie anders nog de nodige posts die je niet beantwoord hebt

Paul heeft hier wel een punt... In de allereerste reactie wordt je gevraagd om eens je eventlogs door te spitten en om je replicatie te controleren. Daar heb je nog niet op geantwoord, terwijl de vragen ontzettend essentieel zijn.

Controleer je eventlogs dus (van zowel DC's als een werkstation waarop je de issue ervaart) en controleer je AD replicatie eens. Gebruik voor het laatste even de Active Directory Replication Status Tool

[Bor]

Killah_Priest schreef op vrijdag 28 februari 2014 @ 16:55:
[...]


Dit gaat naar mijn idee wel erg ver, vaak kom je er niet onder uit om in ieder geval met een domain admin account te moeten werken (ok, ik doe zelf altijd gewoon "run as" ipv interactief inloggen met een domain admin account) ; je DSRM password moet je uiteraard wel goed opbergen.

Want? Ik kan mij geen enkele reden bedenken eigenlijk zolang je de rechten maar goed uitdeelt. Niet inloggen met het domain admin account is best practise en hoort de standaard werkwijze te zijn. Acties horen terug te kunnen worden herleid naar een persoon.

[Paul]

Bor de Wollef schreef op vrijdag 07 maart 2014 @ 08:26:
Acties horen terug te kunnen worden herleid naar een persoon.

Er zit behoorlijk wat spraakverwarring in dit topic. 'een domein admin' is niet hetzelfde als 'BUILTIN\Administrator' of 'CN=Administrator,CN=Users,DC=contoso,DC=com'...

Je had Killah_Priest in "[Win2k8 R2 AD] Inloggen kan nog met oud ww na ww change" al gelezen?

[Bor]

Die spraakverwarring komt door het gebruik van "een'" domain admin en "het / de" domain admin account vermoed ik. Had de reactie van Killah Priest idd al gelezen.

[ Voor 3% gewijzigd door Bor op 07-03-2014 09:25 ]

[marc181982]

nvm

[ Voor 98% gewijzigd door marc181982 op 10-03-2014 14:17 ]