> 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