Re: ACL's and permissions viewed after Migrating from NT 4 domain... The twilight zone?

From: Dmitri Gavrilov [MSFT] (dmitrig@online.microsoft.com)
Date: 02/13/03 

From: "Dmitri Gavrilov [MSFT]" <dmitrig@online.microsoft.com>
Date: Thu, 13 Feb 2003 10:10:31 -0700

When you migrated the user, the NT4 sid that was assigned to him was added
to the new w2k user's sid history. ACLUI cracks the SID it got from the ACL
against the AD, and it is able to find the new user by the old SID, because
it also checks the sid history when attempting to crack a sid to a user. 

-- 
Dmitri Gavrilov
SDE, Active Directory Core
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Angel_Venjador" <notengo@nohay.es> wrote in message
news:OeL3MS00CHA.2552@TK2MSFTNGP12...
> Hi,
>
>
>
> we're currently migrating our NT 4 domain to AD using ADMT from Microsoft.
>
>
> Everything is fine, except for what is viewing ACL's after migration.
>
>
> The ADMT documentation says :
>
> The security on resources does not need to be translated before the source
> account is deleted. However, for cosmetic reasons, you will most likely
want
> to translate security before deleting the source account. Once the source
> account is gone, the resource will no longer be able to resolve the SID to
a
> name and the security properties will show as "account unknown". The
access
> will still work, but you can't resolve the SID name. If you upgrade the
> resource domain to Windows 2000, Windows 2000 will be able to detect the
SID
> History and resolve the name properly. So, over time, you will want to
> manually clean up SID History and grant access to the new security
> principals.
>
>
> The problem (or good thing) is that these cosmetic reasons that ADMT help
> says are not right!!!!! in fact, after giving access in a file that is in
an
> AD DC to a NT4 domain user, if this NT4 user has been migrated keeping
> sidhistory, if we view the permissions of these file then the permissions
> are aparently set to the AD user, not the NT4 user!!
>
>
> This is really astonishing since we EXPLICITELY gave permissions to the
NT4
> USER!!!
>
>
> Any one has an explanation?
>
>
> This happends even if we delete the NT4 domain user!!!! permissions are
> always said to be given to the AD user!! and if then we explciitely set
> permissions to the AD user, we can see that permissions are set to the AD
> user TWICE!!!!!
>
>
> I'd like to know so why does the GUI shows the DA user instead of the real
> user the ACL's are been given to... Why does it interprets so badly the
> SID's?
>
> IS IT A BUG?
>
>

Relevant Pages

  • Access to Exchange 2003 from NT4
    ... migration I shall be migrating user accounts from Nt4 to 2003 with SID ... SID history they wold still be able to access Exch2003 mail using NT4 ...
    (microsoft.public.exchange.setup)
  • User access to Exch2003 from NT4 accounts
    ... migration I shall be migrating user accounts from Nt4 to 2003 with SID ... SID history they would still be able to access Exch2003 mail using NT4 ...
    (microsoft.public.windows.server.migration)
  • Re: ACLs and permissions viewed after Migrating from NT 4 domain... The twilight zone?
    ... And if I decomission the old NT4 domain this should ... > (the little problem I have noticed is that if you give permissions to both ... >> to the new w2k user's sid history. ... >> it also checks the sid history when attempting to crack a sid to a user. ...
    (microsoft.public.win2000.security)
  • Re: Migrating accounts nt4 to 2k3 and SIDs
    ... to my knowledge there is no need to disable SID filtering on the outgoing ... trust side because on that side is the NT4 side and SID filtering is ... Migrated users with sid history and fixing group membership ... histories work with my user accounts. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Keeping desktops when changing domains
    ... If you are not migrating your resources to the new domain then you will need ... not to use SID history. ...
    (microsoft.public.windows.server.active_directory)