[Freeipa-users] ipa-setup-ca

2024-03-13 Thread Omar Pagan via FreeIPA-users 
Hey guys,
I finished installing two replicas of my master.  Both installations of the 
replicas completed successfully, but when I try to run the ipa-setup-ca it is 
having some issues.  

The errors I get are:
ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA instance
ipaserver.install.dogtaginstance: CRITICAL See the installation logs and the 
following files/directories for more information:
ipaserver.install.dogtaginstance: CRITICAL   /var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

But I don't see any issues in the /var/log/pki/pki-tomcat, or at least I can't 
find any "CRITICAL" errors.  Please advise on how to confirm that the master CA 
is working properly and perhaps how to get the 2 replicas to also help with the 
ca role.  Thanks
--
___
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: "Internal server error 'Link'" from ClonesConnectivyAndDataCheck health check on RHEL 8 when talking to RHEL 9 server

2024-03-13 Thread Sam Morris via FreeIPA-users 

On 12/03/2024 12:27, Rob Crittenden via FreeIPA-users wrote:

I guess the newer version of Dogtag in RHEL 9 doesn't include this
"Link" attribute, but pki.cert:CertDataInfoCollection.from_json in RHEL
8 expects it to be present.


Thanks for doing the research, this is great! Any chance you can file a
ticket against the "Red Hat Certificate System" project at
https://issues.redhat.com/ ? I don't own this particular check.


Done at https://issues.redhat.com/browse/RHEL-29137

Please check the component, it's definitely wrong but I don't know what 
the right value is.



I'd encourage you to run your entire topology on the same IPA release.
We recognize that this isn't always possible, or desirable immediately,
but the transition is hopefully kept short. I usually recommend weeks
not months.


Agreed, I'm way behind regarding getting my whole homelab running RHEL 
9... ;)


--
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
--
___
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: Failed FreeIPA replica installation

2024-03-13 Thread D S via FreeIPA-users 
Good call, thank you. Got rid of
failed request, will retry: 903 (an internal error has occurred).)
However, got this instead:
>[28/30]: importing IPA certificate profiles
>Lookup failed: Preferred host ipa-slave01.flora.ltfs.tools does not provide CA.
>Lookup failed: Preferred host ipa-slave01.flora.ltfs.tools does not provide CA.
>Failed to import profile 'acmeIPAServerCert': Request failed with status 500: 
>Non-2xx >response from CA REST API: 500. . Running ipa-server-upgrade when 
>installation is >completed may resolve this issue.
And still unable to login via web UI with the same
Login failed due to an unknown reason
error. I will dig into the logs for more details. 
--
___
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: Failed FreeIPA replica installation

