Ubuntu 12.04 Ultimate Server Guide

Part 7: Connecting Ubuntu Clients

The clients are going to be configured so that they mount home directories from the server and verify usernames and passwords using LDAP and Kerberos.

I won’t cover the installation of Ubuntu itself here (it’s incredibly simple and there are a million guides, videos, etc. out there if you do need help) however, it is important that during the install, when asked to specify the machine’s hostname, you enter its FQDN, e.g. dan-desktop.danbishop.org

If you forget to do this, or are working with an existing Ubuntu installation, then edit /etc/hosts and change the line that reads “ dan-desktop” to read “ dan-desktop.danbishop.org dan-desktop”.

You MUST check that the command “hostname -f” outputs yourmachine.yourdomain (e.g. dan-desktop.danbishop.org) BEFORE proceeding any further.

I also recommend you create a local user during the install named “adminlocal”. We will use this account to configure the client.

First we need to install SSSD on the client, this will handle all LDAP and Kerberos configuration as well as providing a caching service for both should the network become unavailable.

sudo apt-get install sssd libsss-sudo krb5-user nfs-common autofs

Answer the questions about the kerberos domain if asked, e.g. domain name: DNABISHOP.ORG, server: kerberos.danbishop.org, admin server: kerberos.danbishop.org

Time to configure sssd.conf. This file may, or may not already exist, but in any case you’re going to want to change a few things for optimum configuration. I suggest proceeding like this:

sudo nano /etc/sssd/sssd.conf
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, sudo
domains = danbishop.org

filter_groups = root
filter_users = root
reconnection_retries = 3

reconnection_retries = 3

; Using enumerate = true leads to high load and slow response
enumerate = false
cache_credentials = false

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5

ldap_uri = ldap://ldap.danbishop.org
ldap_search_base = dc=danbishop,dc=org
ldap_sudo_search_base = ou=sudoers,dc=danbishop,dc=org
ldap_tls_reqcert = never

krb5_kdcip = kerberos.danbishop.org
krb5_realm = DANBISHOP.ORG
krb5_changepw_principle = kadmin/changepw
krb5_auth_timeout = 15
krb5_renewable_lifetime = 5d

In order for sssd to start correctly, the config file needs to be readable only by the root user, if the file already existed when you went to edit it, this step shouldn’t be necessary:

sudo chmod 600 /etc/sssd/sssd.conf

Now we can restart sssd and you should be able to login at the terminal as one of your LDAP/Kerberos users:

sudo service sssd restart

At this point, you’ll find that you can now su to any user in your domain using the terminal. However, you won’t be able to log in graphically as domain users don’t currently have a home directory… let’s sort that now.

Although we have configured everything so that clients can get kerberos settings from DNS… kadmin does not fully support this 🙁

This means we’re going to have to make a small change to /etc/krb5.conf on the clients to make the following steps a LOT easier.

sudo dpkg-reconfigure krb5-config

Enter the realm again (DANBISHOP.ORG – it should already be present) and then when asked whether you’d like to add the realm information to /etc/krb5.conf select YES, not the default option of no. Now enter the kerberos server and admin server addresses (both kerberos.danbishop.org).

Now we’re going to create a kerberos principal for NFS on the client like so:

kadmin -p dan/admin -q "addprinc -randkey nfs/$(hostname -f)"

Having specified the admin server in /etc/krb5.conf we can run these command directly from the client.

Now we need to add the principal that’s just been created on the server, to the keytab file on the client:

sudo kadmin -p dan/admin -q "ktadd nfs/$(hostname -f)"

Configuring NFS

NFS needs to be configured to use kerberos by editing /etc/default/nfs-common:

# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".

# Do you want to start the statd daemon? It is not needed for NFSv4.

# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/?SecuringNFS

# Do you want to start the gssd daemon? It is required for Kerberos mounts.

Note that NEED_GSSD has been set to yes.


Now we’re going to install and configure autofs to mount home directories on login.

To configure autofs we will edit /etc/auto.master.

sudo nano /etc/auto.master

Here is the sample file provided by Ubuntu:

# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc
# NOTE: mounts done from a hosts map will be mounted with the
#       "nosuid" and "nodev" options unless the "suid" and "dev"
#       options are explicitly given.
#/net   -hosts
# Include central master map if it can be found using
# nsswitch sources.
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.

