Announcement

Collapse
No announcement yet.

Migration, ADMT, Built-in problem

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Migration, ADMT, Built-in problem

    Hi.

    I'm using admt to migrate one domain objects into another forest in some OUs. I've noticed two problems.

    1 ADMT doesn't touch built-in groups at all - after migration user that were members of Domain Admins, users are just ordinary users.
    Built-in group membeship is not migrated.

    2 After migration workstations, shares that were shared for built-in groups from source domain are still shared for them - SID translation doesn't work and in security tab there is always source domain name not target one (groups, users are already migrated). I've checked what is after removing trust between migrating domains - name is unresolved.

    Help me please

    (VBS or SID mapping changing in ADMT ?)

    Thank you

  • #2
    1 ADMT doesn't touch built-in groups at all - after migration user that were members of Domain Admins, users are just ordinary users.
    Built-in group membeship is not migrated.
    Indeed. This is by design. Builtin groups already exist in target domains, hence ADMT does not migrate those groups and that's the reason it does not take care of membership of those groups.

    2 After migration workstations, shares that were shared for built-in groups from source domain are still shared for them - SID translation doesn't work and in security tab there is always source domain name not target one (groups, users are already migrated). I've checked what is after removing trust between migrating domains - name is unresolved.
    ADMT does not change the ACL of the shares or files. You need to understand the notion of "sIDHistory" attribute. When an account is migrated using ADMT, it receives a new SID and it's sIDHistory attribute is populated with the user's old SID.
    When the user tries to access a resource in it's old domain (or ACL-ed using security principals from old domain), it will present it's OLD SID and will get access.
    Guy Teverovsky
    "Smith & Wesson - the original point and click interface"

    Comment


    • #3
      I know and understand it. But I'm thinking about smart solution.

      first problem I would like to solve writing scripts for every built-in group (it will be easier to debug than using one script for all). I would like to use VBScript, that will dump group membership to separate file for every group. After migration I will use another script to import this information and add members.

      Maybe someone did it and has such script. Maybe that solution is not the best.

      Second problem is for me more complex - I have many shares (DFS that pretends old 3 file servers - another nice solution) But that shares have built-in groups permissions and I don't know how many files and folders have separate settings for built in groups.
      I've read once about changing Sidmapping file just to translate SIDS for destination built-in groups but I don't like this solution , if someone has any idea how to solve it feel free to write it.

      Than you,

      guyt - thanks for answer

      Comment


      • #4
        Take a look at Security Explorer from Script Logic. I am almost sure it can do everything you want.

        The support folks are quite friendly and should give you a definit answer.

        Another approach (free one) might be trying to script the sidwalker utility:
        http://www.microsoft.com/technet/pro...9ff5ae554.mspx
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"

        Comment


        • #5
          Thanks,

          I probably won't make custmer buy security explorer - I'll try "set acl" to change that shares permissions.
          That sid walker could be very usefull. I didn't heard about it before I'll check it tomorow morning.
          I still have time to find best solution for my admt problems .

          Comment

          Working...
          X