Introduction

This post will explore a solution for dynamically adding the enrolling user of a device (the account that joins Entra ID) to a local group. In my case, that group is called Docker-Users but it could easily be Administrators or any other group which is required.
The need emerged in our company (and some customers) since the developers are not administrators on their local computers and the Docker installer will add the account executing the installer as a member of that group.
Since all our applications are deployed via Intune this means “System” account. That is not helpful since the devs cannot run or control docker without being members of that group.

Alternatives

Before reaching the current method, I attempted some other solutions which I’ll share more about below and the reason why they did not suit my needs.

Add current logged-on user during installation

  • How
    Adding a wrapper logic to my Docker Win32App on PowerShell to add the current user logged on to the group.

  • Why it did not work
    The logged-on user might not be the owner of said device. In that case, it would allow for someone else to run the installer (or maybe a newer version) and be added to that group, resulting in control of other person’s docker instances.

Available app with a script to add current logged-on user to the Docker-Users group

  • How
    Similar to the attempt before, the only difference is the script is on another Win32App or Remediation which does not involve the main app package.

  • Why it did not work
    If said app is advertised for more than one user (ie: all the developers who need to be in the group on their respective devices) nothing would stop someone from logging on to another device and triggering the installation from the Company Portal, resulting in the same control of other person instances.

Using Account Protection to manage group membership

  • How
    Use Account protection profile to manage members of the Docker-Users group.

  • Why it did not work
    Account protection can only manage built-in groups, and the other issue is that it would require one profile per user since using variables like %username% is not supported.

Prerequisites

This solution is based on Proactive Remediation, so it needs to be licensed accordingly. If you would like to use this solution and don’t have the licenses to use proactive remediations please feel free to reach out to me and I’ll be more than happy to work on porting to a Win32App.

The Script and its mechanics

Detection

if (Get-LocalGroup "docker-users") {
    if (
        (Get-ChildItem -Path 'HKLM:\SOFTWARE\Microsoft\IdentityStore\Cache' | Where-Object { $_.Name -match 'S-1-12-1-\d+-\d+-\d+-\d+' } | ForEach-Object { Get-ChildItem  $_.pspath } | ForEach-Object { Get-ChildItem  $_.pspath } | ForEach-Object { Get-ItemProperty $_.pspath | Where-Object { $_.Username -eq (Get-ChildItem -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo" | ForEach-Object { Get-ItemProperty -Path $_.PSPath -Name UserEmail -ErrorAction SilentlyContinue } | Where-Object { $_.UserEmail }).UserEmail } } | Select-Object -First 1 -Property @{Name = 'Combined'; Expression = { $_.ProviderName + '\' + $_.samname } }).Combined -in (Get-LocalGroupMember -Group "docker-users").name)
    { Exit 0 }
    else { Exit 1 }
}

Remediation

try {
    $Username = "AzureAD\" + "$((Get-ChildItem -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo" | ForEach-Object {Get-ItemProperty -Path $_.PSPath -Name UserEmail -ErrorAction SilentlyContinue} | Where-Object {$_.UserEmail}).UserEmail)"
    net localgroup "docker-users" /add $Username  
} 
catch {
    Write-Error "Error Processing detection: $_"
    Exit 1
}

The script utilises the Cache Identity Store to help translate the ProviderName + SAMName (ie: AzureAD\JoseSchenardie) back to the UserPrincipalName (ie: jose.schenardie@intune.tech) of the joining account, that way we can read the members from the group and validate the detection.

Notes

Note 1: Given this script uses IdentityStore\Cache registry and these keys are only populated once the user logs on, this script will not work until the enrolling user logs on.

Note 2: Specifically to this example, the **Docker-Useers** group is only created once Docker is installed. In case you would like to create the group before and populate it with the enrolling user, make sure you only assign the script to devices that will receive the Docker application.

Unsupported scenarios

  • Windows 365 & Dev Box: These workloads use a different way of joining entra and the enrolling user will be fooUser@domain.com (ie: fooUser@intune.tech) hence the script will not work. In that case, a variation of the script to add the current logged-on account would work since those Workloads are not shared among users and normally the only account that will ever log in is the actual primary user of said device. I don’t have a license to test Frontline scenarios, so I can’t comment on that.

  • Autopilot self-deploying: Similar to the above case, self-deploying devices are enrolled to Entra ID by the account autopilot@domain.com (ie: autopilot@intune.tech) so they will also not work with this script. Since self-deploying is aimed at kiosks, digital signage or devices I don’t believe they would need a solution like this.

Hope that was informative and thanks for reading.

Updated:

Comments