Can't authenticate using RHEL 8.7 on AD

[Francis Augusto Medeiros-Logeay]

Hi,

After the latest updates coming from Red Hat on RHEL 8.7, we can't 
authenticate on AD. The logs show this:

Nov 22 14:15:53 ic-rhel8-t001.c.domain.no sshd[6275]: 
pam_sss(sshd:auth): received for user ec-franciaa: 4 (System error)
Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sshd[6275]: Failed password 
for ec-franciaa from ::1 port 51406 ssh2
Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed: 
GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide 
more information, Minor = Server not found in Kerberos database.
Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed: 
GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide 
more information, Minor = Server not found in Kerberos database.
Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed: 
GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide 
more information, Minor = Server not found in Kerberos database.
Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed: 
GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide 
more information, Minor = Server not found in Kerberos database.
Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed: 
GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide 
more information, Minor = Server not found in Kerberos database.
Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed: 
GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide 
more information, Minor = Server not found in Kerberos database.
Nov 22 14:15:56 ic-rhel8-t001.c.domain.no sshd[6275]: Connection closed 
by authenticating user francis ::1 port 51406 [preauth]

I've deleted the computer account and rejoined the machine to the 
domain. I can check users existence using id, it seems the machine is 
well joined, but somehow authentication doesn't work.

[domain/DOMAIN.NO]
id_provider = ad
auth_provider = ad
autofs_provider = ad
chpass_provider = ad
access_provider = ad
ldap_id_mapping = false
ldap_user_principal = nosuchattribute
ad_server = dc.domain.no

ldap_id_mapping = false

# getent on users with more -- results in a lot of noise
enumerate = false
cache_credentials = true

# Setup schema, rfc2307 is for OpenLDAP, rfc2307bis is A/D-close, and ad 
is A/D
dns_discovery_domain = dc.domain.no

krb5_realm = AD.FP.EDUCLOUD.NO
# how long including renewals may a ticket be valid for
krb5_renewable_lifetime = 14d
# time in seconds between checking if a ticket must be renewed
krb5_renew_interval = 3600
# template used for placing kerberos tickets by default
ad_gpo_map_interactive = +gdm-vmwcred
use_fully_qualified_names = False

[kcm]
tgt_renewal = true
tgt_renewal_inherit = DOMAIN.NO
krb5_renew_interval = 60m
debug_level = 10
socket_path = /var/run/.heim_org.h5l.kcm-socket

We have a machine built two weeks ago with the same sssd.conf, and it 
just works.

Any hints?

Best,

Francis

[Sumit Bose]

Am Tue, Nov 22, 2022 at 02:21:13PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> Hi,
>
> After the latest updates coming from Red Hat on RHEL 8.7, we can't
> authenticate on AD. The logs show this:
>
> Nov 22 14:15:53 ic-rhel8-t001.c.domain.no sshd[6275]: pam_sss(sshd:auth):
> received for user ec-franciaa: 4 (System error)
> Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sshd[6275]: Failed password for
> ec-franciaa from ::1 port 51406 ssh2
> Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> information, Minor = Server not found in Kerberos database.
> Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> information, Minor = Server not found in Kerberos database.
> Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> information, Minor = Server not found in Kerberos database.
> Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> information, Minor = Server not found in Kerberos database.
> Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> information, Minor = Server not found in Kerberos database.
> Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> information, Minor = Server not found in Kerberos database.
> Nov 22 14:15:56 ic-rhel8-t001.c.domain.no sshd[6275]: Connection closed by
> authenticating user francis ::1 port 51406 [preauth]
>
> I've deleted the computer account and rejoined the machine to the domain. I
> can check users existence using id, it seems the machine is well joined, but
> somehow authentication doesn't work.
>
> [domain/DOMAIN.NO]
> id_provider = ad
> auth_provider = ad
> autofs_provider = ad
> chpass_provider = ad
> access_provider = ad
> ldap_id_mapping = false
> ldap_user_principal = nosuchattribute

Hi,

there is a fair chance that the line above will make the PAC validation
fail which was added in the latest version. Do you really need this
option? If not, please remove it and try again. If it is really needed
adding

