Thanks again for the reply :)
Short update from my side: turns out it was indeed my upgrade path that was causing
issues. I just managed to join my 4.9 client to a 4.10 server without issues. Rather than
restoring a 4.9 backup to a 4.10 server (which is unsupported, as it turns out), I
restored the backup to a clean server with the exact same version, and then upgraded the
OS (rocky) from 8 to 9, which came with a ipa-server upgrade to 4.10. My next move will be
to see if I can replicate this to a clean Rocky 9.
I didn't chase down what the actual error was, since I was doing strange things anway
:)
Peter
________________________________________
From: Rob Crittenden <rcritten(a)redhat.com>
Sent: Friday, 15 March 2024 18:57
To: FreeIPA users list
Cc: Kroon PC, Peter
Subject: Re: [Freeipa-users] Re: Cannot enroll a 4.9 client to 4.10 server fails with
PrincipalName not found
Kroon PC, Peter via FreeIPA-users wrote:
> Thanks for the super fast reply! I'll do my best to reply in-line, but I'm
bound to outlook, which doesn't like it too much.
>
>>> Hi all!
>>>
>>> I'm working on updating my freeipa server from rocky 8 to 9. I'm
playing around with a virtual machines as playground server and client, since I'd
rather not break my everything right away. As part of this, I first installed ipa-server
version 4.10.2-8.el9_3 on the server. Then I did an ipa-restore with a backup from my
production ipa server (rocky 8, 4.9.12-11.module+el8.9.0+1652+4ee71f6a), followed by an
ipa-server-upgrade. All is well so far (I think).
>
>> I don't know how you achieved this. ipa-restore attempts to prevent
>> using restore as a backdoor upgrade mechanism.
>
> It didn't complain /too/ much honestly. It saw the version mismatch between the
backup and the installed server, asked for a "yes", and then happily went on its
way. Is there a better way to achieve what I want/need?
Create a replica and disconnect it from the topology to have a
sandbox.
>>> The client is running Debian bookworm with backports,
where the latest ipa-client version is 4.9.11-1. Then, I went with the usual
ipa-client-install --no-ntp, which fails with "Joining realm failed: Failed to parse
result: PrincipalName not found." after retrieving the CA cert.
>>> The logs don't tell me much more, but the --debug flag does. It
negotiates a JSON-RPC response, in which it says '{... "principal":
"admin(a)EXAMPLE.COM", ...}'. I note that principal != PrincipalName. Also
note, that on the server, the host /is/ added.
>>>
>>> So I guess my question is: how much version skew between server and client is
supported?
>
>> Plenty. There isn't much to client enrollment and the API hasn't changed
>> significantly in a long time.
>
> Ok. Is there any other place I can look for what's going wrong?
The server httpd error log should have something about the request as
well as the client install log.
To get more details on the server side you can create
/etc/ipa/server.conf with the contents:
[global]
debug = True
Then restart httpd. Warning, it can be very verbose so I wouldn't
leave
it like that for long in production.
rob