2024-03-13 Thread Rob Crittenden via FreeIPA-users 
D S via FreeIPA-users wrote:
> And another update. Tried patching the file - still the same issue.
> Note: line 863 now has ca_kdc_check(self.api instead of ca_kdc_check(ldap
> [Wed Mar 13 19:07:28.353046 2024] [:error] [pid 13823]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 863, in 
> execute
> [Wed Mar 13 19:07:28.353048 2024] [:error] [pid 13823] 
> ca_kdc_check(self.api, alt_principal.hostname)
> [Wed Mar 13 19:07:28.353051 2024] [:error] [pid 13823]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 301, in 
> ca_kdc_check
> [Wed Mar 13 19:07:28.353053 2024] [:error] [pid 13823] master_dn = 
> api_instance.Object.server.get_dn(unicode(hostname))
> [Wed Mar 13 19:07:28.353055 2024] [:error] [pid 13823] AttributeError: 
> 'ldap2' object has no attribute 'Object'

Did you restart httpd after applying the change?

rob
--
___
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: Failed FreeIPA replica installation

2024-03-13 Thread D S via FreeIPA-users 
And another update. Tried patching the file - still the same issue.
Note: line 863 now has ca_kdc_check(self.api instead of ca_kdc_check(ldap
[Wed Mar 13 19:07:28.353046 2024] [:error] [pid 13823]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 863, in 
execute
[Wed Mar 13 19:07:28.353048 2024] [:error] [pid 13823] 
ca_kdc_check(self.api, alt_principal.hostname)
[Wed Mar 13 19:07:28.353051 2024] [:error] [pid 13823]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 301, in 
ca_kdc_check
[Wed Mar 13 19:07:28.353053 2024] [:error] [pid 13823] master_dn = 
api_instance.Object.server.get_dn(unicode(hostname))
[Wed Mar 13 19:07:28.353055 2024] [:error] [pid 13823] AttributeError: 'ldap2' 
object has no attribute 'Object'
--
___
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: Failed FreeIPA replica installation

2024-03-13 Thread D S via FreeIPA-users 
>Did you make any plugin changes?
Ok, you were right. I managed to fix ipa-replica-manage del command. 
Apparently, after I restored original .py files I needed to delete .pyc files 
as well. That fixed the error here.

As for AttributeError: 'ldap2' object has no attribute 'Object' - I applied 
this https://pagure.io/freeipa/issue/8686 patch since it is supposed to fix the
>PKINIT certificate request failed: Certificate issuance failed 
>(CA_UNREACHABLE: Server at >https:///ipa/json failed request, will retry: 903 
>(an internal error has >occurred).)
error.
 
--
___
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: Failed FreeIPA replica installation

2024-03-13 Thread D S via FreeIPA-users 
Hi Rob,
Thanks for your reply.
>what OS release are you using?
My master is running in docker container with freeipa-server:centos-7-4.6.8 and 
replica is freeipa-server:almalinux-8-4.9.12.

>I'd also look in the journal for certmonger to see if it logged additional 
>info about the request.
Here is all I can find in journalctl about that particular request

Mar 12 14:48:50 replica.example.com systemd[1]: Started The Apache HTTP Server.
Mar 12 14:48:50 replica.example.com httpd[3413]: Server configured, listening 
on: port 443, port 80
Mar 12 14:48:50 replica.example.com platform-python[299]: GSSAPI client step 1
Mar 12 14:48:50 replica.example.com platform-python[299]: GSSAPI client step 1
Mar 12 14:48:50 replica.example.com platform-python[299]: GSSAPI client step 1
Mar 12 14:48:50 replica.example.com platform-python[299]: GSSAPI client step 2
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[3685]: 2024-03-12 14:48:51 
[3685] error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[478]: 2024-03-12 14:48:51 [478] 
Wrote to /var/lib/certmonger/requests/20240312144851
Mar 12 14:48:51 replica.example.com certmonger[3686]: 2024-03-12 14:48:51 
[3686] Setting "CERTMONGER_REQ_SUBJECT" to 
"O=EXAMPLE.COM,cn=replica.example.com" for child.
Mar 12 14:48:51 replica.example.com certmonger[3686]: 2024-03-12 14:48:51 
[3686] Setting "CERTMONGER_REQ_HOSTNAME" to "replica.example.com" for child.
Mar 12 14:48:51 replica.example.com certmonger[3686]: 2024-03-12 14:48:51 
[3686] Setting "CERTMONGER_REQ_PRINCIPAL" to "krbtgt/example@example.com" 
for child.
Mar 12 14:48:51 replica.example.com certmonger[3686]: 2024-03-12 14:48:51 
[3686] Setting "CERTMONGER_OPERATION" to "SUBMIT" for child.
Mar 12 14:48:51 replica.example.com certmonger[3686]: 2024-03-12 14:48:51 
[3686] Setting "CERTMONGER_CSR" to "-BEGIN CERTIFICATE REQUEST-
Mar 12 14:48:51 replica.example.com certmonger[3686]: 
MIID3DCCAsQCAQAwQjEZMBcGA1UECgwQRkxPUkEuTFRGUy5UT09MUzElMCMGA1UE
Mar 12 14:48:51 replica.example.com certmonger[3686]: 
AxMcaXBhLXNsYXZlMDEuZmxvcmEubHRmcy50b29sczCCASIwDQYJKoZIhvcNAQEB
Mar 12 14:48:51 replica.example.com certmonger[3686]: 
BQADggEPADCCAQoCggEBAPRUIp5MLhpT5+vBdM3Gxt5IdVBJHlfu6uIfSK3HJcsb
Mar 12 14:48:51 replica.example.com certmonger[3686]: 
rjRdh6jPmo/WTPsnEKVQtBpy6UQVK6CGmjUX3gc+TeZ/XWYFk08Nl+C2QCPYzyp7
Mar 12 14:48:51 replica.example.com certmonger[3686]: 
0/RorK2sx0wcUN4LVQTtXalGPpUn+TZgO7w40VqwYRAa/cJt5jGOljE2V7tVpJXF
Mar 12 14:48:51 replica.example.com certmonger[3686]: 
qsE2AaTc+vGl2xwUlgFj0/lAYsJZvv3prnkHk2ZHtuUEhNyc7HfXCjnzkCToj1gm
Mar 12 14:48:51 replica.example.com certmonger[3686]: 
FlQdgGxfmbyAMSWjiz6mRDJq0XJgoAoqSs7u+IOny0v+27jJu2eobPTNPMav2hlo
Mar 12 14:48:51 replica.example.com certmonger[3686]:

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-13 Thread Ian Kumlien via FreeIPA-users 
On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud  wrote:
>
> Hi,
>
> On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien  wrote:
>>
>> On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud  
>> wrote:
>> >
>> > Hi,
>> >
>> > On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users 
>> >  wrote:
>> >>
>> >> Hi,
>> >>
>> >> So i have spent quite some time trying to get out of the swamp that is
>> >> centos stream 8 and back to something with a actual upgrade path,
>> >> fedora =)
>> >>
>> >> Everything works except the ipa-ca-install on the replica - mostly
>> >> fails at the same step
>> >>
>> >> At some point the conncheck failed, dropping me in to a prompt asking
>> >> for the password of a admin- account
>> >>
>> >> Anyway, I do know about the issue with - vs _ and validated on master,
>> >> changed on replica as detailed here:
>> >> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
>> >>
>> >> But it still fails..
>> >>
>> >> Oh and btw, none of the machines are running any firewalls =)
>> >>
>> >> Anyone that has a clue of what to test next?
>> >>
>> >> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
>> >>
>> >> ipa-ca-install --skip-conncheck
>> >> Directory Manager (existing master) password:
>> >>
>> >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>> >>   [1/28]: creating certificate server db
>> >>   [2/28]: setting up initial replication
>> >> Starting replication, please wait until this has completed.
>> >> Update in progress, 7 seconds elapsed
>> >> Update succeeded
>> >>
>> >>   [3/28]: creating ACIs for admin
>> >>   [4/28]: creating installation admin user
>> >> ipaserver.install.dogtaginstance: ERRORUnable to log in as
>> >> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
>> >> ldap://freeipa-1.xerces.lan:389
>> >>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>> >> did not replicate to ldap://freeipa-1.xerces.lan:389
>> >>
>> >> Your system may be partly configured.
>> >> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>> >>
>> >> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
>> >> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
>> >> replicate to ldap://freeipa-1.xerces.lan:389
>> >>
>> > The installation of a CA clone creates this user on the replica, lets the 
>> > replication copy the entry on the master and then checks by doing a ldap 
>> > bind from the replica to the master that the entry has been properly 
>> > replicated.
>> > When this error happens, it can either mean that the entry was not 
>> > replicated or that the bind failed.
>> >
>> > In order to know exactly what is happening for you, you can check
>> > - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and 
>> > check if it exists. If the entry is present, the replication properly 
>> > propagated the entry from replica to master and you are probably hitting 
>> > the 2nd issue.
>> > # ldapsearch -D "cn=directory manager" -W -b 
>> > uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>> >
>> > - on the replica, do a ldapsearch for this entry and check the 
>> > userpassword attribute. It is base64-encoded, and you can decode it in 
>> > order to find the password storage scheme that was used to encrypt the 
>> > password.
>> > For instance on my machine:
>> >
>> > dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
>> > userPassword:: 
>> > e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
>> >  
>> > NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
>> >  
>> > dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
>> >  
>> > 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
>> >  
>> > pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
>> >  
>> > wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
>> >  
>> > ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
>> >  2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>> >
>> >
>> > If I base64 decode the value:
>> >
>> > # echo 
>> > e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>> >  | base64 -d
>> >

[Freeipa-users] Re: ipa-getcert request results in CA_REJECTED, on an enrolled host

2024-03-13 Thread Alexander Bokovoy via FreeIPA-users 

On Срд, 13 сак 2024, Bo Lind via FreeIPA-users wrote:

Update!

Our organisation has four IPA servers. I tried to edit
/etc/ipa/default.conf, to point at a different one. Server two didn't
work either, but server three did!


Perhaps some of those are RHEL9?

See https://access.redhat.com/articles/7046409 for some details on what
you are seeing. It also explains what should be done and in which order.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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: Failed FreeIPA replica installation

2024-03-13 Thread Rob Crittenden via FreeIPA-users 
D S via FreeIPA-users wrote:
> Hello, I've encountered several issues while installing freeipa replica.
> 
> I have freeipa 4.6.8 master and the replica I tried installing is 4.9.12. 

Rather than focusing on the versions, what OS release are you using?
There are known crypto incompatibilities between RHEL 7 and RHEL 9, for
example, such that you can't go directly between them.

> During the replica install it seems that the replica is unable to get a CA 
> cert from my master:
> 
> DEBUG Configuring Kerberos KDC (krb5kdc)
> DEBUG   [1/1]: installing X509 Certificate for PKINIT
> DEBUG flushing ldapi://%2Frun%2Fslapd-[REDACTED].socket from SchemaCache
> DEBUG retrieving schema for SchemaCache 
> url=ldapi://%2Frun%2Fslapd-[REDACTED].socket 
> conn=
> DEBUG certmonger request is in state 'NEWLY_ADDED_READING_KEYINFO'
> DEBUG certmonger request is in state 'SUBMITTING'
> DEBUG certmonger request is in state 'CA_UNREACHABLE'
> DEBUG Cert request 20240312144851 failed: CA_UNREACHABLE (Server at 
> https://[REDACTED]/ipa/json failed request, will retry: 903 (an internal 
> error has occurred).)
> DEBUG Giving up on cert request 20240312144851
> WARNING PKINIT certificate request failed: Certificate issuance failed 
> (CA_UNREACHABLE: Server at https://[REDACTED]/ipa/json failed request, will 
> retry: 903 (an internal error has occurred).)
> WARNING Failed to configure PKINIT
> DEBUG Full PKINIT configuration did not succeed
> DEBUG The setup will only install bits essential to the server functionality
> DEBUG You can enable PKINIT after the setup completed using 
> 'ipa-pkinit-manage'
> DEBUG certmonger request is in state 'GENERATING_CSR'
> DEBUG certmonger request is in state 'MONITORING'
> DEBUG Cert request 20240312144853 was successful
> DEBUG step duration: krb5kdc setup_pkinit 2.72 sec
> DEBUG Done configuring Kerberos KDC (krb5kdc).
> 
> (However the the installation succeeds with INFO The ipa-replica-install 
> command was successful)

A failed PKINIT cert request is not considered fatal because a
self-signed one is issued in this case. I'd also look in the journal for
certmonger to see if it logged additional info about the request.

> 
> On master in /var/log/httpd/error_log:
> 
> ipa: ERROR: non-public: AttributeError: 'ldap2' object has no attribute 
> 'Object'
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 369, in 
> wsgi_execute
>  result = command(*args, **options)
>File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 450, in 
> __call__
>  return self.__do_call(*args, **options)
>File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in 
> __do_call
>  ret = self.run(*args, **options)
>File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in 
> run
>  return self.execute(*args, **options)
>File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 
> 863, in execute
>  ca_kdc_check(ldap, alt_principal.hostname)
>File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 
> 301, in ca_kdc_check
>  master_dn = api_instance.Object.server.get_dn(unicode(hostname))
>  AttributeError: 'ldap2' object has no attribute 'Object'
>  ipa: INFO: [jsonserver_kerb] host/ipa-replica01.[REDACTED]@[REDACTED]: 
> cert_request(u'MIID3DCCAsQCAQAwQjEZMBcGA1UECgwQRkxPUkEuTFRGUy5UT09MUzElMCMGA1UEAxMcaXBhLXNsYXZlMDEuZmxvcmEubHRmcy50b29sczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANhiTu7x/3sRCBq0spuBM1M2dkAzfMFEtJRx/BUcDi7PrRhJBa+w2o+XfOjtP9YFYpnOYbqV6eNlslGuYbHYIZX5D4lawvcT+IfqBaeWAz3ZRyK+nFVotMm+BRHNeUFse3OUL2kGPLRgXZQ1wdzE+V17rTRtPHDV9cs0ERjTjMyntM24zYxWicrdsoFfwF/BJQRXVO+GZDdhJcmNvCcxywaUD8C/y9TYYLwhFdIRYFmOHvTHJwabPt5/QM8EkrAfkpCHypwf6oz7xvyiqnRFyx5okWexHqE1xXHbvMS+pjd2eNBl4n38H+hbdb83wJFS64M9zerlhU/u5h4cbY0WdIJtOz2dP7A3NvQL0X5oF10ivWYw5+Rbar8h6nCr07ApVku6m5kXePp6rK3c0f+IORxflJFEdRGBG7zBbE1Dt4Kf5Q+uTwiEjN2wEre1s6CFg8oTipncOwHkyettAplFisitfdxs4HlEZpsN3kxh6NQDFAhx4JE1WNGMPVZNKuBz6tHhMwgpDDXS16UjIXZqYllUDnBaf5GdawCgWr2wbXEaUflgOWje/QyvZkYVsHZzUFw9Bqh8B7jxw7h/4KAM43XBDWN9P6J2+gqp2M3SQ=',
>  profile_id=u'KDCs_PKINIT_Certs', principal=u'krbtgt/[REDACTED]@[REDACTED]', 
> add=True): InternalError
> 
> That's the issue number one. Number two is that I can't login into web UI of 
> my replica - it gives me "Login failed due to an unknown reason" error. From 
> /var/log/httpd/error_log:
> 
> [auth_gssapi:error] GSS ERROR gss_acquire_cred[_from]() failed to get server 
> creds: [Unspecified GSS failure.  Minor code may provide more information ( 
> SPNEGO cannot find mechanisms to negotiate)]
> [wsgi:error] ipa: INFO: 401 Unauthorized: No session cookie found

Newer IPA requires that every user have a SID. I'm guessing this is related.

> 
> Finally, my third issue is that I can't remove replica from my master. 
> ipa-replica-manage del --force --cleanup fails with:
> 
> Traceback (most recent call last):
>   File "/usr/sbin/ipa-replica-manage", line

[Freeipa-users] Re: Number of concurrent connections are decreased by replication.

2024-03-13 Thread Rob Crittenden via FreeIPA-users 
seojeong kim via FreeIPA-users wrote:
> Hello Rob 
> As you said, If  any group member exceed 3K then you can experience slow down 
> in server response. 
> But in the big size of operation environment, members( especially the number 
> of hosts) exceeding 3k is not that uncommon. 
> So, I wonder if there is any way you recommend to manage  this case  such as  
> you split up into several  groups internally, or disable some configurations. 
> If there is no reference or guide from IPA about that, I have no option but 
> to face slow-down performance issue ?

We consider an API call to be "slow" if it takes > 2s. At 3k a group
adding a new member tends to exceed that. Not by a lot but the more
members, the slower it gets. I didn't test member removal from a group >
3k but its likely to be similar.

I also didn't test absolutely massive groups. I was only looking to find
out where adding a new member exceeded 3s. So I have no graphs on the
rate at which adding a new member slows.

Splitting groups using nesting results in the same problem. The
underlying issue is the memberof plugin in 389-ds which calculates the
membership. There is no getting around it.

Work is happening to address the known performance issues but I'm not
doing the work and have no insight into their progress. All I know is
that it's a hard nut to crack.

Currently there are no known mitigations.

rob
--
___
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: Using ipa-ca-install on a replica

2024-03-13 Thread Florence Blanc-Renaud via FreeIPA-users 
Hi,

On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien  wrote:

> On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud 
> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> >>
> >> Hi,
> >>
> >> So i have spent quite some time trying to get out of the swamp that is
> >> centos stream 8 and back to something with a actual upgrade path,
> >> fedora =)
> >>
> >> Everything works except the ipa-ca-install on the replica - mostly
> >> fails at the same step
> >>
> >> At some point the conncheck failed, dropping me in to a prompt asking
> >> for the password of a admin- account
> >>
> >> Anyway, I do know about the issue with - vs _ and validated on master,
> >> changed on replica as detailed here:
> >>
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
> >>
> >> But it still fails..
> >>
> >> Oh and btw, none of the machines are running any firewalls =)
> >>
> >> Anyone that has a clue of what to test next?
> >>
> >> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
> >>
> >> ipa-ca-install --skip-conncheck
> >> Directory Manager (existing master) password:
> >>
> >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
> >>   [1/28]: creating certificate server db
> >>   [2/28]: setting up initial replication
> >> Starting replication, please wait until this has completed.
> >> Update in progress, 7 seconds elapsed
> >> Update succeeded
> >>
> >>   [3/28]: creating ACIs for admin
> >>   [4/28]: creating installation admin user
> >> ipaserver.install.dogtaginstance: ERRORUnable to log in as
> >> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
> >> ldap://freeipa-1.xerces.lan:389
> >>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> >> did not replicate to ldap://freeipa-1.xerces.lan:389
> >>
> >> Your system may be partly configured.
> >> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> >>
> >> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
> >> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
> >> replicate to ldap://freeipa-1.xerces.lan:389
> >>
> > The installation of a CA clone creates this user on the replica, lets
> the replication copy the entry on the master and then checks by doing a
> ldap bind from the replica to the master that the entry has been properly
> replicated.
> > When this error happens, it can either mean that the entry was not
> replicated or that the bind failed.
> >
> > In order to know exactly what is happening for you, you can check
> > - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and
> check if it exists. If the entry is present, the replication properly
> propagated the entry from replica to master and you are probably hitting
> the 2nd issue.
> > # ldapsearch -D "cn=directory manager" -W -b
> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> >
> > - on the replica, do a ldapsearch for this entry and check the
> userpassword attribute. It is base64-encoded, and you can decode it in
> order to find the password storage scheme that was used to encrypt the
> password.
> > For instance on my machine:
> >
> > dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
> > userPassword::
> e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
> >
> NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
> >
> dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
> >
> 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
> >
> pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
> >
> wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
> >
> ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
> >  2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
> >
> >
> > If I base64 decode the value:
> >
> > # echo
> e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
> | base64 -d
> >
>

