Account lockout without locking out the domain 2

[bdoub1eu]

I need some clarification about this...

We currently have Two user OU's and One computer OU.

Users1
Users2
Computers

I applied an account lockout to the computer's OU since it is a computer based policy and it works. Problem is that since it is a computer based policy, I can't exclude the domain admins from getting their accounts logged out.

First question...Should I have applied the "default domain policy" to the entire domain for account lockout or is it okay to apply it to just the computers OU

Second question...How do I exclude the domain admin accounts from getting locked out too if it is a computer based policy...

Thanks!

 

[markdmac]

First off, don't mess with the default domain policy. The only settings you will want to put in there will be password related and they will apply to everyone.

Next, I'd suggest moving your admins and their computers into a separate OU just for them. You can then right click on that OU in AD Users and computer and choose to Block Policy Inheritance which will prevent the other user and computer policies from having an affect on them.

I hope you find this post helpful.

Regards,

Mark

 

[Koonan]

If you create a GPO and apply it to an OU, it will only affect the "Local" users on those servers and workstations, not the Domain Users. If you want this to work for Domain Users, you have to do it in the Default Domain Policy.

If you plan to use this feature, why would you exclude the Domain Admins, these are the accounts you want to protect this policy. There isn't a way to "exclude" someone from the Security Policy in the Default Domain Policy. Generally if a group of users need different Security Policy settings you have create a new domain for them, with a different Security Policy.

 

[bdoub1eu]

Koonan, you mention that if you create a GPO and apply it to an OU, then only the "local" users are affected???

Well, that's exactly what I did and users are logging into the domain, not locally. We tested this and accounts are being locked out after 3 attempts like the GPO we created stated...

 

[Koonan]

Check your Default Domain Policy, I'm sure someone set something there. I'm 100% sure on the Security Policy on OUs. It's also not possible to Block Inheritance on the Security Policy, that is part of the Default Domain Policy. Other parts of the Default Domain Policy can be blocked.

Also, did you ever make this Security setting in the Default Security Policy? If so then those settings have already been applied to your servers and workstations. Unchecking the box doesn't reset the setting on those clients that have already applied it.

 

[bdoub1eu]

Default Domain Policy is actually not being applied to authenticated users...Is that what you meant by "unchecking the box doesn't reset the setting on those clients?"

Just trying to figure out what's going on and how it's supposed to work.

If I make changes to the Computer configuration of a GPO, and apply that GPO to an OU of users, will the GPO be applied? or do you have to apply changes to the computer configuration to an OU of computers?

By default, is the domian default policy locking out accounts after a certain time or is that something you have to manually set?

 

[Koonan]

I did a little testing on a test virtual server I have. My last statement wasn't completely accurate. The Security section is kind of special. When it comes to GPOs at the domain level. I was told that the GPO at the Domain level with the highest prior was used to set your security settings. I did some testing and I found this not to be true. I'll have to do some more digging on this.

On your system, who does have Apply rights on the Default Domain Policy? I'll have to see what happens on my test server if I remove Authenticated Users. Are any of the lockout policies set in the Default Domain Policy?

 

[bdoub1eu]

On the default domain policy, the apply checkbox for authenticated users isn't checked so I assume it's not being applied...

 

[markdmac]

Again I will stress DO NOT MESS WITH THE DEFAULT DOMAIN POLICY.

You can create your own policy and link it at the same level as the Default Domain Policy, but you should not be editing that. Do a bit of searching on the Microsoft.com web site and you will find that Microsoft had to create a tool to recreate this policy because people hosed it up and messed up their AD.


Linking a policy to an OU will only affect the user object or computer objects contained within that OU or an OU underneath it in the AD Structure. I believe this is what was being referenced as "local users" in an earlier post. It has nothing to do with the users logging in to the domain vs locally on the PC.

Sounds like you have settings that you are unaware of their origin. You can use RSOP or GPRESULT to help you isolate this. But as I stated earlier you quick and easy fix is to move the admin IDs and Computer to their own OU and block policy inherritance.

I hope you find this post helpful.

Regards,

Mark

 

[Teknoratti]

