> On 27 Jun 2023, at 14:03, Sumit Bose <sb...@redhat.com> wrote:
>
> Am Tue, Jun 27, 2023 at 01:32:12PM +0200 schrieb Francis Augusto
> Medeiros-Logeay via FreeIPA-users:
>> Hi Sumit,
>>
>>> On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
>>> <freeipa-users@lists.fedorahosted.org> wrote:
>>>
>>>>
>>>> No. The users are the same on both - same uid, gid, etc, but no
>>>> connection, trust, or anything.
>>>> The mapping on sssd.conf is this one:
>>>>
>>>> [certmap/mydomain.com/truesso] #Add this section and
>>>> following lines to set match and map rule for certificate user
>>>> matchrule = <EKU>msScLogin
>>>> maprule =
>>>> (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
>>>> domains = mydomain.com
>>>> priority = 10
>>>>
>>>> When id_provider = ad, it works, but not when it is `ldap`. But the users,
>>>> in principle, are the same. Could it be those attributes that are wrong?
>>>
>>> Hi,
>>>
>>> with 'id_provider = ad' the 'auth_provider' will be 'ad' as well, which
>>> is basically 'auth_provider = krb5' and Smartcard authentication is done
>>> the Kerberos way. With 'id_provider = ldap' the 'auth_provider' will be
>>> 'ldap' as well, so you might have to explicitly add 'auth_provider =
>>> krb5'
>>>
>>> Additionally, the 'maprule' is looking for LDAP attributes, so you IPA
>>> user must at least have the 'userPrincipal' attribute set with the
>>> principal which is stored in the subject alternative names of the
>>> certificate.
>>>
>>> Feel free to add 'debug_level = 9' to the [pam] and [domain/...]
>>> sections of sssd.conf, restart SSSD, try again and send the SSSD logs
>>> here.
>>>
>>> bye,
>>> Sumit
>>
>>
>> What happens is that when I have the sssd.conf configured like this:
>>
>> [domain/MYDOMAIN.NO]
>> ad_site = dc.mydomain.no
>> ad_domain = mydomain.no
>> id_provider = ad
>> access_provider = ad
>> #auth_provider = krb5
>>
>> It works with certificates and passwords.
>>
>> When I change it to this:
>>
>> [domain/MYDOMAIN.NO]
>> ad_site = dc.mydomain.no
>> ad_domain = mydomain.no
>> id_provider = ldap
>> access_provider = ad
>> auth_provider = krb5
>>
>> ldap_user_principal = userPrincipalName
>>
>> ldap_uri = ldaps://ldap.mydomain.no
>> ldap_default_bind_dn = cn=pam-common,cn=services,dc=mydomain,dc=no
>> ldap_default_authtok = not-so-secret
>> ldap_search_base = cn=system,dc=mydomain,dc=no
>> ldap_netgroup_search_base = cn=netgroups,cn=system,dc=mydomain,dc=no
>> ldap_group_search_base = cn=filegroups,cn=system,dc=mydomain,dc=no
>> ldap_user_home_directory = homeDirectory
>>
>>
>> It doesn’t work. Even the password doesn’t work, which is weird.
>> The rest of the sssd.conf is this:
>>
>>
>> krb5_realm = MYDOMAIN.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
>> krb5_store_password_if_offline = True
>>
>> [pam]
>> pam_cert_auth = True
>> pam_p11_allowed_services = +gdm-vmwcred
>> debug_level = 9
>>
>> [certmap/mydomain.no/truesso]
>> matchrule = <EKU>msScLogin
>> maprule =
>> (|(userPrincipalName={subject_principal})(uid={subject_principal.short_name}))
>> domains = mydomain.no
>> priority = 10
>> debug_level = 9
>>
>>
>> Do you see anything that clearly can be the problem?
>>
>> The error I get is this one:
>>
>> Jun 27 12:58:33 localhost.localdomain org.a11y.Bus[6510]: SpiRegistry daemon
>> is running with well-known name - org.a11y.atspi.Registry
>> Jun 27 12:58:34 localhost.localdomain krb5_child[6617]: Pre-authentication
>> failed: Cannot read password
>> Jun 27 12:58:34 localhost.localdomain desktopWorker[5838]:
>> pam_sss(gdm-vmwcred:auth): authentication success; logname= uid=0 euid=0
>> tty= ruser= rhost= user=francis
>
> Hi,
>
> the above says that authentication was successful, so I guess the next
> step, access control, might have failed. Can you try if using
>
> access_provider = permit
>
> instead of 'access_provider = ad' makes the login successful?
>
> bye,
> Sumit
Yes, it worked, with the certificate and all!
Thank you!
Best,
Francis
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