[Freeipa-users] Re: ipa-getcert request results in CA_REJECTED, on an enrolled host

2024-03-13 Thread Bo Lind via FreeIPA-users 
Update!

Our organisation has four IPA servers. I tried to edit /etc/ipa/default.conf, 
to point at a different one. Server two didn't work either, but server three 
did!
--
___
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-getcert request results in CA_REJECTED, on an enrolled host

2024-03-13 Thread Bo Lind via FreeIPA-users 
I don't get very far. Step one is non-existant, I never get the AS_REQ, even 
going back several days in the log.

For step two, I get:

Mar 13 10:51:29 idm0.example.local krb5kdc[1704](info): TGS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 192.168.37.50: 
S4U2PROXY_MISSING_EXTENDED_KDC_SIGN_IN_EVIDENCE_TKT_PAC: authtime 1710323487, 
etypes {rep=UNSUPPORTED:(0)} HTTP/idm0.example.local@EXAMPLE.LOCAL for 
ldap/idm0.example.local@EXAMPLE.LOCAL, KDC policy rejects request
Mar 13 10:51:29 idm0.example.local krb5kdc[1704](info): ... 
CONSTRAINED-DELEGATION s4u-client=
Mar 13 10:51:29 idm0.example.local krb5kdc[1704](info): closing down fd 4

