ADMT V2 and access denied from resource domain

[David Missen]

I am trying to migrate a Windows 200 AD (Root and 3 Child domains) to
a single Windows 2003 AD.

I have setup Trusts between my new 2K3 Domain and all of the W2k
domains (The ADMT Trust Migration wizard confirms this) and all the
trusts verify.

I have also created the necessary group in my source domain
(DomainName$$$) and added the TcpipClientSupport Registry entry.

I have migrated an account from the Root domain of W2K to the new W2K3
AD and when I logged in to the 2K3 domain this account can access
resources in the 2K root but not resources in one of the child domains
that it should be able to access.

I have checked with ADSIedit that the SIDHistory has migrated ,and I
have also used the W2K3 resource kit tool Showacls.exe against the
directory in the child domain that shows w2k3domain\user as having
full access to the directory, but still when I try to map a drive I
get an "access denied" mesage. (The drive does subsequently appear in
Explorer and at a command prompt when I issue a net use command.)

Anyone got any ideas?

Thanks

[Bob Qin [MSFT]]

Hi David,

Thanks for your posting here.

Please verify the trusts relationship in "Active Directory Domains and
Trusts", what is the result?

In addition, how did you set the NTFS permission and Share permission on
the resource?

Please create a new share and add the original user account in the
permission list. Now logon the target domain and try again. What is the
result? How about adding the new user account in the permission list?

More information.

816301 HOW TO: Create an External Trust in Windows Server 2003
http://support.microsoft.com/?id=816301

Best regards,

Bob Qin
Product Support Services
Microsoft Corporation

Get Secure! - www.microsoft.com/security

====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[David Missen]

Thanks for the reply.

The trusts verify ok in AD domains and trusts.

I noticed that the migrated user did not have access to their
resources in the child domains e.g Their mailbox resides on a EX2K
server in one of the child domains and they cannot access existing
shares to which they should have access in this domain either.

The particular share\folder that I am describing in the email is a new
share that I created for testing purposes. The folder is in a child
domain and permissions were granted to W2kParentDomain\user just as
the existing shares.

Using the showacls.exe against this newly created share shows
w2k3domain\Migrated user as having the permissions to the share/folder
so I believe the SID history is working as intended....However the
user cannot gain access to the share/folder.

I will try and grant the w2k3domain\migrated user access to the
share/folder directly. I suspect that this will work because I had to
add the w2k3\administrator account to the administrators group in the
w2K domain from which I am migrating the account. (so the principle of
adding accounts from W2K3 to W2K resources is established)

I assume what I am trying to do here should actually work, shouldn't
it?

[Bob Qin [MSFT]]

Hi David,

Showacls.exe only show the NTFS permissions. How about the share
permissions?

In addition, please save the attachment on your computer and extract the
mytoken.exe. Logon as the w2k3domain\Migrated user and run the mytoken.exe
tool. Please paste the result in your post.

Have a nice day!

Regards,

[David Missen]

Hi.

Firstly, many thanks for the assistance.

Secondly, I need to eat a small slice of humble pie (Maybe even a
large slice!). I re-checked the access to the existing resource in the
W2K parent Domain and this was being determined by the presence or
absence of "Everyone" in either the share or NTFS permissions. So, my
original contention that SID History was working was simply wrong
...Sorry!

I have carried out further tests and it seems that the problem is that
exactly the opposite is true i.e. SID History is not working properly.
The Migrated user cannot access a share in either the root or child
domain when share permission is Everyone FC and NTFS Permission is set
to W2kRootDomain\user FC. (NB The Migration Log and ADSIEdit seem to
confirm that the migrated account has SIDHistory).

Finally, I didn't find an attachment with your last posting but have
obtained "mytoken.exe" from elsewhere. This is the output when logged
on as the migrated user in the W2k3 Domain:- ( I have removed the
NetBIOS W2K3 domain name and replaced it with xxxxxxx)

User : xxxxxxx\jenny_stenning
Owner : xxxxxxx\jenny_stenning
Primary Group : xxxxxxx\Domain Users
LUID for this instance of token 8603558664
LUID for this logon session 8600099064
Token is type PRIMARY
Token source is <User32 ZE >

Retrieving Group information from current process token
SID 0 Group: xxxxxxx\Domain Users
SID 1 Group: \Everyone
SID 2 Group: BUILTIN\Users
SID 3 Group: BUILTIN\Pre-Windows 2000 Compatible Access
SID 4 Group: NT AUTHORITY\INTERACTIVE
SID 5 Group: NT AUTHORITY\Authenticated Users
SID 6 Group: NT AUTHORITY\This Organization
SID 7 Group: NT AUTHORITY\NONE_MAPPED
SID 8 Group: \LOCAL
SID 9 Group: xxxxxxx\Jenny_Stenning

Privileges associated with this token (2)
SeChangeNotifyPrivilege - (attributes) 3
SeMachineAccountPrivilege - (attributes) 0

I hope this is what you were expecting.

One last point,in case it's relevant, the new W2K3 domain Forest and
Domain Functional level are Windows Server 2003. (There will be no DCs
other that W2K3 in the new Domain)

Regards

[David Missen]

Further information:-

I didn't confirm in my earlier posting the result of adding the
w2k3domain\user to the NTFS permissions lists for my share.

The result was as expected i.e. the user could access the share.

I ended up with a resource that has the following setup:-

Share Permissions
Everyone full Control

NTFS Permissions
Domain Admins - FC
w2kroot\user - FC
w2k3domain\user - FC (This is the migrated user account referred to
above)

Running SHOWACLS reports :-
Domain Admins - FC
w2k3domain\user - FC
w2k3domain\user - FC

(i.e both the user entries in the permissions list are identified as
my migrated user)

So surely SID History is in place, but if I take away the explicit
w2k3domain\user FC I get "access denied" when I try to access the
share.

I have used the ADMT tool before for Migrating Domains (N4 to W2K) and
it's always worked in the past.

If I'm being stupid here please tell me (preferably with the answer)
because this is driving me nuts!

I am going to try one more thing...migrating a user account that
doesn't contain an underscore character (I am beginning to clutch at
straws now !)

[Bob Qin [MSFT]]

Hi David,

Do you mean that if you leave NTFS Permissions as:

Domain Admins - FC
w2kroot\user - FC

Then, w2k3domain\user will get "access denied" when try to access the share
from target domain?

The mytoken.exe tool is very useful to troubleshoot such SIDhistory issue.

Please run "mytoken > log1" when you log on as w2kroot\user on the source
domain and run "mytoken > log2" when you log on as w2k3domain\user in
target domain.

Now attach the two files in your post.

I am looking forward to your response.

[David Missen]

Sorry I haven't got back in a while.

It looks like I have found the answer.

SID Filtering was introduced to Windows 2000 Domains with either the
application of a Post-SP2 Security roll-up OR by installation of
SP3/SP4. (I believe there may be a similar Post-SP6a security roll-up
fix for Windows NT4)

I have used the "Netdom trust..." command to turn SID Filtering off in
my test environment (a simple W2K/W2K3 scenario) and "Hey
Presto!"....Problem solved.

I need to try this in the live environment which has a more complex
W2K AD structure (Root and 4 child domains), but the indications are
that this will resolve the issue.

Thanks for your assistance.

[Bob Qin [MSFT]]

Hi David,

Thank you for your update and the additional feedback on how you were
successful in resolving this issue. Many customers with similar issues will
benefit from this information. Much to my regret, I did not help you
resolving this issue in a timely manner. I'm glad everything is working
however.

We look forward to helping you in the future.

Thanks again for using our newsgroup.