Block OU browsing but still apply policy?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello All,

I was wondering, I'm trying to change the ACL's on an OU to block casual
browsing of the contents, but it is also the same top-level OU that will
house our user accounts shortly (that's why I want to block casual
browsing). If I block read access to the OU, then policy doesn't apply
because it can't enumerate the policies attached to that OU. I half solved
it by adding Domain Computers to "Read" but obviously that doesn't help for
user policies. I've tried every configuration of User ACL's that I can
think; of on all the little sub-object types, to no avail. Is this doable
or will I have to live with just having them able to browse the structure?

Any ideas appreciated.

Thanks!
 
Hi

How are users browsing the policies? It's usually not something they can do
without elevated privs (at least via DSA.msc). In any case, users can
usually see the settings applied to them via RSOP.msc or gpresult after the
fact.

For group policy to apply, the account (machine or user) must have ALLOW
"read" and "apply group policy" permissions to the policy.

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
It's not the policies themselves that are the problem, it basically comes
down to, if read access on the OU is blocked, then it can't get the list off
policies which are attached to it. They have access to read and apply the
policies themselves, but if they are blocked access to read the OU on which
they reside, the OU can't read off the names of the linked policies to the
requestor; if they don't get enumerated they don't get applied.

Mark Renoden said:
Hi

How are users browsing the policies? It's usually not something they can
do without elevated privs (at least via DSA.msc). In any case, users can
usually see the settings applied to them via RSOP.msc or gpresult after
the fact.

For group policy to apply, the account (machine or user) must have ALLOW
"read" and "apply group policy" permissions to the policy.

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.
Hello All,

I was wondering, I'm trying to change the ACL's on an OU to block casual
browsing of the contents, but it is also the same top-level OU that will
house our user accounts shortly (that's why I want to block casual
browsing). If I block read access to the OU, then policy doesn't apply
because it can't enumerate the policies attached to that OU. I half
solved it by adding Domain Computers to "Read" but obviously that doesn't
help for user policies. I've tried every configuration of User ACL's
that I can think; of on all the little sub-object types, to no avail. Is
this doable or will I have to live with just having them able to browse
the structure?

Any ideas appreciated.

Thanks!
Click to expand...
Click to expand...
 
I'm still not clear - how are users "browsing" the policies?

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
They're not really browsing them, but when a user logs on, the user must
read the OU in order to see what policies are linked to it, so it knows what
to apply. I don't want them browsing to OU structure and nosing through
where computer,group, and user accounts are, so I took "read" permission
off of authenticated users. Once I did that they stopped getting policy and
the event log recorded an error for applying policy, indicating it received
an "access denied" when trying to get the list of policies for the OU.
That's my problem. I need to be able to block the users from nosing through
the OU structure, but at the same time they must be able to enumerate the
policies attached to them.

Mark Renoden said:
I'm still not clear - how are users "browsing" the policies?

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.
Is there any property in the security property sheet that might allow for
this?
Click to expand...
Click to expand...
 
Your best bet is to restrict the use of the MMC, so they don't have a means
of using the information. They still have to have rights to "read" it, or
else they can't apply it,
Anthony, http://www.airdesk.co.uk

They're not really browsing them, but when a user logs on, the user must
read the OU in order to see what policies are linked to it, so it knows
what to apply. I don't want them browsing to OU structure and nosing
through where computer,group, and user accounts are, so I took "read"
permission off of authenticated users. Once I did that they stopped
getting policy and the event log recorded an error for applying policy,
indicating it received an "access denied" when trying to get the list of
policies for the OU. That's my problem. I need to be able to block the
users from nosing through the OU structure, but at the same time they must
be able to enumerate the policies attached to them.

Mark Renoden said:
I'm still not clear - how are users "browsing" the policies?

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.
Is there any property in the security property sheet that might allow
for this?

<-> wrote in message Hello All,

I was wondering, I'm trying to change the ACL's on an OU to block
casual browsing of the contents, but it is also the same top-level OU
that will house our user accounts shortly (that's why I want to block
casual browsing). If I block read access to the OU, then policy
doesn't apply because it can't enumerate the policies attached to that
OU. I half solved it by adding Domain Computers to "Read" but
obviously that doesn't help for user policies. I've tried every
configuration of User ACL's that I can think; of on all the little
sub-object types, to no avail. Is this doable or will I have to live
with just having them able to browse the structure?

Any ideas appreciated.

Thanks!
Click to expand...
Click to expand...
Click to expand...
 
Is there any way I can block the browsing, but through the use of one of the
many sub-ACL's, permit GP link enumeration?