(I know that naughtyhost.example.local is not mentioned in the entry, but it 
happened as I attempted the request; I watched the log in realtime.)

And, obviously, we never get step three and four either.

Thanks for your continuous help, by the way!
--
___
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-getcert request results in CA_REJECTED, on an enrolled host

2024-03-13 Thread Alexander Bokovoy via FreeIPA-users 

On Аўт, 12 сак 2024, Bo Lind via FreeIPA-users wrote:

root@naughtyhost:~# ipa host-show --all --raw naughtyhost|grep -i canon
 krbcanonicalname: host/naughtyhost.example.local@EXAMPLE.LOCAL

Looks like that part is in order...? Does the capitalization matter?


It does.

When you attempt to do that request, what do you see in the
/var/log/krb5kdc.log on the IPA server, related to requests from this
host?

Typically you'd see something like the sequence below. I am using
'master2.ipa2.test' which is an IPA server in itself as an example here,
but for your case host/master2.ipa2.test would be
host/naughtyhost.example.local and it would talk to your IPA server:

1. Get TGT using the host keytab:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: 
NEEDED_PREAUTH: host/master2.ipa2.t...@ipa2.test for 
krbtgt/ipa2.t...@ipa2.test, Additional pre-authentication required
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, 
host/master2.ipa2.t...@ipa2.test for krbtgt/ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

