Jonathan Johnson
2004-Jun-10 01:37 UTC
[Samba] 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