Group: Unable to add Different forest User to Local Group

[ld0614]

I am running the following resource
       Group AddUser
    {
            GroupName = "Administrators"
            MembersToInclude = @("DOMAINB\USER1")
    Credential = $DomainBCredential
            Ensure = 'Present'
    }

There are two forests with a single domain each, Computer1 is in domainA and user1 is in domainB. There is a full trust relationship between domains, it should be noted that NETBIOS name is not the same as FQDN on either forest.

I am attempting to add User1 to the local administrators group on Computer1. It should be noted that a number of additional users from domainA are already added into the Computer1 administrative user group via Group Policy, there are also a number of orphaned SIDs. This operation succeeds if done manually.

The credential is to another account on DomainB and has domain admin rights. When running the code I get the following error:

VERBOSE: [COMPUTERNAME]: [[Group]AddUser] Resolving DOMAINB in the Domain Admins domain.
Exception calling "FindByIdentity" with "3" argument(s): "The user name or password is
incorrect.
"
+ CategoryInfo : NotSpecified: (:) [], CimException
+ FullyQualifiedErrorId : COMException,ResolveSidToPrincipal
+ PSComputerName : COMPUTERNAME.DOMAINA.com

When running the exact same configuration using the xGroup resource the configuration resolves and runs correctly. All parameters where kept in memory so the actual username and password couldn't have had a typo. Unfortunately there is a secondary issue with xGroup which I'll post separately.

[ld0614]

Apologies, I realized that was was using the builtin Group Resource and not the version from this page, I have since updated but unfortunately continue to get a failure. I am running Version 2.8.0.0 of the PSDSCResource Module with PowerShell 5.1 on Windows Server 2012 R2.

Unfortunately there are 2 unresolved SIDs already in the Administrators group, the Test and Set Methods successfully flag these with a warning. The DomainB Group member is also successfully resolved according to the verbose output.

The error message I get is:
VERBOSE: [COMPUTERNAME]: LCM: [ End Set ] [[Group]AddUser] in 3.9420 seconds. PowerShell DSC resource MSFT_GroupResource failed to execute Set-TargetResource functionality with error message: Exception calling "Add" with "1" argument(s): "An error (1332) occurred while enumerating the group membership. The member's SID could not be resolved." + CategoryInfo : InvalidOperation: (:) [], CimException + FullyQualifiedErrorId : ProviderOperationExecutionFailure + PSComputerName : COMPUTERNAME.DOMAINA.com

My guess is that the set command is attempting to re-add the unknown SIDs in which is failing. Is it possible to update to allow this scenario to work please?

[shurick81]

I had this issue

VERBOSE: [COMPUTERNAME]: [[Group]AddUser] Resolving DOMAINB in the Domain Admins domain. Exception calling "FindByIdentity" with "3" argument(s): "The user name or password is incorrect.

I fixed it by using "domain\username" format when login for "Credential" parameter.

[ld0614]

To do further testing I have set up a lab environment with A domain controller and a separate VM in each DomainA.Local and DomainB.Local. On DomainA-VM-01 I ran the following configuration:

configuration AddUserToGroup
{
    Import-DscResource -ModuleName PSDSCResources
    Node $AllNodes.NodeName
    {
        Group AddGroup
        {
            GroupName = "localgroup"
            MembersToInclude = "DomainB\DomainB-User1"
        }       
    }
}

When the GroupName was set to localgroup (which was a specific local group I created) the operation succeeded however when setting GroupName to Administrators the operation failed with the following message:

VERBOSE: An LCM method call arrived from computer DOMAINA-VM-01 with user sid S-1-5-21-3810035134-3837839851-1744469092-500.
VERBOSE: [DOMAINA-VM-01]: LCM:  [ Start  Set      ]
VERBOSE: [DOMAINA-VM-01]: LCM:  [ Start  Resource ]  [[Group]AddGroup]
VERBOSE: [DOMAINA-VM-01]: LCM:  [ Start  Test     ]  [[Group]AddGroup]
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Invoking the function Test-TargetResourceOnFullSKU for the group Administrators.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] A group with the name Administrators exists.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving DomainAAdmin as a local account.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving Domain Admins in the domain DOMAINA.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving DomainB-Group1 in the domain DOMAINB.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving DomainB\DomainB-User1 with domain trust.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] MembersToExclude is empty. No group member removals are needed.
VERBOSE: [DOMAINA-VM-01]: LCM:  [ End    Test     ]  [[Group]AddGroup]  in 5.7340 seconds.
VERBOSE: [DOMAINA-VM-01]: LCM:  [ Start  Set      ]  [[Group]AddGroup]
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Begin executing Set functionality on the group Administrators.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Performing the operation "Set" on target "Group: Administrators".
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving DomainAAdmin as a local account.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving Domain Admins in the domain DOMAINA.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving DomainB-Group1 in the domain DOMAINB.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Resolving DomainB\DomainB-User1 with domain trust.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] MembersToExclude is empty. No group member removals are needed.
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Adding Group Member
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Group to be added to: Administrators
VERBOSE: [DOMAINA-VM-01]:                            [[Group]AddGroup] Principal to be added: Domain B User 1
VERBOSE: [DOMAINA-VM-01]: LCM:  [ End    Set      ]  [[Group]AddGroup]  in 10.7750 seconds.
PowerShell DSC resource MSFT_GroupResource  failed to execute Set-TargetResource functionality with error message: Exception calling "Add" with "1" argument(s): "The 
network path was not found.
" 
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : ProviderOperationExecutionFailure
    + PSComputerName        : DomainA-VM-01
 
VERBOSE: [DOMAINA-VM-01]: LCM:  [ End    Set      ]
The SendConfigurationApply function did not succeed.
    + CategoryInfo          : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : MI RESULT 1
    + PSComputerName        : DomainA-VM-01
 
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 16.853 seconds

I can manually add the user into the administrators group and when I do the test resource completes successfully.

Looking at the code it appears that the actual add command is failing which is here

To assist with debugging I added the following lines just above the add command:

	Write-Verbose "Adding Group Member"
	Write-Verbose "Group to be added to: $Group"
	Write-Verbose "Principal to be added: $MemberAsPrincipal"

You can see in the verbose output above that the user was successfully resolved from DomainB\DomainB-User1 to Domain B User 1 which is the user's full name.

[mbreakey3]

I apologize for the long delayed reply. The reason you are seeing the first error (at least) is because when you run the configuration, DSC runs Test-DscConfiguration. If you have members to include or members to exclude as part of the config, then DSC must iterate through the members of the Group to check if the indicated members are present/absent to test if the node is in the desired state. To compare the members accurately, the Group resource attempts to get the SIDs of each user in the group to compare, if there are any issues getting the SIDs of any of the members or if the user running the command doesn't have permissions to access all of the user information in the group, then you're going to get an error before Set-DscConfiguration even runs. When you manually add the users you're not doing any test to see if the user already exists in the group so the operation succeeds.

I'm not sure about the second error that you're seeing though. What exactly is different about the nature of the two different groups you are testing with?

[johlju]

@ld0614 Thanks for the detailed configuration and verbose output. I label this as a 'bug' and 'help wanted' so anyone in the community can run with this issue.

[SDedik]

Hello,
I know that is this is quite old issue, but I stumbled upon it as well and this is quite important for my environment, so I decided to try and resolve it.

First some observations. Assuming I have myDomain.local and foreignDomain.local and the computer I am running the resource on belongs to myDomain. Domains have trust relationships established, obviously.
The group I am working with is built-in Administrators group. Lets say its initial members are: Administrator, Domain Admins and I am running resource like this

Invoke-DscResource -Name Group -ModuleName PSDscResources -Method Set -Property @{GroupName = 'Administrators'; MembersToInclude = @('myDomain\user1', 'foreignDomain\user2')} -Verbose