krb5_validate = false

to the [domain/...] section of sssd.conf and restarting SSSD might help
until a better fix is available. The issue is tracked in
https://bugzilla.redhat.com/show_bug.cgi?id=2144491.

HTH

bye,
Sumit
> ad_server = dc.domain.no
>
> ldap_id_mapping = false
>
> # getent on users with more -- results in a lot of noise
> enumerate = false
> cache_credentials = true
>
> # Setup schema, rfc2307 is for OpenLDAP, rfc2307bis is A/D-close, and ad is
> A/D
> dns_discovery_domain = dc.domain.no
>
> krb5_realm = AD.FP.EDUCLOUD.NO
> # how long including renewals may a ticket be valid for
> krb5_renewable_lifetime = 14d
> # time in seconds between checking if a ticket must be renewed
> krb5_renew_interval = 3600
> # template used for placing kerberos tickets by default
> ad_gpo_map_interactive = +gdm-vmwcred
> use_fully_qualified_names = False
>
> [kcm]
> tgt_renewal = true
> tgt_renewal_inherit = DOMAIN.NO
> krb5_renew_interval = 60m
> debug_level = 10
> socket_path = /var/run/.heim_org.h5l.kcm-socket
>
> We have a machine built two weeks ago with the same sssd.conf, and it just
> works.
>
> Any hints?
>
> Best,
>
> Francis
>
> -- 
> Francis Augusto Medeiros-Logeay
> Oslo, Norway
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

> On 22 Nov 2022, at 15:22, Sumit Bose  wrote:
>
> Am Tue, Nov 22, 2022 at 02:21:13PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > Hi,
> >
> > After the latest updates coming from Red Hat on RHEL 8.7, we can't
> > authenticate on AD. The logs show this:
> >
> > Nov 22 14:15:53 ic-rhel8-t001.c.domain.no sshd[6275]: pam_sss(sshd:auth):
> > received for user ec-franciaa: 4 (System error)
> > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sshd[6275]: Failed password for
> > ec-franciaa from ::1 port 51406 ssh2
> > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > information, Minor = Server not found in Kerberos database.
> > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > information, Minor = Server not found in Kerberos database.
> > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > information, Minor = Server not found in Kerberos database.
> > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > information, Minor = Server not found in Kerberos database.
> > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > information, Minor = Server not found in Kerberos database.
> > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > information, Minor = Server not found in Kerberos database.
> > Nov 22 14:15:56 ic-rhel8-t001.c.domain.no sshd[6275]: Connection closed by
> > authenticating user francis ::1 port 51406 [preauth]
> >
> > I've deleted the computer account and rejoined the machine to the domain. I
> > can check users existence using id, it seems the machine is well joined, but
> > somehow authentication doesn't work.
> >
> > [domain/DOMAIN.NO]
> > id_provider = ad
> > auth_provider = ad
> > autofs_provider = ad
> > chpass_provider = ad
> > access_provider = ad
> > ldap_id_mapping = false
> > ldap_user_principal = nosuchattribute
>
> Hi,
>
> there is a fair chance that the line above will make the PAC validation
> fail which was added in the latest version. Do you really need this
> option? If not, please remove it and try again. If it is really needed
> adding
> krb5_validate = false
>
> to the [domain/...] section of sssd.conf and restarting SSSD might help
> until a better fix is available. The issue is tracked in
> https://bugzilla.redhat.com/show_bug.cgi?id=2144491.
>
> HTH
>
> bye,
> Sumit

Thanks a lot, Sumit!

Removing `ldap_user_princilap = nosuchattribute` didn’t work, but adding the `krb5_validate = false` did.

Is there an upcoming fix coming for this, by any chance?

Best,

Francis

[Sumit Bose]

