I recently ran into some strange results while writing an audit script. A user from domain A was listed as a member of the Domain Admins group from Domain B - thats not possible! Then I noticed another users DN was in Domain A but the NTAccountName attribute was DomainB\<userName>.
So whats going on then?
I guessed that SIDHistory was coming into play here. Personally I hate SIDHistory but trying to get others to not to use it is next to imppossible. Everyone like to take the easy route and just import SIDHistory. In testing years back I remember that looking at the local administrator group on a server would show different user IDs as you moved the server from one domain to another and in a multimaster domain model (I think that was what it was called - it was so long ago now) the user name could change from one refresh to another as what really happens is the SID is used to lookup the user and the user displayed is dependent on the trust and DC at the end of the trust you use to resolve the name.
How to fix this then? Well actually it's simple just make sure you are explicit in your connection strings when using the quest cmdlets.
for each domain you want to interogate I usually setup a connection (or I do now :-))
if I need alternate credentials then I use Get-Credentials
$domainACreds = get-credentials
$domainBCreds = get-credentials
$arsCredentials = get-credentials
$domainAconnection = Connect-QADService -service "domainA.com" -credentials $domainAcreds
$domainBconnection = Connect-QADService -service "domainB.com" -credentials $domainBcreds
$arsConnection = Connect-QADService -service "arsServer.domainA.com" -credentials $arsCredentials
then when you use a cmdlet just use the -connection parameter with the requisite connection variable. This also allows a single line of code if you preceed it with a switch statement checking for the user domain.
Switch ( $member.DomainName ) {
"DomainA" { $connectionToUse = $domainAconnection ; break }
"DomainB" { $connectionToUse = $domainBconnection ; break }
Default { Write-Host "Connection Unknown " -ForegroundColor Yellow -BackgroundColor Black }
} # Switch ( $member.DomainName ) {
If you don't do this then the cmdlet uses the last connection used so if you were expecting results from domainA and the last connection was to domainB you won't get back any accounts from domainA.
Using this also appears to fix the SIDHistory "bug" which kicked off this whole discussion.
If you are just using the proxy connection then you can use the -searchroot parameter to target a specific domain otherwise that too can produce unexpected results when searching using non fully qualifies attributes, e.g searching for <username> instead of <domain>\<username>. the former will return as many matches as it can across all managed domains.
For those of you with single domains it's still good practice to do this I think as you never know when a merger or acquisition will break one of your scripts or worse the script works but is silently ignoring users becasue it's not handling the naming conflicts well.
