Security Principal Translation op remote GC

[YellowOnline]

Op het eerste zicht lijkt dit in het Powershelltopic thuis te horen, maar de vraag is iets te gespecialiseerd daarvoor denk ik en ik worstel er al heel lang mee.

Ik heb een script dat zich met de Global Catalog verbindt en van een gebruiker de het tokenGroups opvraagt. De verbinding zelf gebeurt als volgt:

PowerShell:

New-Object System.DirectoryServices.DirectoryEntry('GC://DC=tweakers,DC=net')

We eindigen met:

PowerShell:

$TokenGroups = $User.Get("tokenGroups")
$Groups=@{}
ForEach ($Token in $TokenGroups)
            {
            $Principal = New-Object System.Security.Principal.SecurityIdentifier($Token,0)
            $Group = $Principal.Translate([System.Security.Principal.NTAccount])
            $Groups[$Group] = 1
            }
$Groups.Keys

Werkt perfect.

Nu hetzelfde met een remote verbinding:

PowerShell:

New-Object System.DirectoryServices.DirectoryEntry('GC://172.0.0.1/DC=tweakers,DC=net', $Username, $Password, 1)

Werkt perfect tot aan de translation. Vanaf dan:

code:

Exception calling "Translate" with "1" argument(s): "Some or all identity references could not be translated."At
line:4 char:1
+ $Group = $Principal.Translate([System.Security.Principal.NTAccount])
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

Wie kent de architectuur van AD goed genoeg om uit te leggen wat hier het probleem is?

[Brahiewahiewa]

Is er een reden waarom je persé naar een GC wilt connecten?
Ik zou proberen

PowerShell:

New-Object System.DirectoryServices.DirectoryEntry('LDAP://172.0.0.1/DC=tweakers,DC=net', $Username, $Password, 1)

[YellowOnline]

Brahiewahiewa schreef op zaterdag 16 januari 2016 @ 02:47:
Is er een reden waarom je persé naar een GC wilt connecten?
Ik zou proberen

PowerShell:

New-Object System.DirectoryServices.DirectoryEntry('LDAP://172.0.0.1/DC=tweakers,DC=net', $Username, $Password, 1)

Ja - omdat het een forest is met heel veel subdomeinen. Als ik met LDAP verbind krijg ik bijvoorbeeld wel de juiste data terug voor gebruikers uit TWEAKERS.NET, maar ik krijg niets terug als ik wat opvraag van een gebruiker uit PW.TWEAKERS.NET of GOT.TWEAKERS.NET.

[ Voor 20% gewijzigd door YellowOnline op 16-01-2016 21:47 ]

[Brahiewahiewa]

Wat ik kan verzinnen is dat de tokens die je opvraagt niet gerepliceerd worden naar de GC.
Als je in je eigen domain die tokens opvraagt, gebruik je het secure channel wat je per definitie als gebruiker in dat domain al hebt. Als je het vanuit een ander domain wilt uitlezen, moet je een DC uitkiezen en daar een secure channel mee opzetten.

Voor de zekerheid: dit is speculatie. Ik weet niet precies wat er wel en niet wordt gerepliceerd naar een GC.
Maar d'r is op msdn vast wel een documentje te vinden waar dit haarfijn wordt uitgelegd

[Razwer]

Brahiewahiewa schreef op zondag 17 januari 2016 @ 01:00:
Wat ik kan verzinnen is dat de tokens die je opvraagt niet gerepliceerd worden naar de GC.

Je zit in de goede richting.
Het Powershell script runt in domain A
Tokengroups worden opgevraagd in domein B. De opvraag wordt een target mee gegeven.
De translation wordt geen/kan geen target mee gegeven worden. Waar vind de translation dus tegen plaats? Domain A. Daar gaat het dus fout.

Best bet (indien mogelijk) is een invoke-command doen met een return terug in je script en daar vanuit verder borduren.

Edit: beetje googlen vond deze 3rd party cmdlet. Die kan sid translaten op een expliciet target
http://www.vexasoft.com/pages/resolve-sid

[ Voor 13% gewijzigd door Razwer op 19-01-2016 10:43 ]

[YellowOnline]

Razwer schreef op dinsdag 19 januari 2016 @ 10:36:
[...]
Je zit in de goede richting.
Het Powershell script runt in domain A
Tokengroups worden opgevraagd in domein B. De opvraag wordt een target mee gegeven.
De translation wordt geen/kan geen target mee gegeven worden. Waar vind de translation dus tegen plaats? Domain A. Daar gaat het dus fout.

Best bet (indien mogelijk) is een invoke-command doen met een return terug in je script en daar vanuit verder borduren.

Edit: beetje googlen vond deze 3rd party cmdlet. Die kan sid translaten op een expliciet target
http://www.vexasoft.com/pages/resolve-sid

Aha, ik snap het, dank u. Eigenlijk logisch: het systeem probeert de SIDs te resolven tegen zijn eigen System.Security.Principal namespace.

Die third-part cmdlet toont vooral aan dat er gemakkelijk geld te rapen valt voor mensen zoals mij Nee, ernstig, dat is een schandaal: geld vragen voor cmdlets.

Wait-KeyPress
Waits (pauses the session) until a user presses a key. For use in scripts.

Kom nou, dat is gewoon geld vragen voor deze regel:

PowerShell:

$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

Ik veronderstel dat ze het inderdaad doen zoals jij zegt: met een invoke command. Ik zal het ook zo doen en dan publiek maken op mijn blog. Met de naam Resolve-SID. Met de groeten aan Vexasoft. Grmblz.