how to apply custom password prompt?
by seojeong kim
ubuntu 20, 22, 24
sssd.conf
[prompting/password]
password_prompt = my_password :
ubuntu 20, 22, 24
[prompting/2fa]
single_prompt = False
first_prompt = 2fa_Password :
second_prompt = 2fa_otp :
But when I try ssh testuer@localhost
always it asks me "Passowrd:"
I tried to change sssd.conf and also tried /etc/pam.d/
/etc/pam.d/sshd
@include common-auth
account required pam_nologin.so
@include common-account
.....
/etc/pam.d/common-auth
auth [success=2 default=ignore] pam_unix.so nullok <-------- I changed it as auth [success=2 default=ignore] pam_unix.so nullok authtok_prompt=my_password:
auth [success=1 default=ignore] pam_sss.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_cap.so
But everything doesn't work.
How can I change the default password prompt ??
14 hours, 29 minutes
SSSD problem one-way trust GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
by Omnis ludis - games
Good afternoon, please tell me there is such an infrastructure windows
domain and samba domain between them, one-sided external outgoing trust
relationships are set up, so that users from the windows domain can freely
enter the samba domain, I entered the client into the samba domain and all
users from the samba domain can safely pass to this client, but that's not
the task of users they do not want to authenticate from the windows domain
in any way when I try to log in to a client from the samba domain under
them, I get the following error in sssd on the client, GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (Server
not found in Kerberos database), do I understand correctly that this works
like this, the client accesses the samba domain controller, since there is
no given user in samba, the request is redirected to the windows domain
controller and that in turn must provide information about this to users
from its database kerberos? but for some reason this does not happen, does
anyone have at least some information on this error, I have already tried
many different scenarios and can not log in as a user in any way, as if
samba does not process information correctly, while if you build a two-way
trusting relationship, then everything works as it should
1 day, 11 hours
Re: 2FA is being enforced after upgrading 2.9.1->2.9.4
by Sumit Bose
Am Mon, Jun 24, 2024 at 08:23:54AM +0000 schrieb Grzegorz Sobański:
> Hi,
> Thanks for working on this.
> Could you please share a source diff for this change? We can’t use this private build - we will need to build it ourselves.
Hi,
please check https://github.com/sumit-bose/sssd/commit/464a7ec2793a82c83330cb3a10b114d...
HTH
bye,
Sumit
>
> Regards,
>
> Grzegorz
> www.payu.com<http://www.payu.com/>
>
>
> From: Sumit Bose <sbose(a)redhat.com>
> Date: Friday, 21 June 2024 at 16:18
> To: End-user discussions about the System Security Services Daemon <sssd-users(a)lists.fedorahosted.org>
> Subject: External : [SSSD-users] Re: 2FA is being enforced after upgrading 2.9.1->2.9.4
> Attention: This email originated outside trusted domains.
>
>
> Am Fri, Jun 21, 2024 at 11:47:54AM +0000 schrieb Grzegorz Sobański:
> > > Am Tue, Jun 18, 2024 at 10:14:29AM +0000 schrieb Grzegorz Sobański:
> > > > Hi,
> > > > after updating Rocky Linux from 9.3 to 9.4 sssd started to enforce 2FA for our sudo configuration, while before it was optional, and we can’t find why did it change.
> > > > We downgraded sssd packages from 2.9.4 to 2.9.1 and 2FA went back to being optional, so we are sure it’s because sssd version change from 2.9.1->2.9.4, all other configuration is the same.
> > > >
> > > > I looked through changelogs and skimmed through the list of commits, but I couldn’t find anything obvious that should change this. Has anyone seen something similar? Do you know if it’s a result of an intended change or some side-effect of other changes? Or a bug?
> > > >
> > > > We are using IPA as Kerberos provider, users do have OTP set up.
> > > > Up to 2.9.1 sudoing worked either with only password or password+otp.
> > > > On 2.9.4 (and 2.9.5) sudoing is not working with only password, both password+otp are required.
> > >
> > > Hi,
> > >
> > > this might be related to https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub....<https://github.com/SSSD/sssd/issues/7152but>
> > > this should be fixed in 2.9.5. Would it be possible to send full debug
> > > logs for sssd-2.9.5 with `debug_level = 9` at least in the [domain/...]
> > > section of sssd.conf covering a failed login attempt?
> >
> > Hi,
> > I attach full debug logs with level 9 from sssd 2.9.5.
>
> Hi,
>
> thanks for the logs, please find a test build which should fix the issue
> at
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsbose.f...<https://sbose.fedorapeople.org/otp_password/sssd-2.9.4-6.el9_4.1sb1.tar.gz>.
> Please let me know if it works for you or not.
>
> If you don't mind it would be nice if you can open a ticket for this
> issue at https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub....<https://github.com/SSSD/sssd/issues/new>.
>
> Thanks.
>
> bye,
> Sumit
>
> >
> > Bye,
> > Grzegorz
>
>
>
> > --
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > List Guidelines: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...<https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > List Archives: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...<https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...>
> > Do not reply to spam, report it: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....<https://pagure.io/fedora-infrastructure/new_issue>
> --
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...<https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...<https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...>
> Do not reply to spam, report it: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....<https://pagure.io/fedora-infrastructure/new_issue>
> --
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2 days, 3 hours
sssd have problem GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
by Omnis ludis - games
Good afternoon, please tell me there is such an infrastructure windows
domain and samba domain between them, one-sided external outgoing trust
relationships are set up, so that users from the windows domain can freely
enter the samba domain, I entered the client into the samba domain and all
users from the samba domain can safely pass to this client, but that's not
the task of users they do not want to authenticate from the windows domain
in any way when I try to log in to a client from the samba domain under
them, I get the following error in sssd on the client, GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (Server
not found in Kerberos database), do I understand correctly that this works
like this, the client accesses the samba domain controller, since there is
no given user in samba, the request is redirected to the windows domain
controller and that in turn must provide information about this to users
from its database kerberos? but for some reason this does not happen, does
anyone have at least some information on this error, I have already tried
many different scenarios and can not log in as a user in any way, as if
samba does not process information correctly, while if you build a two-way
trusting relationship, then everything works as it should, sssd have one
trust relationship or no this time?
2 days, 5 hours
GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
by Omnis ludis - games
Good afternoon, please tell me there is such an infrastructure windows
domain and samba domain between them, one-sided external outgoing trust
relationships are set up, so that users from the windows domain can freely
enter the samba domain, I entered the client into the samba domain and all
users from the samba domain can safely pass to this client, but that's not
the task of users they do not want to authenticate from the windows domain
in any way when I try to log in to a client from the samba domain under
them, I get the following error in sssd on the client, GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (Server
not found in Kerberos database), do I understand correctly that this works
like this, the client accesses the samba domain controller, since there is
no given user in samba, the request is redirected to the windows domain
controller and that in turn must provide information about this to users
from its database kerberos? but for some reason this does not happen, does
anyone have at least some information on this error, I have already tried
many different scenarios and can not log in as a user in any way, as if
samba does not process information correctly, while if you build a two-way
trusting relationship, then everything works as it should
2 days, 9 hours
Re: 2FA is being enforced after upgrading 2.9.1->2.9.4
by Sumit Bose
Am Fri, Jun 21, 2024 at 11:47:54AM +0000 schrieb Grzegorz Sobański:
> > Am Tue, Jun 18, 2024 at 10:14:29AM +0000 schrieb Grzegorz Sobański:
> > > Hi,
> > > after updating Rocky Linux from 9.3 to 9.4 sssd started to enforce 2FA for our sudo configuration, while before it was optional, and we can’t find why did it change.
> > > We downgraded sssd packages from 2.9.4 to 2.9.1 and 2FA went back to being optional, so we are sure it’s because sssd version change from 2.9.1->2.9.4, all other configuration is the same.
> > >
> > > I looked through changelogs and skimmed through the list of commits, but I couldn’t find anything obvious that should change this. Has anyone seen something similar? Do you know if it’s a result of an intended change or some side-effect of other changes? Or a bug?
> > >
> > > We are using IPA as Kerberos provider, users do have OTP set up.
> > > Up to 2.9.1 sudoing worked either with only password or password+otp.
> > > On 2.9.4 (and 2.9.5) sudoing is not working with only password, both password+otp are required.
> >
> > Hi,
> >
> > this might be related to https://github.com/SSSD/sssd/issues/7152but
> > this should be fixed in 2.9.5. Would it be possible to send full debug
> > logs for sssd-2.9.5 with `debug_level = 9` at least in the [domain/...]
> > section of sssd.conf covering a failed login attempt?
>
> Hi,
> I attach full debug logs with level 9 from sssd 2.9.5.
Hi,
thanks for the logs, please find a test build which should fix the issue
at
https://sbose.fedorapeople.org/otp_password/sssd-2.9.4-6.el9_4.1sb1.tar.gz.
Please let me know if it works for you or not.
If you don't mind it would be nice if you can open a ticket for this
issue at https://github.com/SSSD/sssd/issues/new.
Thanks.
bye,
Sumit
>
> Bye,
> Grzegorz
> --
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2 days, 10 hours
Re: 2FA is being enforced after upgrading 2.9.1->2.9.4
by Sumit Bose
Am Tue, Jun 18, 2024 at 10:14:29AM +0000 schrieb Grzegorz Sobański:
> Hi,
> after updating Rocky Linux from 9.3 to 9.4 sssd started to enforce 2FA for our sudo configuration, while before it was optional, and we can’t find why did it change.
> We downgraded sssd packages from 2.9.4 to 2.9.1 and 2FA went back to being optional, so we are sure it’s because sssd version change from 2.9.1->2.9.4, all other configuration is the same.
>
> I looked through changelogs and skimmed through the list of commits, but I couldn’t find anything obvious that should change this. Has anyone seen something similar? Do you know if it’s a result of an intended change or some side-effect of other changes? Or a bug?
>
> We are using IPA as Kerberos provider, users do have OTP set up.
> Up to 2.9.1 sudoing worked either with only password or password+otp.
> On 2.9.4 (and 2.9.5) sudoing is not working with only password, both password+otp are required.
Hi,
this might be related to https://github.com/SSSD/sssd/issues/7152 but
this should be fixed in 2.9.5. Would it be possible to send full debug
logs for sssd-2.9.5 with `debug_level = 9` at least in the [domain/...]
section of sssd.conf covering a failed login attempt?
Thanks
bye,
Sumit
>
> I attach excerpts from logs, they are similar for both 2.9.1 and 2.9.4, with one difference standing out:
> On 2.9.1:
> (2024-06-17 12:07:45): [krb5_child[3400913]] [sss_krb5_prompter] (0x0200): [RID#729] Prompter interface isn't used for password prompts by SSSD.
> On 2.9.4:
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [sss_krb5_responder] (0x4000): [RID#38] Got question [otp].
> Although one is in loglines other in backtrace.
>
> Logs:
> On 2.9.1:
>
> (2024-06-17 12:07:45): [be[realm]] [dp_pam_handler_send] (0x0100): Got request with the following data
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): domain: realm
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): user: gsobanski@realm
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): service: sudo
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): tty: /dev/pts/1
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): ruser: gsobanski
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): rhost:
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): authtok type: 1 (Password)
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): priv: 0
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): cli_pid: 3400909
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): child_pid: 0
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): logon name: not set
> (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): flags: 0
> [...]
> (2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] Will perform auth
> (2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] Will perform online auth
> (2024-06-17 12:07:45): [krb5_child[3400913]] [get_and_save_tgt] (0x0400): [RID#729] Attempting kinit for realm [realm]
> (2024-06-17 12:07:45): [krb5_child[3400913]] [sss_krb5_prompter] (0x0200): [RID#729] Prompter interface isn't used for password prompts by SSSD.
> (2024-06-17 12:07:45): [krb5_child[3400913]] [validate_tgt] (0x0400): [RID#729] TGT verified using key for [host/hostname@realm].
> (2024-06-17 12:07:45): [krb5_child[3400913]] [safe_remove_old_ccache_file] (0x0400): [RID#729] New and old ccache file are the same, none will be deleted.
> (2024-06-17 12:07:45): [krb5_child[3400913]] [k5c_send_data] (0x0200): [RID#729] Received error code 0
> (2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] krb5_child completed successfully
>
> On 2.9.4:
>
> (2024-06-17 12:12:23): [be[realm]] [dp_pam_handler_send] (0x0100): Got request with the following data
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): domain: realm
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): user: gsobanski@realm
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): service: sudo
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): tty: /dev/pts/1
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): ruser: gsobanski
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): rhost:
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): authtok type: 1 (Password)
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): priv: 0
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): cli_pid: 1757901
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): child_pid: 0
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): logon name: not set
> (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): flags: 0
> [...]
> (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform auth
> (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform online auth
> (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0400): [RID#38] Attempting kinit for realm [realm]
> (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0020): [RID#38] 2367: [-1765328360][Preauthentication failed]
> ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] krb5_child started.
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x1000): [RID#38] total buffer size: [179]
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x0100): [RID#38] cmd [241 (auth)] uid [123456] gid [1002] validate [true] enterprise principal [false] offline [false] UPN [gsobanski@realm]
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x0100): [RID#38] ccname: [FILE:/tmp/krb5cc_123456_XXXXXX] old_ccname: [FILE:/tmp/krb5cc_123456_3UVHOp] keytab: [/etc/krb5.keytab]
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [switch_creds] (0x0200): [RID#38] Switch user to [123456][1002].
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [switch_creds] (0x0200): [RID#38] Switch user to [0][0].
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_check_old_ccache] (0x4000): [RID#38] Ccache_file is [FILE:/tmp/krb5cc_123456_3UVHOp] and is active and TGT is valid.
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_setup_fast] (0x0100): [RID#38] Fast principal is set to [host/hostname@realm]
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [find_principal_in_keytab] (0x4000): [RID#38] Trying to find principal host/hostname@realm in keytab.
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [match_principal] (0x1000): [RID#38] Principal matched to the sample (host/hostname@realm).
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [check_fast_ccache] (0x0200): [RID#38] FAST TGT is still valid.
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [become_user] (0x0200): [RID#38] Trying to become user [123456][1002].
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x2000): [RID#38] Running as [123456][1002].
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [set_lifetime_options] (0x0100): [RID#38] No specific renewable lifetime requested.
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [set_lifetime_options] (0x0100): [RID#38] No specific lifetime requested.
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [set_canonicalize_option] (0x0100): [RID#38] Canonicalization is set to [true]
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform auth
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform online auth
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [tgt_req_child] (0x1000): [RID#38] Attempting to get a TGT
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0400): [RID#38] Attempting kinit for realm [realm]
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [sss_krb5_responder] (0x4000): [RID#38] Got question [otp].
> * (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0020): [RID#38] 2367: [-1765328360][Preauthentication failed]
> ********************** BACKTRACE DUMP ENDS HERE *********************************
>
> (2024-06-17 12:12:23): [krb5_child[1757979]] [map_krb5_error] (0x0040): [RID#38] 2496: [-1765328360][Preauthentication failed]
> (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_send_data] (0x0200): [RID#38] Received error code 1432158222
> (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] krb5_child completed successfully
>
> Grzegorz Sobański
> www.payu.com<http://www.payu.com/>
>
> --
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
5 days, 7 hours
2FA is being enforced after upgrading 2.9.1->2.9.4
by Grzegorz Sobański
Hi,
after updating Rocky Linux from 9.3 to 9.4 sssd started to enforce 2FA for our sudo configuration, while before it was optional, and we can’t find why did it change.
We downgraded sssd packages from 2.9.4 to 2.9.1 and 2FA went back to being optional, so we are sure it’s because sssd version change from 2.9.1->2.9.4, all other configuration is the same.
I looked through changelogs and skimmed through the list of commits, but I couldn’t find anything obvious that should change this. Has anyone seen something similar? Do you know if it’s a result of an intended change or some side-effect of other changes? Or a bug?
We are using IPA as Kerberos provider, users do have OTP set up.
Up to 2.9.1 sudoing worked either with only password or password+otp.
On 2.9.4 (and 2.9.5) sudoing is not working with only password, both password+otp are required.
I attach excerpts from logs, they are similar for both 2.9.1 and 2.9.4, with one difference standing out:
On 2.9.1:
(2024-06-17 12:07:45): [krb5_child[3400913]] [sss_krb5_prompter] (0x0200): [RID#729] Prompter interface isn't used for password prompts by SSSD.
On 2.9.4:
* (2024-06-17 12:12:23): [krb5_child[1757979]] [sss_krb5_responder] (0x4000): [RID#38] Got question [otp].
Although one is in loglines other in backtrace.
Logs:
On 2.9.1:
(2024-06-17 12:07:45): [be[realm]] [dp_pam_handler_send] (0x0100): Got request with the following data
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): domain: realm
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): user: gsobanski@realm
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): service: sudo
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): tty: /dev/pts/1
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): ruser: gsobanski
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): rhost:
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): authtok type: 1 (Password)
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): priv: 0
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): cli_pid: 3400909
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): child_pid: 0
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): logon name: not set
(2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): flags: 0
[...]
(2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] Will perform auth
(2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] Will perform online auth
(2024-06-17 12:07:45): [krb5_child[3400913]] [get_and_save_tgt] (0x0400): [RID#729] Attempting kinit for realm [realm]
(2024-06-17 12:07:45): [krb5_child[3400913]] [sss_krb5_prompter] (0x0200): [RID#729] Prompter interface isn't used for password prompts by SSSD.
(2024-06-17 12:07:45): [krb5_child[3400913]] [validate_tgt] (0x0400): [RID#729] TGT verified using key for [host/hostname@realm].
(2024-06-17 12:07:45): [krb5_child[3400913]] [safe_remove_old_ccache_file] (0x0400): [RID#729] New and old ccache file are the same, none will be deleted.
(2024-06-17 12:07:45): [krb5_child[3400913]] [k5c_send_data] (0x0200): [RID#729] Received error code 0
(2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] krb5_child completed successfully
On 2.9.4:
(2024-06-17 12:12:23): [be[realm]] [dp_pam_handler_send] (0x0100): Got request with the following data
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): domain: realm
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): user: gsobanski@realm
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): service: sudo
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): tty: /dev/pts/1
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): ruser: gsobanski
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): rhost:
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): authtok type: 1 (Password)
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): priv: 0
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): cli_pid: 1757901
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): child_pid: 0
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): logon name: not set
(2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): flags: 0
[...]
(2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform auth
(2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform online auth
(2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0400): [RID#38] Attempting kinit for realm [realm]
(2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0020): [RID#38] 2367: [-1765328360][Preauthentication failed]
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] krb5_child started.
* (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x1000): [RID#38] total buffer size: [179]
* (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x0100): [RID#38] cmd [241 (auth)] uid [123456] gid [1002] validate [true] enterprise principal [false] offline [false] UPN [gsobanski@realm]
* (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x0100): [RID#38] ccname: [FILE:/tmp/krb5cc_123456_XXXXXX] old_ccname: [FILE:/tmp/krb5cc_123456_3UVHOp] keytab: [/etc/krb5.keytab]
* (2024-06-17 12:12:23): [krb5_child[1757979]] [switch_creds] (0x0200): [RID#38] Switch user to [123456][1002].
* (2024-06-17 12:12:23): [krb5_child[1757979]] [switch_creds] (0x0200): [RID#38] Switch user to [0][0].
* (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_check_old_ccache] (0x4000): [RID#38] Ccache_file is [FILE:/tmp/krb5cc_123456_3UVHOp] and is active and TGT is valid.
* (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_setup_fast] (0x0100): [RID#38] Fast principal is set to [host/hostname@realm]
* (2024-06-17 12:12:23): [krb5_child[1757979]] [find_principal_in_keytab] (0x4000): [RID#38] Trying to find principal host/hostname@realm in keytab.
* (2024-06-17 12:12:23): [krb5_child[1757979]] [match_principal] (0x1000): [RID#38] Principal matched to the sample (host/hostname@realm).
* (2024-06-17 12:12:23): [krb5_child[1757979]] [check_fast_ccache] (0x0200): [RID#38] FAST TGT is still valid.
* (2024-06-17 12:12:23): [krb5_child[1757979]] [become_user] (0x0200): [RID#38] Trying to become user [123456][1002].
* (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x2000): [RID#38] Running as [123456][1002].
* (2024-06-17 12:12:23): [krb5_child[1757979]] [set_lifetime_options] (0x0100): [RID#38] No specific renewable lifetime requested.
* (2024-06-17 12:12:23): [krb5_child[1757979]] [set_lifetime_options] (0x0100): [RID#38] No specific lifetime requested.
* (2024-06-17 12:12:23): [krb5_child[1757979]] [set_canonicalize_option] (0x0100): [RID#38] Canonicalization is set to [true]
* (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform auth
* (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform online auth
* (2024-06-17 12:12:23): [krb5_child[1757979]] [tgt_req_child] (0x1000): [RID#38] Attempting to get a TGT
* (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0400): [RID#38] Attempting kinit for realm [realm]
* (2024-06-17 12:12:23): [krb5_child[1757979]] [sss_krb5_responder] (0x4000): [RID#38] Got question [otp].
* (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0020): [RID#38] 2367: [-1765328360][Preauthentication failed]
********************** BACKTRACE DUMP ENDS HERE *********************************
(2024-06-17 12:12:23): [krb5_child[1757979]] [map_krb5_error] (0x0040): [RID#38] 2496: [-1765328360][Preauthentication failed]
(2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_send_data] (0x0200): [RID#38] Received error code 1432158222
(2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] krb5_child completed successfully
Grzegorz Sobański
www.payu.com<http://www.payu.com/>
1 week, 1 day
looks like bug https://bugzilla.redhat.com/show_bug.cgi?id=1984591 is back...
by Spike White
sssd personnel,
In RHEL7, sssd was auto-discovering AD domains that trusted this domain,
but that this domain did not trust. i.e., it was over-discovering AD
domains.
For a large company, you'll have one or more prod AD domain. That all
trust each other.
Then you'll likely have an engineering and possibly a test AD domain.
These engineering and test domains would trust the prod domain(s), but the
prod domain(s) wouldn't trust these engineering/test domains (nor should
they).
So if sssd were AD-integrated to one of the prod domains, it should
auto-discover the prod domains only. It's true that buried deep in AD's
data structures, there is a trust relationship with the test domain and the
engineering domain. But it's a trust going the wrong way.
Sumit fixed this for RHEL7, it seems the fix was first pushed out in
sssd-1.16.5-10.el7_9.11.
RHEL7 seems to still be fixed as of today.
At least on RHEL8 and RHEL9, it seems to have reverted.
There is a work-around. in /etc/sssd/sssd.conf file, you can add:
[domain/prod1.company.com]
....
ad_enabled_domains = prod1.company.com, prod2.company.com, prod3.company.com
So while all these extraneous auto-discovered AD domains still show in
'sssctl domain-list', they no longer cause problems.
Spike
1 week, 5 days