2. Request a service ticket to IPA API:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): TGS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, 
host/master2.ipa2.t...@ipa2.test for HTTP/master2.ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

3. IPA API needs to talk to LDAP server so it needs own TGT ticket
first:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548788](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: 
NEEDED_PREAUTH: HTTP/master2.ipa2.t...@ipa2.test for 
krbtgt/ipa2.t...@ipa2.test, Additional pre-authentication required
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548788](info): closing down fd 11
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, 
HTTP/master2.ipa2.t...@ipa2.test for krbtgt/ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

4. And then asks for a service ticket to LDAP service on behalf of the
original Kerberos client (host requesting an operation):
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): TGS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha384-192(20)}, 
HTTP/master2.ipa2.t...@ipa2.test for ldap/master2.ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): ... 
CONSTRAINED-DELEGATION s4u-client=host/master2.ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

If you'd see any breakage in those steps, show the log.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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: Using ipa-ca-install on a replica

2024-03-13 Thread Ian Kumlien via FreeIPA-users 
On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud  wrote:
>
> Hi,
>
> On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users 
>  wrote:
>>
>> Hi,
>>
>> So i have spent quite some time trying to get out of the swamp that is
>> centos stream 8 and back to something with a actual upgrade path,
>> fedora =)
>>
>> Everything works except the ipa-ca-install on the replica - mostly
>> fails at the same step
>>
>> At some point the conncheck failed, dropping me in to a prompt asking
>> for the password of a admin- account
>>
>> Anyway, I do know about the issue with - vs _ and validated on master,
>> changed on replica as detailed here:
>> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
>>
>> But it still fails..
>>
>> Oh and btw, none of the machines are running any firewalls =)
>>
>> Anyone that has a clue of what to test next?
>>
>> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
>>
>> ipa-ca-install --skip-conncheck
>> Directory Manager (existing master) password:
>>
>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>>   [1/28]: creating certificate server db
>>   [2/28]: setting up initial replication
>> Starting replication, please wait until this has completed.
>> Update in progress, 7 seconds elapsed
>> Update succeeded
>>
>>   [3/28]: creating ACIs for admin
>>   [4/28]: creating installation admin user
>> ipaserver.install.dogtaginstance: ERRORUnable to log in as
>> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
>> ldap://freeipa-1.xerces.lan:389
>>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>> did not replicate to ldap://freeipa-1.xerces.lan:389
>>
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
>> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
>> replicate to ldap://freeipa-1.xerces.lan:389
>>
> The installation of a CA clone creates this user on the replica, lets the 
> replication copy the entry on the master and then checks by doing a ldap bind 
> from the replica to the master that the entry has been properly replicated.
> When this error happens, it can either mean that the entry was not replicated 
> or that the bind failed.
>
> In order to know exactly what is happening for you, you can check
> - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and 
> check if it exists. If the entry is present, the replication properly 
> propagated the entry from replica to master and you are probably hitting the 
> 2nd issue.
> # ldapsearch -D "cn=directory manager" -W -b 
> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>
> - on the replica, do a ldapsearch for this entry and check the userpassword 
> attribute. It is base64-encoded, and you can decode it in order to find the 
> password storage scheme that was used to encrypt the password.
> For instance on my machine:
>
> dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
> userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
>  NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
>  dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
>  055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
>  pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
>  wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
>  ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
>  2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>
>
> If I base64 decode the value:
>
> # echo 
> e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>  | base64 -d
> {PBKDF2_SHA256}AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai

Yes, and the value is the same on both replicas, both the encoded
base64 and the password scheme:

[Freeipa-users] Re: ipa-getcert request results in CA_REJECTED, on an enrolled host

2024-03-13 Thread Bo Lind via FreeIPA-users 
Just updated the machine to newest Rocky Linux 8.9 and rebooted, problem 
persists...
--
___
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] Failed FreeIPA replica installation

2024-03-13 Thread D S via FreeIPA-users 
Hello, I've encountered several issues while installing freeipa replica.

I have freeipa 4.6.8 master and the replica I tried installing is 4.9.12. 

During the replica install it seems that the replica is unable to get a CA cert 
from my master:

DEBUG Configuring Kerberos KDC (krb5kdc)
DEBUG   [1/1]: installing X509 Certificate for PKINIT
DEBUG flushing ldapi://%2Frun%2Fslapd-[REDACTED].socket from SchemaCache
DEBUG retrieving schema for SchemaCache 
url=ldapi://%2Frun%2Fslapd-[REDACTED].socket 
conn=
DEBUG certmonger request is in state 'NEWLY_ADDED_READING_KEYINFO'
DEBUG certmonger request is in state 'SUBMITTING'
DEBUG certmonger request is in state 'CA_UNREACHABLE'
DEBUG Cert request 20240312144851 failed: CA_UNREACHABLE (Server at 
https://[REDACTED]/ipa/json failed request, will retry: 903 (an internal error 
has occurred).)
DEBUG Giving up on cert request 20240312144851
WARNING PKINIT certificate request failed: Certificate issuance failed 
(CA_UNREACHABLE: Server at https://[REDACTED]/ipa/json failed request, will 
retry: 903 (an internal error has occurred).)
WARNING Failed to configure PKINIT
DEBUG Full PKINIT configuration did not succeed
DEBUG The setup will only install bits essential to the server functionality
DEBUG You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
DEBUG certmonger request is in state 'GENERATING_CSR'
DEBUG certmonger request is in state 'MONITORING'
DEBUG Cert request 20240312144853 was successful
DEBUG step duration: krb5kdc setup_pkinit 2.72 sec
DEBUG Done configuring Kerberos KDC (krb5kdc).