Am Tue, Nov 22, 2022 at 03:29:18PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > On 22 Nov 2022, at 15:22, Sumit Bose  wrote:
> >
> > Am Tue, Nov 22, 2022 at 02:21:13PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > > Hi,
> > >
> > > After the latest updates coming from Red Hat on RHEL 8.7, we can't
> > > authenticate on AD. The logs show this:
> > >
> > > Nov 22 14:15:53 ic-rhel8-t001.c.domain.no sshd[6275]: pam_sss(sshd:auth):
> > > received for user ec-franciaa: 4 (System error)
> > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sshd[6275]: Failed password for
> > > ec-franciaa from ::1 port 51406 ssh2
> > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > information, Minor = Server not found in Kerberos database.
> > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > information, Minor = Server not found in Kerberos database.
> > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > information, Minor = Server not found in Kerberos database.
> > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > information, Minor = Server not found in Kerberos database.
> > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > information, Minor = Server not found in Kerberos database.
> > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > information, Minor = Server not found in Kerberos database.
> > > Nov 22 14:15:56 ic-rhel8-t001.c.domain.no sshd[6275]: Connection closed by
> > > authenticating user francis ::1 port 51406 [preauth]
> > >
> > > I've deleted the computer account and rejoined the machine to the domain. I
> > > can check users existence using id, it seems the machine is well joined, but
> > > somehow authentication doesn't work.
> > >
> > > [domain/DOMAIN.NO]
> > > id_provider = ad
> > > auth_provider = ad
> > > autofs_provider = ad
> > > chpass_provider = ad
> > > access_provider = ad
> > > ldap_id_mapping = false
> > > ldap_user_principal = nosuchattribute
> >
> > Hi,
> >
> > there is a fair chance that the line above will make the PAC validation
> > fail which was added in the latest version. Do you really need this
> > option? If not, please remove it and try again. If it is really needed
> > adding
> > krb5_validate = false
> >
> > to the [domain/...] section of sssd.conf and restarting SSSD might help
> > until a better fix is available. The issue is tracked in
> > https://bugzilla.redhat.com/show_bug.cgi?id=2144491.
> >
> > HTH
> >
> > bye,
> > Sumit
>
> Thanks a lot, Sumit!
>
> Removing `ldap_user_princilap = nosuchattribute` didn’t work, but adding the `krb5_validate = false` did.

Hi,

would it be possible to send me debug logs with 'debug_level = 9' in the
[domain/...] and [pac] sections of sssd.conf where neither
ldap_user_principal nor 'krb5_validate = false' is set?
> Is there an upcoming fix coming for this, by any chance?

Yes, please watch the bugzilla ticket.

bye,
Sumit
> Best,
>
> Francis 
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

> On 22 Nov 2022, at 17:43, Sumit Bose  wrote:
>
> Am Tue, Nov 22, 2022 at 03:29:18PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > > On 22 Nov 2022, at 15:22, Sumit Bose  wrote:
> > >
> > > Am Tue, Nov 22, 2022 at 02:21:13PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > > > Hi,
> > > >
> > > > After the latest updates coming from Red Hat on RHEL 8.7, we can't
> > > > authenticate on AD. The logs show this:
> > > >
> > > > Nov 22 14:15:53 ic-rhel8-t001.c.domain.no sshd[6275]: pam_sss(sshd:auth):
> > > > received for user ec-franciaa: 4 (System error)
> > > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sshd[6275]: Failed password for
> > > > ec-franciaa from ::1 port 51406 ssh2
> > > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> > > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > > information, Minor = Server not found in Kerberos database.
> > > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6280]: tkey query failed:
> > > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > > information, Minor = Server not found in Kerberos database.
> > > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> > > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > > information, Minor = Server not found in Kerberos database.
> > > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6284]: tkey query failed:
> > > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > > information, Minor = Server not found in Kerberos database.
> > > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> > > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > > information, Minor = Server not found in Kerberos database.
> > > > Nov 22 14:15:55 ic-rhel8-t001.c.domain.no sssd[6288]: tkey query failed:
> > > > GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more
> > > > information, Minor = Server not found in Kerberos database.
> > > > Nov 22 14:15:56 ic-rhel8-t001.c.domain.no sshd[6275]: Connection closed by
> > > > authenticating user francis ::1 port 51406 [preauth]
> > > >
> > > > I've deleted the computer account and rejoined the machine to the domain. I
> > > > can check users existence using id, it seems the machine is well joined, but
> > > > somehow authentication doesn't work.
> > > >
> > > > [domain/DOMAIN.NO]
> > > > id_provider = ad
> > > > auth_provider = ad
> > > > autofs_provider = ad
> > > > chpass_provider = ad
> > > > access_provider = ad
> > > > ldap_id_mapping = false
> > > > ldap_user_principal = nosuchattribute
> > >
> > > Hi,
> > >
> > > there is a fair chance that the line above will make the PAC validation
> > > fail which was added in the latest version. Do you really need this
> > > option? If not, please remove it and try again. If it is really needed
> > > adding
> > >
> > > krb5_validate = false
> > >
> > > to the [domain/...] section of sssd.conf and restarting SSSD might help
> > > until a better fix is available. The issue is tracked in
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2144491.
> > >
> > > HTH
> > >
> > > bye,
> > > Sumit
> >
> > Thanks a lot, Sumit!
> >
> > Removing `ldap_user_princilap = nosuchattribute` didn’t work, but adding the `krb5_validate = false` did.
>
> Hi,
>
> would it be possible to send me debug logs with 'debug_level = 9' in the
> [domain/...] and [pac] sections of sssd.conf where neither
> ldap_user_principal nor 'krb5_validate = false' is set?

