Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We would like to lock a couple of accounts to prevent even domain admins from resetting the password without already knowing the current password. From what I can see in the permission sets, this looks possible. Anything I've found on the subject recommends against altering default permissions, but doesn't go into detail why.

Assuming that domain admin retains the ability to reset passwords without knowing current passwords is it reasonable to prevent password resets on the domain admin account and maybe a couple of others? If not, why not?

share|improve this question
1  
Possible perhaps but definitely not advisable. The road you want to take heads into the land of inaccessible systems, resulting from accounts that no longer have access and no way to gain access without resorting to hacking techniques. Those same techniques makes the point moot. –  John Gardeniers Apr 7 '10 at 23:44
    
Thanks, John, that's so obvious that I feel silly for not having already thought of it. –  user39986 Apr 8 '10 at 14:20
add comment

1 Answer

up vote 3 down vote accepted

It should be possible with ADSI edit. (I know you know, but: Be careful with ADSI Edit).

But the real problem here is that you have to be able to trust the "Domain Admins". If you can't trust them with resetting passwords on important accounts, how can you trust them not to format the DCs?

If you want to keep some accounts Special, move them into an OU and call it "ImportantAccounts" and tell all your domain admins not reset these passwords!

You can however centralise security auditing and keep track of who reset which password if you want to apportion blame after the fact.

share|improve this answer
    
First of all, ADSI edit is off limits! Second, trust would seem to be at the heart of the issue. In most areas, I like to work with a 'trust but verify' model. That suggests that we should leave things as they are, but adding proper auditing and reporting. –  user39986 Apr 8 '10 at 14:18
    
John Gardinier's comment to my question addresses the technical reasons why this tactic cannot succeed and this answer raises valid concerns over the organization reasons for developing this strategy. If the two were merged into one answer, that would be ideal, but this is the only actual answer and problem has been fully addressed to my satisfaction. –  user39986 Apr 8 '10 at 14:37
    
On a note about trust: We had summer students in here installing software on PCs and we made them normal "Domain Users" but put the "Interns" group into "Local Admins" of each desktop PC using a script. So they could mess with normal PCs but couldn't log into Servers or use AD. –  Seanchán Torpéist Apr 8 '10 at 16:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.