[Freeipa-users] Re: AD certificate authentication against FreeIPA - is that possible?
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
> > 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
> >>> 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/sssd-us...@lists.fedorahosted.org/
> >>
> >> 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 = 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
>
___
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:
[Freeipa-users] Re: AD certificate authentication against FreeIPA - is that possible?
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 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
> >>> 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 = 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 = 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
[Freeipa-users] Re: AD certificate authentication against FreeIPA - is that possible?
> On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> 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
>>> 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/sssd-us...@lists.fedorahosted.org/
>>
>> 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 = 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
___
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
[Freeipa-users] Re: 'ipa-ca-install' conncheck failure on freeIPA
Hello, Thank you for the answer! I don't know how i overlooked that thread, but he seems to have the exact same error messages. Unfortunately I do not seem to have the same issue causing my problems. I tried running the command `pki securitydomain-show` and it had this output: Domain: IPA CA Subsystem: Host ID: CA ipa01.example.com 443 Hostname: ipa01.example.com Port: 80 Secure Port: 443 Domain Manager: TRUE Which is what i would expect to see, so no ghost pki servers. Because your post on that thread said that the problem is likely on the master I looked again at some of the logs ont there but i am not entirely sure what to make of them. /var/log/httpd/error_log: [Tue Jun 27 19:15:32.337225 2023] [auth_gssapi:error] [pid 6960] [client 193.190.253.81:51488] Failed to unseal session data!, referer: https://ipa01.exampe.com/ipa/xml [Tue Jun 27 19:15:32.337346 2023] [auth_gssapi:error] [pid 6960] [client 193.190.253.81:51488] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa01.example.com/ipa/xml [Tue Jun 27 19:15:32.616436 2023] [:error] [pid 6955] ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) [Tue Jun 27 19:15:32.934945 2023] [:error] [pid 6954] ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) And i also found some errors in /var/log/dirsv/slapd-EXAMPLE-COM/errors: [27/Jun/2023:17:29:09.056259008 +0200] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=example,dc=com--no CoS Templates found, which should be added before the CoS Definition. [27/Jun/2023:17:29:09.178628062 +0200] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa01.example@example.com] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [27/Jun/2023:17:29:09.246224361 +0200] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests [27/Jun/2023:17:29:09.315077882 +0200] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests [27/Jun/2023:17:29:09.375742873 +0200] - INFO - slapd_daemon - Listening on /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests [27/Jun/2023:17:29:09.415783191 +0200] - ERR - schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [27/Jun/2023:17:29:10.745933826 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [27/Jun/2023:17:29:14.894515440 +0200] - ERR - schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=example,dc=com [27/Jun/2023:17:29:20.263045483 +0200] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=example,dc=com [27/Jun/2023:17:29:20.308590630 +0200] - ERR - schema-compat-plugin - Finished plugin initialization. [27/Jun/2023:17:30:44.625896180 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389): Replication bind with GSSAPI auth resumed [27/Jun/2023:19:04:28.171069570 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [27/Jun/2023:19:07:37.983080605 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389): Replication bind with GSSAPI auth resumed [27/Jun/2023:19:55:46.403689644 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [27/Jun/2023:19:57:19.079492205 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389): Replication bind with GSSAPI auth resumed [27/Jun/2023:20:20:55.449501930 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [27/Jun/2023:20:22:28.551932671 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica1.example.com" (replica1:389): Replication bind with GSSAPI auth resumed Do you have any other insights or things I could try to help resolve my issue? Sincerely, Arne ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: ipa-pkinit-manage failure
Hi On Thu, Jun 22, 2023 at 5:27 PM Алексей Иванов via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > Greetings, > > I'm trying to configure my replica IPA servers to support PKINIT. > > [root@office-ipa-1 ~]# ipa-pkinit-manage enable > Configuring Kerberos KDC (krb5kdc) > [1/1]: installing X509 Certificate for PKINIT > PKINIT certificate request failed: Certificate issuance failed > (CA_UNREACHABLE: Server at https://office-ipa-1./ipa/json failed > request, will retry: 4301 (Certificate operation cannot be completed: Key > Parameters 4096,8192 Not Matched).) > Failed to configure PKINIT > Full PKINIT configuration did not succeed > The setup will only install bits essential to the server functionality > You can enable PKINIT after the setup completed using 'ipa-pkinit-manage' > Done configuring Kerberos KDC (krb5kdc). > The ipa-pkinit-manage command was successful > [root@office-ipa-1 ~]# > > I've manually installed the correct KDC cert with ipa-server-certinstall > -k, but it seems I'm missing something out. > > I know it is extremely confusing but if you are using an externally-signed KDC certificate, you don't need to execute ipa-pkinit-manage enable. After adding the certificate with ipa-server-certinstall -k, you can see that the server is configured for pkinit with the following command: # ipa pkinit-status 1 server matched Server name: server.ipa.test PKINIT status: enabled Number of entries returned 1 Even though ipa-pkinit-manage status returns something different: # ipa-pkinit-manage status PKINIT is disabled The ipa-pkinit-manage command was successful So in your case, execute ipa-server-certinstall -k and don't launch ipa-pkinit-manage enable as this would try to issue a KDC cert signed by IPA CA. flo Error regarding Key Parameters 4096,8192 Not Matched is expected, as we've > changed all our certificate templates to support 4096 key and above. But I > don't understand why ipa-pkinit-manage enable command tries to issue a > new certificate and does not utilise the existing one? > > Regards, > Alex Ivanov. > ___ > 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 > ___ 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
[Freeipa-users] Re: 'ipa-ca-install' conncheck failure on freeIPA
Hi, another user recently had the same issue, see https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/VCARE7OOXWBEB5UXF75AQVFQXNOA43XM/#VFPHENT3PPWTY6W5L42FKQJFQ5GBWKOR We are not sure how the situation got solved, but he cleaned the security domain from ghost servers. Maybe it could help? flo On Tue, Jun 27, 2023 at 5:50 PM Arne Verheyden via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > I'm facing a problem while trying to set up a replica of our main FreeIPA > server. We're planning to migrate from an old server to a new one. > ipa-replica-install and ipa-dns-install runs without issue but the problem > arises when I try to use the ipa-ca-install command. The command fails at > the connection check phase with this output: > $ ipa-ca-install > Directory Manager (existing master) password: > > Run connection check to master > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Connection check failed! > See /var/log/ipareplica-conncheck.log for more information. > If the check results are not valid it can be skipped with --skip-conncheck > parameter. > > Logs of /var/log/ipa-replica-conncheck.log > 2023-06-27T14:25:28Z DEBUG Ports opened, notify original thread > 2023-06-27T14:25:28Z DEBUG Original thread resumed > 2023-06-27T14:25:28Z INFO Get credentials to log in to remote master > 2023-06-27T14:25:28Z DEBUG KRB5CCNAME set to /tmp/krbcc2_1ny8e1/ccache > 2023-06-27T14:25:28Z INFO Check RPC connection to remote master > 2023-06-27T14:25:28Z DEBUG Starting external process > 2023-06-27T14:25:28Z DEBUG args=['/usr/bin/certutil', '-d', > '/tmp/tmp66e_2bfv', '-N', '-f', '/tmp/tmp66e_2bfv/pwdfile.txt', '-@', > '/tmp/tmp66e_2bfv/pwdfile.txt'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout= > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout= > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', > '/tmp/tmp66e_2bfv'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for > /tmp/tmp66e_2bfv > > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout= > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', > '/tmp/tmp66e_2bfv/cert9.db'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for > /tmp/tmp66e_2bfv/cert9.db > > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout= > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', > '/tmp/tmp66e_2bfv/key4.db'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for > /tmp/tmp66e_2bfv/key4.db > > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout= > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', > '/tmp/tmp66e_2bfv/pkcs11.txt'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for > /tmp/tmp66e_2bfv/pkcs11.txt > > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout= > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', > '/tmp/tmp66e_2bfv/pwdfile.txt'] > 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 > 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for > /tmp/tmp66e_2bfv/pwdfile.txt > > 2023-06-27T14:25:29Z DEBUG stderr= > 2023-06-27T14:25:29Z DEBUG Starting external process > 2023-06-27T14:25:29Z DEBUG args=['/usr/bin/certutil', '-d', >
[Freeipa-users] 'ipa-ca-install' conncheck failure on freeIPA
I'm facing a problem while trying to set up a replica of our main FreeIPA server. We're planning to migrate from an old server to a new one. ipa-replica-install and ipa-dns-install runs without issue but the problem arises when I try to use the ipa-ca-install command. The command fails at the connection check phase with this output: $ ipa-ca-install Directory Manager (existing master) password: Run connection check to master Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Connection check failed! See /var/log/ipareplica-conncheck.log for more information. If the check results are not valid it can be skipped with --skip-conncheck parameter. Logs of /var/log/ipa-replica-conncheck.log 2023-06-27T14:25:28Z DEBUG Ports opened, notify original thread 2023-06-27T14:25:28Z DEBUG Original thread resumed 2023-06-27T14:25:28Z INFO Get credentials to log in to remote master 2023-06-27T14:25:28Z DEBUG KRB5CCNAME set to /tmp/krbcc2_1ny8e1/ccache 2023-06-27T14:25:28Z INFO Check RPC connection to remote master 2023-06-27T14:25:28Z DEBUG Starting external process 2023-06-27T14:25:28Z DEBUG args=['/usr/bin/certutil', '-d', '/tmp/tmp66e_2bfv', '-N', '-f', '/tmp/tmp66e_2bfv/pwdfile.txt', '-@', '/tmp/tmp66e_2bfv/pwdfile.txt'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout= 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout= 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', '/tmp/tmp66e_2bfv'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for /tmp/tmp66e_2bfv 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout= 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', '/tmp/tmp66e_2bfv/cert9.db'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for /tmp/tmp66e_2bfv/cert9.db 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout= 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', '/tmp/tmp66e_2bfv/key4.db'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for /tmp/tmp66e_2bfv/key4.db 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout= 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', '/tmp/tmp66e_2bfv/pkcs11.txt'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for /tmp/tmp66e_2bfv/pkcs11.txt 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/usr/sbin/selinuxenabled'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout= 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/sbin/restorecon', '-F', '/tmp/tmp66e_2bfv/pwdfile.txt'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout=Warning no default label for /tmp/tmp66e_2bfv/pwdfile.txt 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG Starting external process 2023-06-27T14:25:29Z DEBUG args=['/usr/bin/certutil', '-d', 'sql:/tmp/tmp66e_2bfv', '-A', '-n', 'CN=Certificate Authority,O=EXAMPLE.COM', '-t', 'C,,', '-a', '-f', '/tmp/tmp66e_2bfv/pwdfile.txt'] 2023-06-27T14:25:29Z DEBUG Process finished, return code=0 2023-06-27T14:25:29Z DEBUG stdout= 2023-06-27T14:25:29Z DEBUG stderr= 2023-06-27T14:25:29Z DEBUG importing all plugin modules in ipaclient.remote_plugins.schema$8182589c... 2023-06-27T14:25:29Z DEBUG importing plugin module ipaclient.remote_plugins.schema$8182589c.plugins 2023-06-27T14:25:29Z DEBUG importing all plugin modules in ipaclient.plugins... 2023-06-27T14:25:29Z DEBUG importing plugin module ipaclient.plugins.automember
[Freeipa-users] Re: pki-tomcat fails to start after upgrade
Hi flo, Many thanks, that resolved my issue, I can safely upgrade my servers now. Tania ___ 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
[Freeipa-users] Re: AD certificate authentication against FreeIPA - is that possible?
> On 27 Jun 2023, at 14:03, Sumit Bose 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
>>> 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 = 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 = 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
[Freeipa-users] Re: AD certificate authentication against FreeIPA - is that possible?
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
> > 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 = 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 = 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@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
___
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:
[Freeipa-users] Re: AD certificate authentication against FreeIPA - is that possible?
Hi Sumit,
> On 23 Jun 2023, at 10:52, Sumit Bose via FreeIPA-users
> 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 = 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 = 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
___
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
[Freeipa-users] Re: pki-tomcat fails to start after upgrade
Hi, On Mon, Jun 26, 2023 at 4:36 PM Tania Hagan via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > Hi FreeIPA, > > I am currently using FreeIPA version 4.9.10 with 6 ipareaplicas. I went > to upgrade the server to 4.9.11 but the ipa-server-upgrade failed where it > attempted to start pki-tomcat. In the /var/log/pki/pki-tomcat/ca/debug.log > I see: > > Unable to connect to LDAP server: Unable to create socket: > java.net.ConnectException: Connection refused (Connection refused) > … > At netscape.ldap.LDAPConnection(Uknown Source) > > Unable to start CA engine: Unable to connect to LDAP server: Unable to > create socket: java.net.ConnectionExection: Connection refused (Connection > refused) > …. > > I've been through the guide > https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ > where I can confirm the /etc/pki/pki-tomcat/ca/CS.cfg is using: > internaldb.ldapauth.authtype=SslClientAuth > internaldb.ldapauth.bindDN=cn=Directory Manager > internaldb.ldapauth.bindPWPrompt=internaldb > internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca > internaldb.ldapconn.host= > internaldb.ldapconn.port=636 > internaldb.ldapconn.secureConn=true > > certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' > shows the cert with the correct Serial number and the cert does not expire > until next year. > > If I read the private key, I have checked the Nickname is correct and does > work on another ipareplica but not the one I'm troubleshooting. > grep internal /var/lib/pki/pki-tomcat/conf/password.conf | cut -d= -f2 > > /tmp/pwdfile.txt > certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n > 'subsystemCert cert-pki-ca' > certutil: Checking token "NSS Certificate DB" in slot "NSS User Private > Key and Certificate Services" > certutil: problem listing keys: SEC_ERROR_INVALID_ARGS: security library: > invalid arguments. > > Sometimes the key alias starts with a prefix. Can you check the output of # certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt If the key is displayed in the output then there is no issue with it. The ldap server configuration looks to be using the correct certificate. > > I rolled back the server to my last known working server, and find that > commands such as ipa cert-find work fine, all my replicas have the same > cert, but the command certutil -K -d /etc/pki/pki-tomcat/alias -f > /tmp/pwdfile.txt -n 'subsystemCert cert-pki-ca' fails on 4 out of 6 > ipareplicas. 2 replicas see the correct result. > > Could any one help point me to how I might resolve this issue? > You may also be hitting https://pagure.io/freeipa/issue/9381. Please check if you have the drop-in file /etc/systemd/system/pki-tomcatd@pki-tomcat.service.d/ipa.conf or otherwise manually create it and re-try the upgrade. flo > > Many Thanks, > Tania > ___ > 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 > ___ 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
