Link to home
Start Free TrialLog in
Avatar of Inbox360
Inbox360

asked on

Using adsiedit to disable the change password for a certain ad account

my problem is that i have a computer on a network that needs to be accessed by one person remotely and not locally. so i thought that i could just lock it down by gpo to do deny local login but he also wants that no one can change his password except for me and that is ok. i am the only enterprise admin. so i go inot adsiedit and i go inot domain and i go into his object and remove groups to not allow them to change his password and it did work great but went back in 20 min and they were changed back. inheritance is not checked.  so i put deny next to change password and reset password but they changed back? what am i missing so that they stick? i cannot find anything on this subject? thanks
Avatar of mediaonegraphics
mediaonegraphics
Flag of United States of America image

It appears that a group policy you have is overwriting the changes. You could always set his computer in an OU and ceate a GPO to it then enable loopback policy.
This sounds like a symptom of adminSDholder, a background mechanism that replaces the ACL on objects that are members of significant security groups.  Which groups is the user a member of?
Avatar of Inbox360
Inbox360

ASKER

he is a domain admin with delegated control of everthing except he cant touch group policy.  my main dc has all 5 roles on it and they are not going to change.  the server has 2003 server standard r2 sp2.  the hotfix says it was fixed with service pack 1? will this still work?

what gpo would i have in place to overwrite this. i made all the gpo's and i dont think i have anything like this. where is the exact location i would find this?
ASKER CERTIFIED SOLUTION
Avatar of MSE-dwells
MSE-dwells
Flag of Yemen image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
PS - if he's a Domain Admin and the GPOs you've delegated control against exist within his domain, he can change them whenever he sees fit to try.
he can change my group policy as a domain admin, even though i didnt give him access under delegate control?

also if i make him a enterprise admin and not allow groups under me like domain admins to changhe out passwords then by changing the adminsdholder template that would work?
If you have only one domain, then yes because he can implicitly take ownership of anything -- ownership in turn implies the ability to change the ACL.

I don't understand your 2nd question.  Let's start with why the user is a DA at present and why you're considering making them an EA -- what do they do what motivates that level of membership?
he used to be the cto and i was the net admin.  we left and still help the company. the new people are trying to kick us out but whenever things break we still fix them. the cto as a Domain admin wanted to make sure they cant change his password so we can keep helping.  thats when i started digging into adsiedit and it kept changing back the changed acl i made under his object? any suggestions?
Sorry, not possible.  All you can do is make it cumbersome but, in the single-domain model, a DA is all-powerful.
so if i knock them down to just admins not domain admin. then they need delegated control to administer AD right? what can they do if they are just admins?
Define just admins?  Are you referring to making them members of the Administrators group on their workstation?  If so, they can do whatever they like on that PC and nowhere else.  Perhaps, you're referring to making them a member of the Administrators grouo within the domain.  If so, that's only one step removed from being a DA and something they'll always be able to add-back for themselves.
well if admins of domain can change them selves to domain admins? then how do you make priveldged levels of access to make ad changes?  how do you make it so admins of domain are just that and cannot make ad changes.  there has to be a difference of being an admin of a domain and a domain admin?
There is a difference ... but it's in the ACLing details which are too many to even begin going into.  The short explanation is that groups give permission primarily based on where they're ACLed within the directory not via some implicit hard-coded fluff as it was in NT (even today though, certain groups do still have implicit permission to do 'stuff').  This is the means by which you're supposed to delegate custom control -- i.e. by creating your own groups, ACLing the group against the resources you're trying to provide access to and adding the relevant members to the groups.

I'm not sure if or where you got the idea that Administrators were less than Domain Admins or vice-versa but I've not seen it stated in a misleading manner myself.  There are pre-existing less-powerful groups that are designed to assist in delegation of the more commonplace tasks, e.g. Server Operators or Backup Operators or ... but, for the most part, simply use AD U&C with Advanced Features switched on and use the Security tab to give specific users permission to do what they need to do.