Reverse a DSACLS command
I've been testing some password change management software in my virtual network and after much trial and error finally got a command which changed permissions for allowing a user to reset a password. The command in question was:
dsacls "OU=Test Users,DC=Domain,DC=Com" /I:S /G "SELF:CA;Reset Password"
It was the quotes that got me !!
Anyway, my understanding is that this is now inheriting from the OU and when checking the security on a user within the OU it's showing greyed out. My question is apart from moving a test user from the OU into another and thus the permission going, what would the string me to reverse the whole process ? Any ideas ?
Don't users already have the rights to reset their own passwords?
A quick search through some documents I remember filing away to 'read later' ten years ago (and it seems MS really don't write documentation like they used to)... and the best I can find imply that dsrevoke and dsacls will strip all ACEs for the specified user/group including the out of the box entries.
So in order to delegate in a way that is reversible, that you should create role groups and use those when assigning custom delegated permissions to OUs. This then gives you a mechanism to revoke them (with DSREVOKE or the /r switch in dsacls) without endangering the OOB ACEs.
But that is mostly inference from the Best Practices for Delegating Active Directory Administration document.
I'd imagine that you've done a lot more testing of this than I ever did, so I'd be interested to see if you found a solution.
You can only reset your password if you know your old password - this command will allow a user to reset their password even if they did not know their password. It's part of a solution I'm trying to get to work called PWM - pwm - Open Source Password Self Service for LDAP directories - Google Project Hosting Pass Word Management software.
Problem is the manual is complete and utter shite and the support is very questionable too. Even the actual command they inform you to enter was bloody wrong. That's how bad it is, shame as the software and package looks good. I have it working in regards to setting security questions and getting the software to read the OU in AD however, it's not working in regards to allowing users to change their passwords and I think it's down to SSL. I have submitted multiple questions on the forum but can't seem to get a YES/NO answer [ god knows why ] so my plan is to now [ somehow as I have never done this ] generate a self SSL cert, get it verified and then [ somehow as yet again I have not done this and they provide NO guide into doing this ] install it on a DC. I can then change how the software binds to AD [ changing the port ] and then hopefully seeing if that helps.
As with most open sauce developed projects like this it's great when it works and fantastic when you have good support - this doesn't and [ in my opinion ] gives open source a bad name.
If I do get this working I'll let you know as I'm fed up with goldfish users forgetting their password and this would save me a heap of work !!
Forgot to say, easiest way to remove the permission I have found so far is to simply move the object [ user ] into a different OU which does not have the permission set. You can also simply tick the deny box on the security [ this will overwrite the inherited permission ] too.
I have to say the more you delve into AD [ and don't get me started on 2008 AD ] the more I hate it. Too restrictive.
Originally Posted by mattx
Ahh. I see.
You already have your solution. Let me propose a more complicated alternative:
For each user, create a group.
Make an ACE for that group on the relevant object for the permissions required.
You can then (when necessary) remove the ACE for that user's group as required.
You can have (very very roughly) 1000 group memberships per AD user account before you have a problem tuning things, so don't worry about that.<-I say this because some people do worry about the number of groups :)
If you want to take an AD deep dive (and I'd recommend it) this book is the best thing out there: The Inside Active Directory book and you may well have done enough research to understand AD permissions beyond what the book covers. I found it far more in depth than the MCSE, and in many ways in terms of practical information it seems half way to what you'd need to know for the MCM. Alas it was never updated for 2008 / R2 / 2012.
I'd be interested to hear what your frustrations are with AD, and why 2008 is worse than 2003.