ansible.windows icon indicating copy to clipboard operation
ansible.windows copied to clipboard

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

Open Yannik opened this issue 2 months ago • 3 comments

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

https://github.com/ansible-collections/ansible.windows/blob/f1f2bcb7bbd605a6e85b6dcd02fa6ffe588886ee/plugins/modules/setup.ps1#L847-L857

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

Yannik avatar Apr 23 '24 20:04 Yannik

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?

jborean93 avatar Apr 25 '24 21:04 jborean93

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.

rhophi2000 avatar May 07 '24 19:05 rhophi2000

@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 https://github.com/ansible-collections/ansible.windows/blob/f1f2bcb7bbd605a6e85b6dcd02fa6ffe588886ee/plugins/modules/setup.ps1#L847-L864 manually do you see any problems on the affected host?

jborean93 avatar May 19 '24 21:05 jborean93

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

Yannik avatar May 23 '24 09:05 Yannik