moving to new domain

[Arc J. Thames]

I am getting ready to migrate our users over to a new domain in a seperate
forest. I have the trust relationships set up and working. My problem is
coming when I try to access resources in the old domain with my new user
account. I copied over the SID's using the sid history feature of the
domain migration tool, but when I try to access old resources with the
migrated account...it says "access denied". Is there some additional option
I need to check to ensure access is allowed for these migrated users?

Thanks!
Arc

 

[Philip Nunn]

if you are moving from a windows 2000 based forest to a windows 2003 based
forest then you need to turn off "SID Filtering" for the trusts. Open up
"Active Directory Domains and Trusts" from your admin tools, right click on
the domain object>go to the Trusts tab>highlight one of the trust
relationships>right click and go to properties>at the bottom you will see a
message about SID filtering. you need to disable this for both directions
of the trust (trusting and trusted) once they are all disabled then users
sidHistory attribute will work across the forests. Once you migration is
complete i would make sure you turn this back on for security reasons.

Philip Nunn

 

[Ryan Hanisco]

Arc,

You can check to see if the SIDHistory attribute was correctly applied using
the ADSI Utility in the Support Tools. (If you didn't install the Support
Tools on your DCs, you can get it off the Server 2000/2003 CD -- you should
make this standard in a DC build.)

Run ADSIEdit and navigate to the User object of a migrated user. Scroll
through the Attributes to see the value of SIDHistory.

If these didn't migrate you may have one of two problems. Either your
target domain wasn't in Native Mode (either 2000 or 2003 Native mode) or
your trust wasn't set up correctly to turn off SID Filtering. You can
verify this using the NETDOM tool.

http://www.microsoft.com/resources/...windowsserv/2003/all/techref/en-us/NetDom.asp

Make sure you are using the newest version of the NETDOM utility -- either
off of the 2003 CD or downloaded from the MS site.

It is very important to do the Test Migrations in ADMTv2 and to read the Log
files. Go back and verify these things -- depending on the size of your
environment, you may have to do the migration again or scramble to reset
permissions across the trust.

One last note... many people recommend that once the migration is complete
that you use the WScript tools to remove the SIDHistory attribute as this is
a potential security hole. Make sure your workstation security translation
was successful or you'll end up in a situation where the local workstation
profiles all dissociate. Then you'll have a bad week... a very bad week.

 

[Andrew]

Ryan,

How do you deal with migrating gradualy when on the same lan as the existing
forest. Regarding dns, wins and dhcp, how can you diferentiate settings
between the old and new forests to your clients. If I'm not being veryu
clear pls say (it;s been a long day!)

Thanks, Andrew

 

[Ryan Hanisco]

Andrew,

I usually do this by migrating the user accounts and workstations first.
Leaving the old SID in the SIDHistory attribute allows you to migrate the
actual resources one by one as long as the trust is in place with SID
filtering disabled.

You can choose to migrate the users and computers one OU at a time which
will further let you test and control who and what are migrated against your
overall project timeline.

Remember that a Migration between forests can be very manageable, but you
have to PLAN very carefully and take your time. Always use the test
migrations and remediate problems before doing anything permanent. Nothing
is more devastating than a global migration gone wrong -- believe me I know.

Of the services, DNS is the most important. The trick here is to Migrate
the workstations' DNS to the target domain before doing the migration and
have the New DNS forward to the OLD domain. This way the workstations are
always aware of both domains.

Make sense?

 

[Andrew]

Thanks Ryan (again)

What of dhcp though, as we will be using the same subnet etc, and only one
dhcp server can be used, how can the migrated accounts be directed towards
the correct wins,dns etc....again, if i am not very clear pls ask.

thanks for your help, andrew

 

[Philip Nunn]

if you get your dns infrastructure for the new domain in place with
secondary zones for your old domains then you should be able to change your
clients to point to the new servers. i wouldnt do this unless you have the
dns system setup and working to allow this.

Philip Nunn

 

[Andrew]

Thanks for the info mate,

so, we can use the new dc's in the new forest for dns resolution for the
existing forest? can our existing clients not yet migrated use the new dc's
dns then? can the new forests dns zones be ad integrated and still have a
zone for the existing forest?

cheers

 

[ptwilliams]

so, we can use the new dc's in the new forest for dns resolution for the

existing forest? can our existing clients not yet migrated use the new
dc's dns then?

Yes. If you have physical access to a DNS server, and that DNS server is
not locked down, then yes you can query it.

can the new forests dns zones be ad integrated and still have a zone for
the existing forest?

That's how you've got to do it. You need to have AD-Integrated for your new
forest, and hold a secondary copy of the old forest/ domain on there too.

There's one other consideration here, and DHCP can't (as far as I'm aware)
cater for it - DNS suffix search list. If your clients are going to be
resolving names in both forests you are going to be querying multiple
different namespaces. In order to do this you need to configure the DNS
Suffix Search list on the TCP/IP settings of each NIC. DHCP can't do this;
it can only do the primary DNS suffix. In order to do this you have two
choices: manually, or via a script.

The script is the only option. This is simply a multi-valued registry
string. So you can do it via a startup script, Kix logon script, or a
script that you run manually and goes off and does the job. Without the DNS
suffix search list, you won't be able to resolve (no fully qualified) names
that aren't part of your namespace.


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

Thanks for the info mate,

so, we can use the new dc's in the new forest for dns resolution for the
existing forest? can our existing clients not yet migrated use the new dc's
dns then? can the new forests dns zones be ad integrated and still have a
zone for the existing forest?

cheers

 

[Guest]

Im currently migrating from an NT4 domain to a Win 2000 domain and I found
that if we dont migrate the groups, that the users belong to, the migrated
accounts dont have access to the resources on the NT4 domain thatthe groups
have rights to. Only when the user groups are migrated or the user account is
specified to have permission to the resources, they can access it. We didnt
want to migrate the old groups, but do we have a choice if we need the new
accounts to access the resources on the old domain?

 

[Guest]

I found that if you dont migrate the groups over, you will have this problem.
Especially if the old domain resource specifies the groups to have permission
access and not the users. The groups have SID also, and its translated during
the migration.