FreeIPA-users October 2024

freeipa-users@lists.fedorahosted.org

6 participants
3 discussions

Can't login after creating a user account
by Kris C 04 Oct '24

04 Oct '24

Not sure if anyone is experiencing this or not and apologize if it's already answered, but I've created an FreeIPA account and with a random password using the command line (ipa user-add user1 --uid=6543 --random). I then, within the WebUI, have the admin account reset user1's password to something more human friendly. I then, as user1, attempt to log into the WebUI to set the final password. I provide the user1 username and the more human friendly password and I can't log in. I've created the user through the WebUI and reset the password and it works just like I want it to. The reason I'm creating the accounts using the CLI is to migrate accounts from an old LDAP instance into FreeIPA via script. I want to then have an admin reset the users password so the user can then log in and set their final password in FreeIPA's WebUI. Thoughts? Thank you!

3 12

GSSAPI Authentication Failure and Inaccessible Kerberos Credentials (Replication bind with GSSAPI auth failed)
by Jan Wagner 03 Oct '24

03 Oct '24

Hey, I've encountered a replication issue, due to replica not being able to construct gss context. The result is, that I cannot bind to the replica (let's call it replica1) using gssapi and other replicas cannot establish replication. The directory logs are full of the following: ``` [02/Oct/2024:13:28:46.834250430 +0200] - DEBUG - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToreplica2.example.com" (replica2:389) - Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: KCM:))) ``` I've already checked, if the time is in sync and it should be: ``` [root@replica1 ~]# clockdiff -o replica2.example.com .................................................. host=replica2.example.com rtt=8(0)ms/8ms delta=2ms/2ms Wed Oct 2 14:09:14 2024 ``` I've already checked that keys in keytab have the same kvno: ``` [root@replica2 ~]# kvno host/replica1.example.com host/replica1.example.com(a)EXAMPLE.COM: kvno = 2 ----- [root@replica1 ~]# kvno host/replica1.example.com host/replica1.example.com(a)EXAMPLE.COM: kvno = 2 ----- [root@replica1 ~]# klist -k -t /etc/dirsrv/ds.keytab Keytab name: FILE:/etc/dirsrv/ds.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 09/02/2024 12:11:19 ldap/replica1.example.com(a)EXAMPLE.COM 2 09/02/2024 12:11:19 ldap/replica1.example.com(a)EXAMPLE.COM 2 09/02/2024 12:11:19 ldap/replica1.example.com(a)EXAMPLE.COM 2 09/02/2024 12:11:19 ldap/replica1.example.com(a)EXAMPLE.COM 2 09/02/2024 12:11:19 ldap/replica1.example.com(a)EXAMPLE.COM 2 09/02/2024 12:11:19 ldap/replica1.example.com(a)EXAMPLE.COM ``` I have not yet tried to get a new keytab with ipa-getkeytab, because I am not sure, how the keytabs are then distributed between peers. ``` VERSION="9.4 (Plow)" VERSION: 4.11.0, API_VERSION: 2.253 (IPA) ``` I am sorry, if I did not provide all relevant logs or if it has an obvious solution. Does anyone has any suggestions? Thanks in advance! Kind regards Jan

4 6

Primary IPA server failed to properly renew krb5kdc Certificate
by Russ Long 01 Oct '24

01 Oct '24

I have a cluster of 3 IPA servers, the primary server renewed the krb5kdc certificate last night, but did not include the principal name when it renewed, here is after the auto-renewal: Number of certificates and requests being tracked: 9. Request ID '20221028185012': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' CA: IPA issuer: CN=Certificate Authority,O=IPA.REDACTED subject: CN=ipa-primary.ipa.redacted,O=IPA.REDACTED issued: 2024-09-30 14:51:55 EDT expires: 2026-10-01 14:51:55 EDT dns: ipa-primary.ipa.redacted key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-pkinit-KPKdc profile: KDCs_PKINIT_Certs pre-save command: post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert track: yes auto-renew: yes After I manually renewed with getcert resubmit, it included the principal line: [root@ipa-primary pki]# getcert list -i 20221028185012 Number of certificates and requests being tracked: 9. Request ID '20221028185012': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' CA: IPA issuer: CN=Certificate Authority,O=IPA.REDACTED subject: CN=ipa-primary.ipa.REDACTED,O=IPA.REDACTED issued: 2024-10-01 13:26:06 EDT expires: 2026-10-02 13:26:06 EDT dns: ipa-primary.ipa.REDACTED principal name: krbtgt/IPA.REDACTED(a)IPA.REDACTED key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-pkinit-KPKdc profile: KDCs_PKINIT_Certs pre-save command: post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert track: yes auto-renew: yes Any idea how I can track down how or why this was missed, and how to prevent this from happening in the future?

2 5

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users October 2024