On 23 Nov 2022, at 12:09, Sumit Bose <sbose(a)redhat.com> 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 <sbose(a)redhat.com> 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:
francis(a)domain.no
>>> (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 [francis(a)domain.no] is empty, running request [0x5649c3a4b960]
immediately.
>>> (2022-11-22 20:03:21): [be[DOMAIN.NO]] [krb5_setup] (0x4000): [RID#7] No
mapping for: francis(a)domain.no
>>> (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 'francis(a)domain.no' on the AD DC?
>>
>> bye,
>
> Here it is:
>
> userPrincipalName: francis
Hi,
ok, this explains the failure. It is expected that the attribute value
is 'name(a)domain.name', 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#user...
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 'name(a)domain.name' 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 francis(a)domain.no
<mailto:francis@domain.no>, 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: francis(a)domain.no <mailto:ec-franciaa@ad.fp.educloud.no>` on
the logs.
Best,
Francis