Printable View
I just put in place a Group Policy through AD to lock out accounts after 5 attempts. However this is not taking effect. It has replicated to all of my DC however when I try to log in(Citrix Enviornment) it doesn't work. The accounts never lock out.
My unlock threshord is set to 999 minutes
and my reset unlock attempts is set to 200minutes
We want people to call the help desk to get them unlocked.
However it isn't work. In my test enviornment it works fine.
Please Assist.
Type GPUPDATE at the command prompt of one of your hosts. Try again. Report your results here.
it says it is not a reconized command when I do it on one of my DC
Do it on a client machine, not the DC.
I also did it on another one of my servers(windows 2000) since were running citrix and I get the same error.
There you have it, the gpupdate utility comes with XP. I assumed you have XP clients.
On 2000, you use secedit. Here is the syntax:
Refresh security settings
secedit /refreshpolicy
This command refreshes system security by reapplying the security settings to the Group Policy object.
Syntax
secedit /refreshpolicy {machine_policy | user_policy}[/enforce]
Parameters
machine_policy
Refreshes security settings for the local computer.
user_policy
Refreshes security settings for the local user account currently logged on to the computer.
/enforce
Refreshes security settings, even if there have been no changes to the Group Policy object settings.
alright but I applied this to all users in the domain. Is there anyway to do this without having to hit this on every computer? Also I guess I want to refresh the machine policy? since this is a domain setting???? for domain accounts?
Will a reboot of a server do this?
Yes. A reboot of each client will force a policy update. Otherwise, the policy will push based on what you have the policy push time set to. BY default I believe it's half hour but I could be wrong.
nope didn't quiet work. I issued the command and the event log says it has been applied however it still doesn't lock out my account.
Check the configuration of the GP object. Sounds like there is something wrong. These two tools work for me all the time.
Just a quick "basic" check question.
Do you have the users placed in an OU?
And you applied the GP to that OU?
If not, try that to make sure the GP settings are propagating correctly...
The default Group Policy refresh rate is 90 mins for workstations and 5 mins for servers...Quote:
Originally posted here by thehorse13
Type GPUPDATE at the command prompt of one of your hosts. Try again. Report your results here.
You Could Right Click on the Domain From AD Users and computers Select Properties...
Then Navigate to the Group Policy Tab...
Edit or Create a Default Domain Group Policy...
Under Computer Configuration Expand Windows Settings...Then Security Settings
Under Account settings Make the necessary changes depending on your requirements..
Close the GP Editor...Then run secedit /refreshpolicy from a workstation...Reboot and test changes...
Account policies are only applicable at the domain level and not to individual OUs.
While it wont complain if you set account policies on a GP applied to an OU, it will NOT take effect.
edit:
Oh, also, to check what policies applied correctly or not, (on XP) use gpresult (at the command line) and/or the "Resultant Set of Policies" (RSoP.mmc) plugin in the MMC.
The later is VERY usefull in diagnosing GP issues!
Ammo
alright, let me apply this to the domain and see if it is effective that way. Will this also lock out administrator/domain admin accounts including the built in Administrator account?
Silly question.... Are you logging in as the domain administrator.... Because he can't be locked out.....
I was planning on doing that... you sound like you are you sure? Would you know of a work around?Quote:
Account policies are only applicable at the domain level and not to individual OUs.
Road:
I really don't believe that information is accurate for several reasons.... Unfortunately I don't have the time to log into my work systems and _prove_ it.
I can say that under each OU there is both computer policies and user policies. Logically, there would be no point having the user policies if they did nothing. Add to that the ability to create a "Problem User" OU that restricts the users in it to what they can do and I would say the information is wrong.
At this point this is a slightly beer blurred answer with no solid facts to back it up.... they will come...
As an afterthought.... It might be a "no overide" issue on the domain policy.... But that's me starting to think when I probably shouldn't.... ;)
Here, confirmation... (with a little caveate...)
http://www.microsoft.com/resources/d...p_log_fann.asp
Also reworded here: http://www.microsoft.com/windows2000...CEacctpols.htmQuote:
Account Policies
Account policies affect Windows XP Professional computers in two ways. When applied to a local computer, account policies apply to the local account database that is stored on that computer. When applied to domain controllers, the account policies affect domain accounts for users logging on from Windows XP Professional computers that are joined to that domain.
Domain-wide account policies are defined in the Default Domain Group Policy object (GPO). All domain controllers pull the domain-wide account policy from the Default Domain GPO regardless of the organizational unit in which the domain controller exists. Thus, while there might be different local account policies for member computers in different organizational units, there cannot be different account policies for the accounts in a domain.
By default, all computers that are not-domain controllers will also receive the default domain account policy for their local accounts. However different account policies might be established for local accounts on computers that are not domain controllers by setting an account policy at the organizational unit level. Account policies for stand-alone computers can be set using Local Security Policy.
So basically,
1- domain accounts are only affected by the domain level account policy.
2- local accounts are by default affected by the domain level account policy
3- (and this is my caveate) the local account's policy can be overriden by an account policy set at the OU level BUT it will only apply to local user accounts, not the domain accounts that login localy.
Ammo
Yeah, I think you're right Ammo.
Anyway, I thought the best way to find out is to test it, and sure enough, I can't make an OU get any other Account policy than what the Domain policy is set to.. :(
That's just stupid though.. lol! I haven't really needed to setup specific GP Account policies on different OU's, I just have the same GP settings for the whole Domain. But I could very well see how it could be very beneficial to be able to set different Account policies on different OU's...!
Even tried to check the box, "No override" on the OU policy, but still no luck.. heh!
I even used RSoP to check what it "thought" the policy should be, and it says the OU policy is what goes, so even RSoP reports it wrong.. not very well thought through it seems.. !?!
Oh well... another stupid "flaw"... !
After some digging... and thanks for making me re-look at this... I found this:-
Since the order is Site - _Domain_ - OU then this seems to clearly state that the policy applies at the OU level on top of the domain policy.Quote:
Group Policy is applied hierarchically from the least restrictive group (site) to the most restrictive group (organizational unit). Group Policy is also cumulative. Child directory service containers inherit Group Policy from parent containers, and Group Policy processing occurs in the following order: site, domain, and organizational unit. This means that if you have assigned a specific Group Policy to a high-level parent container, that Group Policy applies to all containers beneath the parent container, including the user and computer objects in each container. However, if you explicitly specify a Group Policy for a child container, the child container's Group Policy overrides the parent container's Group Policy.
This seems to be confirmed by this
Then there's the "fiddling" that can be done with the "No override" and "Block inheritance" settings and I'm pretty sure you can do anything you please.... If you do it right. The issue is that the policy is appled from the top level, (site), through the domain to the OU. The way it works is that if I set a policy, (let's forget the Site for now), at the domain level under the user policy that states that the users of this domain can't use Word then since that policy is set if it is "not set" at the OU level then the domain policy "wins". However, if it is set to enabled or disabled then the OU policy "wins". At the same time, if the OU policy is "not set" but the OU has Block Inheritance set then the domain policy doesn't apply.Quote:
In general, Group Policy is passed down from parent to child containers. If you have assigned a specific Group Policy to a high-level parent container, that Group Policy applies to all containers beneath the parent container, including the user and computer objects in each container. However, if you explicitly specify a Group Policy setting for a child container, the child container's Group Policy setting overrides the parent container's setting.
Am I making myself clear here? It's the way I always understood AD to work with regard to policies.... I'll work harder to make myself clear if there are questions.....
Yeah, I actually had wanted to do that in the past (diffrent account policies for OUs) and found myself in this impass...
In a way I kind of find it a good thing, however, forcing everyone on the domain to have the same strength passwords and such gives you a technical excuse for not letting directors and boss's have easier passwords!
Ammo
Ammo: See above...
[Edit]
All of which raises the question, (since I can't be bothered to go back through the entire thread),.... Are his users logging in locally or as domain users... Because then only the computer policy would apply IIRC...
[/Edit]
Err, I'm confused now, is your final stance that what I said (AND microsoft referenced) is right or do you still dispute that?
[edit]btw, I'm in no way contesting that GPs are applied hierachically, inherited, and etc.; what I'm saying is that the account polices are special and are not respected by windows the way you might expect, just like I said and referenced in post #18.
[/edit]
Ammo
Ammo:
This is one of those situations where I need to reread the _whole_ thread... assimilate the original question, the responses and then the "truth".... This isn't going to happen in short time... I have a meeting tomorrow where I have to "sell" something so my thoughts are on that.... But this whole issue is worth revisiting..... If only my Alzheimer's will let me go for a day or two... :eek:
Someone.... Anyone... Keep posting just so that I keep getting the reminders that I need to respond to this thread..... Please..... :) It's an important issue and needs to be put in "English" for all to understand.....
Ok, you are both probably right, the exception to Tigers statement is like Ammo says, at least through the testings I've now done, it doesn't apply to the Account Policies.
A few examples:
1. Domain GP - no OU GP = Domain GP wins
2. Domain GP - conflicting OU GP = OU GP wins
3. Domain GP (Account Policy) - no OU GP = Domain GP (Account Policy) wins
4. Domain GP (Account Policy) - conflicting OU GP = Domain GP (Account Policy) wins!!
5. Domain GP (Account Policy) - conflicting OU GP, with Block Inheritance = Domain GP STILL wins!!
Doesn't make much sense, but that seems to be how it works.. !
Found a pretty good link that explains the "Blocking" and "Enforcing" as well:
http://www.microsoft.com/technet/pro...542d06b2c.mspx
SourceQuote:
This order means that the local GPO is processed first, and GPOs that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites settings in the earlier GPOs if there are conflicts. (If there are no conflicts, then the earlier and later settings are merely aggregated.)
coupled with:-
SourceQuote:
GPO processing is based on a last writer wins model, and GPOs that are processed later have precedence over GPOs that are processed sooner. Group Policy objects are processed according to the following order:
1. The local Group Policy object (LPGO) is applied.
2. GPOs linked to sites.
3. GPOs linked to domains
4. GPOs linked to organizational units. In the case of nested organizational units, GPOs associated with parent organizational units are processed prior to GPOs associated with child organizational units.
Both of which being preceded with language similar to, and assuming that by using the term "Account policies" we are talking about "User Policies":-
Now, to me, this clearly implies that the final policy set on a computer or user is that of the last OU in the tree of OU's which are below the domain in the tree by default. This means to me that if the last OU in the tree says that the user, (account(?)), can't run Word but the domain policy says he can then the OU policy overwrites the domain policy's setting in the local security policy, (because that's the only policy there really is and the domain etc. policies simply "adjust" that policy), then the OU "wins" because it is set later and therefore alters the previous setting of the domain policy.Quote:
To apply the settings of a Group Policy object (GPO) to the users and computers of a domain, site, or organizational unit
Now, I need to explain that I _believe_ that the default link order is as written in the MS documents, thus it goes Site - Domain - OU - nested OU. I could be wrong but I don't see why they would write the docs in one way for this and then have the default order be different... But then it wouldn't be the first time on complex issues MS' documentation either is wrong or they have multiple documents that contradict each other.... :rolleyes:
To avoid conflicts and problems the traditional advice has always been that you apply the least restrictive policy at the domain level, (this assumes that you forget about local policies and site policies though in certain infrastructures site policies may be relevant but that setting the local policy is always pretty irrelevant in a domain environment). This is where you set things like a lockout policy for example... You want all users, anywhere in the domain, to be locked out for an hour if they fail login three times.... Then at the basic OU level you choose that no-one in OU A can run the command prompt but users in OU B can so in OU A you set the policy that no user, (account(?)), in the OU can run cmd.exe but in OU B you don't even set the policy, (leave it disabled). In the case of OU B the local policy "wins" with regard to running cmd.exe because neither the domain policy nor the OU policy set the policy. However, in OU A, the local policy "loses" because, even though the domain policy did not overwrite the policy with a "deny cmd.exe" policy the OU policy did. In a situation where the domain policy states that cmd.exe is blocked and the OU policy is disabled then the domain policy wins because the OU policy did not overwrite the local policy after the domain policy did - remember, there's only one policy. But - if the domain policy said that cmd.exe is blocked and the OU policy says that the policy is enabled, (this might not be a great example but run with it...), and denies no executables then the OU policy "wins".... (But I think that this is where the issue is based... Does an "enabled" but with no parameters set overide a parameter that has already been set? ie: if I say at the domain level that cmd.exe is denied but at the OU level I change the setting from "not set" to enabled but put no parameters in there do I overwrite the change in policy that the domain policy previously set?.... Dunno....)
This is all very complex and can be affected very subtlely if the policies aren't in a logical and "increasing" fashion from the domain downwards. The conventional advice was given because it was difficult to determine and comprehend the accumlating policies, (and where they were set from), set in a domain environment easily so the advice was given to try to simplify the management of a domain for the admin.
Ammo et al... I'm not arguing here... I'm trying to find the "truth". I think when the combined minds and talents here do we should summarize the whole thing into "common" language so that it can benefit all.....
Thoughts, comments, expertise are gratefully accepted.....
Ok, I think I see what's going on here:
When SawPer and I are refering to "Account Policies", we are refering to the policies (in gpedit.msc) under "computer configuration | Windows Settings | Security Settings | Account Policies" under which are defined the "password policy", "account lockout policy" and such.
I believe that you took it to mean the "User Configuration" (as opposed to the "Computer Configuration") section of policies.
Did I get you right?
Ammo
Ahhhh... doncha just love terminology.... and how, if you aren't accurate with it you can waste a whole lot of time.... :eek:
I got on the wrong track about 200 posts ago in the thread thinking we were discussing "user account policies" , akin to "computer account policies", in a domain rather than what the entire rest of the world has been discussing. Apologies for being a dolt.... :o
But it made me think and revisit some things that might have been overdue.... Thanks all....
Yepp, heh!!Quote:
Originally posted here by ammo
Ok, I think I see what's going on here:
When SawPer and I are refering to "Account Policies", we are refering to the policies (in gpedit.msc) under "computer configuration | Windows Settings | Security Settings | Account Policies" under which are defined the "password policy", "account lockout policy" and such.
I believe that you took it to mean the "User Configuration" (as opposed to the "Computer Configuration") section of policies.
Did I get you right?
Ammo
It is really confusing with the "Account Policies" settings only being effective from the Domain level. I wonder if you don't set any "Account Policies" settings at all on the Domain level, if you then can set them on the OU level??? That might be a good workaround to be able to set different settings for different users?!? :)
Or maybe you can ONLY set the "Account Policies" on the Domain level period??
Don't know if I wanna test that on my network.. heh.. ?! Anyone got a lab to test this? :)
Well, gald we finally all cleared things up!
AFAIK the latter is correct.Quote:
Or maybe you can ONLY set the "Account Policies" on the Domain level period??
Ammo
Well does it? If the policy propagation goes _Site_ - Domain - OU - Nested OU is it possible, (though probably no-one ever though much about it because most people, myself included, all tend to see the heirarchy as Domain - Site - OU etc.), that it could be set at the site level which would over-ride the Domain?Quote:
AFAIK the latter is correct.
Just throwing it out there... I'm not going to try it on my production network.... ;)
Maaan Tiger... ! You are forcing me to try it on my network! :PQuote:
Just throwing it out there... I'm not going to try it on my production network.... ;)
I can't just let this go now.. heh!!
Oh well... I'm too busy right now to test it, but if nobody else does it, I will... ! HAVE to know now.. hehe!!
Just makes no sense to have it available at all, if it can only be used on the Domain level, to have it available on the OU level.. !
Or MS was just too lazy... easier to just leave it the same everywhere, even though it has no functionality.. ?!
Actually, don't bother.... Logically, since the heirarchy is Site - Domain - OU the domain policy would overwrite the Site policy anyway when it runs. The fact that the OU can't override the domain policy with regard to account policies makes no difference i don't think. I have a suspicion from my digging that it has something to do with the domain encryption keys at this point but haven't found anything concrete yet to back that up.
well... I had a pretty calm morning, so I had to go ahead and test it out.. heh! ;)
These are my findings:
1. Domain GP (Account Policy) - OU GP (A.P.) = Domain GP wins
2. Domain GP with A.P. set to 0 tries lockout threshold (never lock out) - OU GP (A.P.) = Domain GP wins
3. No Domain GP (A.P.) - OU GP (A.P.) = BUG!? The last set Domain GP wins.. lol!
With other words, the Account Policy GP settings are only effective on the Domain GP level, it doesn't matter at all if you try to apply A.P. settings on the OU level.
However, I found a bug, where if you completely disable/uncheck the A.P. settings on the Domain, it won't disable the A.P. ! It will use what ever the policy was set to last.. heh!!
Maaan what a mess those Account Policies are.. !
That's because the policy item is set in the registry of the client and thus if it isn't ovrwritten by another policy then it won't be changed.Quote:
It will use what ever the policy was set to last.. heh!!
Try adding a freshly installed machine to the domain when the domain policy no longer exists and see what happens.
Oh.. I see... well.. I would still consider that a bug though, other GP's do get disabled when you disable them. Not sure which are set in the registry or not though...Quote:
Originally posted here by Tiger Shark
That's because the policy item is set in the registry of the client and thus if it isn't ovrwritten by another policy then it won't be changed.
Do you happen to know where in the registry this is set? It would give me one more additional test, if I could go in to the registry and completely disable it on the Domain level...!
Thanks! :)
Hehe!! Good thought! ;)Quote:
Originally posted here by zENGER
Try adding a freshly installed machine to the domain when the domain policy no longer exists and see what happens.
Now that is time consuming though.. I probably won't have that time today...
Hmm... in best case, the Domain policy won't be there, but the OU policy still has no functionality... so I guess it won't really matter... unless an OU A.P. policy isn't getting written in the registry, and the registry is currently overriding the OU policy.. heh?
Let me try to predict the outcome:
1. Client: Clean install never joined to a domain. Domain has no particular policy set. OU has no particular policy set, (default policies at the local level, OU level and domain level are all the same IIRC). Client is joined to the domain:-
Result: Client maintains the default local policy as set at install, (though it has been set by the domain - if the domain policy was altered from the default this would have been reflected at the client).
2. Client: Clean install joined to a domain. Domain has no particular policy set. OU has policy changed to a custom policy, client policy refreshed:-
Result: Client maintains the default local policy as set at install, (Domain policy is still in effect).
3. Client: Clean install joined to a domain. Domain has custom policy, (different from OU), set. OU has policy maintains a custom policy, client policy refreshed:-
Result: Client adopts the custom domain policy.
However.... While looking to see _exactly_ why there can only be a single "Account Policy" in a domain I found, in the "time honored tradition" of Microsoft, this clearly contradictory information.... :rolleyes:
SourceQuote:
By default, Account Policies (Password, Lockout, and Kerberos settings) are all defined in the Default Domain GPO. Since Domain Controllers are responsible for enforcing these domain-wide policies, Domain Controllers always receive these settings from the Default Domain GPO. Furthermore, since Password and Lockout Policies are defined in the Default Domain GPO, all Windows 2000 machines in that domain obtain the same password and lockout policies for their local Security Accounts Manager (SAM) database even though they have their own default local account policies defined. This happens because domain-level policies have precedence over local policies. Note that it is possible to specify a different local password policy on workstations or servers by including those workstations or servers in an OU which has its own account policy settings. This is because an OU policy has precedence over a domain policy.
Which is the way it _should_ be.... But I thought we have ascertained that the domain account policy is not able to be overridden....
I also found this that might be important in the testing methodology:-
To demonstrate the contradictory nature of M$:-Quote:
Also, do not confuse domain accounts and local accounts. If a workstation is in a domain and a user logs on with a LOCAL account only, any domain user account configuration GPO settings are not processed because the account is local. Also, if you log on to a domain member that is disconnected from the network with a CACHED DOMAIN ID, you will not get your UPDATED user configuration settings. You will log on with the CACHED credentials ONLY.
SourceQuote:
When you set account policies (including password policies, account lockout policies, and Kerberos policies) in Active Directory, there can only be one domain account policy throughout all servers, workstations, and domain controllers in the domain. The policy is the account policy that is applied at the root domain of a domain tree. Although account policies affect user accounts, the policies are defined on computers.
Hmmm.... Technet doesn't agree with resources..... But it seems that in real life technet is more accurate... The answer to the question "Why?" is still unanswered.... and I still lean towards it being the kerberos settings which are unavailable in the local policy and I believe must be the same domain wide but no-one ever seems to have deemed fit to write about why to confirm or deny my theory.....
I remain "seeking enlightenment".... :D