Dont want to beat a dead horse but everyone is correct in saying dont muck with the Default Domain policy. If you want these settings on the Computers GPO then create the GPO on the computers, and make sure you block inheritance. That way you can set your policy from the computer gpo down, just remember that whatever gpo you set inside the computers gpo with take inheritance from the parent which is the computer gpo.

 

[bdoub1eu]

So is it fair to say that if I modify the computer settings of a group policy, I have to apply that policy to an OU that has computers? I can't apply computer settings group policies to a user can I?

Also, the default domain policy and default domain controller sercurity policy shortcuts in the administrative programs both modify the GPO at the domain level, right? So you're saying not to mess with this but just create a new policy at the domain level?

Thanks guys for your help!

 

[markdmac]

You are correct. You can not apply computer settings to a user.

Correct again, you can create a new policy at the domain level.

A few more tid-bits of info for you.

You can create a policy at the domain level. You can use One policy to set both user and computer restrictions so long as you place it high enough in the structure to affect al of the containers below it. Doing this at the domain level will do that for you. I would specifically add the domain admins group and a group for domain admin computers and apply the DENY attribute so the policy will not be applied to these users. I consider this a standard practice and you will find it documented in my FAQ faq329-6116 Optimizing Group Policies.

I hope you find this post helpful.

Regards,

Mark

 

[bdoub1eu]

Great info guys....Thanks!

 

[Koonan]

Good luck, I will state this one last time. There can only be one Domain Security Policy, and it must be in a GPO that is at the Domain level. If you create a Security Policy that is at the OU level, it will only apply to users that are local to those systems.

You also can’t use Block Inheritance on an OU to get around the Domain Security Policy. I just tried it by putting both the user and computer in an OU and blocked inheritance. Used GPresults to make sure there were no Policies applied. My Security Policy was still in effect. To my knowledge, but not 100% sure yet, the Security Policy is used by the DCs.

Again good luck with your configuration.

 

[Koonan]

Here's are really good article about the Security Policy. I was really close if not right on.

http://searchwin2000.techtarget.com/tip/1,289483,sid1_gci1108125,00.html

 

[bdoub1eu]

So you're saying that if I create a GP and place it at the domain level, I cannot create another OU and block inheritance on that domain level OU?

I was thinking about creating a domain level GP for account lockout and then creating another OU for domain admins their computers and blocking inheritance...Are you saying that wouldn't work?

Thanks again for your help!

 

[markdmac]

I was thinking about creating a domain level GP for account lockout and then creating another OU for domain admins their computers and blocking inheritance...Are you saying that wouldn't work?

No, that is not what is being said. That WILL work.

I hope you find this post helpful.

Regards,

Mark

 

[markdmac]

I was thinking about creating a domain level GP for account lockout and then creating another OU for domain admins their computers and blocking inheritance...Are you saying that wouldn't work?

No, that is not what is being said. That WILL work.

I hope you find this post helpful.

Regards,

Mark

 

[bdoub1eu]

Little confused...Isn't the Domain Security Policy (Start, Administrative Tools, Domain Security Policy) the same thing as the Default Domain Policy that is already at the domain level by default? The one that everybody has said not to use???

Also someone said there can only be one domain security policy...Could you not have a few GP's at the domain level that all applied to security? Sorry, I'm trying to understand...Koonan's answer got me a little confused...

He stated: You also can’t use Block Inheritance on an OU to get around the Domain Security Policy...

Sounded like if there is a GP at the domain level that applies to security, then you can't block inheritance on that.

Ok, I think this is confusing me...Is the domain security policy the same as the default domain policy that is there at the domain level by default?

 

[Koonan]

I feel like I keep repeating myself here. Did you read the article I posted, it explains it pretty well. I will clarify a few things.

1) Yes the Default Domain Policy can be blocked on OUs.
2) Will blocking the Default Domain Policy on a OU block the Domain Security Policy, No. Because the Domain Security Policy is applied to the DCs not to Users or their Workstation.
3) There can only be one Domain Security Policy, because it is applied to DCs and they can only have one.
4) Security settings in GPOs that apply to OUs will only affect Local Users on that server or workstation.

The article also explains what happens if you Block Inheritance on the Domain Controllers OU. Odd things can happen.