This works successfully. Moreover, in the verbose output it can be seen that security principals are successfully resolved from local SAM database, myDomain and foreignDomain.

Now lets make state of the group following: Administrator, Domain Admins, myDomain\user1 and run resource like this adding only account from foreignDomain:

Invoke-DscResource -Name Group -ModuleName PSDscResources -Method Set -Property @{GroupName = 'Administrators'; MembersToInclude = @('foreignDomain\user2')} -Verbose

This also succeeds. This is important, above two cases prove that resource can work with foreign accounts and is able to use domain trusts successfully.
Now lets revert is and make initial group state like so: Administrator, Domain Admins, foreignDomain\user2 and run the resource:

Invoke-DscResource -Name Group -ModuleName PSDscResources -Method Set -Property @{GroupName = 'Administrators'; MembersToInclude = @('myDomain\user1')} -Verbose
...
PowerShell DSC resource MSFT_GroupResource  failed to execute Set-TargetResource functionality with error message: Exception calling "Add" with "1" argument(s): "The network path was not found."

Literally any attempts to run resource against group which already has security principals from other domain fails. Specifying Credentials parameter does nothing. Substituting users with groups does nothing. Examining $PrincipalContextCache and verbose logs proves that security principals are resolved successfully, that domain trusts do work, that $PrincipalContext and $PrincipalContextCache are exactly the same as in the cases where accounts were added successfully.
It all fails inside the Add-GroupMember function on this line:

$Group.Members.Add($MemberAsPrincipal)

It appears like a bug in underlying .net classes and no matter how I struggled, I couldn't make Add method work if System.DirectoryServices.AccountManagement.PrincipalCollection already has foreign members in it.

The solutions I see at the moment are:

1. Notify Microsoft about this PrincipalCollection class behavior and hopefully let them acknowledge and fix the issue because I see no flaws or broken logic in the powershell dsc resource implementation. If anybody has any connections/channels to let Microsoft know - that would be awesome because I don't have any.
2. Ditch the System.DirectoryServices.AccountManagement namespace for the Add operations and where else is applicable and use ADSI WinNT provider instead https://docs.microsoft.com/en-us/windows/win32/adsi/adsi-winnt-provider This will make sure that resource is consistent and clean, but that will require more work and thorough testing.
3. We can wrap faulty line into try-catch block and fallback to ADSI provided only when this specific issue is encountered:

function Add-GroupMember
{
    [CmdletBinding()]
    param
    (
        [Parameter(Mandatory = $true)]
        [ValidateNotNull()]
        [System.DirectoryServices.AccountManagement.GroupPrincipal]
        $Group,

        [Parameter(Mandatory = $true)]
        [ValidateNotNull()]
        [System.DirectoryServices.AccountManagement.Principal]
        $MemberAsPrincipal
    )

    try
    {
        $Group.Members.Add($MemberAsPrincipal)
    }
    catch
    {
        Write-Verbose "Hit the The network path was not found error"
        [ADSI] $adsiGroup = ("WinNT://$env:COMPUTERNAME/$($Group.Name),group")
        $adsiGroup.Add("WinNT://$($MemberAsPrincipal.Sid)")
    }
}

I tested this third approach in my environment and it works great, however I would like to hear opinion from more experienced colleagues about it. Also, more careful checks might be required to validate if we indeed hit this issue rather than simply catching all exceptions.

Looking forward to hearing from maintainers to finally get this issue resolved.

[Sudman1]

@SDedik - That looks like a good workaround to the problem. I'd love to see you put a Pull Request in for it. I'll go ahead and review it as soon as I'm notified.

[SDedik]

@Sudman1, PR has been created. Please have a look. I'm not sure if any kind of automated tests can be developed for this kind of problem because it heavily depends on external infrastructure layout, therefore I made the PR without any additional tests.