Posted 07 September, 2020
So, after my rage post a few weeks back, I finally managed to let Centos 8 talk to AD server for authentication and authorization. (there is a difference); I have in the past “always” relied on legacy systems I did not fully understand; I set up samba shares using a windows domain before, but found it really complex and if it stopped working, I stressed out cause what lever to pull, no idea. This post won’t change that, I just share how this time I got it to work on a test server, which is inherently a first step towards anything production worthy !
So to authenticate (login + password -> you are fine) and authorization (you are you, and you have access) using a Windows Domain AD, there are a few options out there and this does not make it much easier; Ill just touch on the ones I played with;
Since our test environment is in Proxmox (LXC); one very specific requirement is needed on the host : we need a privileged container. If you forget this, you will be able to connect to AD, get all information all the test will succeed, but ssh will still fail (for a really hard to pin-point issue). In unprivileged containers root will be mapped to a “normal” Linux user, which means if you break the security you are still only at user level of the host; While I see no reason why unprivileged containers should fail, I did not find a way to make it work. (if you did; please leave a comment!)
Install & Setup
First make sure the system is up-to-date; the hostname is set correctly; and fix the time. For me this was already correct, however in Linux containers, not all default options such as NTP are available, due to the fact you can’t change kernel values. Make sure the time is right.
Since we want to login, openssh-server needs to be installed and running.
yum -y yum install openssh-server hostnamectl set-hostname server timedatectl set-timezone Europe/Brussels systemctl enable openssh-server systemctl start openssh-server
Check that you can correctly resolve your domain; preferably take the DNS server from AD.
$ cat /etc/resolv.conf
I used sssd and realm, which are the most future proof solutions; (winbind seems to be somewhat)
yum install sssd realmd
discover the realm :
[[email protected] ~]# realm discover ad.domain.be ad.domain.be type: kerberos realm-name: AD.DOMAIN.BE domain-name: ad.domain.be 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
These required package need to be installed; (note : required-package)
$ yum install oddjob oddjob-mkhomedir sssd adcli samba-common-tools
Join the domain, this can be as a normal user. (Administrator not required)
[[email protected]svennd ~]# realm join ad.domain.be -U SvennD Password for SvennD:
[[email protected] ~]# realm list ad.domain.be type: kerberos realm-name: AD.DOMAIN.BE domain-name: ad.domain.be 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
[[email protected] ~]# authselect select sssd with-mkhomedir Profile "sssd" was selected. The following nsswitch maps are overwritten by the profile: - passwd - group - netgroup - automount - services Make sure that SSSD service is configured and enabled. See SSSD documentation for more information. - with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module is present and oddjobd service is enabled - systemctl enable oddjobd.service - systemctl start oddjobd.service
Let’s do what they say and start oddjobs :
systemctl enable oddjobd.service systemctl start oddjobd.service
After that, you should be almost ready to go; I entered /etc/sssd/sssd.conf to adapt the default configuration :
[sssd] domains = ad.domain.be config_file_version = 2 services = nss, pam [domain/ad.domain.be] ad_domain = ad.domain.be krb5_realm = AD.DOMAIN.BE realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%[email protected]%d access_provider = ad ad_gpo_ignore_unreadable = True
Important changes :
use_fully_qualified_names = False (you can login with svennd instead of [email protected]) ad_gpo_ignore_unreadable = True (broke the login) fallback_homedir = /home/%[email protected]%d (this can be whatever)
After that be sure to restart sssd :
systemctl restart sssd
Tests & Debug
Pretty much all the tutorials on the web, are really successful, but in reality, you most likely will fail 10 times, and succeed only after weeks of pure horror. Finding that one shitty flag/file/whatever. Here are some tools and methods I used to find the ultimate succes;
Login over ssh, with a fully qualified name:
ssh -l [email protected] localhost
But that will most likely tell you wrong password, even tho its completely something else; So a good start of debugging might be to login not using ssh :
su -l svennd
Print user and group information for the specified USER, or (when USER omitted) for the current user.
[[email protected] ~]# id svennd uid=123123132(svennd) gid=123123132(domain users) groups=123123132(domain users),123123132(epic_cool_guys)
If everything seems fine, but you still can’t login, try to check if you can check all info using the getent (Get entries from administrative database); This is what Linux will do during other operations :
[[email protected] ~]# getent passwd svennd svennd:*:1914847771:1914800513:John Doe:/home/[email protected]:/bin/bash [[email protected] ~]# getent shadow svennd [[email protected] ~]# getent group "domain users" domain users:*:1231321312:svennd,user1,administrator,user2,user3
note : getent shadow should be empty for domain users, but local users will return a hash; For group this will be the users that have been cached or have logged in on the system. (the server is not queried!)
Good luck and may the Windows-Linux operation god(s) be with you.
If you enjoyed this article, please consider buying me a Dr Pepper.
Fuel the beast!
Buy me a Dr Pepper