As you can see, everything except the last line is commented out. COMMENT OUT THE LAST LINE. Then take note of the format used by the examples. Each mount point is associated with another configuration file. We will create a new configuration file for our NFS share(s).

Add the following line at the end of /etc/auto.master:

/home   /etc/auto.home

This creates a mount point at /home and configures it according to the settings specified in /etc/auto.home (which we are about to create).

Now we will create the file which countains our automounter map:

sudo nano /etc/auto.home

This file should contain a separate line for each NFS share. The format for a line is {mount point} [{mount options}] {location}.

*   -fstype=nfs4,rw,hard,intr,sec=krb5   neo.danbishop.org:/home/&

This will automount any directory you try to access in /home allowing any user to login 🙂

All that remains is to restart automount (personally I’d just reboot the machine) by running:

sudo service autofs restart

Admin Rights

We want the local machine to grant privileges to the domainadmins group so that its members have admin rights on every machine on the network.

You should find that install libsss-sudo has already added the following to /etc/nsswitch.conf:

sudoers:        files sss

This has sorted the use of sudo from LDAP, however, if you’d also like domainadmins to be able to use graphical programs as an administrator (for example, The Ubuntu Software Centre) then we need to tell polkit to grant domainadmins the necessary rights:

sudo nano /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf

Append “;unix-group:10000” to the file like so:


Replacing 10000 with the correct Group ID for your administrators group. If you’ve been following this guide from the beginning, it should be 10000, but you can check with the command “getent group”. DO NOT use the group’s name, i.e. domainadmins. Although this should work, a bug prevents it from doing so at present.

LightDM – The Login Screen

By default, the Ubuntu 12.04 login screen lists all the usernames on the system. However, we want to be able to enter a username manually. This requires a small change to /etc/lightdm/lightdm.conf

sudo nano /etc/lightdm/lightdm.conf

Append “greeter-hide-users=true” to the file like so:


You might also like to append “allow-guest=false” to disable the guest account.

Now restart the client machine and you’re done! 😀



  • Christian Oswald

    it’s a very useful tutorial and I learned a lot from it.
    I had also the problem with “Error adding group domainusers to LDAP” and in my case I solved it with switches TLS off in the LDAP-Server. I made it with webmin because I can’t find the correct place for it in the configuration files. I think it depends from the defaults of the ubuntu installation (in my case 14.04).
    But I have also a problem with the kerberos authentification. It works nice on the server (kadmin.local runs, kinit brings a ticket …) but from a client I get all times the error “kadmin: Cannot contact any KDC for requested realm while initializing kadmin interface”.
    I have reinstalled all, checked the configuration file of dnsmasq, krb5 … nothing helps, no firewall runs …
    I have tested a lot – ping, nslookup works and give the correct server. But nmap said that only port 749 is open on the server but in the kdc.conf is written that port 750 and 88 is used. I don’t if it’s important.
    Has anyone any idea for the reason of this error?


  • Jezzirolk

    hey Dan, i have used your guides a few times and they are great. Still work with 14.04 i dont think there was any tweaking i really had to do. i have a question though, is there a reason you disabled cache_credntials. Not saying there arent possible security reasons but i was more curious if there were other technical reasons becasue when connecting a laptop it is providing to make this a bit harder.


    • danbishop88

      Hi Jezzirolk,

      I believe my reason for this was to do with: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1039151

      Basically, without it SSSD tends to come up before your network connection. This forces it into “offline” mode and it won’t even try to reconnect to your ldap/kerberos server until two minutes have elapsed. This prevents anyone from logging in for the full two minutes.

      A better workaround is listed in that thread, which is forcing the login screen to wait for the network to come up before appearing. I intend to move to that if I ever get round to finishing my 14.04 guide.

      Hope that helps…


      • Jezzirolk

        Hey Dan,
        this still doesn’t really solve the issues i think, waiting for the network doesn’t do much for my case of a laptop. if i am off site it still wont connect properly unless you try to use cached credentials. Are we saying use cached credentials and then wait for network as to prevent the false negative of can not connect to ldap server? if that’s the case that might work.

        i guess the better question is if i log in off line. how does reconnecting once we end up back on a network with access to the server?

        Any thoughts on this and how to deal with the NFS mounts with laptop or systems that end up off site.