|
True – except that no one really
needs to be a member of the EA or DA group at all. In the scenarios that
I submitted, once the trusted DA (read TRUSTED DA) sets up the roles, he can have
InfoSec remove him as the last member of the DA group, create a new user for
DA/EA purposes only, and then change that password. InfoSec then retains
the password in a sealed envelope until such time that it’s needed. However, this does mean that someone needs
to take the old DA out a shoot him as he knows too much and is a danger to the
company. Or, we can just assume that someone *is* trusted and should be the only DA,
except for that ‘control’ account that InfoSec retains in their
off-site, triple protected, fireproof safe in Area 51. -rtk From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Both of your suggestions are good ….
Except that neither does much to PREVENT a DA or admin from doing much of
anything. I figured that you are shying away from employing the Joe-Stick (not
to be confused with Joystick J) and telling Mark to go back to the drawing board and re-thinking
why these people he is trying to lock down (out) are members of those groups in
the first place. A well-known solution to Mark’s problem is to remove the
people from those groups. He’d be fine ever after. Deji From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan 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... Rick Kingslan
- RE: [ActiveDir] Problem: Limit Domain Admin... joe
- RE: [ActiveDir] Problem: Limit Domain A... Rick Kingslan
- RE: [ActiveDir] Problem: Limit Domain Admin... Brian Desmond
- RE: [ActiveDir] Problem: Limit Domain Admin... Renouf, Phil
- RE: [ActiveDir] Problem: Limit Domain Admin... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Limit Domain Admin... Ruston, Neil
- RE: [ActiveDir] Problem: Limit Domain Admin... Myrick, Todd (NIH/CC/DNA)
