samba - Sep 2003 - NT4-Samba Migration Test Results

John,

We previously corresponded on our testing of Samba 3.0.0 RC4. Since
then,
we have downloaded the Samba 3.0.0 Release version for testing with some

interesting results.

The Setup
Major Networks: Solaris (NIS), Windows Native NT4 Domain

Our Test Plan
We are testing Samba 3.0 as a candidate for replacing the old NT4
Domain.
Being a complex production networking environment, we replicated the
networking scenario for testing in our lab.

Current Test Results:

Test 1:
passwd backend = smbpasswd

First,  we followed your instructions in Chapter 31 of the Samba HOWTO
Collection. When we ran the exact syntax for "net rpc vampire",  no
accounts
migrated from the NT4 PDC to our Samba v3.0 Samba PDC running on
Solaris.

Test 2:
passwd backend = smbpasswd
Problem Resolution:

We imported all the NIS accounts and NT4 machine accounts into the local

account database of the Solaris server.  Then, we ran "net rpc
vampire"
again.
This time only 2620 of our 5000+ NT4 accounts migrated.

After choking, the following error message was generated:

[2003/09/29 12:36:51, 0]
utils/net_rpc_samsync.c:fetch_group_mem_info(591)
  Could not find global group 512
[2003/09/29 12:36:51, 0]
utils/net_rpc_samsync.c:fetch_group_mem_info(591)
  Could not find global group 513
Failed to fetch domain database: NT code 0x00000001

Test 3:
passwd backend = tdbsam
Problem Resolution:

We reread your Chapter 11 Part III Advanced Configuration documentation
from May 24, 2003 and the tdbsam password backend looked interesting.
Although it warned that it should be limited to <250 accounts, we
decided to
try it. It ran perfectly! All 5000+ NT4 accounts migrated.

We tested NT4 and Win2K machine accounts  and user logins. All were
good,
no extra configuration required.


Comments
Vampire is very cool indeed! Perhaps there have been changes in the
password
backends since the May 24th documentation. However, smbpasswd didn't
work
in our tests and tdbsam did.

Questions

1. We are inquiring if there are any warnings or known gotcha's with the
tdbsam
or any updates to the smbpasswd? If there are no issues we will likely
use the
tdbsam scenario for our actual production NT4 migration.

2. We invented the part about pre-importing the NIS and machine accounts
into the
local OS. Does that sound like a best practice, or is there a better
way?


So far, so good. Samba 3 is pretty cool...
We are looking forward to your thoughts and comments on the 2 questions.



Larry Liu
Robert Inerbickler

NT Migration Team
Sun Microsystems

On Tue, 30 Sep 2003, Larry Liu wrote:

Larry,

I have found that the easiest way to migrate from NT4 to SAmba3 is to:

1. Use tdbsam as a medium for migration.
2. Before migrating accounts:
	i. Make sure that you configure your smb.conf carefully
	ii. Include all the "user/group/machine scripts"
	iii. Do NOT run smbd before vampire is run.
3. Set up the smb.conf for a Samba-BDC
4. Join the domain before running vampire
5. Then finally run vampire.

IF you want to use an LDAP or smbpasswd backend, use pdbedit to migrate
the database.

- John T.
> John,
>
> We previously corresponded on our testing of Samba 3.0.0 RC4. Since
> then,
> we have downloaded the Samba 3.0.0 Release version for testing with some
>
> interesting results.
>
> The Setup
> Major Networks: Solaris (NIS), Windows Native NT4 Domain
>
> Our Test Plan
> We are testing Samba 3.0 as a candidate for replacing the old NT4
> Domain.
> Being a complex production networking environment, we replicated the
> networking scenario for testing in our lab.
>
> Current Test Results:
>
> Test 1:
> passwd backend = smbpasswd
>
> First,  we followed your instructions in Chapter 31 of the Samba HOWTO
> Collection. When we ran the exact syntax for "net rpc vampire", 
no
> accounts
> migrated from the NT4 PDC to our Samba v3.0 Samba PDC running on
> Solaris.
>
> Test 2:
> passwd backend = smbpasswd
> Problem Resolution:
>
> We imported all the NIS accounts and NT4 machine accounts into the local
>
> account database of the Solaris server.  Then, we ran "net rpc
vampire"
> again.
> This time only 2620 of our 5000+ NT4 accounts migrated.
>
> After choking, the following error message was generated:
>
> [2003/09/29 12:36:51, 0]
> utils/net_rpc_samsync.c:fetch_group_mem_info(591)
>   Could not find global group 512
> [2003/09/29 12:36:51, 0]
> utils/net_rpc_samsync.c:fetch_group_mem_info(591)
>   Could not find global group 513
> Failed to fetch domain database: NT code 0x00000001
>
> Test 3:
> passwd backend = tdbsam
> Problem Resolution:
>
> We reread your Chapter 11 Part III Advanced Configuration documentation
> from May 24, 2003 and the tdbsam password backend looked interesting.
> Although it warned that it should be limited to <250 accounts, we
> decided to
> try it. It ran perfectly! All 5000+ NT4 accounts migrated.
>
> We tested NT4 and Win2K machine accounts  and user logins. All were
> good,
> no extra configuration required.
>
>
> Comments
> Vampire is very cool indeed! Perhaps there have been changes in the
> password
> backends since the May 24th documentation. However, smbpasswd didn't
> work
> in our tests and tdbsam did.
>
> Questions
>
> 1. We are inquiring if there are any warnings or known gotcha's with
the
> tdbsam
> or any updates to the smbpasswd? If there are no issues we will likely
> use the
> tdbsam scenario for our actual production NT4 migration.
>
> 2. We invented the part about pre-importing the NIS and machine accounts
> into the
> local OS. Does that sound like a best practice, or is there a better
> way?
>
>
> So far, so good. Samba 3 is pretty cool...
> We are looking forward to your thoughts and comments on the 2 questions.
>
>
>
> Larry Liu
> Robert Inerbickler
>
> NT Migration Team
> Sun Microsystems
>
>
-- 
John H Terpstra
Email: jht@samba.org

>Larry,
>I have found that the easiest way to migrate from NT4 to SAmba3 is to:
>1. Use tdbsam as a medium for migration.
>2. Before migrating accounts:
>	i. Make sure that you configure your smb.conf carefully
>	ii. Include all the "user/group/machine scripts"
>	iii. Do NOT run smbd before vampire is run.
>3. Set up the smb.conf for a Samba-BDC
>4. Join the domain before running vampire
>5. Then finally run vampire.
>
>IF you want to use an LDAP or smbpasswd backend, use pdbedit to migrate
>the database.
>- John T.

John,

Would it be possible for you to show us a copy of your smb.conf for each
stage of your migration?  I'm also interested in how you use pbedit to
migrate the database.

Thanks,
Sapan

If someone answers my question I'll even write a howto!

-----Original Message-----
From: Ganguly, Sapan 
Sent: 06 October 2003 10:06
To: 'samba@lists.samba.org'
Cc: 'jht@samba.org'
Subject: Re: [Samba] NT4-Samba Migration Test Results


>Larry,
>I have found that the easiest way to migrate from NT4 to SAmba3 is to:
>1. Use tdbsam as a medium for migration.
>2. Before migrating accounts:
>	i. Make sure that you configure your smb.conf carefully
>	ii. Include all the "user/group/machine scripts"
>	iii. Do NOT run smbd before vampire is run.
>3. Set up the smb.conf for a Samba-BDC
>4. Join the domain before running vampire
>5. Then finally run vampire.
>
>IF you want to use an LDAP or smbpasswd backend, use pdbedit to migrate 
>the database.
>- John T.

John,

Would it be possible for you to show us a copy of your smb.conf for each
stage of your migration?  I'm also interested in how you use pbedit to
migrate the database.

Thanks,
Sapan

Thanks John, for the confirmation. 

We know your documentation mention about " Samba-3 cannot function as a 
BDC to an MS Windows NT4 PDC, and Samba-3 can not function correctly as 
a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows NT4 can 
function as a BDC to its own type of PDC" in Chapter 6

