Default Domain Policy GPO

Hi Guys.

Im looking at sitting the 290 exam sometime next month but I am having troubles with making sense of the Default Domain Policy Group Policy Object (GPO).

Ok, I am aware that after a machine running Windows Server 2003 is promoted as a Domain Controller using DcPromo.exe, two default GPOs are added and linked to Active Directory, those being the "Default Domain Policy" and the "Default Domain Controllers Policy".

By default, I understand that the "Default Domain Controllers Policy" GPO only affects user rights and security with respect to the Domain Controllers located within the domain.

However, my problem is with the "Default Domain Policy" GPO. I should point out, that my testing environment is actually via Microsoft Virtual PC 2004.

Correct me if Im wrong, but after a fresh install of Server 2003 and an immediate promotion to a Domain Controller (i.e. no manual changes have been made), the "Default Domain Policy" GPO has the following characteristics:

- Account Policies
- Password Policy (components defined)
- Account Lockout Policy (components defined)
- Kerberos Policy (components defined)

- Local Policies
- Audit Policy (all components not defined)
- User Rights Assignment (all components not defined)
- Security Options (all components not defined)

When looking at these characteristics, its the fact that the local security policies have not been defined that seems strange to me. Here's why:

As we know, GPOs applied at the domain level (i.e. through Group Policy Object Editor on the Domain Controller) takes precedence over Local Security Policy.

So, lets for example consider the user right of "Backup files and directories" that is located on a member server called MembSrv1.

The default local security policy setting on MembSrv1 gives both Administrators and Backup Operators this right.

However, once the Default Domain Policy (which is linked to the entire domain) is applied, the security setting is replaced with "not defined" which in essence gives all users in the domain the right to backup files and folders located on MembSrv1.

This to me makes no sense. Effectively, the promotion of the Domain controller has made all the security settings on MembSrv1 (as seen by the above example) far less secure.

Of course, I realise that I could open up Group Policy Object editor and stop linking the Default Domain Policy GPO to the domain, but I am wanting to keep everything as default for exam study purposes.

So, in summary, is it true to say that by default, the Default Domain Policy GPO does not define any security settings under the local policies tree?

If so, why would this be the case. I can only guess it might be because the Default Domain Policy would apply to both Member servers and clients, which for obvious reasons would require different configurations.

Otherwise, I can only hope that my Virtual Server is corrupted and playing tricks on me.

Please help me out guys.

Mark

Find more posts tagged with

Comments

Mishra

Markie wrote:

Hi Guys.

Im looking at sitting the 290 exam sometime next month but I am having troubles with making sense of the Default Domain Policy Group Policy Object (GPO).

Ok, I am aware that after a machine running Windows Server 2003 is promoted as a Domain Controller using DcPromo.exe, two default GPOs are added and linked to Active Directory, those being the "Default Domain Policy" and the "Default Domain Controllers Policy".

By default, I understand that the "Default Domain Controllers Policy" GPO only affects user rights and security with respect to the Domain Controllers located within the domain.

However, my problem is with the "Default Domain Policy" GPO. I should point out, that my testing environment is actually via Microsoft Virtual PC 2004.

Correct me if Im wrong, but after a fresh install of Server 2003 and an immediate promotion to a Domain Controller (i.e. no manual changes have been made), the "Default Domain Policy" GPO has the following characteristics:

- Account Policies
- Password Policy (components defined)
- Account Lockout Policy (components defined)
- Kerberos Policy (components defined)

- Local Policies
- Audit Policy (all components not defined)
- User Rights Assignment (all components not defined)
- Security Options (all components not defined)

When looking at these characteristics, its the fact that the local security policies have not been defined that seems strange to me. Here's why:

As we know, GPOs applied at the domain level (i.e. through Group Policy Object Editor on the Domain Controller) takes precedence over Local Security Policy.

So, lets for example consider the user right of "Backup files and directories" that is located on a member server called MembSrv1.

The default local security policy setting on MembSrv1 gives both Administrators and Backup Operators this right.

However, once the Default Domain Policy (which is linked to the entire domain) is applied, the security setting is replaced with "not defined" which in essence gives all users in the domain the right to backup files and folders located on MembSrv1.

