Score:0

Problems sudoing using a host connected to Active Directory (sssd, kerberos local sudoers file)

pl flag

I am configuring Active Directory authentication for an Alma 8 box using SSSD, Kerberos, and initial SSH key for log in stored in an Active Directory object, and a local sudoers file that lists groups permitted to sudo.

I have connected the server to the domain and been able to authenticate as a domain user user, logging in initially using the SSH key. An AD domain password must subsequently be supplied when escalating up to root, and this is the point at which the process is failing, seemingly with an incorrect password error.

/etc/nsswitch.conf

passwd:     sss files
group:      sss files
sudoers:    files sss

/etc/sssd/sssd.conf

[sssd]
services = ssh, nss, pam, sudo
config_file_version = 2
domains = XXXXXXXXXX.COM

[domain/XXXXXXXXXX.COM]
debug_level = 0x3ff0
ad_domain = xxxxxxx.com
krb5_realm = XXXXXXXXXX.COM

id_provider = ad
access_provider = ad
enumerate = false
cache_credentials = false
use_fully_qualified_names = False
ldap_user_ssh_public_key = sshPublicKey
ad_enable_gc = false
ad_gpo_access_control = disabled
ad_server = dc1.xxxxxxx.com,dc2.xxxxxxx.com
debug_level = 9

dyndns_update = true
dyndns_update_ptr = true
ad_hostname = testbox.xxxxxxx.com

[nss]
default_shell = /bin/bash
fallback_homedir = /home/%d/%u

[ssh]

[sudo]
debug_level = 0x3ff0

/etc/sudoers.d/company_sudoers


"%company admins" ALL=(ALL) ALL
"%domain admins" ALL=(ALL) ALL
"%gg-srvlocaladmin" ALL=(ALL) ALL

"%dl-linuxadministrators" ALL=(ALL) ALL

I have verified that I am logging in as a domain user, and am a member of one of the necessary groups (dl-linuxadministrators):

[me@testbox ~]$ groups
domain users nonprod-zabbix-admins prod-zabbix-admins nonprod-glog-allstreams-users prod-glog-allstreams-users prod-glog-views-users gg-linuxadmins dl-linuxadministrators

When I come to sudo up to root however, my password is seemingly not being accepted:

[me@testbox  ~]$ sudo -i
[sudo] password for me:
Sorry, try again.
[sudo] password for me:
Sorry, try again.
[sudo] password for me:
sudo: 3 incorrect password attempts

I’ve enabled sudo and sssd debug logs. The sudo logs are quite verbose, I’ve not spotted anything that obviously strikes me as as an error or similar in them (I'm happy to post excerpts however if people can advise on anything specific I should be looking for). The sssd logs I think indicate that this portion of the authentication process is being handed off to PAM.

This config has been ported across from existing Ubuntu servers, on which it works without any problems. I can see from looking in the files in /etc/pam.d/ that several on the Ubuntu

boxes reference the pam_sss.so module, whereas these are missing on the Alma box.

root@otherbox:/etc/pam.d# grep sss * | grep -v old
common-account:account  [default=bad success=ok user_unknown=ignore]    pam_sss.so
common-auth:auth        [success=1 default=ignore]      pam_sss.so use_first_pass
common-password:password        sufficient                      pam_sss.so use_authtok
common-session:session  optional                        pam_sss.so

I have tried translating and porting some of these across, seemingly without any effect, but it may be that I've not done this correctly due ton differences between distros.

Syslog however shows an error message coming back from what appears to be a krb child process:

Feb  4 16:08:45 testbox krb5_child[2117]: Preauthentication failed
Feb  4 16:08:45 testbox  krb5_child[2117]: Preauthentication failed
Feb  4 16:08:45 testbox  krb5_child[2117]: Preauthentication failed

I still think the issue is likely to be PAM related, but I'm not 100% certain.

Is anybody able to offer me any guidance no where to take this next?

Thanks in advance.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.