Windows Server

moparmanimal@gmail.com · Guest

Hello,

I'm migrating a Win2k native forest to a Win2k3 native forest. I'm
using ADMTv2 for the migration and am migrating with passwords and SID
history. Everything is working with the migrated accounts and computers
so far except for the built-in group: Domain Admins. Meaning email,
access to file shares, and the like are all working except any migrated
admins cannot administer computers not yet migrated (no \\machine\c$
for example). What happens is I am prompted for credentials which tells
me no SID history.

Obviously ADMT cannot migrate "Domain Admins" so I used sidhist.vbs and
it appeared to run with no errors. I verified that the SID history
attribute of Target\Domain Admins was indeed populated with the SID of
Source\Domain Admins - or is it?

When I am in the source domain logged in as myself (a memeber of Domain
Admins) and run "whoami /all" I see a SID for "Domain Admins" - in fact
the SID that in the Target Domain SidHistory attribute. When I run
getsid.exe to compare the two Source domain DC SIDs for "Domain Admins"
they match with the same SID - again the SID displayed in the target
"Domain Admins" SidHistory. HOWEVER, when I run ldp.exe and browse to
the object "Domain Admins", the "objectSid:" property shows a totally
different SID that isnt even close!

It seems to me that this must be why the SID history for "Domain
Admins" is not working but how is it that LDAP shows one SID yet the
SID showing utils (whoami and getsid) display something else?

I've searched and cannot find any info on this. Anyone have any ideas
for me?

Thanks,

Chris
Information Services
Clackamas County, OR

Vincent Xu [MSFT] · Guest

Hi,

I think it is really weird that the sid is different by using whoami and
ldp. I'd like to provide the steps I do it in ldp.

1. run ldp.
2. click "connection->bind" and type Domain Administrator's username and
password.
3. click "View-Tree" and type "cn=domain admins,cn=users,dc=<your domain
name>,dc=com"
4. click OK you will find the objectsid at right column.

I'd like to suggest you follow this steps to run ldp and sending me a
screen shot to let me know the sid. As well as the screen shot of the
results of whoami

I noticed that you have logged as source domain admins to do the same
thing, please also send me the screen shots of this.

As you said the domain admins cannot access file share. Please let me know
the NTFS permissions settings and the file share permission settings. You
may also sending me the screen shots to let me know this. My mail is :
v-xuwen@microsoft.com

Looking forward for your response.

Have a good day!

Best regards,

Vincent Xu
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security

--------------------

moparmanimal@gmail.com · Guest

Thanks for the response Vincent. I sent you an email as requested. If
we get it figured out I'll post the results for the benefit of everyone.

Vincent Xu [MSFT] · Guest

Hi ,

I have reviewed the screen shot and actually the 2 sid is the same. The sid
displaied in ldp is the hexadecimal number.

Now we need to do is generate a SID mapping file for security translations.
Please refer to following article:

835991 How to use a SID mapping file with the ADMT tool to perform a
resource
http://support.microsoft.com/?id=835991

Hope it helps.

I will out off office from 10/5/2005 to 10/6/2005. During that time, you
can contact my backup at pngfd@microsoft.com and add following information,
they will respond you as soon as possible.

Post queue (For example: microsoft.public.server.migration)
Post tile
My name (Vincent Xu)

Have a good day.

Best regards,

Vincent Xu
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security

--------------------

moparmanimal@gmail.com · Guest

Hmmm... well if the SID displayed in LDap is hex and actually the
correct SID then I'm really not sure why it's not working. I'm also a
bit confused as to why building a SID mapping file would help when the
SID of the source\Domain Admins is already in the SIDHistory of
target\Domain Admins.

Could you clarify this a bit for me when you get a chance?

Thanks for all of your help,

Chris

Vincent Xu [MSFT] · Guest

Hi,

I think we can take it as a workaround cause this issue seems to related to
the sidhistory. After you created the sid mapping file ,you also need to
perform a security migration via ADMT.

I also found following article for your reference:

893191 The security IDs for built-in domain groups are filtered in Windows
http://support.microsoft.com/?id=893191

Hope it helps.

Best regards,

Vincent Xu
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security

--------------------

moparmanimal@gmail.com · Guest

Ok - I'll give it a try and post the results. Incidentally I do already
have SID filtering turned off at the trusts - I don't think I mentioned
that before.

Thanks again for your help,
Chris

moparmanimal@gmail.com · Guest

I set up the SID mapping file and ran the security translation wizard
against a workstation in the source domain using the sid mapping file.
I still could not get to the admin share or any other resouce locked
down with the Domain Admins group from the target domain. Everything
I've researched and tested is telling me that it should be working -
but it doesn't. Unless there's something obvious that I'm doing wrong,
I think I'm going to move on to other issues and simply work around
this one.

Thanks for your help Vincent,
Chris

	Windows Server Forum Index -> Migration	All times are GMT
Page 1 of 1