[Samba] Adding a Windows Server down the road
jon at sutinen.com
Thu Apr 14 07:18:58 GMT 2005
John H Terpstra wrote:
>On Wednesday 13 April 2005 11:46, Josh Kelley wrote:
>>Andrew Bartlett wrote:
>>>What's wrong with running the windows server as a domain member. There
>>>is no way to import users (well, their passwords are the tricky part)
>>>from Samba into AD that I know of.
>>Microsoft provides the Active Directory Migration Tool (ADMT). As one
>>of its features, it's supposed to let you import users from a NT 4
>>domain. Since a Samba server runs an NT 4 domain, any chance that ADMT
>>I'm guessing no, for the same reason that a Samba PDC can't take an NT 4
>>BDC, but I thought that I'd mention it as a possibility and see if
>>anyone knew if it would work.
>Why don't you do a test installation of ADS and try it. Please let me know
>what happens. I'd appreciate your help in documenting this process to spare
>others from having to ask.
>- John T.
Been there, done that, and can say YES, it works. I had to do this when
a customer wanted to move to Exchange (don't ask me WHY! :-) ) and thus
required migration to a Windows 2003 Active Directory domain. There are
a few gotchas to be aware of:
1. Administrator password must be THE SAME on the Samba server, the 2003
ADS, and the local Administrator account on the workstations. This is
not documented. (Perhaps this goes without saying, but there needs to be
an account called "Administrator" in your Samba domain, with full
administrative (root) rights to that domain.)
2. In the Advanced/DNS section of the TCP/IP settings on your Windows
workstations, make sure "DNS suffix for this connection" field is blank.
This is not documented.
3. Because you are migrating from Samba, user passwords cannot be
migrated. You'll have to reset everyone's passwords. (If you were
migrating from NT4 to ADS, you could migrate passwords as well.)
4. I don't know how well this works with roaming profiles; I've only
used this with local profiles.
5. Disable the Windows Firewall on all workstations. Otherwise,
workstations won't be migrated to the new domain. This is not documented.
6. When migrating machines, always test first (using ADMT's test mode)
and satisfy all errors before committing the migration. Note that the
test will always fail, because the machine will not have been actually
migrated. You'll need to interpret the errors to know whether the
failure was due to a problem, or simply due to the fact that it was just
There are some significant benefits of using the ADMT, besides just
migrating user accounts.
1. You can also migrate workstations remotely. You can specify that SIDs
be simply added instead of replaced, giving you the option of joining a
workstation back to the old domain if something goes awry. The
workstations will be joined to the new domain.
2. Not only are user accounts migrated from the old domain to the new
domain, but ACLs on the workstations are migrated as well. Like SIDs,
ACLs can be added instead of replaced.
3. Locally stored user profiles on workstations are migrated as well,
presenting almost no disruption to the user. Saved passwords will be
lost, just as when you administratively reset the password in Windows ADS.
4. The ADMT lets you test all operations before actually performing the
migration. You can migrate accounts and workstations individually or in
batches. User accounts can be safely migrated all at once (since no
changes are made on the original domain); I recommend migrating only one
or two workstations as a test before committing them all.
I'm fairly impressed with the Active Directory Migration Tool. It sure
made my job easier, both times I used it (once migrating from NT4 to ADS
2003; second time from Samba 3 to ADS 2003). The three gotchas that I
labeled "not documented" are things that tripped me up, but (thankfully)
I was able to resolve.
ADMT can be found on the Windows 2003 CD.
Sutinen Consulting, Inc.
More information about the samba