Restrict Clients from viewing Domain Structue/OUs using GPMC
Server 2003 SP1 and AD 2003
Clients (workstations) - XP PRO. Domain users are local administrators on the client machine.
GPMC can be used on any client to view policies that apply to each OU. I want to restrict it such that no client machine can view GP policies per OU. For example, I have an OU for Sales. I don't want a user in the Finance department to be able to run GPMC on their machine and be able to browse the OUs in the domain and see what login scripts, policies, etc they are using.
For that matter, I don't want any client able to view the Domain/OU structure!
Thanks,
Clients (workstations) - XP PRO. Domain users are local administrators on the client machine.
GPMC can be used on any client to view policies that apply to each OU. I want to restrict it such that no client machine can view GP policies per OU. For example, I have an OU for Sales. I don't want a user in the Finance department to be able to run GPMC on their machine and be able to browse the OUs in the domain and see what login scripts, policies, etc they are using.
For that matter, I don't want any client able to view the Domain/OU structure!
Thanks,
MidnightOne
Unless they have domain admin rights on the domain, they shouldn't have the access rights to use the GPMC or ADUC tools against a domain controller.
ASKER
yeah, that is what i expected, but they can use the GPMC. The users are only Authenticated Domains users. No administrative rights whatsoever except on their local machines.
They can not make any changes, but they can view the structure and such. :-\
They can not make any changes, but they can view the structure and such. :-\
Do the clients -require- admin access on t he local machines? Although that's a separate problem, it will keep them from installing the admin tools and other idiocy.
ASKER
Yes they require it - being developers and such. That company policy won't change unfortunately.
I just can't believe that it is that simple to browse the hierarchy on the domain controller. This is a problem because employees using the tool are seeing the tiers of management and the varying share rights based on OU names and script names.
I need to restrict it if at all possible.
I just can't believe that it is that simple to browse the hierarchy on the domain controller. This is a problem because employees using the tool are seeing the tiers of management and the varying share rights based on OU names and script names.
I need to restrict it if at all possible.
ASKER
up'd points
Unfortunately, you won't ben able to stop them from getting at the logon scripts at all; these are housed at %logonserver%\netlogon and all users have RX privileges to that share and files.
It's possible to use GPO software installation to remove the admin tools from the user's workstations, but given the myriad versions this may be cumbersome at best.
Do the users have the tools installed locally?
It's possible to use GPO software installation to remove the admin tools from the user's workstations, but given the myriad versions this may be cumbersome at best.
Do the users have the tools installed locally?
ASKER
Yes, the users have the tools installed locally.
Again, it isn't simply the viewing of the scripts, but more so the AD structure.
So you think the only solution is to remove the tools and either restrict install or live with it?
Again, it isn't simply the viewing of the scripts, but more so the AD structure.
So you think the only solution is to remove the tools and either restrict install or live with it?
Here's a possibility to add to the logon script, presuming you can put the admin tools installer in the netlogon foloder
msiexec /x %logonserver%\netlogon\adm
This performs an immediate stealth uninstall of the admin tools.
HAND
MidnightOne
msiexec /x %logonserver%\netlogon\adm
This performs an immediate stealth uninstall of the admin tools.
HAND
MidnightOne
ASKER
haha, that's cool and funny. They will install it repeatedly and it will be removed everytime they log on. The only problem with that is they will install it after they are logged on and use it during that session :-\
I am going to try that (at the least) to see how annoyed they get with it.
I am going to try that (at the least) to see how annoyed they get with it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That is the answer I needed. Pretty crummy that is works that way.
Thanks for you suggestions!
Thanks for you suggestions!