anonymous kinit (-n) failed with "PKINIT client could not verify DH reply" (solution)
by Sam Morris
I found that 'kinit -n' was prompting me for the password for
WELLKNOWN/ANONYMOUS(a)IPA.EXAMPLE.COM. This happened on everal, but not
all clients.
After setting the environment variable KRB5_TRACE=/dev/stderr, the
useful parts of the output of 'kinit -n' were:
[826240] 1693432177.150062: PKINIT loading CA certs and CRLs from FILE /var/lib/ipa-client/pki/kdc-ca-bundle.pem
[826240] 1693432177.150063: PKINIT loading CA certs and CRLs from FILE /var/lib/ipa-client/pki/ca-bundle.pem
[826240] 1693432177.150064: PKINIT client computed kdc-req-body checksum 14/265A6783F1767B3DB744B8ED1FE333185EFFEB7B
[826240] 1693432177.150066: PKINIT client making DH request
[826240] 1693432177.150067: Preauth module pkinit (16) (real) returned: 0/Success
[826240] 1693432177.150068: Produced preauth for next request: PA-FX-COOKIE (133), PA-PK-AS-REQ (16)
[826240] 1693432177.150069: Sending request (1565 bytes) to IPA.EXAMPLE.COM
[826240] 1693432177.150070: Initiating TCP connection to stream 192.0.2.5:88
[826240] 1693432177.150071: Sending TCP request to stream 192.0.2.5:88
[826240] 1693432177.150072: Received answer (1609 bytes) from stream 192.0.2.5:88
[826240] 1693432177.150073: Terminating TCP connection to stream 192.0.2.5:88
[826240] 1693432177.150074: Response was from primary KDC
[826240] 1693432177.150075: Processing preauth types: PA-PK-AS-REP (17), PA-PKINIT-KX (147)
[826240] 1693432177.150076: Preauth module pkinit (147) (info) returned: 0/Success
[826240] 1693432177.150077: PKINIT client could not verify DH reply
[826240] 1693432177.150078: Preauth module pkinit (17) (real) returned: -1765328360/Preauthentication failed
Searching online for "PKINIT client could not verify DH reply" didn't
come up with anything useful so I am writing this message to help anyone
else who might experience a similar problem.
I noticed that all the failing clients were talking to the same IPA
server. And on that server, 'kinit -n' failed with the same message.
As for the underlying cause: it turns out that there was a problem with
the KDC's PKI certificate on the server.
[root@ipa5 ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 12.
Request ID '20221103090547':
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: SelfSign
issuer: CN=ipa5.ipa.example.com,O=IPA.EXAMPLE.COM
subject: CN=ipa5.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-07-08 18:12:32 UTC
expires: 2024-07-08 18:12:32 UTC
dns: ipa5.ipa.example.com
principal name: krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
certificate template/profile: KDCs_PKINIT_Certs
profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
Note the CA is "SelfSign", which caused certmonger to generate a
self-signed certificate on 2023-07-08 when it renewed, instead of
contacting the IPA CA.
The fix was to run:
[root@ipa5 ~]# getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -c IPA
Request "20221103090547" modified.
[root@ipa5 ~]# getcert resubmit -w -v -f /var/kerberos/krb5kdc/kdc.crt
Resubmitting "20221103090547" to "IPA".
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State READING_CERT, stuck: no.
State POST_SAVED_CERT, stuck: no.
State MONITORING, stuck: no.
[root@ipa5 ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 12.
Request ID '20221103090547':
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.EXAMPLE.COM
subject: CN=ipa5.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-08-30 21:51:48 UTC
expires: 2023-11-28 21:51:48 UTC
dns: ipa5.ipa.example.com
principal name: krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
certificate template/profile: KDCs_PKINIT_Certs
profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
After this, 'kinit -n' on the server and clients was successful again.
I've no earthly idea how the tracking request was set up with the wrong
CA, but at least this appears to have fixed it.
There are some other differences between the tracking request on this
server and another server (both of which are running fully-updated RHEL
8):
[root@ipa3 ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 12.
Request ID '20210423163239':
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.EXAMPLE.COM
subject: CN=ipa3.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-07-29 16:33:03 UTC
expires: 2023-10-27 16:33:03 UTC
principal name: krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM
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
On ipa3 the tracking request has no 'dns' line (subsequently, in the
issued certificate there is no dnsName in the subjectAltName extension).
There's also no 'certificate template/profile' line. Neither of these
seem to affect any functionality, but I do wonder where the difference
came from. Perhaps this is a chance in behaviour in freeipa between when
ipa3 and ipa5 were installed?
The tracking request with the wrong CA wasn't picked up by
ipa-healthcheck, I can file an issue about that if it's helpful.
Hopefully someone else could find this info useful.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
8 months, 1 week
How to use ipa-dsu
by Duarte Petiz
Hello freeipa users!
I'm trying to follow the guide that is available here: https://freeipa.readthedocs.io/en/latest/designs/disable-stale-users.html about ipa-dsu.
I was trying to do a dry-run in order to check what it really does on my env but the package seems to not be present.
I'm using the freeipa-server:rocky-9 docker image.
root@prod-us-freeipa:~# docker exec -ti ipa_freeipa_1 bash
[root@prod-us-freeipa /]# ipa-dsu --dry-run
bash: ipa-dsu: command not found
What could I do?
Regards
8 months, 1 week
Issue with rsyslog file permissions.
by Ole Froslie
Hi,
I am setting up centralized logging from FreeIPA version 4.10.1 running on CentOs.
I have tried to set up rsyslog, initially just reading the access log, using this config (with domain and ips obfuscated)
module(load="imfile")
input(type="imfile" File="/var/log/dirsrv/slapd-MY_DOMAIN/access" Tag="ipa-security-log" Facility="local0")
# Forward local facilities
if $syslogfacility >= 16 then @my_ip_adress:514
When restarting rsyslog with this config , I get error message (with servername and domains obfuscated):
Aug 29 10:46:28 myserver.mydomain.net systemd[1]: Starting System Logging Service...
Aug 29 10:46:28 myserver.mydomain.net rsyslogd[12607]: imfile: on startup file '/var/log/dirsrv/slapd-MY-DOMAIN/access' does not exist but is configured in static file monitor - this may indicate a misconfiguration. If the file appears at a later time, it will automatically be processed. Reason: Permission denied [v8.2102.0-109.el9]
I have observed the following, following tips on various threads and info found on internet.
rsyslog is working as intended when exporting the standard linux logs
rsyslog is running as root. There is no drop privileges configured. I have checked this in the /etc/rsyslog.conf, and I also see that rsyslog is running as root when using ps -ef | grep rsyslogd
running as root should enable it to read any file, should´t it?
I have tried to turn off SELinix, the problem remains the same. I have also checked logs , but there are no signs of SELinux being the cause of the problem.
FreeIPA is using its system user dirsrv when creating the files.
The ownership of the directories and files are as follows:
drwxr-xr-x. 3 root root 28 Aug 23 15:23 dirsrv
drwxrwx--x. 2 dirsrv dirsrv 4096 Aug 28 16:55 slapd-MY-DOMAIN
-rw-------. 1 dirsrv dirsrv 6007159 Aug 29 10:56 access
I have tried to manually change the access rights of the access file with chmod o+r access and set chmod o+x on the slapd-directory. This removes the error after restart of rsyslog, and rsyslog exports the logs as expected.
However, due to the FreeIpa log rotation set-up, new files are created and rotated removing the read access for others, and the logging stops again.
Has anyone seen anything similar, does anyone have any clues about what the cause of this could be?
Is there anything I can do with the set-up of the FreeIPA server itself, to change the permissions?
regards,
Ole
8 months, 1 week
Basic set-up for 2FA for ubuntu linux authentication
by Ole Froslie
Hi all,
I do acknowledge that this topic has been discussed in various threads, but I am struggling to get it working and to understand the concepts.
My use cases are to use OTP 2FA with for example Google Authenticator as additional security measure for
1. access to the freeipa server itself for selected users (typically admins)
2. access to selected linux servers enrolled in FreeIPA . All users with any access to these ,should always use OTP on these servers. No requirement for OTP for access to other servers.
3. access to applications using LDAP integrations to FreeIPA
The first use case works right out of the box. I have managed to configure individual users for OTP in the User Auth settings, assign tokens and get it working using Google Authenticated.
I am struggling with the second use case for server access.
Instead of diving into all the detailed configs and logs and to understand why it is not working I would rather start with how it is supposed to work at the high level, to ensure I have gotten the basics correct first.
Is the use case supported at all?
How should I configure the selected users FreeIPA ?
How should I configure the selected hosts in FreeIPA ?
How should I configure on the selected hosts, i.e with respect to SSSD, PAM etc.
regards,
Ole
8 months, 1 week
Custom ssl cert for freeipa docker
by Leo O
Hello Guys,
I'm would like to use custom ssl certificates for http and ldap, I saw the following:
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
But I wonder how would this be done when using freeipa in a docker/podman container. I mean the container is started with "--read-only" flag. So it's not clear to me what the correct approach here would be. I hope it's not that you have to re-build an own image with the ssl certificates every time?
Background Info: I'm using acme.sh in a VM, which creates my wildcard letsencrypt certificates and puts them on an nfs share. Freeipa should simply use that certificates for http and ldap and that's it. No renewing as this is done by the acme.sh VM itself.
8 months, 2 weeks
FreeIPA in Containers - Ready for Prod?
by Jonas R
Hello all,
we have setup a test system with FreeIPA running on a docker (swarm) host and are very happy with the tool. Now we are moving forward towards the planning for implementation and considering wthether to run in in Containers or VMs.
On the FreeIPA website it says "the team also maintains PoC container release of FreeIPA". That's why I am wondering, if running FreeIPA in containers is generally considered as something for testing environments or PoC, but not for production. Are there any experiences running it in containers for production? Or is everybody using bare metal/VMs? We are planning an environment with 40-50 clients on one site.
Thanks,
Jonas
8 months, 2 weeks
Time skew is 82 years off, with no replicas
by Kevin Konzem
So in our environment, we had 3 freeipa 4.9.11 servers (ipa4, ipa5, ipa6) in a replicated setup, DL1, and a couple weeks ago, something happened that broke the replication between the three of them. We were able to get ipa6 up and running and accepting clients, so we shut down ipa4 and ipa5 and removed all replication agreements, ruvs, and topology segments related to ipa4 and ipa5. We are trying to clean up ipa6 before attempting to stand up new replicas, and we are stuck on this one problem: when running ipa-healthcheck, it complains that the time skew is over 24 hours, specifically it is 30145 days off, a bit over 82 years.
ipa6 ~ $ ipa-healthcheck
[
{
"source": "ipahealthcheck.ds.dse",
"check": "DSECheck",
"result": "CRITICAL",
"uuid": "ecc2c131-b86a-4851-a156-c304d77ebb0b",
"when": "20230822183329Z",
"duration": "0.012828",
"kw": {
"key": "DSSKEWLE0003",
"items": [
"Replication",
"dc=DOMAIN,dc=DOMAIN,dc=DOMAIN",
"Time Skew",
"Skew: 30145 days, 2 hours, 20 minutes, 16 seconds"
],
"msg": "The time skew is over 24 hours. Setting nsslapd-ignore-time-skew\nto \"on\" on each replica will allow replication to continue, but if the\ntime skew continues to increase other serious replication problems can\noccur."
}
I was able to find mention of this method to correct time skew issues:https://www.port389.org/docs/389ds/howto/howto-fix-and-reset-time-... , but since we are now running on a single node with no replicas, I dont see how that would help. How is it even possible to have a skew in time between replicas if there are no replicas?
Thanks,
Kevin
8 months, 2 weeks
Restrict access in FreeIPA
by Ivan Nagornov
Hi all, just a small question about access control in FreeIPA which bomb my head around a few days:
- is there any possibility to restrict ACI permissions in FreeIPA to limit their impact to another groups/users?
We have a theoretical situation, let's suppose that we have the permission "Manage User Password", this permission included in privilege, than in Role and Role should be assigned.
When we assign this role to Account1, this account could change password for any user in this realm (let it be "freeipa.test.lab").
So, in details my question is - can we somehow limit permission for account1 to make this permission works only for target group of users? lets imagine that we have a branch and administrator in this branch which should change passwords only for users in this branch.
I know that another instance of FreeIPA and maybe trusts between these 2 instances could work, but firstly I wish to solve this task in the simple way.
Thanks in advance.
8 months, 2 weeks
Setting Max lifetime (days) global_policy password policy to 20000 causes LDAP authentication to fail with Error Code 49 Password Expired
by James Martin
All,
I just had a blip of downtime on some services recently caused by setting "Max lifetime (days)" password policy to 20000 while troubleshooting another much more minor issue. This caused services connecting to FreeIPA via LDAP to fail with error code 49, with an explanation of "Password Expired". Needless to say, none of our passwords are 20000 days old. Setting it back to 0, where it was before, solved this issue. Authentication via Kerberos or passworded SSH to enrolled hosts was unaffected. I did some searching on Pagure and couldn't find any issues like this, so I wanted to report it.
James
8 months, 2 weeks
