I ran across the following catch22 in my workstation installation script while trying to automatically add a domain group to the local administrators.
The catch I’m experiencing is the following:
- When I’m using the local admin I have the rights to add users to a local group but need to provide domain credentials to connect to the domain
- When I’m using a domain user I can connect to the AD, but the user doing this is not yet a local admin so I can’t yet modify local groups.
I’m in a GMP environment so rules and regulations are !really! strict which limits other possible paths.
- Roles are split so I don’t have access to the domain admin.
- No changes are allowed to OU’s which could push the group from Group Policy
- Using PowerShell with remote scripts is not allowed
This is fairly easy to manually get around when using compmgmt.msc and provide the necessary credentials when asked … but I’d like to avoid adding manual steps and just automate the entire installation as much as possible.
A few details:
- The workstation's OS is Windows 10
- The script I'm using is PowerShell
- The script is running with a local admin account with elevated privileges
- The workstation is already joined to the domain
- The account used to join the workstation to the domain is not a domain admin
- To have admin rights with my domain account I need to add our department’s group to local admin group
The code I use to add a group to the local admin group is
$de = [ADSI]"WinNT://$Env:ComputerName/Administrators,group"
This code works like a charm when run with a domain account and is a local admin.
Since this is used for installation of a brand new workstation I can run this either as domain account or local admin.
With the former the
$de.psbase.Invoke("Add", part fails
With the latter the
I tried using
start-process cmdlet with
–verb runas options to get a different security context but I ran into the same problem as above.
Is there any way I can
- only resolve
([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").pathin the security context of a domain user and pass that to the rest of my script running in the security context of the local admin (This is much the way compmgmt.msc does it)
- build the [ADSI] object from hardcoded data without the need to connect to the domain
- something else blindingly obvious I haven’t thought of