Centos 8 (Proxmox) + Active Directory authorization
Posted on September 7, 2020 • 5 minutes • 1052 words • Suggest Changes
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;
- Kerberos : this one is actually easy to setup, but only provides authentication; which is pretty useless if you want users to login on a system; as users only can prove they are a user but not where they have or don’t have access.
- LDAP : Lightweight Directory Access Protocol, it should be possible to set this up if your domain controller is AD, since LDAP is the protocol, and AD is the “program” (like nginx (AD) and HTTP (LDAP)); This is also the protocol that is being used to connect to other directory services such as FreeIPA, OpenLDAP, Red Hat Directory Service, …
- AD : this is directory services, that provides LDAP, kerberos, … this is what we want to connect to tell our server that this user is oké to access this server.
- Winbind : this is a alternative to sssd we use here;
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 :
[root@svennd ~]# 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)
[root@svennd ~]# realm join ad.domain.be -U SvennD Password for SvennD:
[root@svennd ~]# 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: %U@ad.domain.be login-policy: allow-realm-logins
[root@svennd ~]# 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/%u@%d access_provider = ad ad_gpo_ignore_unreadable = True
Important changes :
use_fully_qualified_names = False (you can login with svennd instead of email@example.com) ad_gpo_ignore_unreadable = True (broke the login) fallback_homedir = /home/%u@%d (this can be [whatever](https://jhrozek.fedorapeople.org/sssd/git/man/sssd-ad.5.html))
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 SvennD@ad.domain.be 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.
[root@server ~]# 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 :
[root@server ~]# getent passwd svennd svennd:*:1914847771:1914800513:John Doe:/firstname.lastname@example.org:/bin/bash [root@server ~]# getent shadow svennd [root@server ~]# 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.