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
5 days, 18 hours
ipa-setup-ca
by Omar Pagan
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
1 week, 2 days
pki-tomcatd not starting
by Omar Pagan
Hello,
I came back from vacation and noticed that the pki-tomcatd was not running. All other services are running fine, I can kinit admin and search for users, I can also log into the UI and see everything. When I try to start the service I see the following errors:
Mar 11 20:44:44 ldap01.app.uaap.maxar.com ipa-pki-wait-running[7903]: ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error: for url: http://ldap01.app.uaap.maxar.com:8080/ca/admin/ca/getStat>
Mar 11 20:44:44 ldap01.app.uaap.maxar.com systemd[1]: pki-tomcatd(a)pki-tomcat.service: Start-post operation timed out. Stopping.
I have checked all the certs and everything is in order:
$ getcert list | grep expire
expires: 2025-01-22 14:07:35 UTC
expires: 2025-01-22 14:06:46 UTC
expires: 2025-01-22 14:06:45 UTC
expires: 2025-01-22 14:06:45 UTC
expires: 2043-02-02 14:06:44 UTC
expires: 2025-01-22 14:06:45 UTC
expires: 2025-02-02 14:08:10 UTC
I also have checked this:
$ klist -ekt /etc/dirsrv/ds.keytab
Keytab name: FILE:/etc/dirsrv/ds.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes256-cts-hmac-sha1-96)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes128-cts-hmac-sha1-96)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes128-cts-hmac-sha256-128)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (aes256-cts-hmac-sha384-192)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (camellia128-cts-cmac)
2 02/02/2023 14:06:06 ldap/ldap01.app.uaap.maxar.com(a)APP.UAAP.MAXAR.COM (camellia256-cts-cmac)
not sure if that's correct or not. Please help, I don't see why pki-tomcatd would just die on me for no reason. I haven't run any updates / upgrades on the system and it was working fine before I left. Thanks
1 week, 5 days
KDC Self Signed Certificate Creation
by Mark Selby
My company has 6 FreeIPA servers across 3 different locations. Five of the six servers are ok, but one we could not login to. The error messages pointed to the expired certificate located at `/var/kerberos/krb5kdc/kdc.crt`
My question is how do I "properly" renew or recreate this certificate. I have been able to renew it with the command listed below - but the renewed cert does not have the same characteristics as the other certs. The existing ones all see to be self signed with the specified profile while my new one does not have these features. It seems to be working Ok but it would great to understand how to generate this cert correctly. All is any help is greatly appreciated.
The servers that work all display the following with using getcert list -f /var/kerberos/krb5kdc/kdc.crt
Request ID '20191003181545':
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=ipa01.sub1.acme.org,O=ACME.ORG
subject: CN=ipa01.sub1.acme.org,O=ACME.ORG
expires: 2022-08-09 22:06:33 UTC
principal name: krbtgt/ACME.ORG(a)ACME.ORG
certificate template/profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
Using the local-getcert start-tracking command below gets me an updated cert but it is not self signed and does not have the specified profile.
local-getcert start-tracking \
-k /var/kerberos/krb5kdc/kdc.key \
-f /var/kerberos/krb5kdc/kdc.crt \
-T KDCs_PKINIT_Certs \
-C /usr/libexec/ipa/certmonger/renew_kdc_cert
Request ID '20220117193849':
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: local
issuer: CN=Certificate Authority,O=ACME.ORG
subject: CN=vipa06.sub3.acme.org,O=ACME.ORG
expires: 2024-01-18 17:32:20 UTC
principal name: krbtgt/ACME.ORG(a)ACME.ORG
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
1 week, 5 days
Reenrolling IPA client in split-brain environment
by William Faulk
I have an IdM environment where one of the replicas stopped replicating out. A number of clients were enrolled into this replica. They are currently working fine, since they're basically only ever talking to that replica. But I need to fix that replica, and the only feasible solution at this point seems to be a re-initialization. But that means that these clients' enrollments will disappear.
Is there any way to get a client in this state to re-enroll into a different replica that doesn't yet know about it, in such a way that it won't have an interruption in the IdM services it consumes? I only have four systems in this state, so I can reasonably make manual changes to support this, as long as they won't be snowflakes in the long term.
--
William Faulk
3 weeks, 4 days
freeipa.py plugin for AWX dynamic inventory not available
by slek kus
Hi, is there a possibility to have the below plugin avialable in Ansible Galaxy FreeIPA collection?
https://github.com/ansible/ansible/blob/stable-2.9/contrib/inventory/free...
Trying to use dynamic inventory by using the plugin. but this is not being included/downloaded with the collection.
I create a dynamic inventory (sourced from project, a git where I have the following folder and file):
inventories/clients_and_controllers.yml, where the contents of the .yml is a single line:
```
plugin: freeipa
```
The collections used are:
```
collections:
- name: freeipa.ansible_freeipa
- name: community.general
```
The error message trying to sync the resource for the dynamic inventory is:
[WARNING]: * Failed to parse
/runner/project/inventories/clients_and_controllers.yml with auto plugin:
inventory config ‘/runner/project/inventories/clients_and_controllers.yml
’
specifies unknown plugin ‘freeipa.py’
Kind regards!
3 weeks, 6 days
unable to convert attribute 'cacertificate:binary'
by Antoine Gatineau
Hello,
When enrolling a opensuse tumbleweed client, ipa-client-install fails to
get the cacertificate from ldap with error:
2024-04-30T11:23:16Z DEBUG Initializing principal adminprincipal using
password
2024-04-30T11:23:16Z DEBUG Starting external process
2024-04-30T11:23:16Z DEBUG args=['/usr/bin/kinit', 'adminuser', '-c',
'/tmp/krbcc2swf0edk/ccache']
2024-04-30T11:23:16Z DEBUG Process finished, return code=0
2024-04-30T11:23:16Z DEBUG stdout=Password for adminuser:
2024-04-30T11:23:16Z DEBUG stderr=
2024-04-30T11:23:16Z DEBUG trying to retrieve CA cert via LDAP from
ipa-server-01.empire.lan
2024-04-30T11:23:16Z DEBUG retrieving schema for SchemaCache
url=ldap://ipa-server-01.empire.lan:389
conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f020cb3f490>
2024-04-30T11:23:17Z ERROR unable to convert the attribute
'cacertificate;binary' value
b'0\x82\x04\x.........ETC........................................' to
type <class 'cryptography.x509.base.Certificate'>
2024-04-30T11:23:17Z DEBUG get_ca_certs_from_ldap() error: %i format: a
real number is required, not dict
2024-04-30T11:23:17Z DEBUG %i format: a real number is required, not dict
2024-04-30T11:23:17Z ERROR Cannot obtain CA certificate
'ldap://ipa-server-01.empire.lan' doesn't have a certificate.
2024-04-30T11:23:17Z ERROR Installation failed. Rolling back changes.
ipa server is 4.11.0 (centos stream 9 latest)
ipa client is 4.11.1 (opensuse tumbleweed) from this source:
https://build.opensuse.org/package/show/security%3Aidm/freeipa
With debian 12 and ipa-client 4.9.11 the enrollment succeeds.
With centos stream 9 and ipa-client 4.11.0 the enrollment succeeds.
Is there a limitation with clients newer than the server?
What can I check to fix this issue?
Thank you
1 month
LDAP conflicts after yum update on Almalinux 8.9
by Lee Csk
After performing a usual Yum update's on multiple IPA servers (not at the same time, one server reportedly started hanging), we started observing "LDAP Conflicts" in multiple IPA replication servers:
az2-replica.noc.net
| LDAP Conflicts | 9 | FAIL |
mi2-replica.noc.net:
| LDAP Conflicts | 9 | FAIL |
mi1-replica.noc.net:
| LDAP Conflicts | 9 | FAIL |
az1-replica.noc.net:
| LDAP Conflicts | 10 | FAIL |
sg1-replicate.noc.net:
| LDAP Conflicts | 3 | FAIL |
sg2-replica.noc.net
| LDAP Conflicts | 3 | FAIL |
The "Replication status" while reports OK, we observe also flapping at times between OK and FAIL too.
We have tried to follow on one of the replication servers: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
- by removing the orphan entry, however the replication broke completely on it (ipa service couldn't start back up), requiring a full re-install of that specific replica.
]$ sudo -u admin /home/admin/.local/bin/cipa -H localhost |grep "LDAP Conflicts"
| LDAP Conflicts | 0 | OK |
$ dsconf -D "cn=Directory Manager" ldap://$(hostname) repl-conflict list-glue "dc=noc,dc=net"
Enter password for cn=Directory Manager on ldap://az1-replica.noc.net:
dn: cn=sg1-replica.noc.net,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
cn: sg1-replica.noc.net
ipaLocation: idnsname=singapore,cn=locations,cn=etc,dc=noc,dc=net
ipaMaxDomainLevel: 1
ipaMinDomainLevel: 1
ipaReplTopoManagedSuffix: dc=noc,dc=net
nsds5replconflict: deletedEntryHasChildren
objectClass: top
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
objectClass: ipalocationmember
objectClass: extensibleobject
objectClass: glue
$ ldapsearch -H ldaps://$(hostname) -W -D 'cn=Directory Manager' '(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))' nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=noc,dc=net> (default) with scope subtree
# filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
# requesting: nsds5ReplConflict
#
# sg1-replica.noc.net + 039c4293-257f11ed-a255f732-cfd01100, masters, ipa, etc, noc.net
dn: cn=sg1-replica.noc.net+nsuniqueid=039c4293-257f11ed-a255f732-cfd01100,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
nsds5ReplConflict: namingConflict (ADD) cn=sg1-replica.noc.net,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
# HTTP/mi1-replica.noc.net(a)noc.NET + 0264df8b-fca611ee-a3cba8b9-8a6b8039,services, accounts, noc.net
dn: krbprincipalname=HTTP/mi1-replica.noc.net@NOC.NET+nsuniqueid=0264df8b-fca611ee-a3cba8b9-8a6b8039,cn=services,cn=accounts,dc=noc,dc=net
nsds5ReplConflict: namingConflict (ADD) krbprincipalname=http/mi1-ipaca.noc.net(a)noc.net,cn=services,cn=accounts,dc=noc,dc=net
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
OR:
az1-replica.noc.net:/$ ldapsearch -H ldap://$(hostname) -D "cn=Directory Manager" -W -b "dc=noc,dc=net" "(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))" \* nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=noc,dc=net> with scope subtree
# filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
# requesting: * nsds5ReplConflict
#
# sg1-replica.noc.net + 039c4293-257f11ed-a255f732-cfd01100, masters, ipa,
etc, noc.net
dn: cn=sg1-replica.noc.net+nsuniqueid=039c4293-257f11ed-a255f732-cfd01100
,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
ipaLocation: idnsname=singapore,cn=locations,cn=etc,dc=noc,dc=net
objectClass: top
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
objectClass: ldapsubentry
objectClass: ipalocationmember
cn: sg1-replica.noc.net
ipaReplTopoManagedSuffix: dc=noc,dc=net
ipaMinDomainLevel: 1
ipaMaxDomainLevel: 1
nsds5ReplConflict: namingConflict (ADD) cn=sg1-replica.noc.net,cn=masters
,cn=ipa,cn=etc,dc=noc,dc=net
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
We expect: | LDAP Conflicts | 0 | OK |
Running versions:
ipa-server-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
ipa-client-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
389-ds-base-1.4.3.37-2.module_el8.9.0+3710+3183c30a.alma.1.x86_64
krb5-server-1.18.2-26.el8_9.x86_64
The yum update happened from:
ipa-server-4.9.12-11.module_el8.9.0+3715+e4197dc9.alma.1.x86_64
to:
ipa-server-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
Please advise, how its best to resolve these "LDAP Conflicts".
How to remove, or retain if its the case?
Thanks,
Lee
1 month
Howto: Migrate DNS/DNSSec off freeipa
by Harry G Coin
If you've decided freeipa's DNS and/or DNSsec isn't part of your future,
here's a way to migrate to another solution without disrupting the rest
of freeipa's capabilities. I couldn't find any documentation about how
to do this in an automated way, this worked for me. (Watch someone
answer this post with 'oh, you just run X and it's all automated!)
This same instruction set can help whenever it's necessary to reinstall
a freeipa-master on a fresh/new system.
Corrections welcome! This is based on experience and with hints posted
at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
It requires a currently running master and at the ability to install (or
re-install) one replica.
1. Review the logs on the master to make sure operations are normal
(you can ignore dns/dnssec related errors). Before making changes: in
case it all goes horribly wrong make a complete snapshot of the master
and save it (usually best done as a low-level disk operation when the
master host is powered off).
2. On the master: Make sure whatever is replacing freeipa's DNS/DNSsec
is operational and has satisfactory content. (We chose Technitium,
after adding failover capability to it). To gain confidence that is
complete, point /etc/resolv.conf on the master at the new DNS server,
then run ipa-healthcheck until there are no complaints. Zone transfer
can be your friend.
3. Create a new system/vm and on it install a replica
(ipa-replica-install) but do not include --setup-dns or related options
like --no-forwarders. Comprehend the details of 'ipa-replica-manage
dnarange-set' which may be necessary on your master and different on
your replica. This replica can be temporary, in that case do not
specify a large dnarange.
4. On the replica, point /etc/resolv.conf to the new dns server, then
run ipa-healthcheck to make sure there are no complaints.
5. On the replica, kinit admin then: ipa config-mod
--ca-renewal-master-server <replica fqdn> . From
/etc/pki/pki-tomcat/ca/CS.cfg remove 'ca.certStatusUpdateInterval=0'
Then ipactl restart on the replica.
6. Add 'ca.certStatusUpdateInterval=0' to
/etc/pki/pki-tomcat/ca/CS.cfg on the soon-to-be-retired master. ipactl
restart on the master.
7. On the master, ipa-crlgen-manage disable and on the replica
ipa-crlgen-manage enable.
8. check that ipa-crlgen-manage status on the master shows disabled,
and on the replica shows enabled.
9. Power down the master. Check that the replica is operating
normally and new DNS operations are normal.
10. On the replica, do 'ipa-replica-manage del <master fqdn> --force
(you will be warned about dns, but you've got that covered, right?)
11. Install a new OS or reformat what was the master. Make sure DNS
is correct on the new setup. Install ipa-server as if on a replica,
pointing at the temporary replica you've created above as the source.
Remember NOT to include --setup-dns or dns related installation options.
12. Reverse steps 7, 6 and 5.
13. On the master, you may need to run step 3 with the prior dna-range.
14. When 'ipa-healthcheck' on the now-new master reports no errors, if
you wish you can delete the replica from the ipa topology and retire
that system.
That's it! The good news is adding freeipa's DNS back into the mix if
that becomes best in your setup is well documented. Some of the
alternative DNS servers can act as secondary servers then 'promote'
themselves to 'primary' using the transferred database, which makes
migration easier. If you use DNSSec, be sure to add DS records for the
new nameserver in your registrar's dns before retiring
bind9-named-pkcs11/softhsm/opendnssec/bind-dynldap and related freeipa
DNS suite subsystems.
We found a way to keep the tight relationship between freeipa and DNS
(host DNS records and the like). To make that a 'native' freeipa
option, you might imagine a freeipa plugin that issued host zone record
related commands to third-party DNS solutions.
Harry
1 month
Fedora 40: new warning in ipa-healthckeck
by Jochen Kellner
Hi,
I've upgraded my freeipa server to Fedora 40 (the system was installed
several releases ago). After the upgrade I get the following new warning
from ipa-healthcheck:
{
"source": "ipahealthcheck.ds.backends",
"check": "BackendsCheck",
"result": "WARNING",
"uuid": "875db8e3-029c-46f7-87e5-bf9a216d9637",
"when": "20240426184431Z",
"duration": "0.031642",
"kw": {
"key": "DSBLE0005",
"items": [
"nsslapd-dbcachesize",
"nsslapd-db-logdirectory",
"nsslapd-db-transaction-wait",
"nsslapd-db-checkpoint-interval",
"nsslapd-db-compactdb-interval",
"nsslapd-db-compactdb-time",
"nsslapd-db-transaction-batch-val",
"nsslapd-db-transaction-batch-min-wait",
"nsslapd-db-transaction-batch-max-wait",
"nsslapd-db-logbuf-size",
"nsslapd-db-page-size",
"nsslapd-db-locks",
"nsslapd-db-locks-monitoring-enabled",
"nsslapd-db-locks-monitoring-threshold",
"nsslapd-db-locks-monitoring-pause",
"nsslapd-db-private-import-mem",
"nsslapd-db-deadlock-policy"
],
"msg": "Found configuration attributes that are not applicable for the configured backend type."
}
},
According to
https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html the
bdb backend is deprecated. The system was installed with
389-ds-base < 1.4.4.9-1.fc33.x86_64 (I see the upgrade to that version
in /var/log/dnf.rpm.log*. Since 3.0 new installations should use LMBD as
the backend. Is that true for new installations?
What is the desired action that I should take?
I can remove the options from the dirsrv configuration. Should I?
Shall I switch to lmdb manually? Or is that something that
ipa-server-upgrade should be doing?
Otherwise I can suppress the message in ipa-healthcheck for now. But I
guess I should fix my installation before the deprecated support really
gets dropped... Is deploying a new replica and decommisioning the old
server we the preferred action?
Jochen
--
This space is intentionally left blank.
1 month, 1 week