(However the the installation succeeds with INFO The ipa-replica-install 
command was successful)


On master in /var/log/httpd/error_log:

ipa: ERROR: non-public: AttributeError: 'ldap2' object has no attribute 'Object'
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 369, in 
wsgi_execute
 result = command(*args, **options)
   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 450, in 
__call__
 return self.__do_call(*args, **options)
   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in 
__do_call
 ret = self.run(*args, **options)
   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run
 return self.execute(*args, **options)
   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 863, 
in execute
 ca_kdc_check(ldap, alt_principal.hostname)
   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 301, 
in ca_kdc_check
 master_dn = api_instance.Object.server.get_dn(unicode(hostname))
 AttributeError: 'ldap2' object has no attribute 'Object'
 ipa: INFO: [jsonserver_kerb] host/ipa-replica01.[REDACTED]@[REDACTED]: 
cert_request(u'MIID3DCCAsQCAQAwQjEZMBcGA1UECgwQRkxPUkEuTFRGUy5UT09MUzElMCMGA1UEAxMcaXBhLXNsYXZlMDEuZmxvcmEubHRmcy50b29sczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANhiTu7x/3sRCBq0spuBM1M2dkAzfMFEtJRx/BUcDi7PrRhJBa+w2o+XfOjtP9YFYpnOYbqV6eNlslGuYbHYIZX5D4lawvcT+IfqBaeWAz3ZRyK+nFVotMm+BRHNeUFse3OUL2kGPLRgXZQ1wdzE+V17rTRtPHDV9cs0ERjTjMyntM24zYxWicrdsoFfwF/BJQRXVO+GZDdhJcmNvCcxywaUD8C/y9TYYLwhFdIRYFmOHvTHJwabPt5/QM8EkrAfkpCHypwf6oz7xvyiqnRFyx5okWexHqE1xXHbvMS+pjd2eNBl4n38H+hbdb83wJFS64M9zerlhU/u5h4cbY0WdIJtOz2dP7A3NvQL0X5oF10ivWYw5+Rbar8h6nCr07ApVku6m5kXePp6rK3c0f+IORxflJFEdRGBG7zBbE1Dt4Kf5Q+uTwiEjN2wEre1s6CFg8oTipncOwHkyettAplFisitfdxs4HlEZpsN3kxh6NQDFAhx4JE1WNGMPVZNKuBz6tHhMwgpDDXS16UjIXZqYllUDnBaf5GdawCgWr2wbXEaUflgOWje/QyvZkYVsHZzUFw9Bqh8B7jxw7h/4KAM43XBDWN9P6J2+gqp2M3SQ=',
 profile_id=u'KDCs_PKINIT_Certs', principal=u'krbtgt/[REDACTED]@[REDACTED]', 
add=True): InternalError

