OK, so after some Google/msdn/technet/soul searching, I found the answer (in bits and pieces), and so decided to post it here, for the future:
Users from trusted domains are represented as ForeignSecurityPrincipals (FSPs) in the domain we're operating in. These FSPs contain only the user's sID - in the distinguishedName, the Common name, etc. This is because the conversion from sID to a name is done in the domain where that account resides, and the trusting domain (where we're at) has no knowledge of it.. As such, what we need to do is find the account's sID.
Now, you'd think that the obvious property would be $acct.objectSid... but no... the trick is to use the old NTAuthority to do the conversion:
$acct = [System.Security.Principal.NTAccount]($Usr.sAMAccountName)
$acctsID = $acct.Translate([System.Security.Principal.SecurityIdentifier])
Now that you have the account's sID, all that's left is to add it to the group in the trusting domain:
$grp.add($acctsID). Right?
hmmm... not quite... turns out that to add the account with the sID form, it needs to be formatted as follows:
$grp.add("ldap://<SID=" + $acctsID.Value + ">")
Last, if you have a group populated with FSPs and you want to find out who these users are (programmatically, of course), then you can use this simple function, providing it the group member's distinguishedName property, and the domain where the account actually resides. What you will get back is the username in the form Domain\UserName.
function getAcctNameFromsID($AcctDN,$Dom) {
$Acct = [adsi]("ldap://$AcctDN")
$AcctSid = $Acct.cn
$AcctSidNT = [System.Security.Principal.SecurityIdentifier]($AcctSid.ToString())
$UserName = $AcctSidNT.Translate([System.Security.Principal.NTAccount])
if (!($UserName -eq $null)) {return($UserName)} else {return "Not Found"}
}
Gal.
Btw, If this can be done more easily using the Quest -qAD- cmdlets, feel free to post it here as an addendum. I have not seen any postings of it, and we do not use qAD in our environment.