Migrating NT accounts with SID History - What happens when old domain is removed?

Discussion in 'Active Directory' started by Idris, Jan 18, 2008.

  1. Idris

    Idris Guest

    Hi,

    We're in the process of migrating users from our NT_Domain to our AD_Domain.

    At the moment i use ADMT v2 and migrate the SID history also.


    This means that when a user with the NT_Domain account has access to SHARE1
    on a server and his account is migrate he will still have permission due to
    the SID being the same.

    This is all working fine for me at the moment although a bit messy I feel?
    Anyway...


    My question is when we finally come to remove the NT_Domain will everything
    be ok? Will the permissions still work for the migrated users?


    Thanks.
     
    Idris, Jan 18, 2008
    #1
    1. Advertisements

  2. Idris

    Marcin Guest

    Idris,
    make sure that you translate the SIDs from the source domain to SIDs in the
    target domain before you decommission the old domain in order to secure
    resource access (as long as that's based on sIDHistory attribute)

    hth
    Marcin
     
    Marcin, Jan 18, 2008
    #2
    1. Advertisements

  3. Once you have completed the move and the old domain is gone you need to
    clean up your sidHistory. This isn't as simple as just going into ADSI edit
    and deleting entries, you have to use a script to do this.

    Microsoft has a script I have used before to help, just run from a command
    line with a parameter of the user to clean.
    http://support.microsoft.com/kb/295758
     
    Paul Bergson [MVP-DS], Jan 18, 2008
    #3
  4. Idris

    Idris Guest

    Thanks.


    I'll take a look at these.





     
    Idris, Jan 18, 2008
    #4
  5. This is a frequently misunderstood topic and there are many
    recommendations floating around that are stated as though they are
    requirements when they are, in fact, little more than a poor
    interpretation of best-practise. If the resources you're accessing are
    in the new domain and they are ACLed with the users and group SIDs from
    the old domain --> then yes, access will continue. To be clear here,
    you don't _need_ to clean SID history --> it is, however, not advisable
    to depend upon it but not because it won't work ... more for the sake of
    eliminating confusion and potential long-term issues related to trust
    .... beyond that, this is the way Windows was designed to work and it
    will conitnue to do so even with the original domain decomissioned.
     
    Dean Wells \(MVP\), Jan 18, 2008
    #5
  6. Idris

    Marcin Guest

    Idris,
    just to clarify, keeping old SIDs in the ACLs of your resources introduces
    unnecessary security risk (more on this subject and its alternative
    remediation method at http://support.microsoft.com/?kbid=289243) - so my
    recommendation would be to remove them (regardless how "unlikely" the
    exploit might be)...

    hth,
    Marcin
     
    Marcin, Jan 19, 2008
    #6
  7. To my mind, you misunderstand the article. The article's purpose is to
    draw attention to the existence of SID history and the fact that it
    _can_ be exploited should an articifical SID be injected into either an
    access token at runtime or, more likely perhaps, an offline DIT.
    Regardless, populating SID history with the SID of a user as it was in
    the user's original domain as part of a traditional migration has no
    baring on this potential avenue of attack; it still exists and it can
    still be exploited [the attribute is multi-valued]. Perhaps you're
    suggesting that some kind of pro-active monitoring of the attribute
    exist across each and every security principal in order to prevent any
    such attempt ... if so, my feeling is this is better addressed with the
    existing SID filtering solutions.
     
    Dean Wells \(MVP\), Jan 19, 2008
    #7
  8. My points related to this are within the new domain after the old domain is
    shut down. Permissions to access migrated objects are not easily seen if
    you use the standard gui tools. Dean has pointed out that by simply using
    the command prompt tools everything is well defined, but what I have found
    is people forget about sidHistory and to remember that it exists and/or even
    know it is there after people change positions can create unknown access.
    I'm not saying that people can/are elevating permissions just that
    sidHistory isn't always known, so that is why I am advocating removal. If
    you work in a large environment where 1000's or 10,000's of objects have
    been migrated this is pretty much not a reasonable request.

    So my opinion is to look at your migration and try as best you can to try
    and keep things as clean as possible.



     
    Paul Bergson [MVP-DS], Jan 22, 2008
    #8
  9. Idris

    Marcin Guest

    Dean,
    besides a number of other limitations (incidentally listed in the same
    article), enabling SID filtering precludes resource access based on the
    sIDHistory (scope of the impact would depend on domains/trusts involved). My
    recommendation was to perform SID translation in order to eliminate
    dependency on sIDHistory - so you can actually have the SID filtering turned
    on (which btw. happens to be the default for external trusts with Windows
    Server 2003 DCs).
    Marcin

     
    Marcin, Jan 23, 2008
    #9
  10. If I misunderstood -- my apologies ... but I still don't follow, you
    said -

    "before you decommission the old domain in order to secure resource
    access"

    .... why ... more specifically do you need to do so beforehand?

    That said, your perspective on what can be done still comes across as
    perhaps a little limited in scale and/or practice to me -- have you ever
    attempted to reACL the a medium to large enterprise (say 10,000 seats +
    minimum)? Are you familiar with the limitations imposed because of the
    inability to configure SID filtering beyond turning it on or off (added
    to that, the diffs. between quarantine mode and forest-level
    filtration)? How do you handle 3rd party applications that exploit the
    Windows authorization model that are not known to the reACLing tool?
    How do you handle mobile users?

    Believe me, I agree with your goal, it's the right one ... but the means
    to fully achieve it simply doesn't exist yet to the best of my
    knowledge.

    --
    Dean Wells [MVP / Directory Services]
    MSEtechnology
    [[ Please respond to the Newsgroup only regarding posts ]]
    R e m o v e t h e m a s k t o s e n d e m a i l


     
    Dean Wells \(MVP\), Jan 23, 2008
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.