That's the issue number one. Number two is that I can't login into web UI of my 
replica - it gives me "Login failed due to an unknown reason" error. From 
/var/log/httpd/error_log:

[auth_gssapi:error] GSS ERROR gss_acquire_cred[_from]() failed to get server 
creds: [Unspecified GSS failure.  Minor code may provide more information ( 
SPNEGO cannot find mechanisms to negotiate)]
[wsgi:error] ipa: INFO: 401 Unauthorized: No session cookie found


Finally, my third issue is that I can't remove replica from my master. 
ipa-replica-manage del --force --cleanup fails with:

Traceback (most recent call last):
  File "/usr/sbin/ipa-replica-manage", line 1624, in 
main(options, args)
  File "/usr/sbin/ipa-replica-manage", line 1524, in main
api.finalize()
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 740, in 
finalize
self.__do_if_not_done('load_plugins')
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 431, in 
__do_if_not_done
getattr(self, name)()
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 620, in 
load_plugins
self.add_package(package)
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 658, in 
add_package
self.add_module(module)
  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 675, in

[Freeipa-users] Re: Number of concurrent connections are decreased by replication.

2024-03-13 Thread seojeong kim via FreeIPA-users 
Hello Rob 
As you said, If  any group member exceed 3K then you can experience slow down 
in server response. 
But in the big size of operation environment, members( especially the number of 
hosts) exceeding 3k is not that uncommon. 
So, I wonder if there is any way you recommend to manage  this case  such as  
you split up into several  groups internally, or disable some configurations. 
If there is no reference or guide from IPA about that, I have no option but to 
face slow-down performance 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