admt migratie probleem met domain local groups

[mookie]

Ik ben 2 domeinen aan het migreren, interforest, en er is een 2-way trust maar met sid filtering actief.
Ik kan dus geen gebruik maken van sid history.

Tot zover gedaan:
Users overgezet (met sid history ook al kan ik dat niet gebruiken)
Groepen overgezet (met sid history...)
Users nog een keer overgezet (merge), deze keer in de juiste groepen laten plaatsen
Groepen nog een keer overgezet (merge), deze keer de juiste users/groepen in de groepen laten plaatsen
Security translation gedraaid op de file servers in add mode

Alles lijkt prima.
Laten we even uitgaan van dit scenario:
Domein A is het source domein, Domein B is het target domein waar we naartoe willen.
Fileserver zit op dit moment nog in domein A
User zit in groep en groep heeft rechten op een folder.

Alles via admt:
domeinA\user overgezet (dus gekopieerd want het is interforest) naar domeinB\user
domeinA\groep overgezet (dus gekopieerd want het is interforest) naar domeinB\groep
In domeinA\groep zit nog steeds enkel domeinA\user, en in domeinB\groep zit, door de ADMT, domeinB\user
Security translation heeft op de folder netjes domeinB\groep erbij gezet met dezelfde rechten als die domeinA\groep had.

Workstation gemigreerd van domein A naar domein B.
Profiel is netjes aangepast, zowel domeinA\user als domeinB\user hebben de juiste rechten.
Inloggen op nieuwe domein gaat ook prima.

Echter, als ik nu in de folder wil, dan heeft domeinB\user geen rechten op die folder.
Dat komt omdat domeinB\groep een "domain local group" is uit domein B en de folder\fileserver zit nog in domein A.
Sterker nog, normaal gesproken kun je niet eens "domain local groups" uit domein B toevoegen aan bestanden die op een server staan die in domein A zit.
Je kunt met speciale tooltjes, zoals admt, wel de SID van domeinB\groep toevoegen aan de ACL van de folder, maar dat doet niets.
Daarom zal de normale explorer interface het ook niet toelaten.

De oplossing is simpel, de local groups moeten ook gemerged worden.
Ik had eigenlijk verwacht dat ADMT dat zou doen, maar dat is dus niet zo.
Dus in domainA\groep moet zowel domeinA\user als domeinB\user, en in domeinB\groep moet zowel domainA\user als domeinB\user
Dat is de enige manier volgens mij dat ik users 1 voor 1 kan overzetten.
Ik kan ook niet even de fileserver overzetten naar domein B
Dan zou het probleem voor gebruikers uit domein B opgelost zijn, maar voor gebruikers uit domein A juist weer beginnen.

Het is bijzonder moeilijk hier informatie over te vinden.
De meesten zeggen gewoon dat je sid filtering maar even uit moet schakelen.
De ADMT guide heeft er ook weinig over te vermelden.
Het enige stukje onder "Determining Your Account Migration Process" zegt:

However, if SID filtering is enabled between your source and target domains and you do not trust the administrators in the source domain, you cannot disable SID filtering.
Nor can you use SID history to enable access to resources in the source domain.
In this case, you must use a different migration process.
You can choose one of the following three methods to migrate accounts between forests while maintaining user rights to access resources in the source domain:
- Migrate user accounts while using SID history for resource access. With this method, you remove SID filtering on the trusts between the domains to enable users to access resources in the source domain by means of their SID history credentials.
- Migrate all users, groups, and resources to the target domain in one step. For more information about this process, see Migrating Accounts While Using SID History, later in this guide.
- Migrate user accounts without using SID history for resource access, but translate security for all resources before the migration process to ensure resource access. For more information about migrating accounts without using SID history, see Migrating Accounts Without Using SID History, later in this guide.
Optie 1 is dus sid filtering uitschakelen, is geen optie
Optie 2 is alles in 1 keer, dat gaat ook niet lukken.
Optie 3 is wat ik wil, maar daar gaat het dus fout met domain local groups.
Optie 3 werkt alleen met domain global groups en niet met domain local groups.

Dus, heeft iemand anders wel eens een grote migratie gedaan en kwam hij dit ook tegen?
En wat zou dan de oplossing zijn?

Op dit moment probeer ik een script te schrijven die doet wat ik heb omschreven.
Alle domain local groups vergelijken, domein A users in domein B groepen, en domein B users in domein A groepen.
maar ik dacht, ik zal het toch hier eens even vragen...

[Semt-x]

Check met een tool als ADExplorer, of het SIDHistory veld van de objecten die je hebt gemigreerd in domeinB is gevuld.

Op het ingelogde werkstation in domeinB, vanaf cmd: whoami /groups > whoami-groups.txt
Hiermee kun je kijken welke tokens die gebruiker heeft, staan er SID's uit het oude domein bij?

Domain local groups zijn wel te migreren naar een ander domein. "domain local" duidt op de scope tijdens normale operatie, niet op het wel of niet te migreren.

h2h,
Sem

[mookie]

Handig tooltje, die ADExplorer, had ik nog niet eerder gezien.
En inderdaad, het "sIDHistory" attribuut bestaat en is ingevuld.
Maar lijkt mij dat ik daar niet zo veel aan heb, sid filtering is immers actief op de trust.

whoami/groups geeft enkel groups uit het lokale domein weer.
Lijkt me overigens ook al dat je helemaal niet de oude sids daar te zien krijgt, maar goed...

het probleem is ook niet dat domain local groups niet te migreren zijn...
Het probleem is als je een DLG uit domein B rechten geeft op een map die op een server in domein A staat, dan doet dat niks.
Normaal gesproken kun je niet eens een DLG uit een ander domein selecteren.
Maar ADMT (en ook andere tooltjes) plakken gewoon die SID in de ACL en dan kan het ineens wel.
Alleen het doet niets.... gebruikers die gemigreerd zijn en inloggen op het nieuwe domein hebben dus effectief geen rechten op de bestanden....

[Remco]

Kan je het niet scripten om een nieuwe groep te maken en die te laten vullen met de users ? Aan de hand van de leden van de oude groep ?

[mookie]

Jazeker, dat probeer ik nu zelf te maken.
Maar ik vind het zo vreemd dat er niets in de ADMT zelf zit die dit kan.
Het mooie aan interforest is dat het niet destructief is en dat je altijd terug kan naar de oude situatie.
Derhalve kun je ook stap voor stap migreren, maar blijkbaar werkt dat dus niet helemaal.

Er is hier verders niemand die ooit interforest heeft gedaan met SID filtering actief?