> On 23 Nov 2022, at 12:09, Sumit Bose <[email protected]> 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 <[email protected]> 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: >>>> [email protected] >>>> (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 [[email protected]] is empty, running request >>>> [0x5649c3a4b960] immediately. >>>> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_setup] (0x4000): [RID#7] No >>>> mapping for: [email protected] >>>> (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 '[email protected]' on the AD DC? >>> >>> bye, >> >> Here it is: >> >> userPrincipalName: francis > > Hi, > > ok, this explains the failure. It is expected that the attribute value > is '[email protected]', 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#userprincipalname > > 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 '[email protected]' 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 [email protected] <mailto:[email protected]>, 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: [email protected] <mailto:[email protected]>` on the logs. Best, Francis
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
