AD certificate authentication against FreeIPA - is that possible?

[Francis Augusto Medeiros-Logeay]

Hi,

We have an application that requires Active Directory. In order to 
provide SSO, the application gets a user certificate from AD and, as I 
understand, uses it towards a RHEL machine as a smart card. I installed 
AD's ca certificates on the RHEL client and it works when sssd.conf is 
all configured towards AD.

I've joined the client to AD, as I said, but I do want my `id_provider` 
in `sssd.conf` to be `ldap` so that it gets my group info from FreeIPA. 
But when I do this, the authentication doesn't work.

Is there a way to either force pam/sssd to check the certificates 
against AD while still getting groups and names from ldap, or to get 
FreeIPA to approve the certificates?

I know this might be a very corner case, but if we make it works, this 
would be beautiful.

Best,
Francis


-- 
Francis Augusto Medeiros-Logeay
Oslo, Norway

[Rob Crittenden]

Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
>  Hi,
>  
>  We have an application that requires Active Directory. In order to
>  provide SSO, the application gets a user certificate from AD and, as I
>  understand, uses it towards a RHEL machine as a smart card. I installed
>  AD's ca certificates on the RHEL client and it works when sssd.conf is
>  all configured towards AD.
>  
>  I've joined the client to AD, as I said, but I do want my `id_provider`
>  in `sssd.conf` to be `ldap` so that it gets my group info from FreeIPA.
>  But when I do this, the authentication doesn't work.
>  
>  Is there a way to either force pam/sssd to check the certificates
>  against AD while still getting groups and names from ldap, or to get
>  FreeIPA to approve the certificates?
>  
>  I know this might be a very corner case, but if we make it works, this
>  would be beautiful. 
IMHO you should cross-post this to the SSSD users list as this seems
more their area,
https://lists.fedorahosted.org/archives/list/[e-mail]...

I think expanding on your configuration would help too. Are you using
the IPA certificate mapping to map the AD-issued certificates to an IPA
user for authentication?

What is the current provider? Is ipa not sufficient/working?

rob

[Francis Augusto Medeiros-Logeay]

>  On 22 Jun 2023, at 14:48, Rob Crittenden via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  
>  Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
> > Hi,
> > 
> > We have an application that requires Active Directory. In order to
> > provide SSO, the application gets a user certificate from AD and, as I
> > understand, uses it towards a RHEL machine as a smart card. I installed
> > AD's ca certificates on the RHEL client and it works when sssd.conf is
> > all configured towards AD.
> > 
> > I've joined the client to AD, as I said, but I do want my `id_provider`
> > in `sssd.conf` to be `ldap` so that it gets my group info from FreeIPA.
> > But when I do this, the authentication doesn't work.
> > 
> > Is there a way to either force pam/sssd to check the certificates
> > against AD while still getting groups and names from ldap, or to get
> > FreeIPA to approve the certificates?
> > 
> > I know this might be a very corner case, but if we make it works, this
> > would be beautiful.
>   
Thanks Rob!

>  IMHO you should cross-post this to the SSSD users list as this seems
>  more their area,
>  https://lists.fedorahosted.org/archives/list/[e-mail]... 
I posted it there first, tbh, but got no reply.

>  I think expanding on your configuration would help too. Are you
> using
>  the IPA certificate mapping to map the AD-issued certificates to an IPA
>  user for authentication? 
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?

>  What is the current provider? Is ipa not sufficient/working? 

It’s ad for everything else, except for `id`, which is ldap. I should try `ipa`, but since
I am using ldap configuration, I think it won’t make any difference.

Best,
Francis

[Sumit Bose]

Am Fri, Jun 23, 2023 at 09:03:55AM +0200 schrieb Francis Augusto Medeiros-Logeay via
FreeIPA-users:
>  
>  
>  > On 22 Jun 2023, at 14:48, Rob Crittenden via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  > 
>  > Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
>  >> Hi,
>  >> 
>  >> We have an application that requires Active Directory. In order to
>  >> provide SSO, the application gets a user certificate from AD and, as I
>  >> understand, uses it towards a RHEL machine as a smart card. I installed
>  >> AD's ca certificates on the RHEL client and it works when sssd.conf is
>  >> all configured towards AD.
>  >> 
>  >> I've joined the client to AD, as I said, but I do want my `id_provider`
>  >> in `sssd.conf` to be `ldap` so that it gets my group info from FreeIPA.
>  >> But when I do this, the authentication doesn't work.
>  >> 
>  >> Is there a way to either force pam/sssd to check the certificates
>  >> against AD while still getting groups and names from ldap, or to get
>  >> FreeIPA to approve the certificates?
>  >> 
>  >> I know this might be a very corner case, but if we make it works, this
>  >> would be beautiful.
>  > 
>  
>  Thanks Rob!
>  
>  > IMHO you should cross-post this to the SSSD users list as this seems
>  > more their area,
>  > https://lists.fedorahosted.org/archives/list/[e-mail]...
>  
>  I posted it there first, tbh, but got no reply.
>  
>  > I think expanding on your configuration would help too. Are you using
>  > the IPA certificate mapping to map the AD-issued certificates to an IPA
>  > user for authentication?
>  
>  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 is the current provider? Is ipa not sufficient/working?
>  
>  
>  It’s ad for everything else, except for `id`, which is ldap. I should try `ipa`, but
> since I am using ldap configuration, I think it won’t make any difference.
>  
>  Best,
>  Francis 
>   
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

Hi Sumit,

>  On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; 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

Best,

Francis

[Sumit Bose]

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(a)lists.fedorahosted.org&gt; 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

>  
>  Best,
>  
>  Francis 
>  
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

>  On 27 Jun 2023, at 14:03, Sumit Bose <sbose(a)redhat.com&gt; 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(a)lists.fedorahosted.org&gt; 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

[Sumit Bose]

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 <sbose(a)redhat.com&gt; 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(a)lists.fedorahosted.org&gt; 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 -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

>  On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  
>  Am Fri, Jun 23, 2023 at 09:03:55AM +0200 schrieb Francis Augusto Medeiros-Logeay via
> FreeIPA-users:
> > 
> > 
> >> On 22 Jun 2023, at 14:48, Rob Crittenden via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
> >> 
> >> Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
> >>> Hi,
> >>> 
> >>> We have an application that requires Active Directory. In order to
> >>> provide SSO, the application gets a user certificate from AD and, as I
> >>> understand, uses it towards a RHEL machine as a smart card. I installed
> >>> AD's ca certificates on the RHEL client and it works when sssd.conf is
> >>> all configured towards AD.
> >>> 
> >>> I've joined the client to AD, as I said, but I do want my `id_provider`
> >>> in `sssd.conf` to be `ldap` so that it gets my group info from FreeIPA.
> >>> But when I do this, the authentication doesn't work.
> >>> 
> >>> Is there a way to either force pam/sssd to check the certificates
> >>> against AD while still getting groups and names from ldap, or to get
> >>> FreeIPA to approve the certificates?
> >>> 
> >>> I know this might be a very corner case, but if we make it works, this
> >>> would be beautiful.
> >> 
> > 
> > Thanks Rob!
> > 
> >> IMHO you should cross-post this to the SSSD users list as this seems
> >> more their area,
> >> https://lists.fedorahosted.org/archives/list/[e-mail]...
> > 
> > I posted it there first, tbh, but got no reply.
> > 
> >> I think expanding on your configuration would help too. Are you using
> >> the IPA certificate mapping to map the AD-issued certificates to an IPA
> >> user for authentication?
> > 
> > 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 

Hi Sumit,

It fails on RHEL 9, though - before I was doing it on RHEL 9.

I get this: 

Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
Preauthentication failed
Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
Preauthentication failed
Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth): received
for user francis: 7 (Authentication failure)
Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: unable to locate daemon
control file
Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: stashed password to try later
in open ses

Exact same configuration. Neither password nor certificate works, though password works on
ssh.

Any tips here?

Best,

Francis

[Sumit Bose]

Am Wed, Jun 28, 2023 at 07:23:58AM +0200 schrieb Francis Augusto Medeiros-Logeay:
>  
>  
>  > On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  > 
>  > Am Fri, Jun 23, 2023 at 09:03:55AM +0200 schrieb Francis Augusto Medeiros-Logeay via
> FreeIPA-users:
>  >> 
>  >> 
>  >>> On 22 Jun 2023, at 14:48, Rob Crittenden via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  >>> 
>  >>> Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
>  >>>> Hi,
>  >>>> 
>  >>>> We have an application that requires Active Directory. In order to
>  >>>> provide SSO, the application gets a user certificate from AD and, as I
>  >>>> understand, uses it towards a RHEL machine as a smart card. I installed
>  >>>> AD's ca certificates on the RHEL client and it works when sssd.conf
> is
>  >>>> all configured towards AD.
>  >>>> 
>  >>>> I've joined the client to AD, as I said, but I do want my
> `id_provider`
>  >>>> in `sssd.conf` to be `ldap` so that it gets my group info from FreeIPA.
>  >>>> But when I do this, the authentication doesn't work.
>  >>>> 
>  >>>> Is there a way to either force pam/sssd to check the certificates
>  >>>> against AD while still getting groups and names from ldap, or to get
>  >>>> FreeIPA to approve the certificates?
>  >>>> 
>  >>>> I know this might be a very corner case, but if we make it works, this
>  >>>> would be beautiful.
>  >>> 
>  >> 
>  >> Thanks Rob!
>  >> 
>  >>> IMHO you should cross-post this to the SSSD users list as this seems
>  >>> more their area,
>  >>>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  >> 
>  >> I posted it there first, tbh, but got no reply.
>  >> 
>  >>> I think expanding on your configuration would help too. Are you using
>  >>> the IPA certificate mapping to map the AD-issued certificates to an IPA
>  >>> user for authentication?
>  >> 
>  >> 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
>  
>  
>  Hi Sumit,
>  
>  It fails on RHEL 9, though - before I was doing it on RHEL 9.
>  
>  I get this: 
>  
>  Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth): received
> for user francis: 7 (Authentication failure)
>  Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: unable to locate daemon
> control file
>  Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: stashed password to try later
> in open ses
>  
>  Exact same configuration. Neither password nor certificate works, though password works
> on ssh.
>  
>  Any tips here? 
Hi,

this might be related to
https://bugzilla.redhat.com/show_bug.cgi?id=2214300
(https://bugzilla.redhat.com/show_bug.cgi?id=2155607 is the
corresponding RHEL-9 ticket, but this is mostly private). Does it work
any better if you set

    update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY

bye,
Sumit

>  
>  Best,
>  
>  Francis
>

[Francis Augusto Medeiros-Logeay]

>  On 28 Jun 2023, at 07:50, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  
>  Am Wed, Jun 28, 2023 at 07:23:58AM +0200 schrieb Francis Augusto Medeiros-Logeay:
> > 
> > 
> >> On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
> >> 
> >> Am Fri, Jun 23, 2023 at 09:03:55AM +0200 schrieb Francis Augusto Medeiros-Logeay
> via FreeIPA-users:
> >>> 
> >>> 
> >>>> On 22 Jun 2023, at 14:48, Rob Crittenden via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
> >>>> 
> >>>> Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
> >>>>> Hi,
> >>>>> 
> >>>>> We have an application that requires Active Directory. In order to
> >>>>> provide SSO, the application gets a user certificate from AD and, as
> I
> >>>>> understand, uses it towards a RHEL machine as a smart card. I
> installed
> >>>>> AD's ca certificates on the RHEL client and it works when
> sssd.conf is
> >>>>> all configured towards AD.
> >>>>> 
> >>>>> I've joined the client to AD, as I said, but I do want my
> `id_provider`
> >>>>> in `sssd.conf` to be `ldap` so that it gets my group info from
> FreeIPA.
> >>>>> But when I do this, the authentication doesn't work.
> >>>>> 
> >>>>> Is there a way to either force pam/sssd to check the certificates
> >>>>> against AD while still getting groups and names from ldap, or to get
> >>>>> FreeIPA to approve the certificates?
> >>>>> 
> >>>>> I know this might be a very corner case, but if we make it works,
> this
> >>>>> would be beautiful.
> >>>> 
> >>> 
> >>> Thanks Rob!
> >>> 
> >>>> IMHO you should cross-post this to the SSSD users list as this seems
> >>>> more their area,
> >>>>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
> >>> 
> >>> I posted it there first, tbh, but got no reply.
> >>> 
> >>>> I think expanding on your configuration would help too. Are you using
> >>>> the IPA certificate mapping to map the AD-issued certificates to an IPA
> >>>> user for authentication?
> >>> 
> >>> 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
> > 
> > 
> > Hi Sumit,
> > 
> > It fails on RHEL 9, though - before I was doing it on RHEL 9.
> > 
> > I get this: 
> > 
> > Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
> > Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
> > Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
> > Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
> received for user francis: 7 (Authentication failure)
> > Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: unable to locate daemon
> control file
> > Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: stashed password to try
> later in open ses
> > 
> > Exact same configuration. Neither password nor certificate works, though password
> works on ssh.
> > 
> > Any tips here?
>  
>  Hi,
>  
>  this might be related to
>  https://bugzilla.redhat.com/show_bug.cgi?id=2214300
>  (https://bugzilla.redhat.com/show_bug.cgi?id=2155607 is the
>  corresponding RHEL-9 ticket, but this is mostly private). Does it work
>  any better if you set
>  
>     update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY
>  
>  bye,
>  Sumit
>   
Not really. I get this:

Jun 28 08:02:00 sso-rhel-test krb5_child[3019]: Pre-authentication failed:
Preauthentication failed
Jun 28 08:02:00 sso-rhel-test krb5_child[3019]: Pre-authentication failed:
Preauthentication failed
Jun 28 08:02:00 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
Jun 28 08:02:00 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth): received for
user francis: 7 (Authentication failure)
Jun 28 08:02:01 sso-rhel-test krb5_child[3083]: Cannot read password
Jun 28 08:02:01 sso-rhel-test krb5_child[3083]: Cannot read password
Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth): received for
user francis: 15 (Authentication service cannot retrieve user credentials)
Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: gkr-pam: unable to locate daemon
control file
Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: gkr-pam: stashed password to try later
in open session
Jun 28 08:02:10 sso-rhel-test krb5_child[3112]: Pre-authentication failed:
Preauthentication failed
Jun 28 08:02:10 sso-rhel-test krb5_child[3112]: Pre-authentication failed:
Preauthentication failed
Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-password:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-password:auth): received
for user francis: 7 (Authentication failure)
Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: gkr-pam: unable to locate daemon
control file

Best,

Francis

[Sumit Bose]

Am Wed, Jun 28, 2023 at 08:03:58AM +0200 schrieb Francis Augusto Medeiros-Logeay via
FreeIPA-users:
>  
>  
>  > On 28 Jun 2023, at 07:50, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  > 
>  > Am Wed, Jun 28, 2023 at 07:23:58AM +0200 schrieb Francis Augusto Medeiros-Logeay:
>  >> 
>  >> 
>  >>> On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  >>> 
>  >>> Am Fri, Jun 23, 2023 at 09:03:55AM +0200 schrieb Francis Augusto
> Medeiros-Logeay via FreeIPA-users:
>  >>>> 
>  >>>> 
>  >>>>> On 22 Jun 2023, at 14:48, Rob Crittenden via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  >>>>> 
>  >>>>> Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
>  >>>>>> Hi,
>  >>>>>> 
>  >>>>>> We have an application that requires Active Directory. In order
> to
>  >>>>>> provide SSO, the application gets a user certificate from AD
> and, as I
>  >>>>>> understand, uses it towards a RHEL machine as a smart card. I
> installed
>  >>>>>> AD's ca certificates on the RHEL client and it works when
> sssd.conf is
>  >>>>>> all configured towards AD.
>  >>>>>> 
>  >>>>>> I've joined the client to AD, as I said, but I do want my
> `id_provider`
>  >>>>>> in `sssd.conf` to be `ldap` so that it gets my group info from
> FreeIPA.
>  >>>>>> But when I do this, the authentication doesn't work.
>  >>>>>> 
>  >>>>>> Is there a way to either force pam/sssd to check the
> certificates
>  >>>>>> against AD while still getting groups and names from ldap, or to
> get
>  >>>>>> FreeIPA to approve the certificates?
>  >>>>>> 
>  >>>>>> I know this might be a very corner case, but if we make it
> works, this
>  >>>>>> would be beautiful.
>  >>>>> 
>  >>>> 
>  >>>> Thanks Rob!
>  >>>> 
>  >>>>> IMHO you should cross-post this to the SSSD users list as this
> seems
>  >>>>> more their area,
>  >>>>>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  >>>> 
>  >>>> I posted it there first, tbh, but got no reply.
>  >>>> 
>  >>>>> I think expanding on your configuration would help too. Are you
> using
>  >>>>> the IPA certificate mapping to map the AD-issued certificates to an
> IPA
>  >>>>> user for authentication?
>  >>>> 
>  >>>> 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
>  >> 
>  >> 
>  >> Hi Sumit,
>  >> 
>  >> It fails on RHEL 9, though - before I was doing it on RHEL 9.
>  >> 
>  >> I get this: 
>  >> 
>  >> Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
>  >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  >> Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
>  >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
> received for user francis: 7 (Authentication failure)
>  >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: unable to locate
> daemon control file
>  >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: stashed password to
> try later in open ses
>  >> 
>  >> Exact same configuration. Neither password nor certificate works, though
> password works on ssh.
>  >> 
>  >> Any tips here?
>  > 
>  > Hi,
>  > 
>  > this might be related to
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2214300
>  > (https://bugzilla.redhat.com/show_bug.cgi?id=2155607 is the
>  > corresponding RHEL-9 ticket, but this is mostly private). Does it work
>  > any better if you set
>  > 
>  >    update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY
>  > 
>  > bye,
>  > Sumit
>  > 
>  
>  Not really. I get this:
>  
>  Jun 28 08:02:00 sso-rhel-test krb5_child[3019]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:00 sso-rhel-test krb5_child[3019]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:00 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  Jun 28 08:02:00 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth): received
> for user francis: 7 (Authentication failure)
>  Jun 28 08:02:01 sso-rhel-test krb5_child[3083]: Cannot read password
>  Jun 28 08:02:01 sso-rhel-test krb5_child[3083]: Cannot read password
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth): received
> for user francis: 15 (Authentication service cannot retrieve user credentials)
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: gkr-pam: unable to locate daemon
> control file
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: gkr-pam: stashed password to try later
> in open session
>  Jun 28 08:02:10 sso-rhel-test krb5_child[3112]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:10 sso-rhel-test krb5_child[3112]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-password:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-password:auth): received
> for user francis: 7 (Authentication failure)
>  Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: gkr-pam: unable to locate daemon
> control file 
Hi,

can you set 'debug_level = 9' in the [pam] and [domain/...] sections of
sssd.conf, restart SSSD, try to authenticate again and send all the logs
from /var/log/sssd?

bye,
Sumit

>  
>  Best,
>  
>  Francis 
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Francis Augusto Medeiros-Logeay]

Yes:

Package krb5-pkinit-1.20.1-8.el9.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

Best,

Francis

>  On 28 Jun 2023, at 08:03, Francis Augusto Medeiros-Logeay via
> FreeIPA-users <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  
>  
>  
> > On 28 Jun 2023, at 07:50, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
> > 
> > Am Wed, Jun 28, 2023 at 07:23:58AM +0200 schrieb Francis Augusto Medeiros-Logeay:
> >> 
> >> 
> >>> On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
> >>> 
> >>> Am Fri, Jun 23, 2023 at 09:03:55AM +0200 schrieb Francis Augusto
> Medeiros-Logeay via FreeIPA-users:
> >>>> 
> >>>> 
> >>>>> On 22 Jun 2023, at 14:48, Rob Crittenden via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org&gt; wrote:
> >>>>> 
> >>>>> Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> We have an application that requires Active Directory. In order
> to
> >>>>>> provide SSO, the application gets a user certificate from AD and,
> as I
> >>>>>> understand, uses it towards a RHEL machine as a smart card. I
> installed
> >>>>>> AD's ca certificates on the RHEL client and it works when
> sssd.conf is
> >>>>>> all configured towards AD.
> >>>>>> 
> >>>>>> I've joined the client to AD, as I said, but I do want my
> `id_provider`
> >>>>>> in `sssd.conf` to be `ldap` so that it gets my group info from
> FreeIPA.
> >>>>>> But when I do this, the authentication doesn't work.
> >>>>>> 
> >>>>>> Is there a way to either force pam/sssd to check the
> certificates
> >>>>>> against AD while still getting groups and names from ldap, or to
> get
> >>>>>> FreeIPA to approve the certificates?
> >>>>>> 
> >>>>>> I know this might be a very corner case, but if we make it works,
> this
> >>>>>> would be beautiful.
> >>>>> 
> >>>> 
> >>>> Thanks Rob!
> >>>> 
> >>>>> IMHO you should cross-post this to the SSSD users list as this seems
> >>>>> more their area,
> >>>>>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
> >>>> 
> >>>> I posted it there first, tbh, but got no reply.
> >>>> 
> >>>>> I think expanding on your configuration would help too. Are you
> using
> >>>>> the IPA certificate mapping to map the AD-issued certificates to an
> IPA
> >>>>> user for authentication?
> >>>> 
> >>>> 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
> >> 
> >> 
> >> Hi Sumit,
> >> 
> >> It fails on RHEL 9, though - before I was doing it on RHEL 9.
> >> 
> >> I get this: 
> >> 
> >> Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
> >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
> >> Jun 28 07:21:09 sso-rhel-test krb5_child[3447]: Pre-authentication failed:
> Preauthentication failed
> >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: pam_sss(gdm-password:auth):
> received for user francis: 7 (Authentication failure)
> >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: unable to locate
> daemon control file
> >> Jun 28 07:21:09 sso-rhel-test desktopWorker[2796]: gkr-pam: stashed password to
> try later in open ses
> >> 
> >> Exact same configuration. Neither password nor certificate works, though password
> works on ssh.
> >> 
> >> Any tips here?
> > 
> > Hi,
> > 
> > this might be related to
> > https://bugzilla.redhat.com/show_bug.cgi?id=2214300
> > (https://bugzilla.redhat.com/show_bug.cgi?id=2155607 is the
> > corresponding RHEL-9 ticket, but this is mostly private). Does it work
> > any better if you set
> > 
> >   update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY
> > 
> > bye,
> > Sumit
> > 
>  
>  Not really. I get this:
>  
>  Jun 28 08:02:00 sso-rhel-test krb5_child[3019]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:00 sso-rhel-test krb5_child[3019]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:00 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  Jun 28 08:02:00 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth): received
> for user francis: 7 (Authentication failure)
>  Jun 28 08:02:01 sso-rhel-test krb5_child[3083]: Cannot read password
>  Jun 28 08:02:01 sso-rhel-test krb5_child[3083]: Cannot read password
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-vmwcred:auth): received
> for user francis: 15 (Authentication service cannot retrieve user credentials)
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: gkr-pam: unable to locate daemon
> control file
>  Jun 28 08:02:01 sso-rhel-test desktopWorker[2835]: gkr-pam: stashed password to try later
> in open session
>  Jun 28 08:02:10 sso-rhel-test krb5_child[3112]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:10 sso-rhel-test krb5_child[3112]: Pre-authentication failed:
> Preauthentication failed
>  Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-password:auth):
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=francis
>  Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: pam_sss(gdm-password:auth): received
> for user francis: 7 (Authentication failure)
>  Jun 28 08:02:10 sso-rhel-test desktopWorker[2835]: gkr-pam: unable to locate daemon
> control file
>  
>  Best,
>  
>  Francis 
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue