Rocky Linux fails when tries to authenticate users using SSSD service

Hi team,

I’ve installed and configured the necessary packages for allow a recent Rocky Linux install to authenticate againts an AD domain. After installing such packages and registering the server to the AD this is failing when it tries to authenticate users.

These are the packages I installed:

realmd
sssd
adcli
samba-common
samba-common-tools
krb5-workstation
authconfig

This is my current sssd.conf config(with some changes for security reasons):


[sssd]
domains = area1.abcxyz.local
config_file_version = 2
services = nss, pam

[nss]
filter_groups = root
filter_users = root

[pam]
offline_credentials_expiration = 3

[domain/area1.abcxyz.local]
ad_domain = area1.abcxyz.local
ad_server = EUSERVER012.area1.abcxyz.local
ad_backup_server = EUSERVER002.area1.abcxyz.local
krb5_realm = AREA1.ABCXYZ.LOCAL
realmd_tags = manages-system joined-with-samba
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

ignore_group_members = True
ad_enable_gc = False
cache_credentials = true
account_cache_expiration = 7
ad_gpo_ignore_unreadable = True
ad_gpo_access_control = enforcing
GSSAPIAuthentication = no
dyndns_update = false

krb5_validate = false

access_provider = simple
simple_allow_groups = WO_Linux_Admins

debug=8

This is my /etc/krb5.conf config:


# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/

[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[libdefaults]
    default_realm = AREA1.ABCXYZ.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
    spake_preauth_groups = edwards25519
#    default_realm = EXAMPLE.COM
#    default_ccache_name = KEYRING:persistent:%{uid}
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5


[realms]
# EXAMPLE.COM = {
#     kdc = kerberos.example.com
#     admin_server = kerberos.example.com
# }

[realms]
 AREA1.ABCXYZ.LOCAL = {
  kdc = EUSERVER012.area1.abcxyz.local
  admin_server = EUSERVER012.area1.abcxyz.local
  default_domain = area1.abcxyz.local
 }


[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

[domain_realm]
 .area1.eurofins.local = AREA1.ABCXYZ.LOCAL
 area1.eurofins.local = AREA1.ABCXYZ.LOCAL

pam = {
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

The service shows it’s working and gets the users from AD (partially) but even though it’s not allowing to authenticate.

Click to see the full logs

[root@eu50apvt951 ~ ]# systemctl status sssd
● sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-07-20 00:51:09 CEST; 40min ago
Main PID: 54653 (sssd)
Tasks: 5 (limit: 49464)
Memory: 53.3M
CGroup: /system.slice/sssd.service
├─54653 /usr/sbin/sssd -i --logger=files
├─54654 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
├─54655 /usr/libexec/sssd/sssd_be --domain area1.abcxyz.local --uid 0 --gid 0 --logger=files
├─54657 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
└─54658 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jul 20 00:51:09 eu50apvt951.area1.abcxyz.local sssd[pam][54658]: Starting up
Jul 20 00:51:09 eu50apvt951.area1.abcxyz.local sssd[nss][54657]: Starting up
Jul 20 00:51:09 eu50apvt951.area1.abcxyz.local systemd[1]: Started System Security Services Daemon.
Jul 20 00:52:43 eu50apvt951.area1.abcxyz.local sssd[be[area1.abcxyz.local]][54655]: Backend is online
Jul 20 00:52:43 eu50apvt951.area1.abcxyz.local adcli[54673]: GSSAPI client step 1
Jul 20 00:52:43 eu50apvt951.area1.abcxyz.local adcli[54673]: GSSAPI client step 1
Jul 20 00:52:43 eu50apvt951.area1.abcxyz.local adcli[54673]: GSSAPI client step 1
Jul 20 01:03:53 eu50apvt951.area1.abcxyz.local adcli[54953]: GSSAPI client step 1
Jul 20 01:03:53 eu50apvt951.area1.abcxyz.local adcli[54953]: GSSAPI client step 1
Jul 20 01:03:53 eu50apvt951.area1.abcxyz.local adcli[54953]: GSSAPI client step 1
[root@eu50apvt951 ~ ]#
[root@eu50apvt951 ~ ]# id adm_w7ea
uid=1344378677(adm_w7ea) gid=968200513(domain users) groups=968200513(domain users)
[root@eu50apvt951 ~ ]#

Checking the logs I’ve found this:

Click to see the full logs

(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [fo_resolve_service_send] (0x0100): Trying to resolve service ‘AD’
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [get_server_status] (0x1000): Status of server ‘EUSERVER012.area1.abcxyz.local’ is ‘working’
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [get_port_status] (0x1000): Port status of port 0 for server ‘EUSERVER012.area1.abcxyz.local’ is ‘not working’
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [get_server_status] (0x1000): Status of server ‘EUSERVER002.area1.abcxyz.local’ is ‘working’
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [get_port_status] (0x1000): Port status of port 0 for server ‘EUSERVER002.area1.abcxyz.local’ is ‘not working’
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [fo_resolve_service_send] (0x0020): No available servers for service ‘AD’
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [be_mark_dom_offline] (0x1000): Marking back end offline
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [be_mark_offline] (0x2000): Going offline!
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [be_mark_offline] (0x2000): Enable check_if_online_ptask.
(2021-07-20 1:38:55): [be[area1.abcxyz.local]] [be_ptask_enable] (0x0080): Task [Check if online (periodic)]: already enabled

Do you know why SSSD is making a request to port 0 to the AD, isn’t suppose it has to make such request to port 389/TCP or 636/TCP ?

Just in case, this same config is working fine in both RHEL 8 and CentOS 8, with a slight difference, it shows all groups where the AD account belongs to

[root@eu50wevp296 ~ ]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.3 (Ootpa)
[root@eu50wevp296 ~ ]# id adm_w7ea
uid=1344378677(adm_w7ea) gid=968200513(domain users) groups=968200513(domain users),352346990(eu_comlims_commercialcustomerframeworkandquotationdmzusers_bx),352346976(eu_comlims_commercialcustomerframeworkandquotationdmzusers_de),352346968(eu_comlims_commercialcustomerframeworkandquotationdmzusers_fr),352346982(eu_comlims_commercialcustomerframeworkandquotationdmzusers_ph)
.
.
. (Output ommited)

Are you filtering ICMP at all?

Not really, in fact, firewalld service is currently down:

[root@eu50apvt951 ~ ]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
[root@eu50apvt951 ~ ]#

Please make sure that communication to the AD servers back to the client are allowed by verifying any firewalls or security groups between where the client and AD servers are located.

The port 0 piece of sssd you’re seeing is normal. If it is saying it’s not working, that indicates communication back from AD to your client is not coming back or is blocked somewhere, and will not continue to check the other ports (389, 636, 3268).

Communication with AD servers is working fine between Rocky Linux machine and AD servers as you can see below:

Click to see the full logs

[root@eu50apvt951 ~ ]# nmap -sT EU50DCVP012.area1.abcxyz.local
Starting Nmap 7.70 ( https://nmap.org ) at 2021-07-22 17:16 CEST
Nmap scan report for EU50DCVP012.area1.abcxyz.local (10.99.224.75)
Host is up (0.65s latency).
Not shown: 982 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
1801/tcp open msmq
2103/tcp open zephyr-clt
2105/tcp open eklogin
2107/tcp open msmq-mgmt
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3389/tcp open ms-wbt-server
8081/tcp open blackice-icecap

Nmap done: 1 IP address (1 host up) scanned in 1.41 seconds
[root@eu50apvt951 ~ ]# nmap EU00DCVP002.area1.abcxyz.local
Starting Nmap 7.70 ( https://nmap.org ) at 2021-07-22 17:17 CEST
Nmap scan report for EU00DCVP002.area1.abcxyz.local (10.99.224.11)
Host is up (0.00055s latency).
Not shown: 987 closed ports
PORT STATE SERVICE
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3389/tcp open ms-wbt-server
8081/tcp open blackice-icecap

Nmap done: 1 IP address (1 host up) scanned in 2.98 seconds
[root@eu50apvt951 ~ ]#

This is a testing machine and use to run with RHEL and CentOS boths 7 & 8 and didn’t present any issue with AD authentication, unfortunatelly Rocky is not working as I expected and I have no idea why

Server was able to register inside AD with no issues as you can see in attached screenshots, this is showing it’s well connected on realm output as well:

Click to see the full logs

[root@eu50apvt951 ~ ]# realm list
area1.abcxyz.local
type: kerberos
realm-name: AREA1.ABCXYZ.LOCAL
domain-name: area1.abcxyz.local
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
login-policy: allow-realm-logins
[root@eu50apvt951 ~ ]#

Is there anything else I could check in order to see why this machine with rocky Linux is not authenticating with AD? Please let me know.

Hello,

Finally I’ve resolved AD authentication issues using SSSD in Rocky Linux.
I’ve just removed the following lines that works fine with RHEL and CentOS 7/8 but they’re giving issues

#ignore_group_members = True
#ad_enable_gc = False
#cache_credentials = true
#account_cache_expiration = 7
#ad_gpo_ignore_unreadable = True
#ad_gpo_access_control = enforcing
#GSSAPIAuthentication = no

After that, I restarted the service and could login into the server with no issues.