Buckit Posted November 28, 2017 Share Posted November 28, 2017 Hoya! Another day, another thread I'm in the process of setting up our privileged accounts for Windows and Linux management. Linux is easy in this case, as we'll limit the user through SUDO rules. Fine and dandy. It's Windows that's throwing me off (it's not really my field of expertise). I'm loathe of making a user account that's simply given access to the local "Administrators" group on each host. That feels damn dangerous to me. So I'm trying to hammer down things and make it work with the least possible privileges. Unfortunately I can't get it to work: I'm stuck at the last step. On the AD-level, the Windows privileged user was given delegated password management rights for AD users. That was also easy, so onwards to the local password management! The priv. user was added to AD-group "powershell-remote". I've set up a global policy that's enforced on the target Windows boxen, which adds the members of AD-group "powershell-remote" to these local groups: * Account Operators * Distributed COM Users * Remote Management Users * WinRMRemoteWMIUsers__ This ensures that the priv user can Invoke-Command and Enter-PSSession. But the remote hosts still balk at letting the user interact with things like win32_group through WMI or Get-CIM*. There's also the local WMI Control tool, which can be used to provide access to WMI components to specific users (see here). That's a bummer though, because that would require local changes on all boxen. Apparently you cannot set these permissions through a global policy, so you will need to resort to manual changes, or a script (see the EDIT below). Opening up the ROOT namespace for the privileged account appears to be sufficient for discovery. Will let you know about password changes Suggestions would be more than welcome! EDIT: At least there are scripts available that will help you set the WMI namespace access permissions through Powershell. See here. That's still not ideal though, but that's down to Windows' design. EDIT 2: One workaround that could be very useful, would be if PasswordState would support JEA: Just Enough Admin, a rather new extension for Powershell which allows you to delegate certain (local) tasks to another non-admin user. That would however require an adjusted set of scripts for discovery / validations / resetting. Thanks to my brother-in-law for suggesting JEA. Link to comment Share on other sites More sharing options...
support Posted November 28, 2017 Share Posted November 28, 2017 Hi Buckit, Sorry, but at this stage this script does require administrative privileges. We have seen some articles in the past about PowerShell Remoting without admin rights, and from memory it looked very complicated in terms of what was required to get this working. And that's regardless of the password reset itself. If we ever come across a method for this, we will post back here. Regards Click Studios Link to comment Share on other sites More sharing options...
Buckit Posted November 28, 2017 Author Share Posted November 28, 2017 In the mean time, I'll keep on prodding and poking. I'll update you guys when I've got things sorted. Hang on... I just realized. Quote Sorry, but at this stage this script does require administrative privileges. I really hope you mean -local- admin rights, as opposed to domain admin. Right?! Just to make sure... Link to comment Share on other sites More sharing options...
support Posted November 28, 2017 Share Posted November 28, 2017 Yes, that's correct - admin rights on the server. Regards Click Studios Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.