Jump to content

AD password changing vagueries


Buckit

Recommended Posts

Hiya,

 

I've been struggling with a few things in our ACC and PROD environments; thought it'd be better to ask for your help. For starters, there's this one:

 

I've defined a privileged account that's used to expire both local Windows passwords and passwords in AD. Conforming to the manuals I've set up the account to be local admin on the Win boxen and to have delegated password management rights on the AD domain. The latter is done through ADUC (Basically like this article describes):

 

  1. Right-click the domain's top / root, choose "Delegate control".
  2. Add the privileged account as the user that gets delegated control.
  3. Choose the task "Reset user passwords and force password change at next logon".
  4. Click Finish.

 

In many cases this works just fine. But not with a number of break-glass accounts that we've built in AD; they're accounts with elevated privileges. In their case I find myself having to edit the Security settings of the account in question, adding the PasswordState privileged user and giving it both "change password" and "reset password" privs.

 

Did I foul things up with the delegation at the AD-level? I thought this'd be enough.

 

Cheers,

 

 

Thomas

Link to comment
Share on other sites

Hi Thomas,

 

Sorry, but we do not really have any experience with delegation like this. From our experience, the account performing the reset must have either the same level of access as the account it's resetting, or more.

 

Maybe someone else in the community has some experience they can share?

Regards

Click Studios

Link to comment
Share on other sites

Dang... I'll have to look into the workings of AD some more. Of course it makes sense that normal user A cannot change the password for super-user B (escalation of privileges etc). I'm a Unix-admin by origins, so I'm still learning this AD/Win stuff :)

Link to comment
Share on other sites

6 hours ago, Buckit said:

I'm a Unix-admin by origins, so I'm still learning this AD/Win stuff

Windows here, blooding in on RHEL? Whats the issue? Delegation rights will work, assuming the right ones are set. 

Although the account will need WMI/RSMAN permissions as well. 

Link to comment
Share on other sites

  • 2 weeks later...

Man @Sarge you lost me with that message. Seems that you wrote that late at night :D 

 

You're saying that it should work as expected? Mmm... Depends of course on how you define "the right ones" when it comes to delegation rights. My 4-step list above shows exactly what I did, which I guess wasn't enough. 

Link to comment
Share on other sites

On 4/1/2018 at 10:15 PM, Buckit said:

Seems that you wrote that late at night

Story of my life lol.

On 4/1/2018 at 10:15 PM, Buckit said:

You're saying that it should work as expected? Mmm... Depends of course on how you define "the right ones" when it comes to delegation rights. My 4-step list above shows exactly what I did, which I guess wasn't enough. 

 

I'd expect it to yeah, however I've properly read your opening post where you've said it usually works, except for the 'break glass' accounts.
Is there anything special with those accounts? (MSAs etc?)

I'll play around in dev this week and see if I can replicate the issue.

Link to comment
Share on other sites

Scratch that Buckit.

Did a bit of the old googling and looks like this could be 'by design'.

This seems similar to your problem: https://davidvielmetter.com/tricks/password-reset-delegation-not-working/

Quote

[troubleshooting] After about an hour of poking around and checking properties, removing, re-applying delegate permissions on the OU, etc. I finally found the culprit. It was that most user accounts in the OU I had chosen to delegate control for were set tonot inherit permissions from the parent object. I found this by clicking on an account and checking the advanced permissions. Basically, if the include inheritable permissions from this object’s parent box isn’t checked, then you can delegate control at the OU level all day long, the objects in that OU won’t inherit the changes. So make sure that your accounts are set to include inheritable permissions from this object’s parent.

 

I'd bet this is happening for you. Further, I'd bet your break glass accounts won't remember the 'include inheritable permissions' checkbox because they are members of some protected AD groups.

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory

 

Quote

If the Inheritable flag keeps unchecking, it’s because the user account in question is likely part of a “protected” group. One examples of these protected groups are Domain Administrators. They’re all listed here : https://technet.microsoft.com/en-us/library/dn535499.aspx.

This is an article describing how Protected Accounts work and how to grant access to them : https://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx

To summarise the article : There is a process which runs every hour that will reset the permissions on any member of a “Protected Group” to have the same permissions as on the “AdminSDHolder” object (and also remove the “Enable Inherit Permissions” flag). This is apparently to protect you from accidentally removing permissions to your own account.

 

https://technet.microsoft.com/en-us/library/2009.09.sdadminholder.aspx

Is the process for updating the AdminSDHolder object.

 

Full credit to the article and the commenters. 
You learn something new everyday!

 

EDIT-

For clarity Buckit, I wouldn't be modifying the AdminSDProp to enable inheritable permissions, I'd simply add a security group with your priv user being a member, and grant it the required roles to perform resets on AdminSDProp based objects.
Wait for the SDProp process to run (1 hour ish), and you should be set.

I don't like the idea of modifying the default ACL for protected objects, but I like the idea of enabling inheritable permissions even less.
Also, i'd be taking screenshots of before and after for every change you make to the AdminSDProp object, and be documenting it fully. 

Link to comment
Share on other sites

You sir, are awesome :D That seems to be absolutely on the nose!

 

I'll run that through DevTest sometime soon! There's a few other things demanding my immediate attention, but this is a seriously great find Sarge!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...