In a post a couple of years ago I gave an example on how to configure an Ubuntu 12.04 server to authenticate to Active Directory. Things used to be hard back then. Now we have the realmd realm enrollment manager to do the hard work of joining the host to an Active Directory domain, and the System Security Services Daemon or SSSD to do the actual authentication and authorization work whenever it is needed. And things are much easier to configure and get running.
Also in the mean time Microsoft has deprecated the Identity Management for UNIX extension to Active Directory. It used to be used to manage POSIX attributes in the AD for use by UNIX clients. Luckily, the SSSD has a nice coherent way of mapping Windows user and group ids to UNIX ones so that POSIX attributes may not be needed at all in the AD anymore, making things more straighforward. If you still need to be able configure attributes by individual LDAP entry basis, you may need to look into FreeIPA and ID Views. The automatic id mapping is not compatible with the old POSIX attributes in the sense that once you enable automatic id mapping, all the existing POSIX attributes are ignored. So you may have to fix group memberships, for example, if your POSIX group memberships don’t match the Windows group memberships (the Windows group memberships are the ones that will be used with id mapping). And of course all the uid numbers will be changed when you flip the switch and enable automatic id mapping.
If you haven’t been using POSIX attributes in the AD schema before, you don’t have to worry about anything I said in the last paragraph. It just works.
Table of Contents
Prerequisites
SSSD and realmd can be found in the Ubuntu repositories, so installation is easy. But a couple of things must be taken care of first.
The first prerequisite is, make sure you are using your Active Directory DNS servers. They will be used to query the addresses of the domain controllers, and when the domain is joined, DNS records (forward and reverse) are added.
The second prerequisite is that your time keeping should closely match the AD domain controller machines (usually within 5 minutes of each other). Use your domain controllers as NTP time sources, or at least use the same time sources for the domain controllers and the Linux hosts to keep their clocks very close to each other.
Install Kerberos client, SSSD and tools
Install the Kerberos client, the realm enrollment tool, the System Security Services Daemon, the AD client tool, and Samba tools:
1 |
apt-get install krb5-user realmd sssd sssd-tools adcli samba-common-bin |
When prompted, type in your AD Kerberos realm. It should generally be your domain name in capital letters (“koo.fi” becomes “KOO.FI”). If your DNS is working properly, that should be all that is needed for the Kerberos client to work alright. Otherwise you may need to add your servers to /etc/krb5.conf.
Authenticating with Kerberos
Try getting a Kerberos ticket as domain administrator:
1 2 |
kinit administrator@KOO.FI klist |
The output of klist should look like this:
1 2 3 4 5 6 |
Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administrator@KOO.FI Valid starting Expires Service principal 06/16/15 16:23:22 06/17/15 02:23:22 krbtgt/KOO.FI@KOO.FI renew until 06/17/15 16:23:18 |
That shows we now have a ticket valid for some hours, meaning the Kerberos authentication is working fine to the domain controller. We can proceed to configuring the realmd realm enrollment tool which will join us to the domain, and later use this ticket to actually execute the join operation.
Configuring realmd
Edit /etc/realmd.conf:
1 2 3 4 5 6 7 8 9 10 11 |
[service] automatic-install = no [users] default-home = /home/%D/%U default-shell = /bin/bash [koo.fi] computer-ou = OU=Linux,DC=koo,DC=fi automatic-id-mapping = yes fully-qualified-names = no |
The automatic-install=no option will disable automatic installation of packages by realmd.
The default-home=/home/%D/%U option will make the home directories of users be of form /home/DOMAIN/USERNAME, eg. /home/koo.fi/administrator. The default-shell is the shell for users.
The computer-ou option tells where the machine account will be added in AD.
The automatic-id-mapping=yes option makes SSSD use automatic id mapping instead of user and group ids stored in POSIX attributes in AD. The SSSD automatic id mapping is intelligent in that it can guarantee the same UNIX uid and gid on different hosts when all the hosts are using SSSD.
The fully-qualified-names=no option will by default remove the domain part from user and group names. It may result in name collisions, but makes things easier for users since they only have to type in their username part and not the domain part every time.
Joining The Host to the Active Directory Domain
You can use the “realm discover” command to see if the Active Directory domain can be discovered. It requires avalid Kerberos ticket as a domain administrator.
1 |
realm discover koo.fi |
Output should look like:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
koo.fi type: kerberos realm-name: KOO.FI domain-name: koo.fi configured: no server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin |
We have all the required packages already installed, so let’s just join:
1 2 |
realm join koo.fi realm list |
Output looks like:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
koo.fi type: kerberos realm-name: KOO.FI domain-name: koo.fi configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin login-formats: %U login-policy: allow-realm-logins |
After a successful join, you should be able to resolve individual users and groups using getent:
1 2 3 4 |
getent passwd administrator # administrator:*:364000500:364000513:administrator:/home/koo.fi/administrator:/bin/bash getent group 'Domain Admins' # domain admins:*:364000512:administrator |
If you run into a “Failed to join the domain” error, try the join with user given as an option:
1 |
realm join koo.fi --user=administrator |
If you run into a “Necessary packages are not installed” error, you may try to install packagekit:
1 2 3 |
apt-get install packagekit killall aptd killall realmd |
And then try again. There’s a bug in Launchpad about it.
Controlling Who Can Log In
Also at this point you should be able to log in with any AD user id by default. You can control who can and who cannot login with
1 2 3 |
realm deny --all realm permit administrator realm permit -g 'Domain Admins' |
You can see the changed policy and permitted logins with
1 |
realm list |
Output:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
koo.fi type: kerberos realm-name: KOO.FI domain-name: koo.fi configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin login-formats: %U login-policy: allow-permitted-logins permitted-logins: administrator permitted-groups: Domain Admins |
Enumerating Users and Groups
The SSSD configuration file /etc/sssd/sssd.conf was generated by the realm join command and will look something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[sssd] domains = koo.fi config_file_version = 2 services = nss, pam [domain/koo.fi] ad_domain = koo.fi krb5_realm = KOO.FI realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%d/%u access_provider = ad |
For performance reasons by default SSSD will not try to enumerate every user and group from AD, but will only query for them when requested. If you want to enable enumeration, add:
1 |
enumerate = True |
under your domain stanza in sssd.conf (and “restart sssd”). It is quick for a small directory, but may be slow for a large one. It can be handy for debugging, as you can list all users and groups with
“getent passwd” and “getent group”.
Automatic Home Directories
To create home directories at first login, add a pam_mkhomedir.so line in /etc/pam.d/common-session:
1 2 3 4 5 6 7 8 |
session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session optional pam_umask.so session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel umask=0022 session optional pam_sss.so session optional pam_systemd.so |
That’s basicly it. At this point you should have a fully functioning AD login for selected users on your Ubuntu server.
Internals
The “machine account” Kerberos principal is saved into the file /etc/krb5.keytab. You can list its contents with “klist -kt /etc/krb5.keytab”:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 3 06/16/15 17:35:57 host/server.koo.fi@KOO.FI 3 06/16/15 17:35:57 host/server.koo.fi@KOO.FI 3 06/16/15 17:35:57 host/server.koo.fi@KOO.FI 3 06/16/15 17:35:57 host/server.koo.fi@KOO.FI 3 06/16/15 17:35:57 host/server.koo.fi@KOO.FI 3 06/16/15 17:35:57 host/SERVER@KOO.FI 3 06/16/15 17:35:57 host/SERVER@KOO.FI 3 06/16/15 17:35:57 host/SERVER@KOO.FI 3 06/16/15 17:35:57 host/SERVER@KOO.FI 3 06/16/15 17:35:57 host/SERVER@KOO.FI 3 06/16/15 17:35:57 SERVER$@KOO.FI 3 06/16/15 17:35:57 SERVER$@KOO.FI 3 06/16/15 17:35:57 SERVER$@KOO.FI 3 06/16/15 17:35:57 SERVER$@KOO.FI 3 06/16/15 17:35:57 SERVER$@KOO.FI |
Here the local server’s hostname is “server”. SSSD uses this keytab file and the principals in it to periodically refres Kerberos tickets, which are saved in the file /var/lib/sss/db/ccache_<REALM>. For example “klist -c /var/lib/sss/db/ccache_KOO.FI”:
1 2 3 4 5 6 7 8 9 10 |
Ticket cache: FILE:/var/lib/sss/db/ccache_KOO.FI Default principal: SERVER$@KOO.FI Valid starting Expires Service principal 06/22/15 13:22:52 06/22/15 23:22:52 krbtgt/KOO.FI@KOO.FI renew until 06/23/15 13:22:52 06/22/15 13:22:52 06/22/15 23:22:52 ldap/dc1.koo.fi@ renew until 06/23/15 13:22:52 06/22/15 13:22:52 06/22/15 23:22:52 ldap/dc1.koo.fi@KOO.FI renew until 06/23/15 13:22:52 |
Here we can see three active tickets. These are used to authenticate the host to AD and fetch information from LDAP.
There are also .ldb files under /var/lib/sss/db which you can dump using tdbdump tool from the tdb-tools package if you want to see internal configuration and cached data.
The IP address of the AD domain controller currently used as KDC can be found in /var/lib/sss/pubconf/kdcinfo.<REALM>.
I followed these instructions but getent would not return any domain users or groups. I found that /etc/krb5.conf did not contain the entries required in the [realms] and [domain_realm] sections. Once I added them it worked.
I have a set-up like this but now want to use samba shares with AD group access controls. Do you know how to map the groups?
Hi, this configuration already maps groups. You should be able to list group members with eg.
You can use those groups when configuring Samba.
Followed you guide and it all worked perfectly, thanks!
One thing though.
I dont have any host/servername.domainname@DOMAINNAME type principals in my keytab.
I have host/servername@DOMAINNAME, servername@DOMAINNAME and RestrictedKrbHost/servername@DOMAINNAME, how do I get host/servername.domainname@DOMAINNAME principals I need them because ssh gssapi checks against them.
If they aren’t present I get Unspecified GSS failure. Minor code may provide more information\nNo key table entry found matching host/servername.domainname@\n
Followed you guide and it all worked perfectly, thanks!
There is just one thing. With the AD user being in the sudoers when sudo is executed an event is generated like so
myhost : Feb 25 08:14:15 : myuser : problem with defaults entries ; TTY=pts/0 ; PWD=/home/my.domain/myuser;
I am wondering if this has something to do with the UMASK that is set in ‘/etc/pam.d/common-session’.
Any ideas?
Your problem has to do libsss-sudo, remove it and those errors will go away.
Hello,
I followed your guide for a Ubuntu 14.04 lxc container. I can enroll in the realm, but I can´t resolve users using getent.
With a kvm machine it all works fine.
Could you please give me a hint?
I would add enumerate=True along with some debug_level to sssd.conf and then see what you get in your log files while running getent passwd. See “man sssd.conf”. I hope that leads you to the culprit.
That did it, at least part of it.
The permissions on the sssd.conf weren´t set correctly, it needs to be owned by root.root and have 0600 permissions.
I can resolve AD users now, but I can´t login with them. I just get
“groups: cannot find name for group ID xyz”
Can you resolve the group with “getent group GID”?
Yes, that works.
To clarify:
I can resolve users and groups with getent.
I can log in as AD-user
The only thing I can´t do is su AD-user.
thanks for the tutorial… it works fine on linux boxen….
however, if a user creates a file/directory on windows, it comes up as different UID:GID on my linux box and the user cannot access it on linus.
anything i missed?
Thanks
S
I have an interesting situation where I have join privileges, but only to a specific OU within the domain. Is there a way to specify which container to join during the join process?
Hi,
I’m getting “[sssd[krb5_child[1905]]]: Decrypt integrity check failed” when i try to log in after your guide.
Getent commands work fine, showing domain users and groups.
Any ideas?
Awesome article and thank you! You pulled in all the piece-parts into one article and it worked like a dream. Thanks again!!!
Thanks! It is nice to hear it still helps people out.
Hello there, great guide! Easy to follow and worked perfectly! My question is this:
How can I make the default login use this realm? For example, when I connect with SSH, I have to use ‘user@domain.com’ as the username, instead of just being able to use ‘user’. How can I make this work without having to specify the domain? Thanks!
Hi kortski
Old but Gold! Thank you for this guide.
– I have a linux mint20 client and a synology diskstation with AD Controller.
I did all the steps nd tests like you described.
Every test worked fine. Each content of the files still validated and fine.
Only one exception:
I can not get the user and groups by getent.
Any idea, where i can search – without any known error message 🙂
Thanks a lot in advance!