Error during machine sid retrieval: An error (1788) occurred while enumerating the group membership. The member's SID could not be resolved.

[Yannik]

SUMMARY

For some reason, one of my hosts (a domain controller) is producing this warning during facts gathering:
[WARNING]: Error during machine sid retrieval: An error (1788) occurred while enumerating the group membership. The member's SID could not be resolved.

I was able to reproduce this error by manually executing the code

ansible.windows/plugins/modules/setup.ps1

Lines 847 to 857 in f1f2bcb

	$adminGroup = (New-Object -TypeName System.Security.Principal.SecurityIdentifier -ArgumentList @(
	"S-1-5-32-544")).Translate([System.Security.Principal.NTAccount]).Value
	$namespace = 'System.DirectoryServices.AccountManagement'
	Add-Type -AssemblyName $namespace
	$context = New-Object -TypeName "$namespace.PrincipalContext" -ArgumentList @(
	[System.DirectoryServices.AccountManagement.ContextType]::Machine)
	$principal = New-Object -TypeName "$namespace.GroupPrincipal" -ArgumentList $context, $adminGroup
	$searcher = New-Object -TypeName "$namespace.PrincipalSearcher" -ArgumentList $principal
	$groups = $searcher.FindOne()

and then trying to list $group.Members.

$adminGroup contains the string BUILTIN\Administratoren.
However, I am unable to see the members of this group, since the affected server is a domain controller, and has no local groups.

get-localgroup $adminGroup returns get-localgroup : Group BUILTIN\Administratoren was not found..

Is there any way I can fix this / list the members of this group so I can see which one is causing issues?

ISSUE TYPE

• Bug Report

COMPONENT NAME

setup

ANSIBLE VERSION

ansible [core 2.16.3]
  config file = /builds/ansible/deployments/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /app/lib/python3.12/site-packages/ansible
  ansible collection location = /builds/ansible/deployments/vendor_collections
  executable location = /app/bin//ansible
  python version = 3.12.2 (main, Feb  7 2024, 22:13:24) [GCC 13.2.1 20231014] (/usr/local/bin/python)
  jinja version = 3.1.3
  libyaml = True

COLLECTION VERSION

Collection      Version
--------------- -------
ansible.windows 1.14.0 

CONFIGURATION

CACHE_PLUGIN_CONNECTION(/home/yannik/projects/xxx/ansible/ansible.cfg) = .ansible_facts
CACHE_PLUGIN_TIMEOUT(/home/yannik/projects/xxx/ansible/ansible.cfg) = 60
CALLBACKS_ENABLED(/home/yannik/projects/xxx/ansible/ansible.cfg) = ['ansible.posix.profile_tasks']
COLLECTIONS_PATHS(/home/yannik/projects/xxx/ansible/ansible.cfg) = ['/home/yannik/projects/xxx/ansible/vendor_collections']
CONFIG_FILE() = /home/yannik/projects/xxx/ansible/ansible.cfg
DEFAULT_FORKS(/home/yannik/projects/xxx/ansible/ansible.cfg) = 25
DEFAULT_HOST_LIST(/home/yannik/projects/xxx/ansible/ansible.cfg) = ['/home/yannik/projects/xxx/ansible/inventory']
DEFAULT_MANAGED_STR(/home/yannik/projects/xxx/ansible/ansible.cfg) = This file is managed by ansible and will be overwritten! Do not change it manually!
DEFAULT_ROLES_PATH(/home/yannik/projects/xxx/ansible/ansible.cfg) = ['/home/yannik/projects/xxx/ansible/vendor_roles']
DEFAULT_STDOUT_CALLBACK(/home/yannik/projects/xxx/ansible/ansible.cfg) = yaml
DEFAULT_TIMEOUT(/home/yannik/projects/xxx/ansible/ansible.cfg) = 120
DIFF_ALWAYS(/home/yannik/projects/xxx/ansible/ansible.cfg) = True
EDITOR(env: EDITOR) = vim
HOST_KEY_CHECKING(/home/yannik/projects/xxx/ansible/ansible.cfg) = False
INTERPRETER_PYTHON(/home/yannik/projects/xxx/ansible/ansible.cfg) = auto_silent
PAGER(env: PAGER) = less
RETRY_FILES_ENABLED(/home/yannik/projects/xxx/ansible/ansible.cfg) = False

OS / ENVIRONMENT

Target OS: windows server 2022

[jborean93]

Are you able to try this out and see if it fails in the same way, if so what exact line is failing?

$adminGroup = (New-Object -TypeName System.Security.Principal.SecurityIdentifier -ArgumentList @( 
    "S-1-5-32-544")).Translate([System.Security.Principal.NTAccount]).Value 

$namespace = 'System.DirectoryServices.AccountManagement' 

Add-Type -AssemblyName $namespace 
$context = New-Object -TypeName "$namespace.PrincipalContext" -ArgumentList @( 
    [System.DirectoryServices.AccountManagement.ContextType]::Machine) 
$principal = New-Object -TypeName "$namespace.GroupPrincipal" -ArgumentList $context, $adminGroup 
$searcher = New-Object -TypeName "$namespace.PrincipalSearcher" -ArgumentList $principal 
$groups = $searcher.FindOne()

$groupMembers = $groups.Members.GetEnumerator()
$i = 0
while ($true) {
    try {
        if (-not $groupMembers.MoveNext()) {
            break
        }
        $g = $groupMembers.Current
        Write-Host "Group [$i] $($g.Name) - $($g.Sid)"
    }
    catch {
        Write-Host "Failed to enumerate group at ${i}: $_"
    }
    $i++
}

Do you see a group with a SID that ends with -500 in that output? Do you see the Failed to enumerate group at ... at any point?

[rhophi2000]

I've been seeing this same issue for over a year now.

I ran the script @jborean93 provided. it produced no errors, and i do see an account with a SID ending with -500.

[jborean93]

@rhophi2000 so you've been seeing the issue but the above code didn't have any problems, specifically it didn't show Failed to enumerate group at ...? If you run the code at

ansible.windows/plugins/modules/setup.ps1

Lines 847 to 864 in f1f2bcb

	$adminGroup = (New-Object -TypeName System.Security.Principal.SecurityIdentifier -ArgumentList @(
	"S-1-5-32-544")).Translate([System.Security.Principal.NTAccount]).Value
	$namespace = 'System.DirectoryServices.AccountManagement'
	Add-Type -AssemblyName $namespace
	$context = New-Object -TypeName "$namespace.PrincipalContext" -ArgumentList @(
	[System.DirectoryServices.AccountManagement.ContextType]::Machine)
	$principal = New-Object -TypeName "$namespace.GroupPrincipal" -ArgumentList $context, $adminGroup
	$searcher = New-Object -TypeName "$namespace.PrincipalSearcher" -ArgumentList $principal
	$groups = $searcher.FindOne()
	foreach ($user in $groups.Members) {
	if ($user.Sid.Value.EndsWith("-500")) {
	$machineSid = $user.Sid.AccountDomainSid.Value
	break
	}
	}

manually do you see any problems on the affected host?

[Yannik]

Hi all,

after quite a bit of research, I can now give you a summary of my findings:

First I tried to find out what the non-resolvable SIDs were. Turns out, you can enumerate them with ADSI:

# from setup.ps1
$adminGroup = (New-Object -TypeName System.Security.Principal.SecurityIdentifier -ArgumentList @(
         "S-1-5-32-544")).Translate([System.Security.Principal.NTAccount]).Value

$adminGroup = $adminGroup -replace '.+\\'
$group = [ADSI]"WinNT://$($env:computername)/$adminGroup"
$group.Invoke("Members") | foreach { $_.gettype().invokemember("name", 'getproperty', $null, $_, $null) }

Trying to further understand why a seemingly local group on a freshly installed DC contains unresolvable SIDs, I found out that on a DC, $adminGroup will contain the AD administrator group, not a local group. This is the case even if the AD administrators group was renamed.
As a matter of fact, this groups SID is of no use to determine the machine SID.
First of all, this AD group needs to exist (which it does by default, but it might've become deleted). Secondly, it needs to contains a user with SID ending in -500 (default AD administrator account)
Finally, this users SID always is DOMAINSID-500. Always resulting in returning the Domain SID as machine SID, which is obviously incorrect.

You can verify this by comparing ansible_machine_id to the domain SID.

It seems like the appropriate way to determine machine SID on a DC would be to use:

(Get-ADComputer $env:computername).SID

I have checked whether the Active-Directory Powershell Module is always installed on DCs, which seem to be the case, even if installing AD-Domain-Services without -IncludeManagementTools.

Looking forward to hearing your thoughts @jborean93