Exchange OWA 2003 Trusted Root Certificate

[Guest]

I am looking to attach a certificate to a GPO, under the Trusted Root
Certificates so that specific users on the network who access the Secure
(https) Outlook Web Agent 2003, will already have the certifiacte installed,
and not have to answer yes to a certificate question each time the browser
access the website on the exchange server.

My attempt has been this, accessed the server and installed the certificate,
then I exported the certificate as p7b...I then could mannually go to other
machines and import the certificate, but do not want to do that over the
enterprise.

I created a GPO based on this link
"http://www.microsoft.com/windows2000/techinfo/planning/security/catruststeps.asp#heading2"
I applied the policy only to my test user that I created, yet the
certificate is never installed as I would have expected it. I suspect that I
have missed something, but can't put my finger on it.

Any ideas?
J

 

[Steven L Umbach]

That policy is "computer configuration". You will have to have that policy
apply to a computer that the user logs onto. For instance if you configured
that Group Policy at the OU level, the computer account will need to be in
that OU. --- Steve

 

[Guest]

Thanks, so barring adding each computer to the policy where I think a user
might log into, would this work: Adding the Computers to the Groups in which
the policy is applied to. So that an OU called "Shipping Department" has a
group assigned to it called "Shipping". Members of the Shipping group are
user1 and user2. A policy is created with Permissions to apply a Trusted
Root Certificate to the Shipping Group, which would install the certificate I
want but only for those particular users. Am I correct in saying that I
should just add the computers that are physically located in the Shipping
Department to the group Shipping, so that all Computer Policies are applied
to the machine?

I kind of thought that the computer policies would apply to the computer
that a particular user logged into, not the a specific computer? Can we
verify this? That link that I included for accomplishing these steps, said
nothing about adding specific users, in fact it was a Default Domain Policy?

Thanks

 

[Paul Adare]

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Thanks, so barring adding each computer to the policy where I think a user
might log into, would this work: Adding the Computers to the Groups in which
the policy is applied to.

Group Policy I s not applied to groups, you have a fundamental
misunderstanding on how Group Policy works.

So that an OU called "Shipping Department" has a
group assigned to it called "Shipping". Members of the Shipping group are
user1 and user2. A policy is created with Permissions to apply a Trusted
Root Certificate to the Shipping Group,

As above, this isn't the way Group Policy works.

which would install the certificate I
want but only for those particular users. Am I correct in saying that I
should just add the computers that are physically located in the Shipping
Department to the group Shipping, so that all Computer Policies are applied
to the machine?

The GPOs that are applied to a user or computer have nothing to do with
the group membership of that user or computer (except that you can
control whether or not a GPO can be processed through the use of ACLs on
the GPOs). The location of the user or computer account in the directory
determines which GPOs will be processed.

I kind of thought that the computer policies would apply to the computer
that a particular user logged into, not the a specific computer? Can we
verify this? That link that I included for accomplishing these steps, said
nothing about adding specific users, in fact it was a Default Domain Policy?

The Default Domain Policy, being at the highest level in the domain
tree, will be processed by all users and computers in the domain.

In your case, you need to examine the OUs that contain the computer
accounts of the computers that these users will be using, and then use a
GPO that is high enough in the domain tree to be processed by these
computers.

You should read up on Group Policy. There is a lot of good information
on how this works on the Microsoft web site.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Steven L Umbach]

It is computer configuration which means that the policy is non user
specific and will apply to all users that logon to that computer. You can
not filter computer configuration policy be user but you could for specific
computers or a global group that computers are a member of. I can't think of
a work around offhand to have it work for specific users. --- Steve

 

[Guest]

If you create a Policy the permissions to Read and Apply that policy may
typically be the Authenticated Users Group. However, if you modify the
policy and add the disired groups to that policy to apply the policy to that
specific group instead of the global Authenticated Users group, and either
apply the policy to the GPO that specific users are a member of, or apply it
to a default domain policy, then only the groups or members that are listed
on the permissions tab will have the policy applied to them.

In my example, the OU "Shipping Department" has in the container the Group
"Shipping" and User1 and User2. User1 and User2 are also members of the
Group "Shipping". If I create a GPO and apply it to the OU, the default
setting will be for Authenticated Users to Read and Apply. But suppose that
I only want to apply the policy to User2, perhaps it is a very custom setup
of there envioronment, etc etc. I can remove the Authenticated Users from
the Permissions Tab, and add only User2 for Apply. Thereby skipping any
policy application on User1. Or, if I specifically want a group, so that no
matter who gets added to the group, all objects in that group can have the
policy applied to them. This would be particularly useful when placing a GPO
on the Domain Level for specific groups to be applied to (but not all
Authenticated Users) and thereby reduce the need to link each OU with the
GPO, you can do it from one place, but have it only apply to those groups
containing those users and/or computers that you have assigned to it.

"You put things you want to control in an OU. Then you grant control to a
group." -MArk Minasi. Basically assigning permissions for folders, shares
etc etc including applying a GPO (hence the name GROUP Policy Object). You
can not assign an OU Permissions, but you can control the members and groups
of that OU with a Policy.

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Thanks, so barring adding each computer to the policy where I think a user
might log into, would this work: Adding the Computers to the Groups in which
the policy is applied to.

Group Policy I s not applied to groups, you have a fundamental
misunderstanding on how Group Policy works.

So that an OU called "Shipping Department" has a
group assigned to it called "Shipping". Members of the Shipping group are
user1 and user2. A policy is created with Permissions to apply a Trusted
Root Certificate to the Shipping Group,

As above, this isn't the way Group Policy works.

which would install the certificate I
want but only for those particular users. Am I correct in saying that I
should just add the computers that are physically located in the Shipping
Department to the group Shipping, so that all Computer Policies are applied
to the machine?

The GPOs that are applied to a user or computer have nothing to do with
the group membership of that user or computer (except that you can
control whether or not a GPO can be processed through the use of ACLs on
the GPOs). The location of the user or computer account in the directory
determines which GPOs will be processed.

I kind of thought that the computer policies would apply to the computer
that a particular user logged into, not the a specific computer? Can we
verify this? That link that I included for accomplishing these steps, said
nothing about adding specific users, in fact it was a Default Domain Policy?

The Default Domain Policy, being at the highest level in the domain
tree, will be processed by all users and computers in the domain.

In your case, you need to examine the OUs that contain the computer
accounts of the computers that these users will be using, and then use a
GPO that is high enough in the domain tree to be processed by these
computers.

You should read up on Group Policy. There is a lot of good information
on how this works on the Microsoft web site.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Paul Adare]

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=
<[email protected]> says...

So you're going to explain to me how Group Policy works now? Ok.

Let's start with getting some basic terminology sorted out:

If you create a Policy

You never create a Policy, you create a Group Policy Object, and that
GPO will contain various settings.

the permissions to Read and Apply that policy may
typically be the Authenticated Users Group.

The default DACL on a GPO do in fact include Authenticated Users with
Read and Apply, correct.

However, if you modify the
policy and add the disired groups to that policy to apply the policy to that
specific group instead of the global Authenticated Users group, and either
apply the policy to the GPO that specific users are a member of,

One cannot be a member of a GPO.

or apply it
to a default domain policy, then only the groups or members that are listed
on the permissions tab will have the policy applied to them.

Correct, assuming of course the the GPO is linked somewhere that the
user or computer will even be able to process it in the first place.

For example, if you have OUA and OUB, both at the same level in the
domain, and you have userB in OUB. You create a GPO and set the
permissions on the GPO such that userB has Read and Apply permissions,
it won't matter how often you log on with the userB account, nor what
the permissions are on the GPO, userB will never process the GPO. Taking
this one step further, you create a group in OUA and make userB a member
of that group, and change the permissions on the GPO linked to OUA such
that the group in OUA that has userB as a member has Read and Apply
permission, that GPO will _still never_ be processed by userB.

