Yeah, that’s been discussed a few
times here. One of the issues that you run into with Domain Admins and
the like is that they can take ownership of any object and then just change
permissions back to what they want. It is the way that AD was designed –
the intent is clearly there to prevent one from irreparably locking themselves
out of controlling their domain/forest. One way to do this, however, is to look at
users (potential DA’s) by what they do. Define the job roles and
create groups for these users. Grant permissions to allow these users to
do what they must at the specific object location – and don’t make
them Domain Admins at all. In this way, you have a very granular approach
to controlling user access. There are very few folks in any environment
that need the full set of permissions that the DA or EA give. Granted, this is an approach that is
fraught with lots of manual effort. Another way to look at this is by
looking at Quest’s Active Roles. It helps you define, manage and
control roles for users, where the role is applied, and the ability to report
and control the actions. It also gives your audit function a boost by not
requiring the person doing the audit to really know anything about AD other
than this person can do ‘A” job with these rights in AD. Rick Kingslan MCSE, MCSA, MCT, CISSP From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
|
- RE: [ActiveDir] Problem: Limit Domain Admins and Administr... Rick Kingslan
- RE: [ActiveDir] Problem: Limit Domain Admins and Admi... deji
- RE: [ActiveDir] Problem: Limit Domain Admins and ... Rick Kingslan
- RE: [ActiveDir] Problem: Limit Domain Admins and Admi... joe
- RE: [ActiveDir] Problem: Limit Domain Admins and Admi... Brian Desmond
- RE: [ActiveDir] Problem: Limit Domain Admins and Admi... Renouf, Phil
- RE: [ActiveDir] Problem: Limit Domain Admins and Admi... Gil Kirkpatrick