-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ActiveDirectoryDsc: ADGroup still fails with members with foreign security principals in v6.2.0-preview0001 #654
Comments
@X-Guardian do you have time to look at this issue, if this solves the pending PR (in draft) from you? Labeling this as a bug and help wanted so someone in the community can work on this. |
No, this is not related to the pending ADGroup PR I have open. @dslcleve, can you post the output from |
I ran Get-ADGroup and Get-ADGroupMember on the command line in a powershell window. Oddly the Get-ADGroupMember returns 0 instead of 8224. I added the log from the DSC and have some debug messages to confirm that it returns 8224 (See the DEBUG messages) Get-ADGroup -Properties * -Identity Role_Admins
|
Thanks @dslcleve. Can you output the full error object you are receiving in the DscResource? You can do this by adding |
Here you go, thanks. VERBOSE: [TESTADML]: LCM: [ Start Resource ] [[ADGroup]Role_Admins] Server stack trace: Exception rethrown at [0]: Server stack trace: Exception rethrown at [0]: |
This hasn't got the JSON output of the error object in it. You need to run |
Sorry, here it is: VERBOSE: [TESTADML]: [[ADGroup]Role_Admins] DEBUG1 FullyQualifiedErrorId: ActiveDirectoryServer:8224,Microsoft.ActiveDirectory.Management.Commands.GetADGroupMember
|
Hi @X-Guardian, have the outputs helped? I found this: https://stackoverflow.com/questions/29808611/get-adgroupmember-stopped-working-for-some-users and it seems like 8224 is an error for the same problem, i.e. foreign security principals as members of the group. I have multiple groups and some succeed because it returns with 0 instead of 8224. The groups are all created via DSC in one automation run and some even in the same loop, therefore same code and same user. The foreign security principals are manually added after creation to the groups. They can be different users, but they are all from the same domain. Can 6.2.0 be updated to also check for 8224? |
Details of the scenario you tried and the problem that is occurring
We have ADGroup DSC resources that create several groups in different OUs. After some of these groups are created by DSC, we manually add cross-domain members (foreign security principals). With ActiveDirectoryDsc version 6.0.1, we get errors as specified here: #619. We upgraded to ActiveDirectoryDsc version 6.2.0-preview0001. The number of these errors went from 20s to under 10.
The fix in 6.2.0 for this problem checks specifically for the following in Get-TargetResource in MSFT_ADGroup.psm1:
$oneWayTrustFullyQualifiedErrorId = 'ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADGroupMember'
But for some reason that I haven't determined, some of the groups return the following error instead (0 vs 8224):
ActiveDirectoryServer:8224,Microsoft.ActiveDirectory.Management.Commands.GetADGroupMember
Verbose logs showing the problem
Following is a snippet of the logs for one of the groups. I replaced the group name to XXXXX:
Suggested solution to the issue
I did the following in Get-TargetResource in MSFT_ADGroup.psm1 and it remedied my problem:
The DSC configuration that is used to reproduce the issue (as detailed as possible)
# insert configuration here
The operating system the target node is running
Version and build of PowerShell the target node is running
Version of the DSC module that was used
ActiveDirectoryDsc 6.2.0-preview0001
The text was updated successfully, but these errors were encountered: