Wednesday, July 14, 2010

Active Directory and BackupPC

This post is going to be slightly off-topic. Mainly because it's the best place for me to put this information.

When I spend a couple days getting a particular setup to work properly, I feel I should post about it as many others have to help someone out who's in the same boat. So, without further ado, here's how I set up BackupPC to work on my corporate network using ADS authentication.

For this setup, I'm using Ubuntu Lucid Lynx 10.04 Server 64-bit with the latest packages as of 7-14-10. This includes BackupPC v3.1.0.

My setup is this: I have the Ubuntu box (backuppc-srv) running as a VM on a local server. For all intents and purposes, this should not change any configuration as it's bridged networking. We have a set of Windows XP machines that need to be backed up. All machines including the server are joined to the corporate domain (Contoso) and have a FQDN of ( I have a domain account that has the ability to create computer objects and join machines to the domain, however, I do not have console access to the domain controller. This will come into play later when we create the keytab.

The Ubuntu help sites have started recommending using Likewise to join the domain. While this is easy to do with a desktop, while trying to get Kerberos working, I had nothing but problems with it, and eventually removed it and decided to go about it with straight Samba. It's actually not that hard, and just requires a little work.

We first need to set up the machine to join the domain. I used this excellent blog post here which I will use several commands from to illustrate the process.

As the linked article mentions, it is very important to have a good working DNS setup on the domain. ADS relies heavily on it for authentication and will not work without being able to do forward and reverse lookups. Also, make sure that your machine has good time synchronization. Chances are, if you have a Primary Domain Controller (PDC) it will also be running as a time server. You should be able to use ntpd or ntpdate to synchronize time, which is also very important to Kerberos, as it is normally configured with a narrow clock skew. More than a few seconds difference and you can experience some issues.

To start, this command can be used to install the requisite packages to run Kerberos and Apache authentication:

backuppc-srv:~$sudo apt-get install apache2-mpm-prefork libapache2-mod-auth-kerb krb5-config krb5-clients krb5-user samba-client openntpd

Now that we have the packages installed, we need to setup Kerberos to authenticate to the proper domain.

Edit the /etc/krb5.conf file with your favorite text editor and start looking around. By default there are a few comments that may or may not be helpful. Here's how mine is:


# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        default_realm = CONTOSO.TEST.COM

Under the next heading you should set up your PDCs.

        kdc =
        master_kdc =
        admin_server =
        default_domain =

Now that those are set up, put in the last couple bits here to make things work right:

[domain_realm] = TEST.COM = CONTOSO.TEST.COM

Now those are out of the way, we can test the Kerberos setup by using kinit. domainuser is the name of some user account who is in the domain and enabled, i.e., it works on other machines.

backuppc-srv$ kinit domainuser
Password for domainuser@CONTOSO.TEST.COM:

Once you've done this, you can check to see if it issued you a ticket by using klist.

backuppc-srv$ klist
Ticket Cache: FILE:/tmp/krb5cc_0
Default principal: domainuser@CONTOSO.TEST.COM

Valid starting      Expires            Service Principal
07/14/10 12:00:15   07/14/10 00:00:25  krbtgt/CONTOSO.TEST.COM@CONTOSO.TEST.COM

Now we see that the account has been issued a ticket. You can then release the ticket with kdestroy:

backuppc-srv$ kdestroy 

Now we can setup Samba. Edit the file /etc/samba/smb.conf. These lines will be scattered throughout the file, if they're not there, just put them in the general section.

netbios name = backuppc-srv
security = ADS
encrypt passwords = yes
password server =
workgroup = CONTOSO

You should also add the keytab settings for completeness:

keytab method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab

Now we can join the computer to the domain. Domainadmin is a user on the domain who has privileges to join a computer to the domain.

backuppc-srv$ sudo net ads join -U domainadmin

It will do several things which will eventually end up joining the computer to the domain.

Now you should ensure your /etc/hosts file is setup correctly. It will have your computer name (backuppc-srv) linked to your localhost as such: localhost backuppc-srv

You need to add another line to this with your server's IP address. is the IP address of backuppc-srv backuppc-srv

When this is all completed, we can now get a keytab so that Apache can use it to authenticate against the server. As the linked article mentions, a lot of the tutorials on the web mention using ktpass on the windows machine, but you don't always have access to that, or a secure method of transporting the resultant keytab into the linux box. Luckily you can just get Samba to get one right off the PDC.

backuppc-srv$ sudo net ads keytab add HTTP -U domainadmin

This will get a keytab, and put it into the default file specified in the krb5.conf file, which is /etc/krb5.keytab in this example.

You can now verify that the keytab was successfully retrieved by using klist.

ktutil: (the last command is a lowercase L)
backuppc-srv$ sudo ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l

This method is much easier than typing all that stuff and was just recently brought to my attention:
backuppc-srv$ sudo klist -k /etc/krb5.keytab

slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1   13 HTTP/
   2   13 HTTP/
   3   13 HTTP/

This shows that there are the proper entries in the keytab.

You need to then give permission to Apache to read the file.

backuppc-srv$ sudo chmod 740 /etc/krb5.keytab
backuppc-srv$ sudo chgrp www-data /etc/krb5.keytab

Now it's time to get apache working. You can use the command a2enmod auth_kerb to ensure that mod_auth_kerb has been properly enabled.

Now we need to edit the backuppc Apache configuration to tell Apache how to authenticate users.
The file to edit is located in /etc/apache2/conf.d/backuppc.conf
This is how my file has been setup. I have commented out the four lines at the bottom there, leaving the require valid-user line in place. I added the six lines at the top.
AuthType Kerberos
AuthName "Kerberos Login"
Krb5Keytab /etc/krb5.keytab
KrbMethodNegotiate On
KrbMethodK5Passwd On

# AuthGroupFile /etc/backuppc/htgroup
# AuthUserFile /etc/backuppc/htpasswd
# AuthType basic
# AuthName "BackupPC admin"
require valid-user

Now that apache is setup, make sure you restart it (sudo /etc/init.d/apache2 restart), or perhaps better, reboot at this point, just to make sure the domain join is working properly. After it restarts, try to access the backuppc web interface. If you are getting the Kerberos login prompt, login with your domainuser name. No domain prefix is required as it's set to logon to a specific domain and Kerberos on linux cannot handle cross-domain logons.

If you are having errors, it's best to tail -f /var/log/apache2/error.log and set the debug level to debug in the /etc/apache2/apache2.conf file to display errors while attempting to login.

If you get a failed to verify krb5 credentials: Server not found in Kerberos database error, that's usually due to DNS issues, double-check your hosts file that you have the right IP addresses and names listed.

Client not found in Kerberos database means just that, it can't find that username. Make sure it's valid on the domain. I found that trying to logon to backuppc using a local linux user doesn't seem to work afterward, maybe I'm not setting something up right.

Wrong principal in request usually has to do with the keytab file. Check to make sure it has the HTTP sections, and if it does, just delete and recreate it with the command above used to initially make the file. Remember to change the permissions back! This has been the fix for the authentication randomly dropping occasionally, for me.

Once you've got yourself logging on via Kerberos, edit the backuppc /etc/backuppc/ file with the proper user settings. I found that i needed to add the domain to make it recognize the user.. i.e. assign a computer with 'user' set to domainuser@CONTOSO.TEST.COM and that should work when they authenticate. You can also add a user into the CGI admin group in the same file, in the same way to allow that user to have admin access.

You will need to make a modification to the samba command that BackupPC uses if you back up with a local user account that's on the computer and not on the domain. On the Xfer tab of the BackupPC config, just before the -U $user, add -W $host. This will tell Samba that the username you're specifying is for the 'local host' domain, i.e., don't try to authenticate to the active directory, only authenticate locally to the computer. In my case, the local backup user accounts are not valid domain users, so this change needs to be made.

I'll update this when I figure out how to get Single Sign-On working on this through IE6. Right now i'm getting a gss_accept_sec_context() failed: An unsupported mechanism was requested (Unknown error).