In my example, the OU "Shipping Department" has in the container the Group
"Shipping" and User1 and User2. User1 and User2 are also members of the
Group "Shipping". If I create a GPO and apply it to the OU, the default
setting will be for Authenticated Users to Read and Apply. But suppose that
I only want to apply the policy to User2, perhaps it is a very custom setup
of there envioronment, etc etc. I can remove the Authenticated Users from
the Permissions Tab, and add only User2 for Apply. Thereby skipping any
policy application on User1. Or, if I specifically want a group, so that no
matter who gets added to the group, all objects in that group can have the
policy applied to them. This would be particularly useful when placing a GPO
on the Domain Level for specific groups to be applied to (but not all
Authenticated Users) and thereby reduce the need to link each OU with the
GPO, you can do it from one place, but have it only apply to those groups
containing those users and/or computers that you have assigned to it.

Once again, you do not assign a GPO to a group. You can certainly use
the DACLs on a GPO to filter which users and computers the GPO will be
processed by, but only if that GPO is linked in the directory in a
location that the user or computer account would process the GPO in the
first place.

"You put things you want to control in an OU. Then you grant control to a
group." -MArk Minasi. Basically assigning permissions for folders, shares
etc etc including applying a GPO (hence the name GROUP Policy Object). You
can not assign an OU Permissions, but you can control the members and groups
of that OU with a Policy.

Sorry sport, but the Group part of Group Policy has nothing to do with
groups that contain user or computer accounts. Its name arises from the
fact that you can GROUP policy settings into objects known as Group
Policy Objects.

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Thanks, so barring adding each computer to the policy where I think a user
might log into, would this work: Adding the Computers to the Groups in which
the policy is applied to.

Group Policy I s not applied to groups, you have a fundamental
misunderstanding on how Group Policy works.

So that an OU called "Shipping Department" has a
group assigned to it called "Shipping". Members of the Shipping group are
user1 and user2. A policy is created with Permissions to apply a Trusted
Root Certificate to the Shipping Group,

As above, this isn't the way Group Policy works.

which would install the certificate I
want but only for those particular users. Am I correct in saying that I
should just add the computers that are physically located in the Shipping
Department to the group Shipping, so that all Computer Policies are applied
to the machine?

The GPOs that are applied to a user or computer have nothing to do with
the group membership of that user or computer (except that you can
control whether or not a GPO can be processed through the use of ACLs on
the GPOs). The location of the user or computer account in the directory
determines which GPOs will be processed.

I kind of thought that the computer policies would apply to the computer
that a particular user logged into, not the a specific computer? Can we
verify this? That link that I included for accomplishing these steps, said
nothing about adding specific users, in fact it was a Default Domain Policy?

The Default Domain Policy, being at the highest level in the domain
tree, will be processed by all users and computers in the domain.

In your case, you need to examine the OUs that contain the computer
accounts of the computers that these users will be using, and then use a
GPO that is high enough in the domain tree to be processed by these
computers.

You should read up on Group Policy. There is a lot of good information
on how this works on the Microsoft web site.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Paul Adare]

microsoft.public.win2000.security news group, Paul Adare

For example, if you have OUA and OUB, both at the same level in the
domain, and you have userB in OUB. You create a GPO,**link it to OUA** and set the
permissions on the GPO such that userB has Read and Apply permissions,
it won't matter how often you log on with the userB account, nor what
the permissions are on the GPO, userB will never process the GPO. Taking
this one step further, you create a group in OUA and make userB a member
of that group, and change the permissions on the GPO linked to OUA such
that the group in OUA that has userB as a member has Read and Apply
permission, that GPO will _still never_ be processed by userB.

Sorry, missed a bit. See the ** ** for the addition.
--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Guest]

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=
<[email protected]> says...

So you're going to explain to me how Group Policy works now? Ok.

Listen I am not trying to pick a fight here.

Let's start with getting some basic terminology sorted out:


You never create a Policy, you create a Group Policy Object, and that
GPO will contain various settings.

When I say Policy, I mean it in a broad sense, I am referring to the GPO,
which as you admitted defaults to "apply" to the Authenticated Users. Based
on what I am seeing, you can perform Filtering by removing the Authenticated
Users from the list, and assign a specific "group" that you would like to
apply the "policy" (GPO containing the set of templates in which settings
have been made) to.

The default DACL on a GPO do in fact include Authenticated Users with
Read and Apply, correct.


One cannot be a member of a GPO.

When I say add a desired group to a GPO, the above was what I was referring
to, I think if you attempt to read to much into the terminology, you miss the
basics of what I am asking, that was why I posted the question in the first
place. Realizing of course that if I add a group, users whatever to the
Security of the GPO to APPLY (better verbiage?), then in any place that I
apply that GPO to an OU, then the groups and users will specifically get the
"settings" contained in that GPO (or as I like to say the policy). A good
example, might be to publish the Active Directory Admin Tools to your admins,
you create a Domain Policy (GPO) and then remove the Authenticated Users, but
add only your Admins to apply the policy to, so that the Published Software
is installed.

Correct, assuming of course the the GPO is linked somewhere that the
user or computer will even be able to process it in the first place.

For example, if you have OUA and OUB, both at the same level in the
domain, and you have userB in OUB. You create a GPO and set the
permissions on the GPO such that userB has Read and Apply permissions,
it won't matter how often you log on with the userB account, nor what
the permissions are on the GPO, userB will never process the GPO. Taking

So is the GPO just created on the Group Policy tab of the OUB? If it is, I
would disagree that it would not work. A good example of this might be a
custom desktop picture. Globally for the domain you lock down any changes to
the display, and background. But on an OU level you create a GPO called
"userB" make userB the only user that the GPO is Applied to. In the Desktop,
you define a custom desktop picture, and path. I do this now, who gets the
picture? Only userB, even though in the OU there are lots of other users. So
I must be mis-understanding what you are saying above.

this one step further, you create a group in OUA and make userB a member
of that group, and change the permissions on the GPO linked to OUA such
that the group in OUA that has userB as a member has Read and Apply
permission, that GPO will _still never_ be processed by userB.

I understand what you are saying here, since a user can only be a member of
1 OU, the GPO can only be applied to that OU in which the user would be a
member of. BUT, in my model I am not creating Groups that spread across
OU's. In OUA, I would have a GROUP called OUAUsers in which I would add all
of the users in that OU to that group, that I would want applied. In OUB, I
have another group called OUBUsers with all of those users from that OU in
it. I create a GPO that has both of those Groups as part of the Apply rather
than the Authenticated Users by default, I also Deny the GPO to the Domain
Admins and Enterprise Admins for Apply but leave the read write change the
same. I apply the GPO to both OUs (OUA and OUB) Now suppose I want to add a
user to OUA, but not have that GPO apply to them. Poof, already done, even
though they are a member of that OU, I bypass them in the application of the
GPO, because I did not make them a member of the OUAUsers or OUBUsers to whom
the GPO is being applied. An example might be someone who is part of that
OU, who has Admin rights whereby you might not want to lock them down, but
keep them part of that OU for organizational reasons.

Once again, you do not assign a GPO to a group. You can certainly use
the DACLs on a GPO to filter which users and computers the GPO will be
processed by, but only if that GPO is linked in the directory in a
location that the user or computer account would process the GPO in the
first place.

Don't get caught up on semantics...I think you understood what I was
attempting to say. Filter is the correct word, you are right.

Sorry sport, but the Group part of Group Policy has nothing to do with
groups that contain user or computer accounts. Its name arises from the
fact that you can GROUP policy settings into objects known as Group
Policy Objects.

By the way, you never answered my original question, rather you attacked how
YOU might have done something or how you thought it should have been done.

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=
<[email protected]> says...

Thanks, so barring adding each computer to the policy where I think a user
might log into, would this work: Adding the Computers to the Groups in which
the policy is applied to.

Group Policy I s not applied to groups, you have a fundamental
misunderstanding on how Group Policy works.

So that an OU called "Shipping Department" has a
group assigned to it called "Shipping". Members of the Shipping group are
user1 and user2. A policy is created with Permissions to apply a Trusted
Root Certificate to the Shipping Group,

As above, this isn't the way Group Policy works.

which would install the certificate I
want but only for those particular users. Am I correct in saying that I
should just add the computers that are physically located in the Shipping
Department to the group Shipping, so that all Computer Policies are applied
to the machine?

The GPOs that are applied to a user or computer have nothing to do with
the group membership of that user or computer (except that you can
control whether or not a GPO can be processed through the use of ACLs on
the GPOs). The location of the user or computer account in the directory
determines which GPOs will be processed.

I kind of thought that the computer policies would apply to the computer
that a particular user logged into, not the a specific computer? Can we
verify this? That link that I included for accomplishing these steps, said
nothing about adding specific users, in fact it was a Default Domain Policy?

The Default Domain Policy, being at the highest level in the domain
tree, will be processed by all users and computers in the domain.

In your case, you need to examine the OUs that contain the computer
accounts of the computers that these users will be using, and then use a
GPO that is high enough in the domain tree to be processed by these
computers.

You should read up on Group Policy. There is a lot of good information
on how this works on the Microsoft web site.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Guest]

So Steve - back to my original question, since my model is small, it is my
understanding that I can "filter" a particular GPO from the Domain Level to
apply only to specific user groups that I have created. (I base that
statement on Chapter 4 - How Group Policy Works in the Windows 2000 Server
doc, on the Technet CD.)

"Administrators can overcome this problem by organizing users and computers
into security groups, and then using these groups to filter the impact of
Group Policy.

The IT department can create groups based on the tasks that their users
perform, the degree of authority users have to modify their own or other
computers, and the configurations that users need to have. For example, the
IT department could accomplish their goal by creating a security group just
for vice presidents. This can greatly simplify the process of administering
users with disparate configuration and permission requirements. Therefore, in
Figure 4.4, the vice presidents' security group might prevent the domain
level GPO (GPO 2) from applying to vice presidents in the Headquarters and
Marketing OUs. "

Based on that, if were to create a domain GPO, and filter based 3 specific
groups to apply, and if in those groups I assigned the computers that were
part of each group...would the Computer Configuration be pushed to the
machines, based on the imported Root Certificate?

Thanks
J

 

[Paul Adare]

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

By the way, you never answered my original question, rather you attacked how
YOU might have done something or how you thought it should have been done.

I didn't attack anything, you're still missing some fundamentals on how
Group Policy works. For example, setting in the computer configuration
section of a GPO are not processed when a user account processes a GPO
and settings in the user configuration section are not processed when a
computer account processes a GPO.

I strongly suggest that you do some reading up on Group Policy.

Have fun.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Paul Adare]

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Based on that, if were to create a domain GPO, and filter based 3 specific
groups to apply, and if in those groups I assigned the computers that were
part of each group...would the Computer Configuration be pushed to the
machines, based on the imported Root Certificate?

Yes.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Guest]

Not based on this - "The Authenticated Users group includes both users and
computers. " See below. I think I have a pretty good working knowledge of
how this should work, I admit, I don't know it all...but I do know that if a
GPO is created, and the default setting for security and applying that
security is Authenticated Users, then this will in fact apply to the computer.

Give me some credit...

"Security Filtering
Security filtering is a way of refining which users and computers will
receive and apply the settings in a GPO. Using security filtering, you can
narrow the scope of a GPO so that it applies only to a single group, user, or
computer by specifying that only certain security principals within a
container where the GPO is linked apply the GPO. Security filtering
determines whether the GPO as a whole applies to groups, users, or computers;
it cannot be used selectively on different settings within a GPO.

In order for the GPO to apply to a given user or computer, that user or
computer must have both Read and Apply Group Policy (AGP) permissions on the
GPO, either explicitly, or effectively though group membership.

