Linux Kerberos Auhtentication
I am jotting down my recipe for RedHat 7.3 Linux and providing user logins from Microsoft's Active Directory. This was tested with two AWS instances and Microsoft AD 2016. There are many articles around the Interwebs but in short things became a lot easier with SSSD in most major distributions.
Out of scope:
- Add AD role to Windows 2016 server
- Add DNS entry and reverse entry for client
- Make sure DNS and reverse DNS works!
# more /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo) # domainname (none) # hostname ip-172-31-22-140.ec2.internal # cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.31.22.140 ip-172-31-22-140.ec2.internal 172.31.16.163 ec2amaz-82floju.iqonda.com ec2amaz-82floju
Install packages.
# yum install realmd sssd adcli
Ensure you are pointing to the AD/DNS server for name resolution. I made sure resolv.conf can't be updated on boot since this is a dynamic EC2 instance.
# cat /etc/resolv.conf search iqonda.com nameserver 172.31.16.163 # chattr +i /etc/resolv.conf # ping 172.31.16.163 PING 172.31.16.163 (172.31.16.163) 56(84) bytes of data. 64 bytes from 172.31.16.163: icmp_seq=37 ttl=128 time=0.653 ms 64 bytes from 172.31.16.163: icmp_seq=38 ttl=128 time=0.522 ms ^C --- 172.31.16.163 ping statistics --- 38 packets transmitted, 2 received, 94% packet loss, time 36999ms rtt min/avg/max/mdev = 0.522/0.587/0.653/0.069 ms # nslookup 172.31.16.163 Server: 172.31.16.163 Address: 172.31.16.163#53 Non-authoritative answer: 163.16.31.172.in-addr.arpa name = ip-172-31-16-163.ec2.internal. Authoritative answers can be found from: # hostname ip-172-31-22-140.ec2.internal # nslookup ip-172-31-22-140.ec2.internal Server: 172.31.16.163 Address: 172.31.16.163#53 Non-authoritative answer: Name: ip-172-31-22-140.ec2.internal Address: 172.31.22.140 # nslookup 172.31.22.140 Server: 172.31.16.163 Address: 172.31.16.163#53 140.22.31.172.in-addr.arpa name = ip-172-31-22-140.ec2.internal.iqonda.com. # nslookup iqonda.com Server: 172.31.16.163 Address: 172.31.16.163#53 Name: iqonda.com Address: 172.31.16.163 # dig -t SRV _ldap._tcp.ad.iqonda.com @172.31.16.163 ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> -t SRV _ldap._tcp.ad.iqonda.com @172.31.16.163 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51524 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;_ldap._tcp.ad.iqonda.com. IN SRV ;; AUTHORITY SECTION: iqonda.com. 3600 IN SOA ec2amaz-82floju.iqonda.com. hostmaster.iqonda.com. 95 900 600 86400 3600 ;; Query time: 0 msec ;; SERVER: 172.31.16.163#53(172.31.16.163) ;; WHEN: Tue Feb 21 13:02:58 EST 2017 ;; MSG SIZE rcvd: 126
Now lets check if we can join the AD domain.
# realm discover realm: No default realm discovered # realm discover ec2amaz-82floju iqonda.com type: kerberos realm-name: IQONDA.COM domain-name: iqonda.com 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 # realm join ec2amaz-82floju Password for Administrator: # realm list iqonda.com type: kerberos realm-name: IQONDA.COM domain-name: iqonda.com 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: %U@iqonda.com login-policy: allow-realm-logins
Add login permission to a specific AD group.
# realm permit -g webadmins@iqonda.com
Test a client login.
$ ssh -l user1@iqonda.com ec2-107-21-198-224.compute-1.amazonaws.com Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Allow SSHD passwords.
# grep PasswordA /etc/ssh/sshd_config PasswordAuthentication yes # systemctl restart sshd
Try client login again. And test sudo as well.
$ ssh -l user1@iqonda.com ec2-107-21-198-224.compute-1.amazonaws.com user1@iqonda.com@ec2-107-21-198-224.compute-1.amazonaws.com's password: Creating home directory for user1@iqonda.com. $ id uid=234601107(user1@iqonda.com) gid=234600513(domain users@iqonda.com) groups=234600513(domain users@iqonda.com),234601104(webadmins@iqonda.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ pwd /home/user1@iqonda.com $ sudo systemctl status sshd We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for user1@iqonda.com: user1@iqonda.com is not in the sudoers file. This incident will be reported.
Allow AD group sudo perms.
# tail -2 //etc/sudoers %webadmins@iqonda.com ALL=(ALL) ALL #%Domain\ Admins@example.com ALL=(ALL:ALL) ALL $ sudo systemctl status sshd [sudo] password for user1@iqonda.com: ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) [..] # systemctl status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/sssd.service.d └─journal.conf Active: active (running) since Tue 2017-02-21 13:05:42 EST; 3min 46s ago Process: 2276 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 2277 (sssd) CGroup: /system.slice/sssd.service ├─2277 /usr/sbin/sssd -D -f ├─2278 /usr/libexec/sssd/sssd_be --domain iqonda.com --uid 0 --gid 0 --debug-to-files ├─2279 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files └─2280 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files Feb 21 13:05:42 ip-172-31-22-140.ec2.internal sssd[nss][2279]: Starting up Feb 21 13:05:42 ip-172-31-22-140.ec2.internal systemd[1]: Started System Security Services Daemon. Feb 21 13:05:42 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 1 Feb 21 13:05:42 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 1 Feb 21 13:05:42 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 1 Feb 21 13:05:42 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 2 Feb 21 13:07:58 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 1 Feb 21 13:07:58 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 1 Feb 21 13:07:58 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 1 Feb 21 13:07:58 ip-172-31-22-140.ec2.internal sssd_be[2278]: GSSAPI client step 2 [/bash For reference sssd config created automatically by realm join. [bash] # cat /etc/sssd/sssd.conf [sssd] domains = iqonda.com config_file_version = 2 services = nss, pam [domain/iqonda.com] ad_server = ec2amaz-82floju ad_domain = iqonda.com krb5_realm = IQONDA.COM realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_sasl_authid = IP-172-31-22-14$ ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = webadmins@iqonda.com