In case of the new Samba 3.0.0 PDC can not handle the load from the 
domain,  is there any other way to back out it back to NT4 with the 
current SAM data?  Third party utility?



John H Terpstra wrote:
>On Tue, 30 Sep 2003, Larry Liu wrote:
>
>Larry,
>
>I have found that the easiest way to migrate from NT4 to SAmba3 is to:
>
>1. Use tdbsam as a medium for migration.
>2. Before migrating accounts:
>	i. Make sure that you configure your smb.conf carefully
>	ii. Include all the "user/group/machine scripts"
>	iii. Do NOT run smbd before vampire is run.
>3. Set up the smb.conf for a Samba-BDC
>4. Join the domain before running vampire
>5. Then finally run vampire.
>
>IF you want to use an LDAP or smbpasswd backend, use pdbedit to migrate
>the database.
>
>- John T.
>  
>
>>
>>
>>Larry Liu
>>Robert Inerbickler
>>
>>NT Migration Team
>>Sun Microsystems
>>    
>>

On Tue, 7 Oct 2003, Larry Liu wrote:
> Thanks John, for the confirmation.
>
> We know your documentation mention about " Samba-3 cannot function as
a
> BDC to an MS Windows NT4 PDC, and Samba-3 can not function correctly as
> a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows NT4 can
> function as a BDC to its own type of PDC" in Chapter 6
>
> In case of the new Samba 3.0.0 PDC can not handle the load from the
> domain,  is there any other way to back out it back to NT4 with the
> current SAM data?  Third party utility?
No. There is no method to migrate from Samba-3 to NT4.

- John T.
>
>
>
> John H Terpstra wrote:
>
> >On Tue, 30 Sep 2003, Larry Liu wrote:
> >
> >Larry,
> >
> >I have found that the easiest way to migrate from NT4 to SAmba3 is to:
> >
> >1. Use tdbsam as a medium for migration.
> >2. Before migrating accounts:
> >	i. Make sure that you configure your smb.conf carefully
> >	ii. Include all the "user/group/machine scripts"
> >	iii. Do NOT run smbd before vampire is run.
> >3. Set up the smb.conf for a Samba-BDC
> >4. Join the domain before running vampire
> >5. Then finally run vampire.
> >
> >IF you want to use an LDAP or smbpasswd backend, use pdbedit to migrate
> >the database.
> >
> >- John T.
> >
> >
> >>
> >>
> >>Larry Liu
> >>Robert Inerbickler
> >>
> >>NT Migration Team
> >>Sun Microsystems
> >>
> >>
>
>
-- 
John H Terpstra
Email: jht@samba.org

John, 

Thank you very much, that has filled in a few gaps but I have one more
question.  Once I've used pdbedit to migrate everything to an LDAP backend
how should the scripts part of my smb.conf look then?

You see, the way I did it was to set up my LDAP database first, then setup
Samba and put the scripts from smbldap-tools into my smb.conf.  I then ran
'net rpc vampire' and that took everything across, all the users,
groups,
and computers went into the database. The only problem was that the most
groups were empty, in fact the only group that is populated is Domain Users.
We have a lot of groups on our site, each time a new project is started we
create a new group and put the team members in it, we have hundreds!!  I did
contemplate putting people back into their groups by hand and I'll have to
do it if that's the only way but I suspect I'm just using a script
wrongly
or just not using the right script....is there even a script for this?  

So before I start again and do it your way I'd just like to know the answer
to that last little bit because although your method will give me a complete
and correct initial database, when my administrators add users and groups to
the system via NT's UserManager I suspect I will have the same problem.

Oh, one more thing, the passwords don't seem to go across either, next to
sambaNTPassword and sambaLMPassword I get "XXX".  This may be solved
if I do
things your way too, but this may also be a problem for administrators when
adding users via UserManager when I convert back to an LDAP
backend....hmm...a few more questions have come up in my mind, but I'll save
them for later...after I have re-read the documentation.  Anyway, in the
short term I can just add the hashes to an LDIF from a 'net rpc samdump'
right?

I really appreciate your help so far but I just have to iron these few
things out, I can't really present this solution to a technical director
just yet as I don't have it straight in my own head.
I promise I have read ALL of the relevant parts of the HOWTO collection but
for someone like me who is going straight from NT4 to Samba+LDAP you kind of
have to piece things together from different parts of the documentation
which is why  I offered to write a complete HOWTO for this specific task, I
will have to document it all for people here anyway.

I'm going to stop now, I know I'm getting this product and support for
it
free, I don't want to push my luck!

Thanks a lot,
Sapan


-----Original Message-----
From: John H Terpstra [mailto:jht@samba.org] 
Sent: 09 October 2003 03:32
To: Ganguly, Sapan 
Cc: 'samba@lists.samba.org'
Subject: RE: [Samba] NT4-Samba Migration Test Results


Sapan,

It is of course a pleasure to help you, but I did expect that my reply was
rather specific enough.

Have you read the Samba-HOWTO-Collection.pdf?

Chapter 31 covers the process (Section 31.1.1.2) covers this rather
completely.

Anyhow, here we go:

1. Configure smb.conf for BDC

   [globals]
	workgroup = NT4DOMAIN
	netbios name = NEWSERVER
	passdb backend = tdbsam
	domain master = No
	domain logons = Yes
	os level = 33
	add user script = /usr/sbin/useradd -m %u
	delete user script = /usr/sbin/userdel %u
	add group script = /usr/sbin/groupadd %g
	add machine script 		/usr/sbin/useradd -d /dev/null -s /bin/false %u
	wins server = x.x.x.x

2. Join the domain as a BDC server:

	net rpc join -UAdministrator%passsword

3. Migrate accounts:

	net rpc vampire -UAdministrator%password

4. Shutdown NT4 PDC

5. Convert Samba-3 BDC to PDC, and make it the WINS server:

   [globals]
        workgroup = NT4DOMAIN
        netbios name = NEWSERVER
	passdb backend = tdbsam
        domain master = Yes
        domain logons = Yes
        os level = 33
        add user script = /usr/sbin/useradd -m %u
        delete user script = /usr/sbin/userdel %u
        add group script = /usr/sbin/groupadd %g
        add machine script                 /usr/sbin/useradd -d /dev/null -s
/bin/false %u
        wins support = Yes

6. Start Samba PDC.


If all worked correctly then your existing Windows NT4 Domain clients will
be able to log on just as with the original NT4 PDC.


Gotchas:
--------

The biggest problem will be the migration of NT4 Group accounts. You will
need to either:

a) convert all group names to all lower-case and less than 32 characters

_OR_

b) create your own replacement for the "groupadd" command on your
system so
that it can add group names that have a space character in them, and that
can have an upper case character in them. You will also need to modify the
way that the NT Group name is passed to the script.


Here is a script that will do the trick, although it is NOT elegant nor does
it do any safety checks. You might call this script: smbaddgrp.sh Of course
it needs to be set to permissions to execute with:
	chmod 755 smbgrpadd.sh

PS: That script is published on page 144 as Example 12.1 smbgrpadd.sh in the
Samba-HOWTO-Collection.pdf.

--------------------------------------------------
#!/bin/bash

# Add the group using normal system groupadd tool.
groupadd smbtmpgrp00
grpunconv

thegid='cat /etc/group | grep smbtmpgrp00 | cut -d ":" -f3'

# Now change the name to what we want for the MS Windows networking end cp
/etc/group /etc/group.bak cat /etc/group.bak | sed s/smbtmpgrp00/$1/g >
/etc/group grpconv

# Now return the GID as would normally happen.
echo $thegid

exit 0
---------------------------------------------------
You will need to change your smb.conf as follows:

	add group script = /usr/sbin/smbgrpadd.sh "%g"



Finally, please note that you must NOT change the Domain Name (WORGROUP) or
the netbios name of the server. If you do, then the SID will change and your
clients will need to be re-joined to the domain.


Oh, and one more pointer (see page 122, Chapter 11.3.2 - The pdbedit
command) for information on how to migrate your account backend to another
backend format.