Thanks a lot, Sumit.
Sending you the log below. But, truth be told, we don’t have a [pac] session configured, so I created one just for the debug_level.

(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_reply_std] (0x1000): [RID#6] DP Request [Initgroups #6]: Returning [Success]: 0,0,Success
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.dataprovider.pamHandler on /sssd
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam]
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_pam_handler_send] (0x0100): Got request with the following data
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): domain: DOMAIN.NO
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): user: [e-mail]
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): service: sshd
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): tty: ssh
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): ruser: 
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): rhost: ::1
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): authtok type: 1 (Password)
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): priv: 1
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): cli_pid: 13919
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): child_pid: 0
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): logon name: not set
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): flags: 0
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000].
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] Number of active DP request: 1
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sss_domain_get_state] (0x1000): [RID#7] Domain DOMAIN.NO is Active
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_send] (0x1000): [RID#7] Wait queue of user [[e-mail]] is empty, running request [0x5649c3a4b960] immediately.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_setup] (0x4000): [RID#7] No mapping for: [e-mail]
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_send] (0x0040): [RID#7] compare_principal_realm failed.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [check_wait_queue] (0x1000): [RID#7] Wait queue for user [[e-mail]] is empty.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_done] (0x0040): [RID#7] krb5_auth_recv failed with: 22
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request handler finished [0]: Success
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x20000): [RID#7] DP Request [PAM Authenticate #7]: Handling request took [0.101] milliseconds.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [_dp_req_recv] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Receiving request data.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request removed.
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] Number of active DP request: 0
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_method_enabled] (0x0400): [RID#7] Target selinux is not configured
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.pamHandler: Success
(2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > Is there an upcoming fix coming for this, by any chance?
>
> Yes, please watch the bugzilla ticket.

Will do so. Thanks!

Francis

[Sumit Bose]

Am Tue, Nov 22, 2022 at 08:10:26PM +0100 schrieb Francis Augusto Medeiros-Logeay:
>

...
> > Hi,
> >
> > would it be possible to send me debug logs with 'debug_level = 9' in the
> > [domain/...] and [pac] sections of sssd.conf where neither
> > ldap_user_principal nor 'krb5_validate = false' is set?
>
> Thanks a lot, Sumit.
> Sending you the log below. But, truth be told, we don’t have a [pac] session configured, so I created one just for the debug_level.
>
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_reply_std] (0x1000): [RID#6] DP Request [Initgroups #6]: Returning [Success]: 0,0,Success
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.dataprovider.pamHandler on /sssd
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam]
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_pam_handler_send] (0x0100): Got request with the following data
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): domain: DOMAIN.NO
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): user: [e-mail]
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): service: sshd
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): tty: ssh
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): ruser: 
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): rhost: ::1
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): authtok type: 1 (Password)
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): priv: 1
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): cli_pid: 13919
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): child_pid: 0
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): logon name: not set
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): flags: 0
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000].
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] Number of active DP request: 1
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sss_domain_get_state] (0x1000): [RID#7] Domain DOMAIN.NO is Active
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_send] (0x1000): [RID#7] Wait queue of user [[e-mail]] is empty, running request [0x5649c3a4b960] immediately.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_setup] (0x4000): [RID#7] No mapping for: [e-mail]
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_send] (0x0040): [RID#7] compare_principal_realm failed.

Hi,

can you check which value is stored in the 'userPrincipalName' attribute
for the user '[e-mail]' on the AD DC?

bye,
Sumit
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [check_wait_queue] (0x1000): [RID#7] Wait queue for user [[e-mail]] is empty.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_done] (0x0040): [RID#7] krb5_auth_recv failed with: 22
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request handler finished [0]: Success
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x20000): [RID#7] DP Request [PAM Authenticate #7]: Handling request took [0.101] milliseconds.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [_dp_req_recv] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Receiving request data.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request removed.
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] Number of active DP request: 0
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_method_enabled] (0x0400): [RID#7] Target selinux is not configured
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.pamHandler: Success
> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > Is there an upcoming fix coming for this, by any chance?
> >
> > Yes, please watch the bugzilla ticket.
>
> Will do so. Thanks!
>
> Francis
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

> On 23 Nov 2022, at 07:19, Sumit Bose  wrote:
>
> Am Tue, Nov 22, 2022 at 08:10:26PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> >
>
> ...
> > > Hi,
> > >
> > > would it be possible to send me debug logs with 'debug_level = 9' in the
> > > [domain/...] and [pac] sections of sssd.conf where neither
> > > ldap_user_principal nor 'krb5_validate = false' is set?
> >
> > Thanks a lot, Sumit.
> > Sending you the log below. But, truth be told, we don’t have a [pac] session configured, so I created one just for the debug_level.
> >
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_reply_std] (0x1000): [RID#6] DP Request [Initgroups #6]: Returning [Success]: 0,0,Success
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.dataprovider.pamHandler on /sssd
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam]
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_pam_handler_send] (0x0100): Got request with the following data
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): domain: DOMAIN.NO
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): user: [e-mail]
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): service: sshd
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): tty: ssh
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): ruser: 
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): rhost: ::1
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): authtok type: 1 (Password)
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): priv: 1
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): cli_pid: 13919
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): child_pid: 0
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): logon name: not set
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): flags: 0
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000].
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] Number of active DP request: 1
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sss_domain_get_state] (0x1000): [RID#7] Domain DOMAIN.NO is Active
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_send] (0x1000): [RID#7] Wait queue of user [[e-mail]] is empty, running request [0x5649c3a4b960] immediately.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_setup] (0x4000): [RID#7] No mapping for: [e-mail]
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_send] (0x0040): [RID#7] compare_principal_realm failed.
>
> Hi,
>
> can you check which value is stored in the 'userPrincipalName' attribute
> for the user '[e-mail]' on the AD DC?
>
> bye,

Here it is:

userPrincipalName: francis

Best,

Francis
> Sumit
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [check_wait_queue] (0x1000): [RID#7] Wait queue for user [[e-mail]] is empty.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_done] (0x0040): [RID#7] krb5_auth_recv failed with: 22
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request handler finished [0]: Success
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x20000): [RID#7] DP Request [PAM Authenticate #7]: Handling request took [0.101] milliseconds.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [_dp_req_recv] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Receiving request data.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request removed.
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] Number of active DP request: 0
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_method_enabled] (0x0400): [RID#7] Target selinux is not configured
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.pamHandler: Success
> > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > > Is there an upcoming fix coming for this, by any chance?
> > >
> > > Yes, please watch the bugzilla ticket.
> >
> > Will do so. Thanks!
> >
> > Francis
> > _______________________________________________
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail].o...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Sumit Bose]

