Am Tue, Jun 27, 2023 at 02:18:22PM +0200 schrieb Francis Augusto Medeiros-Logeay via FreeIPA-users: > > > > On 27 Jun 2023, at 14:03, Sumit Bose <[email protected]> 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 > >>> <[email protected]> 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!
Hi, great, glad it is working for you now. Please note that with 'access_provider = permit' all users which are authenticated successfully are allowed to log in. You might want to apply some further restrictions. There is e.g. 'access_provider = simple', see man sssd-simple for details, or 'access_provider = ldap', see man sssd-ldap for details, which might be suitable for your environment. bye, Sumit > > Thank you! > > Best, > Francis > _______________________________________________ > FreeIPA-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 _______________________________________________ FreeIPA-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
