David_Wallis

Is there anyway of restricting Domain Admins from using the default tools, mainly AD Users and Computers?

I thought I could actually set permissions when highlighting the domain, but looks like I was on the stella when I decided that.

I only want enterprise admins to be able to use AD users and computers and everyone else to 'have' to use the other tools provided.

Removing them from domain admins could be a bit of a headache due to needing admin rights on servers and being able to manage domain controllers etc.

David

Barmyclown

Right long time since I done this, but if you highlight the domain admin group, and go to custom permissions, I think you can just untick Add Users and Add Computers to the domain. If my memry serves me corrrect.

Jase.

roblane

kinda depends what you want your non admin admins to be able to do. giving someone membership of domain admins is akin to giving them the keys to your scoob and telling them they can only sit in the passenger seat - temptation will win out.

That said with judicious use of permissions on the AD it can be done.

the general principle is as follows:

1. Create a Global Security Group called DCAdmins, and add any/all users or groups that will require local DC administrator privileges.

2. Create a Global Security Group called DenyDCAdmins.

3. Add the DCAdmins group to the DenyDCAdmins group.

4. Using the AD Users & Computers snap-in, deny ALL access to the domain NC to the DenyDCAdmins group.

5. Add the DCAdmins group to the <domain>\Administrators group

This does mean all members of your dcadmins will be able to "admin" any dc.

If you need to make it more granular that can be done too but its more complex.

personally if you don't trust em - fire em...

David_Wallis

its not down to trust and I know that its like giving the keys away..

Those that implement this will have enterprise admins, ie me and three others.. however We need the others to be able to work as normal.. except they need to use netIQ DRA to add / create users / groups.

I know that them 'being' domain admins will enable them to get back in, unless we remove rights.. however if we can just stop them from 'using' the mmc snapin (must include them just installing it on a machine though.. so deleting mmc is no good.. nor is permissions on the mmc)

David

roblane

if its just add and create users / groups in the AD then you should be able to that via delegation as normal users. Are there other tasks you want them to have domain admin privs for? If so you can modify the method described earlier and just miss out the deny aces you need for them to be able to perform the ad related functions you want.

roblane

another thought - have you considered software restriction policies? Never used them myself but in theory you could have a policy to restrict execution of the dll's used by the admin tool snapins.

HHxx

Don't give them Domain Admins membership.

Create global security groups and assign the groups permissions just to do enough. E.g "Uk User Creators", "Uk User deletion" etc..

Every user on our network are just normal domain users, some with more rights than others. Each IT member has an additional "admin" account which cannot logon to workstations, and some can logon to servers with this account. Even if our admins use the normal mmc snapins to perform their duties, they can only do so much. We have created a taskpad in mmc to make it easier for them to perform their roles, they have to use the "run as" on them using their admin account.

For workstations, we use the local admin account only. If they cannot do what is required then the ticket is escalated to domain admins and if they cant do it either then its the enterprise admin team.

I haven't used that NetIQ product so not sure how that works.

H

HHxx

GPO policies and delegations is your friend

David_Wallis

the whole point is I dont want them using the MMC.. they dont need rights to be able to create users. What they do need to be able to do is work without restrictions..

Ie Moving Roles, Restores, DSMaint, its just we want to force them to use DRA to create the users and groups.

David

HHxx

My bad for not paying attention

Does this DRA app use the credentials of the logged in user or does it have its own account?

I would think making their normal ad account non domain admins and giving them alternate accounts for logging into servers etc and restrict this account so they cannot logon to their workstation with it. That just leaves the problem of the "admin" account being used with runas on the mmc. But that could be restricted via a group policy. Just an idea.

H

David_Wallis

the DRA app runs using a domain/enterprise admin service account.. you then grant rights in the app using normal groups.. so we can let helpdesk modify users, restrict them from seeing their own users (so they cant add themselves into groups etc) also provides a recycle bin for restoring users groups etc.

The problem is the people we want to restrict are mainly MCSE's so it needs to be a proper way of restricting them.. Yeah yeah I know dont give domain admins.

David

roblane

David, just wondered did you give the software restriction policy a whirl? I just configured a policy to prevent dsadmin.dll and dsprop.dll from being executed for a given user via a hash based rule and then the user can no longer run dsa.msc (Users and computers). I think its an XP / 2003 only kinda thing so if they have 2000 its not so useful.

HHxx

I think I have worked out want you want to do.

Take these junior domain admins and put them in a ou. Apply a GPO to this to restrict access. Using the:
User Configuration, Administrative Templates, Windows Components, Microsoft Management Console

• Restrict users to the explicitly permitted list of snap-ins (Enabled/Disabled)

User Configuration, Administrative Templates, Windows Components, Microsoft Management Console, Restricted/Permitted snap-ins

• Active Directory Users and Computers (Enabled/Disabled)

User Configuration, Administrative Templates, Windows Components, Microsoft Management Console, Restricted/Permitted snap-ins, Group Policy

• Group Policy snap-in (Enabled/Disabled)

etc....
Obviously there are loads more options. The only problem is you wouldn't want them being able to modify GPO's.

Is that what you wanted?

H

David_Wallis

looks good..

Also thinking about using ADSI edit and editing permissions on the USERS container.. but need to test it.

David