In the FAQ on this site it says
This is the normal answer to this question and probably the 'right' answer on an MCP exam.Originally Posted by GPAnswers
However, I know from experience that this is not the case!
You can apply a security policy anywhere you like, but the behaviour is very different depending on where you do it.
If you apply it in the default domain policy then the policy applies to all domain accounts. Like the books say, nice and easy.
If you apply an account policy anywhere else it applies to the accounts on the objects in that OU / site. What objects have accounts? Computers. So you have applied a policy to the local accounts of the computers in the affected area.
In reality, since a domain user's local machine account is a cached version of their domain account, what happens when they change a password is that they are restricted in their choice by the policy which is in force on the local machine, so complexity, length, rotation etc are enforced on their choice.
This appears to be restricting their domain account, and it is in effect, but in a roundabout way.
The one account policy which only seems to take effect at domain level that I found is account lockout policy. This makes sense that you don't want to expire an account when not on the domain as they cannot contact their PDC emulator to change it so you would have some strange things going on. They can use their cached credentials beyond the expiry period as far as I know (but would then be "pre-expired" if they connect back to the domain)
So, to clarify your original question as far as I have been able to test: this does not change the local policies, it is a domain GP affecting local accounts on the computer, which is subtly diferent.
So you are correct (AFAIK) that local accounts are unaffected by this when logging on to the local machine and not to the domain.
How do I know this? I tried it out (back when GP was all new to me and I did not know better) by setting an account policy on a test OU so I would not affect users if I got it wrong, used complexity, enforced length, no part of name, re-use after 20 etc.
It appeared to work so I moved it to the relevant OUs and users had it applied (but not in the way I thought). Later I was tidying up and I thought, "hell, why not move it to the default domain policy now, it's thoroughly tested and bedded in" (and I had read that account policies should be here or they would not work, but I didn't see how that cold be so, since they did 'work' as far as I could see). So I did.
And everything was fine except users started getting lockouts. Strange, since I had not changed this setting in the policy, just copied the settings verbatim. Never worked out why until I read "Hardening Windows Systems" by Roberta Bragg (a very good book all round) and she explained it all properly so at least I now knew why what I did had done what it did!
What I never tested (and might be interesting for anyone who finds the time):
can a user change password on cached domain account while offline and if so what policy (if any) applies? My guess is only the local account policy (if any) applies.
can you apply a policy setting which overrides the default domain policy by setting eg. length to be higher on servers or in the AdminWorkstations OU? (in theory this should work ie if a user changes their password on these machines, the policy affecting the local version would be in force, as well as the policy in their domain user account, so a password would have to fit to both policies)
I have seen several books (including MS Press titles) which apply account policy settings to an OU as part of a worked example, and in the same book say that you can't do this, but no explanation as to what really happens! I hope this helps anyone confused by the conflicting information on this.


LinkBack URL
About LinkBacks
Reply With Quote