1

We have a PowerShell script that will enumerate the members of a specified AD group and then will create a text file with login ID and Name. The script will when create an email to Managers informing them of the membership of the AD Groups that manage there application/service. The issue we are having is with the following line:

Get-ADGroupMember -Identity $ADGroupName -Recursive |
    Get-ADUser -Properties * | Select-Object employeeID, name |
    Sort-Object name | Out-File -FilePath $Attachment

This will correctly create the file with the requested information when a user runs the script. The issue is when we attempt to run this script via a Scheduled Task using a gMSA. When running this under the gMSA, a zero-byte file is created. Changing the file creation line to:

Get-Service | Out-File -FilePath $Attachment

creates a file as expected so the issue appears to be the Get-ADGroupMember. Can a gMSA be used to query AD like this?

Our internal group that manages the MSA/gMSA accounts informs us everything should be working correctly. Our Security Group is preferring everything that needs some type of user context to be run via MSA/gMSA, since password management is not an issue.

Gabriel Luci
  • 38,328
  • 4
  • 55
  • 84
Star Gryphon
  • 11
  • 1
  • 3
  • Why would you believe it is only Get-AdGroupMember? What other Get-AD* cmdlets did you try. All ADDS users have read access/permissions to ADDS by default. What ADDS access/permissions are you setting for your MSA/gMSA accounts? The Get-Service use case you are running locally, and thus have local read access/permissions. So, not really an apples to apples comparison since you are not reaching accross the wire to a remote resource. – postanote Jun 08 '20 at 21:58
  • Get-ADUser looking up my network account creates a file with the expected data as does Get-ADgroup filtered to the same AG group that produces a zero byte file using Get-ADGroupMember. – Star Gryphon Jun 08 '20 at 23:11
  • Not sure if gMSA is able to call `Get-ADGroupMember` per MSDN: *A standalone Managed Service Account (sMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators.* – Riley Carney Jun 09 '20 at 00:17
  • So, you are running the task, and all Get-AD* stuff is working but *Group*, and you are running the task directly on the DC and not come remote host? That's just odd, as each of those is just getting an AD Object. As a rule of thumb, MSA/gMSA is really for local service stuff, not reaching across the wire to a remote resource. Curious, if you do this using the ADSI approach https://stackoverflow.com/questions/45351476/getting-ad-group-membership-adsi-using-powershell. – postanote Jun 09 '20 at 05:23

1 Answers1

0

The group that manages the gMSA/MSA accounts 'fixed' the issue by placing the gMSA in the Domain Users group. It looks like the Get-ADUser and Get-ADgroup command work without the gMSA in the Domain Users group but Get-ADGroupMenber requires it.

Star Gryphon
  • 11
  • 1
  • 3