CentOS Active Directory - stanislawbartkowski/wikis GitHub Wiki

Inspiration

CentOS - Active Directory integration is quite easy and straightforward although not everything is obvious from the beginning. A very good description can be found here https://www.rootusers.com/how-to-join-centos-linux-to-an-active-directory-domain/. During my test, I was using CentOS 7.6, RHEL 7.6, RHEL 8.2 hosts and Windows 2016 Active Directory Domain Controller. The purpose is to have Linux users and groups managed by Active Directory. The user can be created, authenticated and assigned to the group through Active Directory Domain.

Prerequisites

CentOS hosts and Windows Active Directory is up and running. Lessons learned.

Active Directory Domain name should match Windows 2016 host name. In my test environment Active Directory Domain name is verse1.fyre.net but Windows 2016 hostname is different. So I added verse1.fyre.net entry to /etc/hosts file to map verse1.fyre.net to a proper IP address.
Avoid mixing small and capital letters in the hostname. There could be a problem with implementing passwordless logging into a Linux host. Use small letters only.
Make sure that AD hostname is the first name in the corresponding entry in /etc/hosts

For instance, assuming AD hostname: verse1.fyre.net Line in /etc/hosts

.....
9.30.54.109 verse1.fyre.net verse1.fyre.ibm.com verse1
.....

Install client software

yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients -y

ansible all -m yum -a "name=sssd,realmd,oddjob,oddjob-mkhomedir,adcli,samba-common,samba-common-tools,krb5-workstation,openldap-clients"

Check that AD Domain is visible

realm discover verse1.fyre.net

fyre.net
  type: kerberos
  realm-name: FYRE.NET
  domain-name: fyre.net
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools

Join AD Domain

It is the only moment when AD Administrator credentials are necessary.

realm join verse1.fyre.net

(Administrator password should be at hand) This command will configure /etc/krb5.conf and /etc/sssd/sssd.conf. Also, a proper entry in AD Directory container is created and AD authentication is ready.

realm list

fyre.net
  type: kerberos
  realm-name: FYRE.NET
  domain-name: fyre.net
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %[email protected]
  login-policy: allow-realm-logins

alt text

id [email protected]

uid=1603200500([email protected]) gid=1603200513(domain [email protected]) grupy=1603200513(domain [email protected]),1603200520(group policy creator [email protected]),1603200519(enterprise [email protected]),1603200572(denied rodc password replication [email protected]),1603200518(schema [email protected]),1603200512(domain [email protected])

Drop domain name from user name

It does not make sense to qualify user name with a domain name if we are not going to authenticate in several AD domains.

vi /etc/sssd/sssd.conf

use_fully_qualified_names = False
fallback_homedir = /home/%u

Restart sssd after applying changes. The domain name is not required any longer and also user home directory is not qualified with domain name whatsoever.

systemctl restart sssd

id Administrator

uid=1603200500(administrator) gid=1603200513(domain users) grupy=1603200513(domain users),1603200520(group policy creator owners),1603200519(enterprise admins),1603200572(denied rodc password replication group),1603200518(schema admins),1603200512(domain admins)

Create users in Active Directory

There is no general rule on how to position Linux user in Active Directory domain. But assume that we do not want to mix regular Windows user and Linux users. So the approach is to create a separate container for Linux users and restrict CentOS only to this set of users and groups. It does not make any sense to allow AD Administrator to log in as Linux user. So I created a separate container CN=centos,DC=fyre,DC=net in AD and two users user1 and user2 belonging to centosuser group.

alt

[root@C11 ~]# id user1
uid=1603201215(user1) gid=1603200513(domain users) grupy=1603200513(domain users),1603201214(centosgroup)
[root@C11 ~]# id user2
uid=1603201216(user2) gid=1603200513(domain users) grupy=1603200513(domain users),1603201214(centosgroup)
[root@C11 ~]#

Logon from remote host as new Linux user

ssh user1@c11
user1@c11's password: 
Creating home directory for user1.
[user1@C11 ~]$ pwd
/home/user1
[user1@C11 ~]$

User home directory should be created without domain name.

Passwordless connection using Kerbers authentication

Configure remote Kerberos client

vi /etc/krb5.conf

.............
[realms]
 FYRE.NET = {
  kdc = verse1.fyre.net
  admin_server = verse1.fyre.net
 }

kinit [email protected]

Password for [email protected]:

klist

Ticket cache: KEYRING:persistent:1001:1001
Default principal: [email protected]

Valid starting       Expires              Service principal
03.02.2019 00:22:24  03.02.2019 10:22:24  krbtgt/[email protected]
	renew until 10.02.2019 00:22:21

Log into CentOS again, the password should not be requested again.

Troubleshooting

Run ssh command with -v parameter

ssh user1@c11 -vv

Enable more talkative logging for sssd daemon.

vi /etc/sssd/sssd

[sssd]
.........
debug_level=9

[domain/fyre.net]
.............
debug_level=9

Run sshd daemon in debug mode

systemctl stop sshd /usr/sbin/sshd -d -d -d

AD keytabs

The recommended method to authenticate in Kerberos environment is passwordless connection with the use of keytabs. More details : https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.iseries.doc/ae/tsec_kerb_create_spn.html Example, generate keytab for user1 user.

ktpass /princ [email protected] /pass secret /ptype KRB5_NT_PRINCIPAL /out user1.keytab

Do not pay attention to the confusing message:

NOTE: creating a keytab but not mapping principal to any user.
For the account to work within a Windows domain, the
principal must be mapped to an account, either at the
domain level (with /mapuser) or locally (using ksetup)
If you intend to map [email protected] to an account through other means
or don't need to map the user, this message can safely be ignored.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to user1.keytab:
Keytab version: 0x502
keysize 48 [email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 1 etype 0x17 (RC4-HMAC) keylength 16 (0xa11851e19f53c60d42efe70d90d95d54)

Copy user1.keytab to protected space in client machine and obtain Kerbetos ticket.

kinit -kt user1.keytab [email protected] klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting       Expires              Service principal
13.02.2019 12:08:18  13.02.2019 22:08:18  krbtgt/[email protected]
	renew until 20.02.2019 12:08:18