By default, all GPOs have Read and AGP both Allowed for the Authenticated
Users group. The Authenticated Users group includes both users and computers.
This is how all authenticated users receive the settings of a new GPO when it
is applied to an organizational unit, domain or site. Therefore, the default
behavior is for every GPO to apply to every Authenticated User. By default,
Domain Admins, Enterprise Admins, and the local system have full control
permissions, without the Apply Group Policy ACE. However, administrators are
members of Authenticated Users, which means that they will receive the
settings in the GPO by default. "

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

By the way, you never answered my original question, rather you attacked how
YOU might have done something or how you thought it should have been done.

I didn't attack anything, you're still missing some fundamentals on how
Group Policy works. For example, setting in the computer configuration
section of a GPO are not processed when a user account processes a GPO
and settings in the user configuration section are not processed when a
computer account processes a GPO.

I strongly suggest that you do some reading up on Group Policy.

Have fun.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Paul Adare]

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Not based on this - "The Authenticated Users group includes both users and
computers. " See below. I think I have a pretty good working knowledge of
how this should work, I admit, I don't know it all...but I do know that if a
GPO is created, and the default setting for security and applying that
security is Authenticated Users, then this will in fact apply to the computer.

Give me some credit...

You don't deserve any as you clearly don't understand how this process
works. Why do you think that there is a Computer Configuration and a
User Configuration section in a GPO?

A user account will never apply the settings in the Computer
Configuration portion of a GPO. A computer account may process the User
Configuration portion of a GPO, but only when loopback processing is
enabled.

Security filtering on determines which GPOs will be processed, not the
sections in the GPO that will be processed.

You really should try to understand this before posting, you're only
digging yourself a deeper hole here.

"Security Filtering
Security filtering is a way of refining which users and computers will
receive and apply the settings in a GPO. Using security filtering, you can
narrow the scope of a GPO so that it applies only to a single group, user, or
computer by specifying that only certain security principals within a
container where the GPO is linked apply the GPO. Security filtering
determines whether the GPO as a whole applies to groups, users, or computers;
it cannot be used selectively on different settings within a GPO.

In order for the GPO to apply to a given user or computer, that user or
computer must have both Read and Apply Group Policy (AGP) permissions on the
GPO, either explicitly, or effectively though group membership.

By default, all GPOs have Read and AGP both Allowed for the Authenticated
Users group. The Authenticated Users group includes both users and computers.
This is how all authenticated users receive the settings of a new GPO when it
is applied to an organizational unit, domain or site. Therefore, the default
behavior is for every GPO to apply to every Authenticated User. By default,
Domain Admins, Enterprise Admins, and the local system have full control
permissions, without the Apply Group Policy ACE. However, administrators are
members of Authenticated Users, which means that they will receive the
settings in the GPO by default. "

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

By the way, you never answered my original question, rather you attacked how
YOU might have done something or how you thought it should have been done.

I didn't attack anything, you're still missing some fundamentals on how
Group Policy works. For example, setting in the computer configuration
section of a GPO are not processed when a user account processes a GPO
and settings in the user configuration section are not processed when a
computer account processes a GPO.

I strongly suggest that you do some reading up on Group Policy.

Have fun.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Guest]

Basically, because one is a set of configurations changes that take place at
the HKLM level, where as the other take place at the HKCU.

Since Computers are part of the Authenticated Users, which is default, the
application to the machine (HKLM) is transparent. That is why just because
the Domain Admin by default does not have the apply setting as part of the
Security of the GPO, they are part of the Authenticated Users and will have
the policy applied.

Let me ask you, how would apply the computer settings that are part of a GPO?

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Not based on this - "The Authenticated Users group includes both users and
computers. " See below. I think I have a pretty good working knowledge of
how this should work, I admit, I don't know it all...but I do know that if a
GPO is created, and the default setting for security and applying that
security is Authenticated Users, then this will in fact apply to the computer.

Give me some credit...

You don't deserve any as you clearly don't understand how this process
works. Why do you think that there is a Computer Configuration and a
User Configuration section in a GPO?

A user account will never apply the settings in the Computer
Configuration portion of a GPO. A computer account may process the User
Configuration portion of a GPO, but only when loopback processing is
enabled.

Security filtering on determines which GPOs will be processed, not the
sections in the GPO that will be processed.

You really should try to understand this before posting, you're only
digging yourself a deeper hole here.

"Security Filtering
Security filtering is a way of refining which users and computers will
receive and apply the settings in a GPO. Using security filtering, you can
narrow the scope of a GPO so that it applies only to a single group, user, or
computer by specifying that only certain security principals within a
container where the GPO is linked apply the GPO. Security filtering
determines whether the GPO as a whole applies to groups, users, or computers;
it cannot be used selectively on different settings within a GPO.

In order for the GPO to apply to a given user or computer, that user or
computer must have both Read and Apply Group Policy (AGP) permissions on the
GPO, either explicitly, or effectively though group membership.

By default, all GPOs have Read and AGP both Allowed for the Authenticated
Users group. The Authenticated Users group includes both users and computers.
This is how all authenticated users receive the settings of a new GPO when it
is applied to an organizational unit, domain or site. Therefore, the default
behavior is for every GPO to apply to every Authenticated User. By default,
Domain Admins, Enterprise Admins, and the local system have full control
permissions, without the Apply Group Policy ACE. However, administrators are
members of Authenticated Users, which means that they will receive the
settings in the GPO by default. "

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=
<[email protected]> says...

By the way, you never answered my original question, rather you attacked how
YOU might have done something or how you thought it should have been done.


I didn't attack anything, you're still missing some fundamentals on how
Group Policy works. For example, setting in the computer configuration
section of a GPO are not processed when a user account processes a GPO
and settings in the user configuration section are not processed when a
computer account processes a GPO.

I strongly suggest that you do some reading up on Group Policy.

Have fun.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Guest]

You know what forget it, I figured out what I need to do...I have it working.
And for future reference, why not offer solutions rather than attack
someone's understanding of how something works. I think I had everything in
place and just missed one step...

See ya

Basically, because one is a set of configurations changes that take place at
the HKLM level, where as the other take place at the HKCU.

Since Computers are part of the Authenticated Users, which is default, the
application to the machine (HKLM) is transparent. That is why just because
the Domain Admin by default does not have the apply setting as part of the
Security of the GPO, they are part of the Authenticated Users and will have
the policy applied.

Let me ask you, how would apply the computer settings that are part of a GPO?

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Not based on this - "The Authenticated Users group includes both users and
computers. " See below. I think I have a pretty good working knowledge of
how this should work, I admit, I don't know it all...but I do know that if a
GPO is created, and the default setting for security and applying that
security is Authenticated Users, then this will in fact apply to the computer.

Give me some credit...

You don't deserve any as you clearly don't understand how this process
works. Why do you think that there is a Computer Configuration and a
User Configuration section in a GPO?

A user account will never apply the settings in the Computer
Configuration portion of a GPO. A computer account may process the User
Configuration portion of a GPO, but only when loopback processing is
enabled.

Security filtering on determines which GPOs will be processed, not the
sections in the GPO that will be processed.

You really should try to understand this before posting, you're only
digging yourself a deeper hole here.

"Security Filtering
Security filtering is a way of refining which users and computers will
receive and apply the settings in a GPO. Using security filtering, you can
narrow the scope of a GPO so that it applies only to a single group, user, or
computer by specifying that only certain security principals within a
container where the GPO is linked apply the GPO. Security filtering
determines whether the GPO as a whole applies to groups, users, or computers;
it cannot be used selectively on different settings within a GPO.

In order for the GPO to apply to a given user or computer, that user or
computer must have both Read and Apply Group Policy (AGP) permissions on the
GPO, either explicitly, or effectively though group membership.

By default, all GPOs have Read and AGP both Allowed for the Authenticated
Users group. The Authenticated Users group includes both users and computers.
This is how all authenticated users receive the settings of a new GPO when it
is applied to an organizational unit, domain or site. Therefore, the default
behavior is for every GPO to apply to every Authenticated User. By default,
Domain Admins, Enterprise Admins, and the local system have full control
permissions, without the Apply Group Policy ACE. However, administrators are
members of Authenticated Users, which means that they will receive the
settings in the GPO by default. "