The 'backup files and directories' policy doesn't have a not defined option. You can set it to be blank.

This to me makes no sense. Effectively, the promotion of the Domain controller has made all the security settings on MembSrv1 (as seen by the above example) far less secure.

These options you are referring to are what I call 'static options'. They are completely defined by group policies and are not allowed to be edited under your local policy. This is because these settings are normally blanket settings for the entire domain. No matter what you don't want an administrator of a workstation getting into your password policy and changing it. Also policies defined in the default domain policy makes sure that any computer (server or workstation, no matter what GPO it is in) gets these security settings before they are allowed to work with domain resources. This is good security.

Of course, I realise that I could open up Group Policy Object editor and stop linking the Default Domain Policy GPO to the domain, but I am wanting to keep everything as default for exam study purposes.

You would actually create group policies or use the default domain policy to make sure these settings are defined throughout your domain.

So, in summary, is it true to say that by default, the Default Domain Policy GPO does not define any security settings under the local policies tree?

Yes, you need to manually set these settings. Group policy planning is a normal part of configuring a domain

If so, why would this be the case. I can only guess it might be because the Default Domain Policy would apply to both Member servers and clients, which for obvious reasons would require different configurations.

Again a lot of these settings are the same between clients and servers. Like your audit policy. If not, you can define these settings in individual GPOs that will take precedense over the default domain policy.

Otherwise, I can only hope that my Virtual Server is corrupted and playing tricks on me.

Please help me out guys.

Mark

Thanks for the well defined post.

Markie

Thanks for the reply.

But with regards to the "Back up files and directories" user right.

When I run gpedit.msc (or secpol.msc) on a member server, the security setting for this right says "Administrators, Backup operators".

But when I run rsop.msc, the security setting says "not defined". Would'nt that mean that now any user can perform backup operations (as opposed to just Administrators and Backup Operators)?

The rsop.msc is obviously reflecting the Default Domain Policy GPO.

My thanks in advance.

Mark

dynamik

No. A setting that is "not defined" does not allow (or restrict, depending on the setting) all users. It means just what it says, not defined. If it's not set there, it can inherit it from somewhere else, such as a site or OU. If no users or groups are specified anywhere, that setting won't apply to anyone.

Mishra

Markie wrote:

Thanks for the reply.

But with regards to the "Back up files and directories" user right.

When I run gpedit.msc (or secpol.msc) on a member server, the security setting for this right says "Administrators, Backup operators".

But when I run rsop.msc, the security setting says "not defined". Would'nt that mean that now any user can perform backup operations (as opposed to just Administrators and Backup Operators)?

The rsop.msc is obviously reflecting the Default Domain Policy GPO.

My thanks in advance.

Mark

The local policy of the machine still has the configurations of the local policies. If you run gpedit.msc and see ""Administrators, Backup operators" then thats the way it is configured. It doesn't show up in the RSOP because changes from group policy are not there because the defaults didn't change.

Again in group policy planning you need to make sure to define these policies in a GPO so administrators can't change them on their workstations.

Tontonsam

Sure. Local policies on client machines still has the configurations of local policies. But what you have to know, GPO apply in Domain site will override local policies on client machines. That why you have to apply GPO in Default domain policy or on an OU. For example, if a local policy for a machine user has to change their password 42 days that is the default and you configure a GPO to change it each 30 days. So, users will be asked to change their password every 30days cause GPO at level domain will override local policy.
But I dont understand your point of view of that: "Again in group policy planning you need to make sure to define these policies in a GPO so administrators can't change them on their workstations." Maybe you want to say admin won't need to change to their workstation?

Mishra

Tontonsam wrote:

But I dont understand your point of view of that: "Again in group policy planning you need to make sure to define these policies in a GPO so administrators can't change them on their workstations." Maybe you want to say admin won't need to change to their workstation?

When you are planning out your group policy infrastructure you want to make sure that you include all the "static" settings in your GPO configurations. For example, you don't want to leave 'Allow logon through Terminal Services" policy unchanged to those users in your environment who have administrator rights to their machine. Malicious users or viruses can go in and change these settings to open security holes in your environment. In most environments, it's best to go ahead and lock all these policies down through group policy.

undomiel

Don't forget how GPOs are applied as well. local->site->domain->OU. So as Mishra is saying if something is not defined in the site/domain/OU then it will filter through from the local machine and be applied. So any local machine administrators would be able to open up some of those undefined policies.

jbaello

Tontonsam wrote:

Sure. Local policies on client machines still has the configurations of local policies. But what you have to know, GPO apply in Domain site will override local policies on client machines. That why you have to apply GPO in Default domain policy or on an OU. For example, if a local policy for a machine user has to change their password 42 days that is the default and you configure a GPO to change it each 30 days. So, users will be asked to change their password every 30days cause GPO at level domain will override local policy.
But I dont understand your point of view of that: "Again in group policy planning you need to make sure to define these policies in a GPO so administrators can't change them on their workstations." Maybe you want to say admin won't need to change to their workstation?

Just follow this simple "mnemonic" as they say:

"LSDOU" Local | Site | Domain | Organizational Unit - Local will always be superseded by the proceeding GPO application and so on, regardless if GPO has been explicitlly modified, but ofcourse you also want to keep in mind of this two:

No Override - This prevents child containers from overriding policies set at higher levels
Block Inheritance - Stops containers inheriting policies from parent containers

No Override takes precedence over Block Inheritance so if a child container has Block Inheritance set but on the parent a group policy has No Override set then it will get applied.

Also the highest No Override takes precedence over lower No Override's set.

http://windowsitpro.com/article/articleid/15420/how-does-the-group-policy-no-override-and-block-inheritance-work.html

Tontonsam

According to LSDOU, is that mean if I apply a GPO to change password every 30 days, a local administrator can modify local policy to apply it in 40 days and so bypass the GPO? If yes, how can I force this GPO apply at the domain level regardless of the local policies? I misunderstand.

royal

Domain passwords can only be modified using the Default Domain Policy or another GPO in the root Domain Container. A password policy applied anywhere else such as OU or local will only apply to local accounts.

jbaello

royal wrote:

Domain passwords can only be modified using the Default Domain Policy or another GPO in the root Domain Container. A password policy applied anywhere else such as OU or local will only apply to local accounts.

I got a little confused with password policy applied to OU will only apply to local accounts, do you mind clarifying

Tontonsam

Give me an example how local policy will take precedence of GPO. For example, if i create a GPO to block internet users by modifying proxy settings, can a local administrator modify local policy and prevent GPO applying on that computer?

dynamik

jbaello wrote:

royal wrote:

Domain passwords can only be modified using the Default Domain Policy or another GPO in the root Domain Container. A password policy applied anywhere else such as OU or local will only apply to local accounts.

I got a little confused with password policy applied to OU will only apply to local accounts, do you mind clarifying

You have to set the password policy for domain users at the domain level. If you do it somewhere else, say an OU, it will only apply to local accounts, not domain accounts.

Tontonsam wrote:

Give me an example how local policy will take precedence of GPO. For example, if i create a GPO to block internet users by modifying proxy settings, can a local administrator modify local policy and prevent GPO applying on that computer?

No, because the local policy is applied first, and if there are conflicting policies from somewhere else, they will override it.

Check out group policy precedence: http://technet.microsoft.com/en-us/library/cc785665.aspx

Although, I believe you can get a local policy to take precedence with loopback processing. This thread makes me look kind of dumb, but it might be interesting: http://techexams.net/forums/viewtopic.php?t=29163

undomiel

I like the diagrams and description here http://windows.stanford.edu/docs/gpoorder.htm for how loopback processing works.

Markie

Ok Guys, thanks for the input but if I can just direct the conversation back to the original subject matter for a moment.

It seems my initial interpretation of the Resultant Set Of Policy (RSOP.msc) tool was incorrect. By the name, one might think that the RSOP tool would actually summarize all of the security settings that are in place (once all the relevant local and Active Directory GPOs have been applied).

However, it seems this is not quite the case, as quoted from Windows Xp help and support:

"RSoP is a query engine that polls existing policies, and then reports the results of the query. It polls existing policies based on site, domain, domain controller, and organizational unit".

The important distinction here is that RSOP does not capture those policies that have been applied at the local level (i.e. LGPOs).

This distinction now explains my initial confusion over all those "not defined" computer settings found in the 'user rights assignement' tree found in RSOP for a member server (or a client workstation for that matter).

"Not Defined" just means that no GPOs based on Site, Domain or OU have been applied. However, the security settings that have been defined within Local Security Policy (i.e. by running gpedit.msc on the member server) are still in effect. Therefore, when running RSOP.msc on a member server, the "not defined" security setting relating to the "Backup files and directories"user right just means that this policy has only been defined in Local Security Policy (which is set to 'Administrators and Backup Operators by default).

Maybe for the above reason, they should have called the tool the "Resultant Set Of Non-Local Group Policy".

I suppose the main reason for keeping the LGPOs out of RSOP is so that it would be easier for a local administrator to quickly locate the overriding group policies that have been applied at the Site, Domain or OU levels.

On the other hand, for a local administrator to fully understand what policies are in place and where they originate from, they would have to run both Gpedit.msc and Rsop.msc.

But please, if anyone finds any faults in what I have said, please post back.

Two more quick points.

Firstly, the main reason why I posted this topic was because I noticed that any user (as opposed to just the default Administrators and Backup Operators groups) on a member server (within my Virtual PC 2004 environment) can run the NTbackup utility and in turn back up files. Based, on all I have mentioned above, I cant work out why this is so. As mentioned above, when I run Gpedit.msc on the member server, the security setting for "Backup files and directories" is set to Administrators and Backup Operators only. When I run, RSOP.msc on the member server, the computer setting for this user right is set to "not defined" (thus meaning that no remotely applied GPOs are affecting this policy). Any suggestions?

Secondly, I have seen a lot of literature stating that GPOs are applied in the following order (from first to last).

-Local Security Policy (LGPO)
-Site Policy
-Domain Policy
-Domain Controllers Policy
-OU Policy

Would'nt it actually be better to state it as follows:

For Non Domain Controllers:

-LGPO
-Site Policy
-Domain Policy
-OU Policy

For Domain Controllers:

-Site Policy (note, you cant configure LGPOs on DCs)
-Domain Policy
-Domain Controllers Policy (Domain Controllers is an OU in its own right)

I suppose, you could technically break down the Domain Controllers OU into child OUs (such as maybe the PDC OU and the Secondary DCs OU (meaning child OU GPOs could be applied as well).

I guess what Im asking is, dont GPOs (such as the Default Domain Controllers Policy) linked to the Domain Controllers OU only affect Domain Controllers (by default).

Wow, is this a long post or what?

Sorry guys.

Mark

dynamik

Which files did you backup as a regular user? I believe users are allowed to backup their own files without having to have any additional privileges. Try backing up another user's files.

Also, I don't think you have to differentiate between DCs and non-DCs in terms of precedence. By default, Domain Controllers are placed in the Domain Controllers OU and has the Default Domain Controllers Policy GPO linked to it. You can see this if you go to ADUC > Domain Controllers OU > right click > properties > Group Policy tab. I'd think of it as any other OU.

Markie

Thanks Dynamik.

You were right. I didnt realise that when I was running NTbackup, I was only backing up the user's 'My Documents' folder. As we know, any user has full access to the files and folders within their own profile.

Oh well, at least I have improved my knowledge on Group Policy, whilst trying to troubleshoot the problem.

Yeah, and with regards to the "Default Domain Controllers Policy", I totally agree that it really should just be thought of as just an OU and therefore the usual precedence of:

-Local Security Policy (LGPO)
-Site Policy
-Domain Policy
-OU Policy

still applies to all objects in Active Directory (including Domain Controllers).

Its just that as I said, a lot of literature includes this default GPO as part of the precedence list (between Domain Policy and OU POlicy). I think this makes things confusing, especially for the uninitiated. Some people might think (as I did initially) that this GPO has a bearing on the entire domain but this is simply not true. As this GPO is only linked to the 'Domain Controllers' OU, only those objects located in this OU (which is just the DCs by default) would be affected by this GPO.

I still think that the RSOP.msc tool would be improved if it included the LGPOs as well.

Anway, thanks for everyone's comments.

Mark