Multiple http services on one host
by Anonymous
I want to authenticate to cockpit with kerberos. Some of the servers however have other services running on the http service in freeipa. Freeipa is also an example. What is the proper way that I can have kerberos authentication on cockpit running on freeipa master and replica servers? I know that I can create a service called cockpit/master.domain.com but from what I've been told, or at least I've understood for kerberos to function the service needs to be HTTP/master.domain.com
1 year, 1 month
Group permission problem
by Ronald Wimmer
I do have a file ztestfile created with user_a:somegroup with mode 660.
If I open this particular file with user_b who belongs to the same group
in vim I get "E212 - can't open file for writing".
user_a is an IPA user
user_b is an AD user
somegroup is an IPA posix group that hols an external (AD) group there
user_b is a member of
Both users as well as the group are resolved properly.
We do have ignore_group_members set to true.
I tried echo "asdf" >> ztestfile. That surprisingly worked on an IPA
client but did not on an IPA server.
What could be the problem here? Where would I see more?
Cheers,
Ronald
1 year, 1 month
Need Help - CA_UNREACHABLE
by Justin Sanderson
THANKS IN ADVANCE FOR ANY HELP INFO YOU CAN PROVIDE!!
Greatly Appreciate!!
Ok. So after doing a LOT of reading and learning about FreeIPA the past
2 days (yep, I inherited), I was able to fix my problem of pki-tomcatd
(DogTAG i think its called) so that it would start.
The pki-tomcatd service wouldn't start due to some cert issues. I was
fortunate enough to figure out how to enable BasicAuth for now to get
the service to start.. so thats a win.
My SETUP:
I have a single server instance as a VM. There are no replicas.
The FreeIPA configuration is:
1) No DNS BIND server - using external DNS via AD in /etc/resolv.conf
2) We ARE running all other services
3) Self-Signed CA configuration using DogTag i think its called. there
are not external certs being used.
ipactl start has no issues now after I fixed the pki-tomcatd start
problem using BasicAuth (workaround)
PROBLEM :
When i run "getcert list" I have 3 that have status CA_UNREACHABLE and
ALL of them are related to /etc/pki/pki-tomcat/alias NSSDB.
They are set to expire in a few weeks so I need to figure this out..
needing some help.
The getcert list outputs a total of 9 or 10 certs so I don't think I'm
missing anything.. Based off what I was able to find, it's common to
have 8-10 certs in the output...?
Below are 2 of 3 certs that are going to expire soon and their CA is in
an UNREACHABLE state. They all use the same NSSDB
**I have no idea where to start looking to fix this problem... which log
file... how is it supposed to talk to the NSSDB. it's not a socket...? **
I'm worried that the certs will expire and I won't know how to fix it.
or where to even look. HELP*!*!
I've seen several people posting already about certmonger not
succesfully tracking/renewing some certs so Im a bit concerned
espicially since the CA_UNREAHABLE error.
How do I fix this:
1) manually generate new certs and wth do I put them?
2) why is the CA_UNREACHABLE on a NSSDB ..? The files are there and
intact. I can view the contents no prob.
============ getcert list output ============================
Request ID '20190621200128':
status: CA_UNREACHABLE
ca-error: Internal error
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS FIPS 140-2 Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS FIPS 140-2 Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=[SANITIZED DNS NAME]
subject: CN=CA Audit,O=[SANITIZED DNS NAME]
expires: 2023-05-04 12:52:47 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20190621200129':
status: CA_UNREACHABLE
ca-error: Internal error
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS FIPS 140-2 Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS FIPS 140-2 Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=[SANITIZED DNS NAME]
subject: CN=OCSP Subsystem,O=[SANITIZED DNS NAME]
expires: 2023-05-04 12:53:17 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
===================================================================================================================================
1 year, 1 month
Ansible FreeIPA Server + Replica
by Finn Fysj
Hi,
I'm new to FreeIPA and the ansible-freeipa collection.
I can successfully install IPA server using the role ipaserver. However, I want to setup a multi-master replication with failover.
As far as I know I need to install ipaserver on all of my masters/replication and then the replica role?
How does the master nodes establish a relationship? Is this done using IPA client?
It might seem weird, but my goal is to setup the IPA server purely as a LDAP server using external CA.
This is because we want to have the ability to have a user interface like the web gui.
1 year, 1 month
Littered /run/ipa/ccaches directory probably causing outage of ipa API
by terrible person
Hi everyone!
We've been experiencing some issues with our FreeIPA setup for the past few months. First of all:
Our package versions are:
ipa-client-common-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
ipa-common-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
ipa-client-4.9.8-7.module_el8.6.0+1103+a004f6a8.x86_64
ipa-server-4.9.8-7.module_el8.6.0+1103+a004f6a8.x86_64
ipa-client-epn-4.9.8-7.module_el8.6.0+1103+a004f6a8.x86_64
ipa-server-common-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
ipa-server-dns-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
We are running a peculiar containerized environment based on the CentOS 8 image.
Specifically, we've been having trouble accessing the FreeIPA API and performing web UI logins, which we suspect is due to the /run/ipa/ccaches directory becoming littered with too many files. For example, on one of the troubled servers, we ran the command:
[root@ipa-server /]# ls -l /run/ipa/ccaches/ | wc -l
174314
We've already tried deleting files in the directory, but the problem persists. The errors we're seeing are something like this:
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (69206018): gss_display_status call returned failure (major 327680, minor 100007). Decoding code: 69206018
Or this:
ipa: ERROR: No valid Negotiate header in server response
I tried looking up the code of mod_auth_gssapi to find the probable cause, but to no effect. I need help with this. First of all, shouldn't the STs in GssapiDelegCcacheDir be deleted by the module? For now the only solution is the container restart which is equivalent to the "ipactl restart" I guess.
I'm interested in learning more about how mod_auth_gssapi is handling ST deletion and what might be causing it to fail in general. If anyone has any insights or suggestions, we would greatly appreciate it.
1 year, 1 month
Proper way to update options on existing certificate
by Shawn Asmussen
Our organization has a large number of existing certificates that we want to make modifications to the options for. Specifically, we have certificates used by a couple of different services, that we want to add in a service restart when the certificate auto-renews, and we also have a lot of certificates that were created before we knew about the options like -O/-M/etc... where we manually set file permissions on the certs after creation. I know how to do these things on a a new cert request, using the various options, but I'd like to update these options on certificates that are already being tracked. The only way I've managed to do it so far is by using ipa-getcert resubmit, with the options that I want changed. However, this method results in the entire certificate being regenerated on the spot. If we had a small number of certs that we wanted to update, this wouldn't be a huge problem, but we have several different certs on a few thousand production systems that we want to update
this way, and I'd prefer not to send 10,000 cert renewals up to the master server, and that would also end up making all of those thousands of certs auto renew at roughly the same time every year, which we consider to be undesirable. I assume that manual edits of the files in /var/lib/certmonger/requests is not the proper way to handle this, but what IS the correct way to make such modifications after the initial ipa-getcert request that created the certs originally?
Thank you,
Shawn Asmussen
1 year, 1 month
Understanding the Internal Algorithm of Automember-rebuild
by terrible person
Hi everyone.
Recently, I have noticed a significant increase in the load generated by the automember-rebuild command, even when there are no changes to be made to the user's group membership. This high load also propagates via replication and affects the entire infrastructure (we have about 30 replicas).
As an example, I issued the following command:
ipa automember-rebuild --type=group --users=someuser
Despite the fact that the user 'someuser' already had all the required group memberships, the automember-rebuild command generated a significant amount of load on the system.
Problem user for example have 23 groups in total, 18 of them are the result of automember rules. With automember we are roughly solving the problem of some identity service, that has no support for ldap nested groups, therefore some users should be directly inserted as group members via automember rule, insted of relying in nestines.
So, when a batch of users getting added I used bash script:
#!/bin/bash
TOTAL_USERS=$(ipa user-find --all --sizelimit=0 | grep 'User login:' | awk '/User login:/ {print $3}' | wc -l)
COUNTER=1
for g in $(ipa user-find --all --sizelimit=0 | grep 'User login:' | awk '/User login:/ {print $3}')
do
echo User $g
ipa automember-rebuild --type=group --users=$g
echo Number of entries processed $COUNTER/$TOTAL_USERS
let COUNTER++
done
To assign needed groups to a new users, if someone was left un-handled by the first line support. But with time as a amout of groups and replicas grew I started to experience problems I described above, even when no changes are were to be applied. So I came to a conclusion that I lack understanding of what automember-rebuild actually does under the hood. For what I only know it puts tasks under the "cn=automember rebuild membership,cn=tasks,cn=config".
What would certainly helped is this feature https://directory.fedoraproject.org/docs/389ds/design/log-operation-stats...
but it's not availiable for my version of 389ds (389-Directory/1.4.3.28, ipa-server-4.9.10-6, CentOS8 container)
So questions are:
1) Can someone provide overview of what automember-rebuild does under the hood?
2) Does those changes affected by replication, even if no changes needs to be applied? (i.e. users already in needed groups but command still being issued for every user)
3) Why is 389-ds being affected so much on 18 rules of membership? For what I see in the monitoring tools I get heavy delays on the disk IO. Is it really to much or it should not affect this much and I need to look for some system tuning (4 CPU 8GB RAM currently, ssd disk).
1 year, 1 month
Let’s Encrypt SSL Certificate doesn't work with .internal suffix
by Loi Do
Hello all,
I'm seeking for a clarity advice rather than fixing an issue since I don't think it's an issue - do let me know otherwise. I recently tried to install an SSL certificate for my FreeIPA server to get rid of the "SSL error" shown on my web browser. I used the official FreeIPA Let's Encrypt management script (https://github.com/freeipa/freeipa-letsencrypt) to install the cert but did not succeed. I'm getting the following error:
Requesting a certificate for newvipa.homelab.internal
An unexpected error occurred:
The server will not issue certificates for the identifier :: Error creating new order :: Cannot issue for "newvipa.homelab.internal": Domain name does not end with a valid public suffix (TLD)
It appears my domain suffix is not acceptable as it's not a public suffix. This is normal because the domain is intended for internal use. My question is, should I be using .com suffix for my domain (homelab.com) and create a subdomain (sub.homelab.com) for internal use so I can use the ssl cert? I know it isn't necessary to use the SSL cert if the server is only meant for internal use - I know it's my server and I can trust it. I'm just more curious if my current domain is following best practice for internal use and I should only be concerned with the issue if it's for public use.
As always, thank you all for assistance.
1 year, 1 month
cant fix ipa server cert issues
by Justen Long
Thanks in advance for your replies.. I've spent 7 hours looking through posts here and trying everything... I'm stuck.
Background: I am a System Administrator in a closed, classified environment. Unfortunately, I cannot post logging here, but I can refer to them as needed.
I inherited this system from someone who departed the program a year or so ago. Fast forward to today, the server certs expired yesterday. Admittedly, I'm unfamiliar (or was) with the certificate update process for IPA servers. On a typical server, we replace the old cert and restart the httpd services; however, I realize this cannot work with IPA servers now.
Additionally to all of this, the CA chain updated 6 months ago.
I ran ipa-cacert-manage to update the CA chain. When trying to run ipa-certupdate, I received errors for an invalid server certificate (it expired on 11 April 2023). It simply won't connect to the web server. HTTPD failed as well, so I had to add "NSSEnforceValidCerts off" to the nss.conf file for HTTPD to start. Still, no dice.
I've ran ipa-server-certinstall for the new cert/key as well, and it fails saying its not trusted ("Peer's certificate issuer is not trusted [certutil: certificate is invalid: Peer's Certificate issuer is not recognized] Please run ipa-cacert-manage install and ipa-certupdate to install the CA certificate.... which, as reported above, can't complete.
I'm at a total loss here... and really struggling being new to all this and trying my best to keep it afloat. Any help would be GREATLY appreciated!
1 year, 1 month
Ansible FreeIPA Server + Replica
by Finn Fysj
Hi,
I'm new to FreeIPA and the ansible-freeipa collection.
I can successfully install IPA server using the role ipaserver. However, I want to setup a multi-master replication with failover.
As far as I know I need to install ipaserver on all of my masters/replication and then the replica role?
How does the master nodes establish a relationship? Is this done using IPA client?
It might seem weird, but my goal is to setup the IPA server purely as a LDAP server using external CA.
This is because we want to have the ability to have a user interface like the web gui.
1 year, 1 month