:

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=
<[email protected]> says...

By the way, you never answered my original question, rather you attacked how
YOU might have done something or how you thought it should have been done.


I didn't attack anything, you're still missing some fundamentals on how
Group Policy works. For example, setting in the computer configuration
section of a GPO are not processed when a user account processes a GPO
and settings in the user configuration section are not processed when a
computer account processes a GPO.

I strongly suggest that you do some reading up on Group Policy.

Have fun.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Steven L Umbach]

You have two options. Either put all the computers in an OU, which could be
a child OU of an existing OU so that all parent OU computer configuration
settings still can apply to computers in the child OU unless the child OU
has same defined settings which will override same defined settings at
parent level, or filter a Group Policy that would apply to computers so that
the "apply" permission has only the global groups that contain computers
that you want the Group Policy computer configuration to apply to. Ether way
the computers must be within the scope of influence of the Group Policy. The
link below may help if you have not seen it yet. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;322176

 

[Paul Adare]

microsoft.public.win2000.security news group, =?Utf-8?B?U211cmZtYW4=?=

Basically, because one is a set of configurations changes that take place at
the HKLM level, where as the other take place at the HKCU.

No, this has nothing to do with it, it is simply the way Group Policy
processing works, nothing more than that. See my previous post on which
portion of a GPO is processed by computer accounts and which is
processed by user accounts.

Since Computers are part of the Authenticated Users, which is default, the
application to the machine (HKLM) is transparent. That is why just because
the Domain Admin by default does not have the apply setting as part of the
Security of the GPO, they are part of the Authenticated Users and will have
the policy applied.

The above makes no sense and has no bearing on the discussion at all.

Let me ask you, how would apply the computer settings that are part of a GPO?

In the context of this discussion this question makes no sense. I _know_
how Group Policy processing works.


--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

 

[Guest]

Okay, so that kind of leads me back to my original issue, I have created a
Domain level GPO called Mail, in order to test this. The GPO has defined in
it, the Trusted Root Certificate that I want specific machines to have
installed on it. I removed the Authenticated Users from the Security of the
GPO, and added my Test user for the User portion of the policy, and I have
added a specific computer by browsing to it. For both I have selected the
options to Apply and Read the GPO.

According to what I have read, when the machine reboots, or at the poling
intervul of 90 minutes I think it was, the computer should pick up and apply
the policy. I think I am seeing it work during a reboot, but not the poling.
I just tested this. Now, this brings me back to one of my original
questions too, asside from having to add each computer as an object to the
Security to Apply, can I add the machines to the same User Group and then
Apply (Filter) the security on that Group. In this situation this solution
seems to be the fastest since I would not have to apply a GPO to each OU that
the computers were a part of.

On the second method - just to clarify, if I already have my computers
assigned to each OU for their respective locations, I would just have to
apply my GPO with the Authenticated Users in the Security by default, to
enforce the Computer Config on the machines in that OU? Is this also correct.

Thanks for the patient responses.

 

[Steven L Umbach]

What makes sense is to have two domain global groups - one for users and one
for computers that you want the Group Policy to apply to. The user group
would only apply user configuration and the computer group to computer
configuration. You could combine them all into one global group but from an
organizational standpoint I would use separate groups. Most Group Policy is
applied at logon/startup and at the refresh interval. Note that the default
interval has a default offset of thirty minus which means it can take up to
two hours for the refresh interval to apply. You can do a manual refresh
with secedit /refreshpolicy machine_policy /enforce for Windows 2000
computers or gpupdate /force for XP/W2003 computers.

If you want to apply Group Policy to all users/computers in an OU, then
leaving authenticated users as the apply group will work fine. You can use
the support tool gpresult to see all the groups that a user or computer is
currently a member of, what Group Policy is applied to a user or computer,
and the last time it was applied.. --- Steve