Am Wed, Nov 23, 2022 at 11:19:25AM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > On 23 Nov 2022, at 07:19, Sumit Bose  wrote:
> >
> > Am Tue, Nov 22, 2022 at 08:10:26PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > >
> >
> > ...
> > > > Hi,
> > > >
> > > > would it be possible to send me debug logs with 'debug_level = 9' in the
> > > > [domain/...] and [pac] sections of sssd.conf where neither
> > > > ldap_user_principal nor 'krb5_validate = false' is set?
> > >
> > > Thanks a lot, Sumit.
> > > Sending you the log below. But, truth be told, we don’t have a [pac] session configured, so I created one just for the debug_level.
> > >
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_reply_std] (0x1000): [RID#6] DP Request [Initgroups #6]: Returning [Success]: 0,0,Success
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.dataprovider.pamHandler on /sssd
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam]
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_pam_handler_send] (0x0100): Got request with the following data
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): domain: DOMAIN.NO
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): user: [e-mail]
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): service: sshd
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): tty: ssh
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): ruser: 
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): rhost: ::1
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): authtok type: 1 (Password)
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): priv: 1
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): cli_pid: 13919
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): child_pid: 0
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): logon name: not set
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): flags: 0
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000].
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] Number of active DP request: 1
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sss_domain_get_state] (0x1000): [RID#7] Domain DOMAIN.NO is Active
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_send] (0x1000): [RID#7] Wait queue of user [[e-mail]] is empty, running request [0x5649c3a4b960] immediately.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_setup] (0x4000): [RID#7] No mapping for: [e-mail]
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_send] (0x0040): [RID#7] compare_principal_realm failed.
> >
> > Hi,
> >
> > can you check which value is stored in the 'userPrincipalName' attribute
> > for the user '[e-mail]' on the AD DC?
> >
> > bye,
>
> Here it is:
>
> userPrincipalName: francis

Hi,

ok, this explains the failure. It is expected that the attribute value
is '[e-mail]', see e.g.
https://learn.microsoft.com/en-us/windows/win32/adschema/a-userprincipalname
and
https://learn.microsoft.com/en-us/windows/win32/ad/naming-properties#userpri...

I guess the name was added manually, because if you use the AD tools a
suitable domain name should be added automatically. Is there a reason
the name was added in this format?

If possible I would suggest to either remove the attribute completely or
replace the value with a one in the '[e-mail]' format where
'domain.name' is wither the name of the AD domain the user is coming
from or a suitable alternative domain suffix if those are defined in
your AD environment.

bye,
Sumit
> Best,
>
> Francis
> > Sumit
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [check_wait_queue] (0x1000): [RID#7] Wait queue for user [[e-mail]] is empty.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_done] (0x0040): [RID#7] krb5_auth_recv failed with: 22
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request handler finished [0]: Success
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_done] (0x20000): [RID#7] DP Request [PAM Authenticate #7]: Handling request took [0.101] milliseconds.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [_dp_req_recv] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Receiving request data.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: Request removed.
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_destructor] (0x0400): [RID#7] Number of active DP request: 0
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_method_enabled] (0x0400): [RID#7] Target selinux is not configured
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.pamHandler: Success
> > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > > > Is there an upcoming fix coming for this, by any chance?
> > > >
> > > > Yes, please watch the bugzilla ticket.
> > >
> > > Will do so. Thanks!
> > >
> > > Francis
> > > _______________________________________________
> > > sssd-users mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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/[e-mail].o...
> > > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> >
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail].o...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

> On 23 Nov 2022, at 12:09, Sumit Bose  wrote:
>
> Am Wed, Nov 23, 2022 at 11:19:25AM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > > On 23 Nov 2022, at 07:19, Sumit Bose  wrote:
> > >
> > > Am Tue, Nov 22, 2022 at 08:10:26PM +0100 schrieb Francis Augusto Medeiros-Logeay:
> > > >
> > >
> > > ...
> > > > > Hi,
> > > > >
> > > > > would it be possible to send me debug logs with 'debug_level = 9' in the
> > > > > [domain/...] and [pac] sections of sssd.conf where neither
> > > > > ldap_user_principal nor 'krb5_validate = false' is set?
> > > >
> > > > Thanks a lot, Sumit.
> > > > Sending you the log below. But, truth be told, we don’t have a [pac] session configured, so I created one just for the debug_level.
> > > >
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_req_reply_std] (0x1000): [RID#6] DP Request [Initgroups #6]: Returning [Success]: 0,0,Success
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_dispatch] (0x4000): Dispatching.
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.dataprovider.pamHandler on /sssd
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam]
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_pam_handler_send] (0x0100): Got request with the following data
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): domain: DOMAIN.NO
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): user: [e-mail]
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): service: sshd
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): tty: ssh
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): ruser: 
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): rhost: ::1
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): authtok type: 1 (Password)
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available)
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): priv: 1
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): cli_pid: 13919
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): child_pid: 0
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): logon name: not set
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [pam_print_data] (0x0100): flags: 0
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] DP Request [PAM Authenticate #7]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000].
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [dp_attach_req] (0x0400): [RID#7] Number of active DP request: 1
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [sss_domain_get_state] (0x1000): [RID#7] Domain DOMAIN.NO is Active
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_queue_send] (0x1000): [RID#7] Wait queue of user [[e-mail]] is empty, running request [0x5649c3a4b960] immediately.
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_setup] (0x4000): [RID#7] No mapping for: [e-mail]
> > > > (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_auth_send] (0x0040): [RID#7] compare_principal_realm failed.
> > >
> > > Hi,
> > >
> > > can you check which value is stored in the 'userPrincipalName' attribute
> > > for the user '[e-mail]' on the AD DC?
> > >
> > > bye,
> >
> > Here it is:
> >
> > userPrincipalName: francis
>
> Hi,
>
> ok, this explains the failure. It is expected that the attribute value
> is '[e-mail]', see e.g.
> https://learn.microsoft.com/en-us/windows/win32/adschema/a-userprincipalname
> and
> https://learn.microsoft.com/en-us/windows/win32/ad/naming-properties#userpri...
>
> I guess the name was added manually, because if you use the AD tools a
> suitable domain name should be added automatically. Is there a reason
> the name was added in this format?
>
> If possible I would suggest to either remove the attribute completely or
> replace the value with a one in the '[e-mail]' format where
> 'domain.name' is wither the name of the AD domain the user is coming
> from or a suitable alternative domain suffix if those are defined in
> your AD environment.
>
> bye,
> Sumit

Hi Sumit,

We are fixing that. But we changed the userPrincipalName to [e-mail] , and still have errors no matter with or without ldap_user_principal, the latter testet with nosuchattribute and with userPrincipalName. It only works with krb5_validate = false.

We get `No mapping for: [e-mail] ` on the logs.

Best,
Francis

[Sumit Bose]

Am Wed, Nov 23, 2022 at 03:55:25PM +0100 schrieb Francis Augusto Medeiros-Logeay:
...
> > > Here it is:
> > >
> > > userPrincipalName: francis
> >
> > Hi,
> >
> > ok, this explains the failure. It is expected that the attribute value
> > is '[e-mail]', see e.g.
> > https://learn.microsoft.com/en-us/windows/win32/adschema/a-userprincipalname
> > and
> > https://learn.microsoft.com/en-us/windows/win32/ad/naming-properties#userpri...
> >
> > I guess the name was added manually, because if you use the AD tools a
> > suitable domain name should be added automatically. Is there a reason
> > the name was added in this format?
> >
> > If possible I would suggest to either remove the attribute completely or
> > replace the value with a one in the '[e-mail]' format where
> > 'domain.name' is wither the name of the AD domain the user is coming
> > from or a suitable alternative domain suffix if those are defined in
> > your AD environment.
> >
> > bye,
> > Sumit
>
> Hi Sumit,
>
> We are fixing that. But we changed the userPrincipalName to [e-mail] , and still have errors no matter with or without ldap_user_principal, the latter testet with nosuchattribute and with userPrincipalName. It only works with krb5_validate = false.
>
> We get `No mapping for: [e-mail] ` on the logs.

Hi,

this messages is expected, it means that are are no explicit mappings
for the user name to a Kerberos principal with the krb5_map_user option
in sssd.conf.

Please, if possible, send the full log together with krb5_child.log and
sssd_pac.log if those files have some content.

bye,
Sumit
> Best,
> Francis
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue