I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
1. Happens on RHEL/Centos only(other distros are not affected)
2. Happens only during the first attempted install of ipa-client package. If we try to reinstall the sshd.conf is not modified.3. We tried with --no-sshd flag to prevent sshd configuration
as suggested in the following ticket
[Freeipa-devel] [PATCH] 85 Add --no-ssh option to ipa-client-install to
We no longer get an messages in /var/log/ipaclientinstall.log about sshd.conf being backed up, BUT the file still gets changed.
on one of our FreeIPA servers we recently got the following error messages:
[05/Feb/2020:22:51:44.078229410 +0100] - ERR - write_function - PR_Write(392) Netscape Portable Runtime error -5999 (Invalid file descriptor.)
[21/Feb/2020:08:25:39.507298208 +0100] - ERR - write_function - PR_Write(273) Netscape Portable Runtime error -5999 (Invalid file descriptor.)
On the second incident, one of the other replicas shortly lost connection to the server with the above error:
[21/Feb/2020:08:25:39.619051486 +0100] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTolPA2" (IPA2:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()
[21/Feb/2020:08:25:43.220221699 +0100] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToIPA2" (IPA2:389): Replication bind with GSSAPI auth resumed
Does anyone know what these errors mean and if there's anything we should do about them? I tried searching for them, but came up with nothing. So far it seems it hasn't affected the operation of our FreeIPA infrastructure.
Thanks in advance for your help.
LCSB Bioinformatics Core & UL HPC Team
UNIVERSITÉ DU LUXEMBOURG
LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | Biotech II
6, avenue du Swing
T +352 46 66 44 5360
This message is confidential and may contain privileged information. It is intended for the named recipient only. If you receive it in error please notify me and permanently delete the original message and any copies.
It describes modification of the LDAP tree
Daniel E. White
NICS Linux Engineer
NASA Goddard Space Flight Center
8800 Greenbelt Road
Building 14, Room E175
Greenbelt, MD 20771
Office: (301) 286-6919
Mobile: (240) 513-5290
If SSSD has cache_credentials set to True it will take some time until
changes become visible on an IPA client. When I change sudo permissions
for a certain user I usually want to changes to be effective
immediately. Does this imply setting cache_credentials to False or what
are best practices here?
On pe, 28 helmi 2020, Ronald Wimmer wrote:
>For instance, I would like to set values for:
>default_shell = /bin/bash
No, there are no centralized settings like that.
There are settings managed as part of 'ipa config-mod', but out of those
SSSD picks up the following settings:
- whether migration mode is enabled,
- default SELinux user context and map order,
- domain resolution order, for trusted domains ('subdomains' in SSSD
Technically, SSSD also loads a host object specific to the host it runs
on, so there are some properties that can be exposed via this. For
example, ID View applied to the host is discovered this way and
FleetCommander integration (deskprofile) is retrieving rules in a
But nothing like this is implemented for a generic option support right
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
I would linke to reinstall a replica for my FreeIPA infra that has failed its ipa-server-upgrade after the updat'e of CentOS ipa-server-4.6.5-11.el7.centos.4.x86_64, a few days ago...
But everytime I try I get the following error on that machine :
[1/4]: Generating ipa-custodia config file
[2/4]: Generating ipa-custodia keys
[3/4]: starting ipa-custodia
[4/4]: configuring ipa-custodia to start on boot
Done configuring ipa-custodia.
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
[1/29]: creating certificate server db
[2/29]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 4 seconds elapsed
[3/29]: creating ACIs for admin
[4/29]: creating installation admin user
[5/29]: configuring certificate server instance
ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpjRZhjK' returned non-zero exit status 1
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.
ipapython.admintool: ERROR CA configuration failed.
ipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
I cannot find any relevant info in the logs to tell me what could be done...
Do you have an idea ?
Linux System Engineer
Rue Fivé 150, B-4100 Seraing
Ce message transmis par voie électronique ainsi que toutes ses annexes contiennent des informations qui peuvent être confidentielles ou protégées. Ces informations sont uniquement destinées à l'usage des personnes ou des entités précisées dans les champs 'A', 'Cc' et 'Cci'. Si vous n'êtes pas l'un de ces destinataires, soyez conscient que toute forme, partielle ou complète, de divulgation, copie, distribution ou utilisation de ces informations est strictement interdite. Si vous avez reçu ce message par erreur, veuillez nous en informer par téléphone ou par message électronique et détruire les informations immédiatement. Ce message n'engage que son signataire et aucunement son employeur.
I've been searching for resolution on this issue for a while now, but it seems all of the issues others have encountered were unrelated.
Host OS: CentOS 8.1.1911
All packages up to date.
This is a stock installation of freeipa, nothing tricky like replication or anything. The system authenticates fine, however when I went to add a host to it, for whatever reason the client got the hostname wrong, thus samba authentication wasn't working. I deleted the install on the client, and went to re-install, and it began asking for a password for the host. I never set one up to my knowledge. So, I went to delete the client host completely from the server, and that is where I got the above error.
I've examined 'getcert list', no error. I confirmed that all firewalls are (currently) off, and ports are open. I've examined all logs under /var/log/pki, and there's no errors that I could find. As far as I can tell, tomcat is working just fine, all certs are fine, but ipa is saying it cannot connect, getting a 403 forbidden error. Any insights would be helpful.