Samba PDC Migration

I spent the days between Christmas 2012 and New Year 2013 migrating our Server from Ubuntu 8.04LTS to 12.04LTS what included an Upgrade from Samba 3.0 to 3.6.3.

I never had so much trouble in those silent days. Most of the trouble was migrating the Samba-Service and I would like to give you a few hints if you plan something similar.

Step 1: Updating the Server

I flattened the root partition of our old Ubuntu 8.04LTS Server and installed Ubuntu 12.04LTS.

Be sure to keep all essentials needed to read the old backup files! The first few hours I spent was restoring the backup key from my smart phone's KeepAss (aka KeePass) and the backup procedure from my home server which luckily uses the same than the one in my company.

A major fault is that KeepAss (Android version) does not chose a clearly indentifiable font (don't know if that is even possible). If you see the key, you cannot decide if it is a lowercase 'l' or a number "1". You cannot decide if it is a letter "O" or a number "0". That's truly bullshit!

After installing Samba and the old configuration files, no one was able to log in. Clients could not find the computer account. This was the reason why I cancelled the 10.04 installation 2 years ago but this time I made my way through!

In my case, two major problems occurred the same time:

• The machine accounts got lost because until now, our samba grew up with smbpasswd backend. 3.6.3 seems not to use smbpasswd so all user- and machine accounts were lost for now.
• The SID of the server and the domain changes with a fresh installation of Samba. So the clients would not recognize our server as the one they were used to, even if it claims to have the same name.

After an endless time of panic, I noticed that my passdb.tdb was empty. The file size showed this.

Our server and the domain are in productive work for about twenty years. As far as I remember, there was no passdb.tdb then. Samba stored all it needed in /etc/samba/smbpasswd. Somewhen, they introduced passdb.tdb but my system still used smbpasswd. Now they seem to have made smbpasswd obsolete and suddenly there are no user nor machine accounts! They could have introduced a seamless automatic migration but they made it the hard way. This is why I hate Linux from time to time. You make a simple upgrade (not even a major release upgrade, just from 3.0 to 3.6) and end up with a completely useless system.

The magic program for the conversion is pdbedit. pdbedit -i smbpasswd -e tdbsam magically did the job. Note that smbpasswd is not a filename, do not add a path! It is just a name for the backend. At first I got a message that the database would be corrupt but after adding a user to the linux passwd that I once deleted from linux passwd file but not from smbpasswd, it ran without trouble and I had all my user- and machine accounts back again!
No, not really. I don't know why but some users and one machine account got lost through the conversion. As our Network is relatively small, it was only little work to add the users, adjust their RID and the machine account.
Note that pdbedit does not complete its dedicated Job if there is a simple error like a user missing in the linux passwd. It just breaks and leaves you back with the ruins!

You can use pdbedit -L -v to verify the results.

The symptom is that if you look on the security settings of a file on a client, you don't see user\domain but an unknown SID.

You can lookup the SID if you log into a client with a local administrator account and have a look at the security settings of a file that was created by a domain user (i.e. a file in his profile).

If you use pdbedit -L -v, you get something like User SID: S-1-5-21-3032337020-1121356995-1681792651-2078
Primary Group SID: S-1-5-21-3032337020-1121356995-1681792651-513

3032337020-1121356995-1681792651 is the domain part, it is identical for all users of the domain, 2078 is the user RID. You have to get the domain SID back to its original value.

You can simply set the SID of the server using net setlocalsid <SID> but unfortunately there is no possibility to specify a domain for the SID.

The workaround is to temporarily set the name of your server in your smb.conf to the name of the domain before using setlocalsid. You must do this! It is not enough if only your server has the correct SID!

I did it for both, don't know if it is necessary.

If you have to recreate a user account, it will be recreated with a different RID.

Lookup its original RID by examinating the security properties of a file created by this user (i.e. a file in his local profile) and set his RID with pdbedit -u <username> -U <old RID>

Now, you again see user\domain instead of cryptical SIDs and I hope your users can happily login again.

I have never been so happy this year as of January, 2nd!