Joining a GNU/Linux machine to a Microsoft Active Directory has been possible for years, but it’s always been a bit of a science project that involved touching half-a-dozen obscure config files and usually resulted in me getting completely locked out of the machine. Various commercial packages such as Likewise and Centrify aimed to smooth out the process, but they weren’t universally accessible across distros, and often produced inconsistent results.
After upgrading a system to Debian 8, I noticed a new option for joining the domain, courtesy of the folks at RedHat: realmd. Realmd puports to make joining an Active Directory domain dead simple. How does it do?
What means this “join”?
When I think of “joining a domain”, my expectation is that I should be able to login to my system as a domain user, have a computer account created in the directory, have a home directory created for me, and potentially have some appropriate permissions granted to me (e.g., sudo privileges for domain admins). Apparently that’s not what everyone means, including the developers of realmd.
realmd will get us part of the way there, but unfortunately we’ll still have to do some config file twiddling to get the last nine yards.
Pre-Setup
Sanity checks
- Make sure you have Debian 8 installed.
- Make sure your machine is on the network, of course, and that you have a domain admin account ready (or one that can join machines to the domain).
- Make sure your DNS server is pointing to a DNS server that knows about AD. We have some pre-AD ones that don’t, and I ran into trouble with this. Most people probably don’t need to worry about this.
- I use sudo in these examples because I prefer it. If you don’t, make sure you’re root and omit the “sudo” whenever you see it.
Installing packages
Realmd is easy enough to install using aptitude:
sudo aptitude install realmd
Ideally, realmd is meant to install other packages required to join your domain (be it Active Directory, openldap, or some other supported directory) automatically when you attempt to join.
In practice, I found this unreliable. So for my AD, I also installed adcli and sssd manually. And since time synchronization is critical for Active Directory, I also installed ntp.
sudo aptitude install ntp adcli sssd
Some fixes
For some reason, the first attempts I made to join a domain failed because a certain samba-related directory didn’t exist. I don’t know if this is a bug in realmd, or something to do with the way it installs dependencies, but simply creating the directory fixes this:
sudo mkdir -p /var/lib/samba/private
Also, sssd was not configured to start at boot for some reason, so this also needed to be done.
sudo systemctl enable sssd
sssd won’t actually start until it has a config file, which realmd will generate for us.
Join up
At this point, you should be able to get some information about your domain with this command:
sudo realm discover my-domain.local
Obviously, replace “my-domain.local” with your AD domain. You should see some output that looks like this:
my-domain.local type: kerberos realm-name: MY-DOMAIN.LOCAL domain-name: my-domain.local configured: no server-software: active-directory client-software: sssd
If this looks good, we can join the domain:
sudo realm join --user=joe.smith my-domain.local
This assumes joe.smith is a domain admin. Use whatever domain admin account you have. You’ll be prompted for a password, of course, and then the magic happens.
If all goes well, your machine should be configured to authenticate users to your domain at this point. You may need to start up sssd:
sudo systemctl start sssd
We can verify this by trying to get a password entry for a domain user:
sudo getent passwd joe.smith@my-domain.local
If that returns something that looks like a line from /etc/passwd for your joe.smith user, you’re in! Otherwise, something went wrong.
Vital finishing touches
You can authenticate users at this point, but we’re not quite done. Two more tweaks are necessary here:
You want a home directory?
By default, Debian isn’t going to make a home directory whenever the user logs in. We need to fix this, because without this you can’t actually log in to the computer. Fortunately, it takes only one line in one config file to acheive this:
echo "session required pam_mkhomedir.so skel=/etc/skel/ umask=0022" | sudo tee -a /etc/pam.d/common-session
This tells PAM to create a home directory for any authenticating user if they don’t have one, and to copy the default contents from /etc/skel. You can change that to something else if you want a different default home directory for domain users.
Local admin privileges
Typically on a domain, domain admins would get local admin rights so they can do admin things on computers. Makes sense.
To get this in our Debian setup, we need to make sure our sudo supports this, and then configure it.
sudo aptitude install libsss-sudo echo "%domain\ admins@my-domain.local ALL=(ALL) ALL" | sudo tee -a /etc/sudoers.d/domain_admins
The first line installs a library to allow sssd and sudo to talk. The second adds a directive to sudo to allow domain admins at my-domain.local sudo privileges. (Copy-pasters take note: you need to edit that command with your domain name.)
Prepare for lift-off
Might as well give it a good reboot at this point just for the heck of it, but it may not actually be required (just a habit from Windows, I guess).
At this point you should be able to log in as any domain user, and domain admins should be able to sudo. Congrats!
For the completely lazy, I’ve thrown this script together that should do the job:
#!/bin/bash
# This script should join Debian Jessie (8) to an Active Directory domain.
echo "Please authenticate with your sudo password"
sudo -v
if ! $(sudo which realmd 2>/dev/null); then
sudo aptitude install realmd adcli sssd
fi
if ! $(sudo which ntpd 2>/dev/null); then
sudo aptitude install ntp
fi
sudo mkdir -p /var/lib/samba/private
echo "Please enter the domain you wish to join: "
read DOMAIN
echo "Please enter a domain admin login to use: "
read ADMIN
sudo realm join --user=$ADMIN $DOMAIN
if [ $? -ne 0 ]; then
echo "AD join failed. Please run 'journalctl -xn' to determine why."
exit 1
fi
sudo systemctl enable sssd
sudo systemctl start sssd
echo "session required pam_mkhomedir.so skel=/etc/skel/ umask=0022" | sudo tee -a /etc/pam.d/common-session
# configure sudo
sudo aptitude install libsss-sudo
echo "%domain\ admins@$DOMAIN ALL=(ALL) ALL" | sudo tee -a /etc/sudoers.d/domain_admins
echo "The computer is joined to the domain. Please reboot, ensure that you are connected to the network, and you should be able to login with domain credentials."
Works like a charm. Thank you!
“Unable to find adcli package”
“Package sssd is not available, but is referred to by another package….”
I’m using Debian 8 stable version, Is this a good version to be joined to AD?
You’re either not running Debian 8, or something is really wrong with your setup. Or maybe you just need to run “aptitude update”?
You’re probably still pointing the package manager at the Debian install DVDs. The adcli and sssd are probably missing or cannot be found on the media.
Be sure you add a main repository to /etc/apt/sources.list. The repository URL may vary based on your location.
deb http://ftp.us.debian.org/debian/ jessie main
OR
deb http://http.us.debian.org/debian/ jessie main
works perfect – thnx!
To login as “user” instead of “user@my-domain.local” set in /etc/sssd/sssd.conf:
use_fully_qualified_names = False
Thanks for that Nathan, that’s what I was looking for. =)
hey,
all works perfect except the sudo part, it says “user $RandomAdminUser is not allowed to run sudo on this machine.”
i have an 2008R2 active directory ( in french i don’t know if this change anything ) i already try with “%doamain\ admins\ du\ domaine@mydomain ALL=(ALL) ALL
have you a tips ? 🙂
Hi, i do every steps, when i do a sudo getent passwd, i get the info of the user from the server, but in login screen, it always says wrong password, i try 2 or 3 users anda same happens.
Same problem here, anyone get an answer for this?
WOW! This was without a doubt the best tutorial I have seen on this subject!
I have tried MANY other tutorials, with no success.
These instructions are clear and concise.
Thank you so much for this wonderful page!
Very thanks!!! Excellent post!!!
For some reason this is not working for me. I was able to join the machine to the domain. But “getent” with the domain_adm@domain_name returns nothing. Running “sudo systemctl status sssd” shows me this warning “ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied”; any idea what I am doing wrong?
Hey all — as much as I’d like to be able to solve everyone’s issues with this, it pretty much “works for me”, and I don’t know why it isn’t working for anyone else. Given the complexity and variety of AD setups, there are easily N+1 things that can go wrong with this.
If you really need help, you’re probably better off heading to your nearest Debian help forum, subreddit, irc, or mailing list.
Everything works fine except groups sudo supports. For example I have user grzyboll with uid=1790201640(grzyboll@musch.local) gid=1790200513(domain users@musch.local) groups=1790200513(domain users@musch.local),1790201326(linux_admin@musch.local), and when I add to sudoers
“%musch.local\\linux_admin ALL=(ALL) ALL” (where domain is musch.local, and group is linux_admin) or “%domain\ linux_admin@musch.local ALL=(ALL) ALL” it doesn’t work. But when I add only user grzyboll@musch.local ALL=(ALL:ALL) ALL it’s work.
One note, on my system anyway, for sudo I had to uncomment the following line
sudoedit /etc/sudoers:Changed:
#includedir /etc/sudoers.d
To:
includedir /etc/sudoers.d
After that I did
/etc/init.d/sudo restartSudo then worked for my domain admins. Thanks for the great write-up.
Oops that’s wrong! (delete that comment so no one makes that mistake!)
Changing the domain_admins file to be:
domain\ admins ALL= ALL
Is what worked for me for domain admins sudo’ing.
Thanks Rick and Nate and Alan! These directions worked perfectly. I can now login with my domain account and I can sudo. Life is good. I am now using a Debian machine for my work computer.
I received the following error message when attempting to login
See: journalctl REALMD_OPERATION=454.3065
realm: Cannot join this realm
I have exactly the same error, can someone help us?
On a fresh install you need to edit the /etc/nsswitch.conf file. From:
hosts: files myhostname mdns4_minimal [NOTFOUND=return]
dns
To:
hosts: files dns
Worked perfectly for me.
If i only have regular user account on AD, and for some reason, my sys Admin is so so so so afraid of Linux, is there a way to join my machine to AD?
Pretty sure the answer there is going to be ‘no’, joining a machine typically requires Domain Admin privileges in the default configuration, but unless you need to authenticate logins against the AD, there may not really be a reason to. If you just want access to your profile/home directory from a Linux system, it’s quite possible to mount samba shares using AD credentials without actually joining the machine to the domain.
Hi bussillis,
as I know, every domain-USER can join up to 10 (ten) computers to a domain without being an administrator.
An administrator can join unlimited computers.
The counter (of up to ten computers) can not be resetted. So if your user-account has joined al 10 computers, you can not join the 11th one …
BUT. Do not fight against your admin!
This is the best tutorial for the topic I’ve found. Thanks a ton! Worked like a charm!
In my system I have a HUGE AD with students staff alumni contractors etc in it. I dont want any of these users to be able to login. I only want specific AD groups to be able to login.
How can I limit the login via ssh and console to local groups and/or specific AD groups?
Hello,
I did everything, and i can join the ad. But when I log out from the local user, and try to login with AD user, it accepts the user/password, try to log in, and then log me out immediately. Can anyone help me with this? Or at least, where should I search for login logs?
Thanks in advance!
I have noticed that login works fine but sudo takes forever to run before reaching the password prompt for the first time.
From what I have read it is the sss_cache being cached. I assume because our AD is so large this is why.
As I am not storing my rules is AD, it just needs to look at the group membership. Is there any way to speed this up?
Dion
You can also create your own security group in AD for example “Linux sudo”
and grant sudo rights to that goroup:
echo “%linux\ sudo@mydomain.local ALL=(ALL) ALL” | tee -a /etc/sudoers.d/linux_sudo
works for me and user don’t have to be Domain admin 🙂
I got to the same problem as some of the others here, as I wasn’t able to see the domain users with getenv, then I found that avahi ‘loop’ my attempts because my domain suffix is .local
I followed this guide and everything worked:
http://www.lowlevelmanager.com/2011/09/fix-linux-dns-issues-with-local.html
Hi
Thanks for your article which was helpful, however I’d like to hear from you if you also get spammed for every sudo command issued once libsss-sudo is installed on jessie?
The user who gets root mails (/etc/aliases will tell you who, typicall the first user at install) receives an error message for each and every sudo command executed once it is installed.
Would be interesting to know since it is really annoying here on even fresh jessie setups here.
I haven’t noticed this so far. I just tried it on a system and did not get a mail, but I don’t have a lot of systems configured like this so maybe something is different with my configurations.
thank you for this very useful write-up.
i haven’t been able to get the sudo via group membership to work but that’s surely not your fault 😉
update:
had to enter this string into a file in /etc/sudoers.d
%ADgroupname ALL=(ALL) ALL
without passing a domain at all
again thank you for this excellent tutorial!
Thanks a lot for this tutorial. For me it needed a reboot between join and getent working. Everything else worked like a charm.
you should also touch a /etc/sssd/sssd.conf
my sssd didnt work and the AD-Join failed, because it didnt create the file itself
Hi Thanks a lot for this tutorial
i have a problem, after insert this command echo “session required pam_mkhomedir.so skel=/etc/skel/ umask=0022” | sudo tee -a /etc/pam.d/common-session and reboot my screen still in black..
The same happened to me, any one that have solution to this issue ?
It didn’t work for me without creating at least the first kerberos ticket using kinit. Authentication simply didn’t work without it. Other than that, it’s pretty spot on.
Can I copy and update this a bit? It’s very useful, but missing a few easy to ignore steps that will make people think it doesn’t work
dade, im about to be doing this myself, can you explain what is missing here so that i don’t think it’s not working.
thanks!
In order to add sudo capabilities to the user, do as follow:
sudo adduser username@my-domain.local sudo
sudo visudo
and then add these line:
name.surname@my-domain.local ALL=(ALL:ALL) ALL
Hi,
Tutorial was good.
i am facing different kind of issue after joining domain i was not able to list domain users using command “getent passwd domain username” but when using “realm list” shows that successfully joined domain. after few hours when system left idle it starts working and listing users.
Error msg found in log files.
an 19 21:38:23 debsys [sssd[ldap_child[990]]]: Client ‘debsys$@domain.com’ not found in Kerberos database
Jan 19 21:38:24 debsys [sssd[ldap_child[991]]]: Failed to initialize credentials using keytab [default]: Client ‘debsys$@domain.com’ not found in
Kerberos database. Unable to create GSSAPI-encrypted LDAP connection.
(Thu Jan 19 21:45:37 2017) [[sssd[ldap_child[1010]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client ‘debsys$@domain.com’ not found in Kerberos database
(Thu Jan 19 21:04:41 2017) [sssd[be[domain.com]]] [ad_account_info_complete] (0x0010): Bug: dp_error is OK on failed request
(Thu Jan 19 21:07:06 2017) [sssd[be[domain.com]]] [ad_account_info_complete] (0x0010): Bug: dp_error is OK on failed request
(sssd.conf file)
[sssd]
domains = domain.com
config_file_version = 2
services = nss, pam
[domain/domain.com]
ad_domain = domain.com
krb5_realm = domain.com
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = ad
how can we with this share a folder with ad authentication
Hi everyone!!
I have done everything in the tutorial, and I can see my debian from the AD administrator. But when I want to start a session with any of my domain users, Debian doesn’t allow it. It shows me this message:
The system administrator has temporarily disabled the login to the system
Hi,
In case anyone else comes across this on Ubuntu 16.04 LTS server.
After following this great tutorial, we were able to successfully authenticate against Acitve Directory in our test environment without installing krb5-user.
However, when we tried the exact same steps on a clean system using client’s server, we just couldn’t join their AD realm. We kept on getting the following error:
[,,,]
Couldn’t authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
[…]
Pro Tip: For debugging purposes, turn on “–verbose” in your join realm command:
sudo realm join –user=joe.smith my-domain.local –verbose
To fix our problem, we ended up installing krb5-user and adding the following line to /etc/krb4.conf to disable reverse DNS lookup .
[libdefaults]
rdns=false
That allowed us to successfully authenticate against AD.
Also, if you don’t want to provide the full domain name in your login credentials, modify /etc/sssd/sssd.conf AFTER you join the realm and BEFORE you start the sssd service by changing:
use_fully_qualified_names = False
Hope that helps…
A
Thanks very much , this helped alot….
You sir, I owe a lunch!
Hello everyone,
This method is not working in Debian 9 Stretch :(, I enter the computer into the domain, but when I try to login it does not accept the user password. Any idea what it might be?
PS: This method is working perfectly for me in Debian 8 Jessie.
I upgraded from Debian 8 to to Debian 9 as well and it broke. I also committed a bajillion other changes and locked myself out of SSH access so there are probably a number of other issues that resulted in this breaking. I.E I can not say for sure if upgrading to Stretch was what caused it to break; however, that being said I was able to fix my problem.
I completely removed and reinstalled SSSD-AD on my system; however, ran into the same issue. Debian login would take my password, but it would not grant access, /var/log/auth.log revealed that my user account was not authorized.
Ultimately the issue resided in /etc/sssd.d/sssd.conf all along
access_provider = ad
I set mine too
access_provider = simple
and added
simple_allow_users = NameofdomainUserYouWantToAllow
Restarted SSSD and was able to login with my FQDN.
It’s pretty obvious now that issue lies in how access_provider = ad is set-up. I don’t know what the correct settings are to make access_provider = ad work, but I’m on the right track. I’ll see if I can make it work here soon.
https://outsideit.net/realmd-sssd-ad-authentication/
any further improvement in sorting out the problem?
your solution seems not to have effect in my case (new installation of debian 9.1)
I can see (from another machine) that the computer object is effectively created in Active Directory but very simply it is not possible to login with an ad account
Thank you, Alan! I’ve been trying off-and-on for 15 years or so to do this (it hasn’t been very high-priority), and your tutorial here made it simple, and better yet, it worked. (I realize a lot of credit goes to the realmd app and developers, but you’re the one that made me aware of it.)
This. Is. Awesome.
Thank you very much for your write-up!
realm join –user=administrator uk.xxxx.co.uk
Password for administrator:
See: journalctl REALMD_OPERATION=r2645.14672
realm: Couldn’t join realm: Necessary packages are not installed: samba-common-bin, sssd-tools, sssd, libnss-sss, libpam-sss
But the packages are installed 🙁
Debian 8.7
please could you give us result of following command
ystemctl status sssd.service
Did you check service is running?
could you provide logs?
Works like a charm, thank you!
thank you very much 🙂
Hi,
Which other packet and configuration I need to share from this machine?
Hello,
Thank you ! Marvellous presentation.
It’s the first time that it’s working for me 🙂 The password, UID and GID are obtain from the AD.
I know that is not your aim, but I have a NIS service and I would keep the UID, GID and homedirs from my NIS map ‘password’.
Have you an idea ?
Thanks again !
Should be any kind of kerberos to be installed on the client?
Its crying for the KDC server of the domain.
When i check the status of sssd servicec its saying:
[sssd[ldap_child[1012]: Failed to initialize credentials using keytab [default]: Cannot find KDC for realm “XY.LOCAL”. Unable to create GSSAPI-encrypted LDAP connection.
[sssd[ldap_child[1012]: Cannot find KDC for realm “XY.LOCAL”
Hello, from a new Jessie, in my /var/log/apt/history I find : sssd-krb5 sssd-krb5-common krb5-locales libgssapi-krb5-2 libkrb5-3 libkrb5support0
This tutorial is worked great, i tested it out on parrotOS so should work on debian 9 aswell. May need to adjust samba and krb5 config files. Just to point to domain but other than that worked just fine
i can’t able to do this step could u please help to resolve this step please .
echo “%domain\ admins@my-domain.local ALL=(ALL) ALL” | sudo tee -a /etc/sudoers.d/domain_admins
/etc/sudoers.d/domain_admins: No such file or directory
You must install sudo. “apt-get install sudo”
unfortunately it seems not working for debian 9
I can’t login with ‘myusername@mydomain’, any hint for that?
thanks
Tried this tuto : excellent work ! :+1:
There is a small fix : if you have installed a very basic system (in my case Debian 9.1 with only “base tools”), you must install policykit-1 to use “realm discover mydomain.local”.
Yes, I had this issue too – had to install policykit-1 on a fresh Debian 9 install. Might want to add it to the guide – – Great guide, by the way, thanks for putting it up!
Great tutorial, but i still had do thinker with krb5.conf to make it work.
Logged in with my user, after i configured my primary AD server as Kerberos provider.
Please help, I followed along your tutorial on ubuntu.
After the command
sudo realm join –user=joe.smith my-domain.local –install=/
I got
realm: Couldn’t join realm: Insufficient permission to join the domain
with my domain admin credentials. It seems that the sssd.config file was not generated by realmd as you wrote above.
Hi,
I just learned that “packagekit” is a dependency on Debian 9. Without it, joining is not possible. I assume that it is also necessary in Debian 8.
Thanks,
Ruediger
This post helped me, so I want to pay it forward… hopefully this can help someone else… Follow the above instructions, make sure your time, and host name is correct before joining to the domain.
## debian 9 install ##
sudo apt install -y realmd policykit-1 packagekit
sudo apt install -y sssd sssd-tools adcli
sudo realm discover domain.net
sudo realm join domain.net
id user@domain.net
## debian 10 install ##
sudo apt install -y realmd packagekit
sudo apt install -y sssd sssd-tools adcli
sudo realm discover domain.net
sudo realm join domain.net
id user@domain.net
## Continue for short name id (both Debian 9 & 10)
sudo vim /etc/sssd/sssd.conf
Change:
use_fully_qualified_names = True
fallback_homedir = /home/%u@d
to:
use_fully_qualified_names = False
fallback_homedir = /home/%u
sudo systemctl restart sssd
id user