Enrolling an Active Directory RHEL-6 client machine using adcli

If you're adding a modern Linux client to an Active Directory domain, you really should be using realmd. It's easy to use, secure and does the right thing by default.

If you haven't heard about realmd already, check out the documentation. In a nutshell, realmd makes the client enrollment as easy as:

# realm join

However, realmd depends on some software that is not available on stable platforms used in production, like RHEL-6 and its derivatives. Still, it's possible to use some of the components realmd builds on separately and have a reasonably user-friendly experience. In this blog post, I’ll show you how, using a package called adcli, that is usually just a building block of realmd.

My test AD server domain is called win.example.com and the server that runs the domain is called server.win.example.com. For the test, I've used a mostly default CentOS 6.5 VM.

Typically, you'll want to point your Linux machine to the AD server for DNS:

# cat /etc/resolv.conf
# host domain name pointer server.win.example.com.

Start the setup by enabling the EPEL repository and installing the 'adcli'

# yum install adcli

You can type just 'adcli' to get an overview of what commands adcli supports. We're interested in joining the client to the AD domain in order to be able to log in as users from Active Directory.

Now you should be able to find your domain already:

# adcli info win.example.com
domain-name = WIN.EXAMPLE.COM
domain-short = WIN
domain-forest = WIN.EXAMPLE.COM
domain-controller = SERVER.WIN.EXAMPLE.COM
domain-controller-site = Default-First-Site-Name
domain-controller-flags = pdc gc ldap ds kdc timeserv closest writable good-timeserv full-secret ads-web
domain-controller-usable = yes
domain-controllers = SERVER.WIN.EXAMPLE.COM
computer-site = Default-First-Site-Name

As you can see, adcli was able to discover quite a few details about my test domain, so it’s time to join the client:

# adcli join win.example.com
Password for Administrator@WIN.EXAMPLE.COM:

You’ll be prompted for the Administrator password by default, but it’s possible to specify another user with the -U option. See the adcli man page for full list of details.

The join operation creates a keytab the machine will authenticate with. When you inspect the with klist -kt, you should see several entries that contain you client hostname in some form. Here are the keytab contents on my test system:

# klist -k | head
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------

It’s recommeded to also configure /etc/krb5.conf to use the AD domain:

default_realm = WIN.EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

kdc = server.win.example.com
admin_server = server.win.example.com

.win.example.com = WIN.EXAMPLE.COM
win.example.com = WIN.EXAMPLE.COM

The final step is setting up the SSSD (or Winbind if you like) to actually make use of the keytab to resolve users. I’ll show how to use the AD back end of SSSD as an example. Make sure sssd and authconfig are installed:

# yum install authconfig sssd

Unfortunately, authconfig in RHEL-6 doesn’t support configuring the AD back end directly, so you’ll have to do a bit of manual configuration. We can still use authconfig to set up the Name Service Switch and PAM stacks:

# authconfig --enablesssd --enablesssdauth --update

Now you should see ‘sss’ being present in /etc/nsswitch.conf and the pam stack configuration:

# grep sss /etc/nsswitch.conf
passwd: files sss
shadow: files sss
group: files sss
services: files sss
netgroup: files sss

The final step is to configure the SSSD itself. Open /etc/sssd/sssd.conf and define a single domain:

services = nss, pam, ssh, autofs
config_file_version = 2

id_provider = ad
# Uncomment if service discovery is not working
# ad_server = server.win.example.com

Start the SSSD and make sure it’s up after reboots:

# service sssd start
# chkconfig sssd on

You should now be able to log in as an AD user just fine:

su - administrator@win.example.com
-sh-4.1$ id
uid=388000500(administrator) gid=388000513(domain users) groups=388000513(domain users),388000512(domain admins),388000518(schema admins),388000519(enterprise admins),388000520(group policy creator owners),388000572(denied rodc password replication group),388001123(supergroup) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

For more information on the SSSD ad provider, see the SSSD wiki page or just sssd-ad the manual page.


10 thoughts on “Enrolling an Active Directory RHEL-6 client machine using adcli

    1. Re: question on SSSD

      Yes and no.

      In theory it should be possible to just set:
      ldap_user_name = sAMAccountName

      however, you might hit this bug -https://fedorahosted.org/sssd/ticket/2184 which will only be solved in 1.12.0

      But I think the important question is why do you want to do that? I suspect that you want to use the principal name as login. We are aiming for this support in 1.12.1 so I suggest you wait a bit and help us test the 1.12 releases! Please join the sssd-users mailing list for more news on sssd. Thank you.


  1. we have legacy users being migrated into AD that we can’t easily change the user ids. Some of those users have name that exceeds 20 chars (yep – long name). some of those accounts are machine accounts that can’t be changed easily. and I also can’t make changes to AD schema to extend the size of the sAMAccountName. That is why we need userPrincipalName

    RE: ldap_user_name = sAMAccountName

    yes – i have tried that but no success. I was not aware of the bug! thanks for the link.


    1. Yeah, this stuff should work in the 1.12.0 or 1.12.1 timeframe.

      by the way for legacy users and especially for scenarios where you need to play with the IDs a bit, I recommend to check out FreeIPA’s AD trust feature and especially the upcoming “views” feature (in FreeIPA 4.1 probably). These are designed to solve cases like yours in a systematic way.


  2. centos 6.5 adcli sssd and gdm logins

    Hey, great trick. I was banging my head with winbind, but his is a much more elegant solution.

    Users can login via ssh, works perfectly. My only issue now is logon’s via X, the gdm login screen. The /var/log/secure file shows that the pam modules has no idea who the user is, not that the password is no good. But that the user doesn’t exist.

    So something in the PAM modules isn’t working. Do you have a working PAM module for the /etc/pam.d/gdm?

    I need to work on the printing too. Do the AD credentials get passed on to the CUPS printing setup? That’s my next task.



  3. SSSD + AD + Samba Shares

    We just upgraded to 1.11.6 for RHEL6.5 and are working through a new configuration to use with AD instead of our previously used LDAP. I noticed the newer version of SSSD requires the use of samba4-libs which made me curious if it was finally possible to use samba shares with sssd on windows? Do you have any posts on how this might be accomplished?


  4. Hi Jakub,

    Your post saved me many hours of work, and everything is working perfectly.

    I still having an issue with 1 thing: Samaccountname

    I’m still testing but when I join a computer to the domain with ADCLI, it seems that ADCLI uses the hostname of the server to create an AD computer Object, this is fine until your hostname is less or equal to 18 characters (many posts tell you the limit is 15 or 20) but after some testing it seems that ADCLI does fail with anything longer than 18 characters.

    The idea is
    – hostname: “thisismylongnameserver”
    – samaccountname: “server1” or “shortname”

    It seems that using adcli with the –computer-name “shortname” option works, and join the computer to the domain with “shortname” But I’m not sure if I need to also to force the ldap_sasl_authid = “shortname” in the sssd,conf file.

    When I don’t force ldap_sasl_authid in sssd.conf, and look at the debug log of sssd, I can see the SSSD is smart enough to automatically set ldap_sasl_authid to the value I used with ADCLI, but where does SSSD get that value from ? /etc/krb5.keytab ? or just using magic 🙂



    1. Yes, we inspect the keytab on start and try to find a principal that matches the hostname. We fall back to the first principal with the correct realm IIRC if we can’t find a match.

      By the way, using these long samaccountnames is not a good idea, even windows just chop off the extra characters, so this is really prone to conflicts.


      1. Just to make it very clear, I’m tying to avoid to use a long samaccountname, and to achieve that I use ADCLI with the “–computer-name” parameter. This will create the krb5.keytab and the AD computer object with a shortname, intead of using the LInux hostname. This works fine.

        What I’d like to understand is if I need to force that shortname with ldap_sasl_authid in the SSSD,conf file, or if relying on the krb5.keytab, that SSSD file read, is enough. My understanding so far is that ldap_sasl_authid becomes unecessary, if I join my computer with adcli “–computer-name”. I;d like to make sure that my reasoning is correct


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s