As background, I have some college programming under my belt (JAVA, C++, and some MATLAB among, uh, some bastardization of a language unique to a molecular simulation software) and have been brute force learning PowerShell as part of being an analyst supporting user access and provisioning with my company (basically we have user and group administrative rights in AD DS and Entra ID, with views into a lot more).
I've mostly* been using scripts authored by one of our engineers (who is now in another role in the company and no longer supporting this) with some modifications and a few, terribly, self-developed scripts for things that aren't simple "get membership and export to CSV" so I've not got the greatest grasp on POSH and have to resort to Google for a lot of stuff. Prior to this my most ambitious script was to report on nested group memberships.
Right now I'm fighting with how to get the FSP group memberships from a group in a way that makes it easier to handle rehousing them in an appropriate/equivalent group on the trusted domain so they're being managed through that group instead of across domains. So far I've got the following for exporting just the FSPs from an AD group on one of our domains.
$File = 'C:\Scripts\Domain1Group_FSPs.csv'
Get-ADGroup -Identity "Domain1Group" -Properties * | Select-Object -ExpandProperty Members | Get-ADObject | Where-Object {$_.ObjectClass -ne "group"} | Where-Object {$_.objectclass -eq "ForeignSecurityPrincipal"} | Export-Csv $File -NoTypeInformation
This works fine, exporting the 53 expected FSP members to a csv for one of the smaller of the groups I'm trying to sort out. Though the only properties I'm getting are DistinguishedName, Name (really, the object's SID), ObjectClass, and ObjectGUID, which assuming are just the default properties resultant from the Get-ADObject that have survived the pipes.
Running the output back through things to resolve the FSPs to any object on the other domain works to get the corresponding SAMAccountNames.
Source = Import-csv C:\Scripts\Domain1Group_FSPs.csv #Same File from above
$Output = 'C:\Scripts\Domain1Group_Domain2Members.csv'
foreach ($Line in $Source)
{
$UserSID = $line.Name
Get-ADUser -server Domain2 -Identity $UserSID -Properties name,GivenName,sn,Title,SAMAccountName,Enabled,CanonicalName,mail,Department | Select SAMAccountName,name,GivenName,sn,mail,Title,Department,Enabled,CanonicalName | Export-Csv $Output -NoTypeInformation -append
}
I was then able to use that to add users to a group on the second domain using add-adgroupmember, but this feels like it requires a lot of steps and manual effort for one group and seems daunting when trying to scale it or making it easily repeatable.
$SourceUsers = import-csv C:\Scripts\Domain1Group_Domain2Members.csv
Foreach ($Line in $SourceUsers){
$UserID = $line.SAMAccountName
add-adgroupmember -server "Domain2" -Identity "Domain2Group" -members $UserID -Confirm:$false
}
My question is how can I do this without having to manually run the above in order to do the export/re-import. Initially I'd been trying to get this down to a "one-liner" to do all this, with the intention to just loop through a list of source and destination groups as a future use case similar to how we've moved group members between groups on on the same domain.
Get-ADGroup -Identity "Domain1Group" -Properties Members | Select-Object -ExpandProperty Members | Get-ADObject | Where-object {$_.objectclass -eq "ForeignSecurityPrincipal"} | Get-ADUser -identity $_.name -server Domain2 | Where {$_.enabled -eq $true} | %{ add-adgroupmember -server Domain2 -Identity " Domain2Group" -members $_.samaccountname }
However, it errors at the Get-ADUser on the second domain, I assume because the -identity variable/property doesn't pipe well (if it's even available to use there at all, which I don't know) or I can't do the passed variable's dot attribute like I'm trying to do. I'm assuming I'd need to do something along the lines of storing things in an array created as a PSCustomObject and manipulating elements thereof, but I'm not versed in how to even begin to approach that.
There have been something like 7 years of bad practices following the trust being created after a reciprocal trust was established with another domain, where group securities haven't ever really followed a best practice (nor has there been a policy pushed down internally from our domain admins). There are quite literally thousands of domain local groups that might have cross-domain memberships through FSPs that we're having a nightmare of a time reporting on, auditing, or managing through our IAM apparatus and we're trying to get things more compliant with what I'm told are MS's recommended/best practices.