For example, if you have your migrated accounts in tdbsam (which stores the
accounts in a file called passdb.tdb) and you want to copy them to an
smbpasswd file you can do this as follows:

	In smb.conf:
		passdb backend = tdbsam, smbpasswd

	Execute:
		pdbedit -i tdbsam -e smbpasswd

If you have your accounts in smbpasswd and you want to migrate them to
tdbsam:

	In smb.conf:
		passdb backend = smbpasswd, tdbsam

	Execute:
		pdbedit -i smbpasswd -e tdbsam

And so on. After migration you can delete the backend that you no longer
need to use from the "passdb backend" parameter line.


Is there something I may have missed? I look forward to your HOWTO.

cheers,
John T.


On Tue, 7 Oct 2003, Ganguly, Sapan  wrote:
>
> If someone answers my question I'll even write a howto!
>
> -----Original Message-----
> From: Ganguly, Sapan
> Sent: 06 October 2003 10:06
> To: 'samba@lists.samba.org'
> Cc: 'jht@samba.org'
> Subject: Re: [Samba] NT4-Samba Migration Test Results
>
>
>
> >Larry,
>
> >I have found that the easiest way to migrate from NT4 to SAmba3 is 
> >to:
>
> >1. Use tdbsam as a medium for migration.
> >2. Before migrating accounts:
> >	i. Make sure that you configure your smb.conf carefully
> >	ii. Include all the "user/group/machine scripts"
> >	iii. Do NOT run smbd before vampire is run.
> >3. Set up the smb.conf for a Samba-BDC
> >4. Join the domain before running vampire
> >5. Then finally run vampire.
> >
> >IF you want to use an LDAP or smbpasswd backend, use pdbedit to 
> >migrate the database.
>
> >- John T.
>
>
> John,
>
> Would it be possible for you to show us a copy of your smb.conf for 
> each stage of your migration?  I'm also interested in how you use 
> pbedit to migrate the database.
>
> Thanks,
> Sapan
>
-- 
John H Terpstra
Email: jht@samba.org

The How-To writes :  "nmbd can be configured as a WINS server, but it is 
not necessary to specifically use Samba as your WINS server. MS Windows 
NT4, Server or Advanced Server 200x can be configured as your WINS 
server. In a mixed NT/200x server and Samba environment on a Wide Area 
Network, it is recommended that you use the Microsoft WINS server 
capabilities. In a Samba-only environment, it is recommended that you 
use one and only one Samba server as the WINS server." in chapter 10.

We found that each of our subnets has to have at least one Samba client 
pointing to the same Samba WINS server, if we have to make enterprise 
WINS(running on Samba 3.0.0) working, in a mixed environment as 
described above,  even though all the Win9x,Winnt, Win2k, & XP clients 
point to the same Samba WINS server.

Has anyone had the similar experience? Or, any work-around instead of 
using MS WINS server(s)?

On Mon, 13 Oct 2003, Larry Liu wrote:
> The How-To writes :  "nmbd can be configured as a WINS server, but it
is
> not necessary to specifically use Samba as your WINS server. MS Windows
> NT4, Server or Advanced Server 200x can be configured as your WINS
> server. In a mixed NT/200x server and Samba environment on a Wide Area
> Network, it is recommended that you use the Microsoft WINS server
> capabilities. In a Samba-only environment, it is recommended that you
> use one and only one Samba server as the WINS server." in chapter 10.
>
> We found that each of our subnets has to have at least one Samba client
> pointing to the same Samba WINS server, if we have to make enterprise
> WINS(running on Samba 3.0.0) working, in a mixed environment as
> described above,  even though all the Win9x,Winnt, Win2k, & XP clients
> point to the same Samba WINS server.
>
> Has anyone had the similar experience? Or, any work-around instead of
> using MS WINS server(s)?
You should be able to run with just one Samba WINS server for your whole
network. All clients (Samba as well as Windows) must be configured to use
that same WINS server.

The reason for the recommendation is that MS Windows based WINS servers
typically use WINS-WINS replication protocols that Samba does not support.

- John T.
-- 
John H Terpstra
Email: jht@samba.org

Thanks, John, for the quick reply.

My test environment is like you recommended, only one WINS running on 
Samba 3.0.0.  The interesting part is: on the server subnet, we can see 
all the win32 and samba clients from other subnets which have at least 
one samba client on each,  but can not see any subnets that have win32 
clients only.  However, if I go down all those subnets, I can see all 
the win32 and samba clients that are using this only WINS.   Any idea ?

John H Terpstra wrote:
>On Mon, 13 Oct 2003, Larry Liu wrote:
>
>  
>
>>The How-To writes :  "nmbd can be configured as a WINS server, but
it is
>>not necessary to specifically use Samba as your WINS server. MS Windows
>>NT4, Server or Advanced Server 200x can be configured as your WINS
>>server. In a mixed NT/200x server and Samba environment on a Wide Area
>>Network, it is recommended that you use the Microsoft WINS server
>>capabilities. In a Samba-only environment, it is recommended that you
>>use one and only one Samba server as the WINS server." in chapter
10.
>>
>>We found that each of our subnets has to have at least one Samba client
>>pointing to the same Samba WINS server, if we have to make enterprise
>>WINS(running on Samba 3.0.0) working, in a mixed environment as
>>described above,  even though all the Win9x,Winnt, Win2k, & XP
clients
>>point to the same Samba WINS server.
>>
>>Has anyone had the similar experience? Or, any work-around instead of
>>using MS WINS server(s)?
>>    
>>
>
>You should be able to run with just one Samba WINS server for your whole
>network. All clients (Samba as well as Windows) must be configured to use
>that same WINS server.
>
>The reason for the recommendation is that MS Windows based WINS servers
>typically use WINS-WINS replication protocols that Samba does not support.
>
>- John T.
>  
>

On Tue, 14 Oct 2003, Larry Liu wrote:
> Thanks, John, for the quick reply.
>
> My test environment is like you recommended, only one WINS running on
> Samba 3.0.0.  The interesting part is: on the server subnet, we can see
> all the win32 and samba clients from other subnets which have at least
> one samba client on each,  but can not see any subnets that have win32
> clients only.  However, if I go down all those subnets, I can see all
> the win32 and samba clients that are using this only WINS.   Any idea ?
What are your Windows clients? 9x/Me or 2KX/XPP? IT makes a difference.
For Win9x/Me to be visible across the entire network you must export a
share on each. Win 2Kx/XPP should be visible without this hack.

- John T.
>
> John H Terpstra wrote:
>
> >On Mon, 13 Oct 2003, Larry Liu wrote:
> >
> >
> >
> >>The How-To writes :  "nmbd can be configured as a WINS server,
but it is
> >>not necessary to specifically use Samba as your WINS server. MS
Windows
> >>NT4, Server or Advanced Server 200x can be configured as your WINS
> >>server. In a mixed NT/200x server and Samba environment on a Wide
Area
> >>Network, it is recommended that you use the Microsoft WINS server
> >>capabilities. In a Samba-only environment, it is recommended that
you
> >>use one and only one Samba server as the WINS server." in
chapter 10.
> >>
> >>We found that each of our subnets has to have at least one Samba
client
> >>pointing to the same Samba WINS server, if we have to make
enterprise
> >>WINS(running on Samba 3.0.0) working, in a mixed environment as
> >>described above,  even though all the Win9x,Winnt, Win2k, & XP
clients
> >>point to the same Samba WINS server.
> >>
> >>Has anyone had the similar experience? Or, any work-around instead
of
> >>using MS WINS server(s)?
> >>
> >>
> >
> >You should be able to run with just one Samba WINS server for your
whole
> >network. All clients (Samba as well as Windows) must be configured to
use
> >that same WINS server.
> >
> >The reason for the recommendation is that MS Windows based WINS servers
> >typically use WINS-WINS replication protocols that Samba does not
support.
> >
> >- John T.
> >
> >
>
-- 
John H Terpstra
Email: jht@samba.org