Ubuntu 12.04 Ultimate Server Guide

Part 6: Account Management

Now you have OpenLDAP and Kerberos up and running, it’s time to learn how to manage your users and groups.

Management Scripts Configuration

Firstly, we’re going to install some scripts to aid with basic management tasks:

sudo apt-get install ldapscripts

Now we need to edit the config file /etc/ldapscripts/ldapscripts.conf uncommenting and changing the following to match your environment:

#  Copyright (C) 2005 Gana�l LAPLANCHE - Linagora
#  Copyright (C) 2006-2011 Gana�l LAPLANCHE
#  This program is free software; you can redistribute it and/or
#  modify it under the terms of the GNU General Public License
#  as published by the Free Software Foundation; either version 2
#  of the License, or (at your option) any later version.
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  GNU General Public License for more details.
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
#  USA.

# Note for Debian users:
# On Debian system ldapscripts will try to parse and use some system config.
# Look on commented variables and description lines started with DEBIAN.
# But you could override it's values here.

# LDAP server
# DEBIAN: values from /etc/pam_ldap.conf are used.
# Suffixes
# DEBIAN: values from /etc/pam_ldap.conf are used.
SUFFIX="dc=danbishop,dc=org" # Global suffix
GSUFFIX="ou=Groups"        # Groups ou (just under $SUFFIX)
USUFFIX="ou=Users"         # Users ou (just under $SUFFIX)
MSUFFIX="ou=Machines"      # Machines ou (just under $SUFFIX)

# Authentication type
# If empty, use simple authentication
# Else, use the value as an SASL authentication mechanism

# Simple authentication parameters
# DEBIAN: values from /etc/pam_ldap.conf are used.
# The following BIND* parameters are ignored if SASLAUTH is set
# The following file contains the raw password of the BINDDN
# Create it with something like : echo -n 'secret' > $BINDPWDFILE
# WARNING !!!! Be careful not to make this file world-readable
# DEBIAN: /etc/pam_ldap.secret or /etc/ldap.secret are used.
# For older versions of OpenLDAP, it is still possible to use
# unsecure command-line passwords by defining the following option
# AND commenting the previous one (BINDPWDFILE takes precedence)

# Start with these IDs *if no entry found in LDAP*
GIDSTART="10000" # Group ID
UIDSTART="10000" # User ID
MIDSTART="20000" # Machine ID

# Group membership management
# ObjectCLass used for groups
# Possible values : posixGroup, groupOfNames, groupOfUniqueNames (case-sensitive !)
# Warning : when using groupOf*, be sure to be compliant with RFC 2307bis (AUXILIARY posixGroup).
# Also, do not mix posixGroup and groupOf* entries up in you directory as, within RFC 2307bis,
# the former is a subset of the latter. The ldapscripts wouldn't cope well with this configuration.
GCLASS="posixGroup"   # Leave "posixGroup" here if not sure !
# When using  groupOfNames or groupOfUniqueNames, creating a group requires an initial
# member. Specify it below, you will be able to remove it once groups are populated.

# User properties
# DEBIAN: values from /etc/adduser.conf are used.
#UHOMES="/home/%u"     # You may use %u for username here
CREATEHOMES="yes"      # Create home directories and set rights ?
#HOMESKEL="/etc/skel"  # Directory where the skeleton files are located. Ignored if undefined or nonexistant.
#HOMEPERMS="755"       # Default permissions for home directories

# User passwords generation
# Command-line used to generate a password for added users.
# You may use %u for username here ; special value "" will ask for a password interactively
# WARNING    !!!! This is evaluated, everything specified here will be run !
# WARNING(2) !!!! Some systems (Linux) use a blocking /dev/random (waiting for enough entropy).
#                 In this case, consider using /dev/urandom instead.
#PASSWORDGEN="cat /dev/random | LC_ALL=C tr -dc 'a-zA-Z0-9' | head -c8"
#PASSWORDGEN="echo changeme"
#PASSWORDGEN="echo %u"

# User passwords recording
# you can keep trace of generated passwords setting PASSWORDFILE and RECORDPASSWORDS
# (useful when performing a massive creation / net rpc vampire)

# Where to log

# Temporary folder

# Various binaries used within the scripts
# Warning : they also use uuencode, date, grep, sed, cut, expr, which... 
# Please check they are installed before using these scripts
# Note that many of them should come with your OS

# OpenLDAP client commands

# Character set conversion : $ICONVCHAR  UTF-8
# Comment ICONVBIN to disable UTF-8 conversion

# Base64 decoding
# Comment UUDECODEBIN to disable Base64 decoding

# Getent command to use - choose the ones used
# on your system. Leave blank or comment for auto-guess.
# GNU/Linux
#GETENTPWCMD="getent passwd"
#GETENTGRCMD="getent group"
# FreeBSD
#GETENTPWCMD="pw usershow"
#GETENTGRCMD="pw groupshow"
# Auto

# You can specify custom LDIF templates here
# Leave empty to use default templates
# See *.template.sample for default templates

The changes from the default file are highlighted below:

# Provides LDAP server's address and the admin username

# These have all been uncommented, Users changed to People
# and the correct suffix set for our domain
SUFFIX="dc=danbishop,dc=org" # Global suffix
GSUFFIX="ou=Groups"        # Groups ou (just under $SUFFIX)
USUFFIX="ou=Users"         # Users ou (just under $SUFFIX)
MSUFFIX="ou=Machines"      # Machines ou (just under $SUFFIX)

# This creates home directories when we create users

If you’ve read through the default comments in /etc/ldapscripts/ldapscripts.conf you’ll see that it finds the LDAP admin password from a /etc/ldap.secret file. So the following two commands create that file, write our admin password to it (change PASSWORD to your admin password) and then set it to be non-world-readable. This prevents users discovering your LDAP password, but allows root, or processes running as root, to read the file and find the password.

sudo sh -c "echo -n 'PASSWORD' > /etc/ldap.secret"
sudo chmod 400 /etc/ldap.secret

You might also have noticed that /etc/adduser.conf is used to determine home directory defaults. Ubuntu allows users to view the contents of other user’s home directories by default. In some environments, particularly home environments, this is fine, but you might want to change that by editing DIR_MODE=0755 to be DIR_MODE=0700.

Managing Users

Now the LDAP scripts are configured we can start creating users. We’re going to use the group name “domainadmins” for administrators to differentiate from the default “admin” or “sudo” group for local Ubuntu users. This will enable us to give admin rights to users on every machine on the network without any further configuration.

The first thing to do is create a password for our first admin user. As we are using Kerberos for authentication, the administrator needs a principal creating. This is done like so:

sudo kadmin.local -q "addprinc dan"

Now we need some groups to hold our users. The first two groups we will create will be “domainadmins” and “domainusers”:

sudo ldapaddgroup domainadmins
sudo ldapaddgroup domainusers

Next we will create a user and assign him to the admins group:

sudo ldapadduser dan domainadmins

And finally add the user to the users group too:

sudo ldapaddusertogroup dan domainusers

You can now login to the server (and later client machines) as this user. If you added sudo to LDAP earlier, as instructed in the OpenLDAP section, then sssd will handle this automatically on the server and users in the group “domainadmins” will have sudo rights on the server – be careful who you assign to this group!



  • 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.