samba - Jun 2004 - Upgrading from workgroup to domain: experiences & gotchas (LONG)

I've decided to share my experiences with the list in hopes that it will
help someone else doing something similar avoid the problems I
experienced, and hopefully, have a better experience.

Here's the scope of my project:

Original installation:
- Samba 2.2.x series server
- Workgroup security (read: local security, not domain security)
- no domain controller
- password database is smbpasswd (passdb backend = smbpasswd)

Migrating to:
- Samba 3 series server (upgrading Samba) 
- Domain security
- Samba server becomes domain controller
- password database migrates to tdbsam (passdb backend = tdbsam). 

My reasons for upgrading in this manner is so that I can implement
security options such as password expiration, NT groups, account
policy, and so forth. Also so that the customer can use familiar NT GUI
tools to administer their server.

The first thing I did was upgrade from Samba 2.2.7 to 3.0.3 (the next
day 3.0.4 came out, so I went to that immediately). So far so good.
Still in "workgroup" mode.

My next step was to migrate from smbpasswd to tdbsam, using the helpful
instructions in the Samba howtos.

Next thing I did was change the mode of the Samba server from being a
workgroup member to being a domain controller.

Joined the workstations to the domain.

Here's where I began experiencing the problem. My first symptom was a
phantom workgroup in Network Neighborhood by the NetBIOS name of the
server ("SERVER") in addition to the workgroup ("DOMAIN")
that should
have been there. Further use of the system revealed additional problems
that seemed to be related to domain browsing issues. Certain security
related tasks seemed to be trying to authenticate against the domain
controller for the workgroup "SERVER" instead of the workgroup
"DOMAIN". In Windows 2000-style terms, it was trying to authenticate
SERVER\user instead of DOMAIN\user.

After much head scratching, several unanswered emails to this list, and
more than one late evening, I finally discovered that (when viewed with
'pdbedit -Lv') accounts created BEFORE the server was a domain
controller listed the account's domain as SERVER. Accounts created
AFTER it became a domain controller listed the account's domain as
DOMAIN. I was able to verify this by logging in to a Windows
workstation with an "old" account and issuing the command 'net
config
workstation.' This listed the workstation domain as SERVER instead of
DOMAIN.

I believe what happened is that when I converted the password database
from smbpasswd to tdbsam, the server was in "workgroup" mode, so it
created the accounts using local security. Because of this, it took the
NetBIOS name of the server as the logon domain.

What I had to do to fix it was, using pdbedit, remove the account then
recreate it (also using pdbedit) specifying the old SIG and GID. (By
specifying the old SID and GID, it does not force the workstation to
create a new profile for the user; I was not using roaming profiles.)

Despite the man pages for pdbedit indicating that you can change the
SID and GID for an existing account, I was not able to do that. It just
would not work. I could see no way of changing an account's logon
domain (in the password database); some facility of doing this would
make things a bunch easier for people who have the same problems.

My recommendation? Make the Samba box a domain controller BEFORE
migrating the password database from smbpasswd to tdbsam (or other
format). Once you've migrated the database, before you do anything
else, use pdbedit to verify that the logon domain is correct.

--Jon Johnson
Sutinen Consulting, Inc.
jon@sutinen.com