Previous Entry Share Next Entry
Enrolling an Active Directory RHEL-6 client machine using adcli
jhrozek

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
nameserver 192.168.122.70
# host 192.168.122.70
70.122.168.192.in-addr.arpa domain name pointer server.win.example.com.

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

# 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]
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]
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
---- --------------------------------------------------------------------------
4 RHEL6$@WIN.EXAMPLE.COM
4 RHEL6$@WIN.EXAMPLE.COM
4 RHEL6$@WIN.EXAMPLE.COM
4 RHEL6$@WIN.EXAMPLE.COM
4 RHEL6$@WIN.EXAMPLE.COM
4 HOST/RHEL6@WIN.EXAMPLE.COM
4 HOST/RHEL6@WIN.EXAMPLE.COM

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

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

[realms]
WIN.EXAMPLE.COM = {
kdc = server.win.example.com
admin_server = server.win.example.com
}

[domain_realm]
.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:

[sssd]
services = nss, pam, ssh, autofs
config_file_version = 2
domains = WIN.EXAMPLE.COM

[domain/WIN.EXAMPLE.COM]
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
Password:
-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.


  • 1
in SSSD , is it possible to map uid to userPrincipalName instead of sAMAccountName?

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.

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.



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.

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.

Thanks

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?

Hi,

This is an awesome way of integrating RHEL6 and AD. I've configured the setup according to what you said and I've come to the point where the root can run "id user1" (user1 is created on the AD) and get the user's UID and GID as on the AD. The root can also login as user1 "su - user1" and login as user1.

The problem is that user1 cannot login directly to the server by himself. When the root runs "getent passwd user1" the output is as follows;

user1:*:UID:GID::homedir:shell

The worrying factor is the * in the password field - which automatically implies "no direct logins". Any idea what could be the problem?

TIA.

SamAccountName Limit

Hi Jakub,

Your post saved me many hours of works, 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.

My question is: is there a way to have a long hostname (let say over 20 characters) but force ADCLI to join the server with another name possibly configure in the KRB5.conf file or SSSD.conf

The idea is
- hostname: "thisismylongnameserver"
- samaccountname: server1 or 2345656




root permission to domain user

Hi,
Great tutorial it help me a lot, well done, well i have a problem now to add root permission to my domain group

im applying %DOMAIN\\groupname ALL=(ALL) NOPASSWD: ALL

Im using Centos 6.7


thanks.

How to connect to RODC

Great post, but how do I connect to RODC? what steps are involved to get that working?

  • 1
?

Log in