Anthony said:
Your best bet is to restrict the use of the MMC, so they don't have a
means of using the information. They still have to have rights to "read"
it, or else they can't apply it,
Anthony, http://www.airdesk.co.uk

They're not really browsing them, but when a user logs on, the user must
read the OU in order to see what policies are linked to it, so it knows
what to apply. I don't want them browsing to OU structure and nosing
through where computer,group, and user accounts are, so I took "read"
permission off of authenticated users. Once I did that they stopped
getting policy and the event log recorded an error for applying policy,
indicating it received an "access denied" when trying to get the list of
policies for the OU. That's my problem. I need to be able to block the
users from nosing through the OU structure, but at the same time they
must be able to enumerate the policies attached to them.

Mark Renoden said:
I'm still not clear - how are users "browsing" the policies?

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to
email me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.
<-> wrote in message Is there any property in the security property sheet that might allow
for this?

<-> wrote in message Hello All,

I was wondering, I'm trying to change the ACL's on an OU to block
casual browsing of the contents, but it is also the same top-level OU
that will house our user accounts shortly (that's why I want to block
casual browsing). If I block read access to the OU, then policy
doesn't apply because it can't enumerate the policies attached to that
OU. I half solved it by adding Domain Computers to "Read" but
obviously that doesn't help for user policies. I've tried every
configuration of User ACL's that I can think; of on all the little
sub-object types, to no avail. Is this doable or will I have to live
with just having them able to browse the structure?

Any ideas appreciated.

Thanks!
Click to expand...
Click to expand...
Click to expand...
 
I've never come across a method for doing what you want. I think that if
you could, you run the risk of breaking things. Searching the directory for
printers etc would be one example. If there's a threat you're trying to
mitigate by doing this, it might be better if you describe that and there
may be a better approach.

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.
Is there any way I can block the browsing, but through the use of one of
the many sub-ACL's, permit GP link enumeration?

Anthony said:
Your best bet is to restrict the use of the MMC, so they don't have a
means of using the information. They still have to have rights to "read"
it, or else they can't apply it,
Anthony, http://www.airdesk.co.uk

They're not really browsing them, but when a user logs on, the user must
read the OU in order to see what policies are linked to it, so it knows
what to apply. I don't want them browsing to OU structure and nosing
through where computer,group, and user accounts are, so I took "read"
permission off of authenticated users. Once I did that they stopped
getting policy and the event log recorded an error for applying policy,
indicating it received an "access denied" when trying to get the list of
policies for the OU. That's my problem. I need to be able to block the
users from nosing through the OU structure, but at the same time they
must be able to enumerate the policies attached to them.

I'm still not clear - how are users "browsing" the policies?

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to
email me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.
<-> wrote in message Is there any property in the security property sheet that might allow
for this?

<-> wrote in message Hello All,

I was wondering, I'm trying to change the ACL's on an OU to block
casual browsing of the contents, but it is also the same top-level OU
that will house our user accounts shortly (that's why I want to block
casual browsing). If I block read access to the OU, then policy
doesn't apply because it can't enumerate the policies attached to
that OU. I half solved it by adding Domain Computers to "Read" but
obviously that doesn't help for user policies. I've tried every
configuration of User ACL's that I can think; of on all the little
sub-object types, to no avail. Is this doable or will I have to live
with just having them able to browse the structure?

Any ideas appreciated.

Thanks!
Click to expand...
Click to expand...
Click to expand...
 
We're just trying to restrict casual browsing.

Mark Renoden said:
I've never come across a method for doing what you want. I think that if
you could, you run the risk of breaking things. Searching the directory
for printers etc would be one example. If there's a threat you're trying
to mitigate by doing this, it might be better if you describe that and
there may be a better approach.

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.
Is there any way I can block the browsing, but through the use of one of
the many sub-ACL's, permit GP link enumeration?

Anthony said:
Your best bet is to restrict the use of the MMC, so they don't have a
means of using the information. They still have to have rights to "read"
it, or else they can't apply it,
Anthony, http://www.airdesk.co.uk

<-> wrote in message They're not really browsing them, but when a user logs on, the user
must read the OU in order to see what policies are linked to it, so it
knows what to apply. I don't want them browsing to OU structure and
nosing through where computer,group, and user accounts are, so I took
"read" permission off of authenticated users. Once I did that they
stopped getting policy and the event log recorded an error for applying
policy, indicating it received an "access denied" when trying to get
the list of policies for the OU. That's my problem. I need to be able
to block the users from nosing through the OU structure, but at the
same time they must be able to enumerate the policies attached to them.

I'm still not clear - how are users "browsing" the policies?

--
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to
email me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.
<-> wrote in message Is there any property in the security property sheet that might allow
for this?

<-> wrote in message Hello All,

I was wondering, I'm trying to change the ACL's on an OU to block
casual browsing of the contents, but it is also the same top-level
OU that will house our user accounts shortly (that's why I want to
block casual browsing). If I block read access to the OU, then
policy doesn't apply because it can't enumerate the policies
attached to that OU. I half solved it by adding Domain Computers to
"Read" but obviously that doesn't help for user policies. I've
tried every configuration of User ACL's that I can think; of on all
the little sub-object types, to no avail. Is this doable or will I
have to live with just having them able to browse the structure?

Any ideas appreciated.

Thanks!
Click to expand...
Click to expand...
Click to expand...
 
restrict browsing through AD structure

Hello,

I have gone through the email chain and i understand, what we want to achieve here to some how try and restrict users browsing through the AD structure.

well, i think it can be done but will require a bit of testing. I know that users should have read permissions in order to process GPOs.
The other aspect of Windows core is that we have have 4 basic ACLs. Yes just 4 basic ACLs
Inherited Allow
Inherited Denial
Explicit Allow
Explicit Denial
And Explicit Denial is the most dominant one, and will win in all cases in scenarios.

So, what you need to do is create a test domain and then GO in ADSIEDIT.MSC
Expand the "Domain" container just by one step.
Then right click on you domain's NC name, it is like DC=DomainName,DC=com for DomainName.com domain.
Go to the security tab, Go to Advanced,
Put an Explicit Denial for "List" permission.

The other thing that you can try and do is use registry based GPO and restict the access to MMCs for users. We need to create an ADM templete for editing registry, which is very simple to create as there are loads of 3rd party tools available on net that will help you do it.
The registry value that you need to modify is -
HKCU\Software\Policies\Microsoft\MMC - then value for RestrictToPermittedSnapins

Please let me know this solutions works or not, any feed back will be highly appreciated.

Thanks & Regards,
Shalabh Sharma,
Ex- Microsoft Enterprise Platform Support - Active Directory
 
Hello,

I have gone through the email chain and i understand, what we want to achieve here to some how try and restrict users browsing through the AD structure.

well, i think it can be done but will require a bit of testing. I know that users should have read permissions in order to process GPOs.
The other aspect of Windows core is that we have have 4 basic ACLs. Yes just 4 basic ACLs
Inherited Allow
Inherited Denial
Explicit Allow
Explicit Denial
And Explicit Denial is the most dominant one, and will win in all cases in scenarios.

So, what you need to do is create a test domain and then GO in ADSIEDIT.MSC
Expand the "Domain" container just by one step.
Then right click on you domain's NC name, it is like DC=DomainName,DC=com for DomainName.com domain.
Go to the security tab, Go to Advanced,
Put an Explicit Denial for "List" permission.

The other thing that you can try and do is use registry based GPO and restict the access to MMCs for users. We need to create an ADM templete for editing registry, which is very simple to create as there are loads of 3rd party tools available on net that will help you do it.
The registry value that you need to modify is -
HKCU\Software\Policies\Microsoft\MMC - then value for RestrictToPermittedSnapins

Please let me know this solutions works or not, any feed back will be highly appreciated.

Thanks & Regards,
Shalabh Sharma,
Ex- Microsoft Enterprise Platform Support - Active Directory
 
Hello,

I have gone through the email chain and i understand, what we want to achieve here to some how try and restrict users browsing through the AD structure.

well, i think it can be done but will require a bit of testing. I know that users should have read permissions in order to process GPOs.
The other aspect of Windows core is that we have have 4 basic ACLs. Yes just 4 basic ACLs
Inherited Allow
Inherited Denial
Explicit Allow
Explicit Denial
And Explicit Denial is the most dominant one, and will win in all cases in scenarios.

So, what you need to do is create a test domain and then GO in ADSIEDIT.MSC
Expand the "Domain" container just by one step.
Then right click on you domain's NC name, it is like DC=DomainName,DC=com for DomainName.com domain.
Go to the security tab, Go to Advanced,
Put an Explicit Denial for "List" permission.

The other thing that you can try and do is use registry based GPO and restict the access to MMCs for users. We need to create an ADM templete for editing registry, which is very simple to create as there are loads of 3rd party tools available on net that will help you do it.
The registry value that you need to modify is -
HKCU\Software\Policies\Microsoft\MMC - then value for RestrictToPermittedSnapins

Please let me know this solutions works or not, any feed back will be highly appreciated.

Thanks & Regards,
Shalabh Sharma,
Ex- Microsoft Enterprise Platform Support - Active Directory
 
Back
Top