For this tutorial I will be walking through how to use a tool called Realmd to connect an Ubuntu Server or Ubuntu Desktop system to a Windows Active Directory Domain.
In the past I wrote an article talking about how to use Powerbroker Identity Services to do the same thing, but the scope of the article was limited to the server version of Ubuntu only. Furthermore, it has since been my experience that PBIS is an unreliable solution at best.
Part of the confusion I have had on this issue in the last two years has been in thinking that there are only one or maybe two ways to make an Ubuntu Desktop/Server OS connect to a Microsoft Active Directory domain and they both used the same underlying stuff. In fact there are more like 10 different ways to do it all using a mix and match of different technologies.
Finally, I don’t like proprietary stuff. PBIS, while having a free version, was still proprietary. Today we will be using a suite of tools called SSSD. SSSD was created by Redhat and it’s opensource. Furthermore we will be using RealmD, which is a “wrapper” of sorts for SSSD that makes it easier to setup and configure. That’s the short of it. Let’s get started.
Windows Domain Controller (2012R2) w/ DNS:
Computer Name: DC01.loc.kiloroot.com
IP Address: 192.168.200.100 (static)
DNS Server: 192.168.200.100
Domain Admin Account Name: Administrator
Second Domain Admin Account: jdoe
Security Group: linuxadmins – jdoe belongs to this group
Domain User Account: nbeam
Security Group: linuxusers – nbeam belongs to this account
As side note about the internal domain name I am using… read this: How To Choose A Sensible Local Domain Name – There are really good reasons not to use a “fake” TLD or to use what are honestly often traditional Microsoft conventions like .local – I ran into a world of headache with Ubuntu using a .local TLD when I tried to do this the first time through! If your company has already standardized on .local I will be writing something separate about how to handle it because Ubuntu Desktop has some issues with it and for good reason…
An Ubuntu Desktop running 14.04 with Unity:
Computer Name: nix01
IP Address: 192.168.200.101 (static/manual)
DNS Server: 192.168.200.100
Search Domains: loc.kiloroot.com
Local Account Name: tester
Tester is also in the “Sudo” Group
Be able to login with jdoe and/or Administrator domain accounts on Ubuntu and have sudo rights. Be able to login with nbeam domain account and have regular user rights. Deny all domain users that aren’t in specifically permitted security groups from logging in.
On the ubuntu box, logged in as “tester” and elevated with “sudo su”
apt-get install realmd sssd samba-common samba-common-bin samba-libs sssd-tools krb5-user adcli packagekit vim -y
You will get prompted to enter your domain during the above install, I entered “LOC.KILOROOT.COM” (note, ALL CAPS)
Next you will need to get a kerberos ticket from the domain controller. You do this with the kinit command and a username of one of the already existing domain users. I will use “jdoe” as he is also a domain admin.
It will prompt for that user’s domain password, enter it. You should get the response back “Authenticated to Kerberos v5”
If that checks out then the next step is to do the domain join!
You will be prompted for jdoe’s domain password, enter it. Then you should get a message back along the lines of:
That’s fine. We are going to fix this by putting some config lines in our SSSD configuration file. I think this is a failing overall of Realmd which otherwise makes this much easier.
echo 'dyndns_update = True' >> /etc/sssd/sssd.conf
service sssd restart
The first line authoritatively sets your machine’s FQDN. Other tutorials I came across had me screwing with the /etc/hosts files but I think due to the way Ubuntu/Debian handles hosts that not everything quite translates…
The second setting enables Dynamic DNS updates to run under certain conditions, specifically when SSSD restarts, hence we restart it. If you have aging/scavenging enabled on your Domain Controller’s DNS server you may want to drop a script in /etc/cron.daily/ to just restart the SSSD service on a daily basis which will initiate a DNS update. If you hop on your domain controller and look in DNS, you should see an entry for your Ubuntu machine.
That all sounds quick and easy above but it took a lot of digging to figure out…
Then the pertinent part of the rest of the message that follows after the above:
Followed by yet another DNS error “ERROR_DNS_GSS_ERROR” and then finally a note about the SSSD service starting and “successfully enrolled machine in the realm.”
You can now check to make sure your machine is truly joined by running realm list:
Which should return a bunch of info about the loc.kiloroot.com domain you are now joined to. To further check domain functionality lets make sure we can view the groups that users belong to…
And for good measure…
As you can see, the groups are correct for both users.
As a side note, if you change group memberships on your domain controller midway through but “id firstname.lastname@example.org” is still not showing the updated groups, then use the command “sss_cache –users” to clear the credentials cache and then try again, that should tell Ubuntu to fetch their user info fresh from the DC.
Great, so we are now domain joined but we aren’t quite ready to authenticate with domain accounts into our machine yet…
Specify Which Groups Have Access
By default, SSSD and RealmD allow all domain users the right to login. If you want to disable that functionality, change the default to deny all.
Next we want to allow the following groups the right to login: Domain Admins, LinuxAdmins, LinuxUsers
Specify Which Groups Have Sudo Privileges
Use the program ViSudo to modify the /etc/sudoers file and specify which groups have sudo privileges.
Add the following lines to the bottom of the file:
%email@example.com ALL=(ALL:ALL) ALL
Make Sure Each New Domain User That Logs In Gets a Home Directory (REQUIRED FOR UBUNTU DESKTOP)
First Test of Truth – SSH Login with Domain Credentials
You can skip this if you don’t plan on using SSH. If you are running the server version of Ubuntu then SSH is probably already installed, if not (i.e. you are running Ubuntu Desktop) then you can install it with “apt-get install openssh-server”.
Now it is time for the first test of domain authentication. Open up an SSH session to your server and try to login with your domain credentials. The USERNAME format should be:
I tried with my nbeam account first, which should NOT have sudoer permissions. It worked and I was not able to elevate. I then tested with the jdoe account and could login and elevate and the same with the administrator account. I finally added one more dummy account in Active Directory with no group memberships and attempted to login and got denied. So all is working correctly.
Enabling Desktop Authentication
Finally, we need to enable a few more things to get authentication into the GUI desktop working. This is for Unity, which by default doesn’t allow you to “free-form” enter a username but rather only lets you select from a list of users. To change that…
echo 'greeter-hide-users=true' >> /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf
echo 'allow-guest=false' >> /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf
The second item hides all of the user who have logged in previously from the selection list which is generally a requirement for most businesses. The third disables guest account access via the GUI.
Reboot the system, then you can login to unity with firstname.lastname@example.org and you should get a desktop!
I really like the combination of RealmD with SSSD. I feel like I have a lot more control and understanding vs. PBIS but that also might just be having a few more years under my belt compared to my first attempt. However I get the feeling that SSSD is a much better package and with Redhat behind it I would imagine it will continue to get updated over time.
That all being said, the above was a bit heavy as far as the amount of work required so I plan on scripting the majority of it and I will provide my results as an update on this post at a later time. I think it should be quite easy to script almost all of this out.
In the meantime, this is a full-fledged working solution from what I can tell! So enjoy!
References: Scripting: LightDM: DNS Resolving and .local:
RealmD & SSSD:
DNS Resolving and .local: