Extra objectClass for new IPA group
by Winfried de Heiden
Hi all,
Following documentation as provided on:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
adding an extra objectClass (groupOfUniqueNames in this case) to newly
created groups turned out to be easy.
It seems we depend of this objectClass and its attribute "uniqueMember"
because of existing applications. Adding the latter attribute will only
work from the CLI. (ipa group-mod dummy3
--addattr=uniqueMember=uid=someuser,cn=users,cn=accounts,dc=example,dc=com)
OK, this seems to work well, but the objectClass will be added to ALL
newly created groups since the objectClass is added to the defaults.
Now, let's say I want to add an extra objectClass to only one new
created group; how would that be possible? The command "ipa group-add"
command does not provide such an option, does it?
FYI, I'm running/testing IPA version: 4.11.0 on RHEL 9.4 Beta :)
The new attributes will not be visible in de webUI, only using the CLI
(or good-old Apache Directory Studio of ldapsearch). Correct?
--
email handtekening privé Met vriendelijke groet,
Winfried de Heiden
wdh(a)dds.nl
1 month, 3 weeks
'ipk11id length should not be 0' -- 'restart counter at 811' how to correct?
by Harry G Coin
What's the correct way to correct the cause of this error message?
There is no guidance online I can find. I first saw it a few years ago,
it's back. ipa-ods-exporter emits this assertion, then quits.
ipk11id length should not be 0
This system hosts the dnssec master db. There is one replica. That's it.
Apr 07 08:12:08 registry1.1.quietfountain.com systemd[1]:
ipa-ods-exporter.service: Scheduled restart job, restart counter is at 811.
Apr 07 08:12:08 registry1.1.quietfountain.com systemd[1]: Stopped IPA
OpenDNSSEC Signer replacement.
Apr 07 08:12:08 registry1.1.quietfountain.com systemd[1]:
ipa-ods-exporter.service: Consumed 2.876s CPU time.
Apr 07 08:12:08 registry1.1.quietfountain.com systemd[1]: Started IPA
OpenDNSSEC Signer replacement.
Apr 07 08:12:09 registry1.1.quietfountain.com ipa-ods-exporter[857534]:
ipa-ods-exporter: INFO To increase debugging set debug=True in
dns.conf See default.conf(5) for details
Apr 07 08:12:10 registry1.1.quietfountain.com python3[857534]: GSSAPI
client step 1
Apr 07 08:12:10 registry1.1.quietfountain.com python3[857534]: GSSAPI
client step 1
Apr 07 08:12:10 registry1.1.quietfountain.com python3[857534]: GSSAPI
client step 1
Apr 07 08:12:10 registry1.1.quietfountain.com python3[857534]:
Configuration.cpp(96): Missing log.level in configuration. Using default
value: INFO
Apr 07 08:12:10 registry1.1.quietfountain.com python3[857534]:
Configuration.cpp(96): Missing slots.mechanisms in configuration. Using
default value: ALL
Apr 07 08:12:10 registry1.1.quietfountain.com python3[857534]:
Configuration.cpp(124): Missing slots.removable in configuration. Using
default value: false
Apr 07 08:12:11 registry1.1.quietfountain.com ipa-ods-exporter[857534]:
Traceback (most recent call last):
Apr 07 08:12:11 registry1.1.quietfountain.com
ipa-ods-exporter[857534]: File "/usr/libexec/ipa/ipa-ods-exporter",
line 718, in <module>
Apr 07 08:12:11 registry1.1.quietfountain.com ipa-ods-exporter[857534]:
ldap2master_replica_keys_sync(ldapkeydb, localhsm)
Apr 07 08:12:11 registry1.1.quietfountain.com
ipa-ods-exporter[857534]: File "/usr/libexec/ipa/ipa-ods-exporter",
line 295, in ldap2master_replica_keys_sync
Apr 07 08:12:11 registry1.1.quietfountain.com ipa-ods-exporter[857534]:
hex_set(localhsm.replica_pubkeys_wrap))
Apr 07 08:12:11 registry1.1.quietfountain.com
ipa-ods-exporter[857534]: File
"/usr/lib/python3.9/site-packages/ipaserver/dnssec/localhsm.py", line
130, in replica_pubkeys_wrap
Apr 07 08:12:11 registry1.1.quietfountain.com ipa-ods-exporter[857534]:
self.find_keys(objclass=_ipap11helper.KEY_CLASS_PUBLIC_KEY,
Apr 07 08:12:11 registry1.1.quietfountain.com
ipa-ods-exporter[857534]: File
"/usr/lib/python3.9/site-packages/ipaserver/dnssec/localhsm.py", line
114, in find_keys
Apr 07 08:12:11 registry1.1.quietfountain.com
ipa-ods-exporter[857534]: key = Key(self.p11, h)
Apr 07 08:12:11 registry1.1.quietfountain.com
ipa-ods-exporter[857534]: File
"/usr/lib/python3.9/site-packages/ipaserver/dnssec/localhsm.py", line
38, in __init__
Apr 07 08:12:11 registry1.1.quietfountain.com
ipa-ods-exporter[857534]: assert len(cka_id) != 0, 'ipk11id length
should not be 0'
Apr 07 08:12:11 registry1.1.quietfountain.com ipa-ods-exporter[857534]:
AssertionError: ipk11id length should not be 0
Apr 07 08:12:11 registry1.1.quietfountain.com systemd[1]:
ipa-ods-exporter.service: Main process exited, code=exited, status=1/FAILURE
Apr 07 08:12:11 registry1.1.quietfountain.com systemd[1]:
ipa-ods-exporter.service: Failed with result 'exit-code'.
Apr 07 08:12:11 registry1.1.quietfountain.com systemd[1]:
ipa-ods-exporter.service: Consumed 2.938s CPU time.
on
[root@registry1 ~]# dnf info ipa-server
Last metadata expiration check: 3:19:38 ago on Sun 07 Apr 2024 04:55:29
AM CDT.
Installed Packages
Name : ipa-server
Version : 4.10.2
Release : 8.el9_3.alma.1
Architecture : x86_64
Size : 1.1 M
Source : ipa-4.10.2-8.el9_3.alma.1.src.rpm
Repository : @System
From repo : appstream
Summary : The IPA authentication server
5.14.0-362.24.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 20 04:52:13
EDT 2024 x86_64 x86_64 x86_64 GNU/Linux
p11 tools has one entry that has no id, no label, RSA of 0 byte length,
with also the 'wrap' flag. There's no obvious way to track that back to
a file-- if that's event the right path to explore.
It's pretty much dead until this is solved.
1 month, 3 weeks
CA Subsystem certificate
by Travis West
The person who set this up is no longer available. We have 6 IPA servers in a cluster, all set as MASTER. All servers are running IPA v. 4.6.4.
On 8 March the CA Subsystem certificate expired. When looking at the certificate I noticed it had an incorrect Common Name, which may be why it didn't renew.
I checked the pki-tomcat CS.cfg and the two lines
ca.subsystem.cert - Has cert with incorrect hostname listed
ca.subsystem.certreq - Has cert request for correct ca subsystem cert (Common Name CA Subsystem)
I tried removing the errant ca subsystem cert from the NSS DB in pki-tomcat/alias and was successful. I then tried to request a new SubSystem Cert using this command
getcert request -I CASubsystem -c dogtag-ipa-renew-agent -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -N 'cn=CA Subsystem,o=IPA.*****.NET' -P 'PIN_FROM_FILE' -t 'NSS Certificate DB'
And that seems to at least have issued the request because 'getcert list' shows the request, but with a CA_REJECTED message.
If I do an ldapsearch for the certificate, it shows the the correct cert with CN=CA Subystem, but the one that expired on 8 March.
How can I get a valid CA Subsystem cert again so I can start the CA on all IPA servers?
1 month, 3 weeks
Possible to split a toplogy to 2 topologies?
by Heo Paul
Hi. I installed ipa-core servers in a toplogy and the version of those are 4.9.3.
A topology : 1 <--> 2 <--> 3 <--> 4 <--> 5 <--> 6
And I'd like to disconnect agreements between 3 and 4 replicas, I expect that there should be 2 seperate topologies like the below.
A topology : 1 <--> 2 <--> 3
B topology : 4 <--> 5 <--> 6
But when I try to execute the following commands, but those all fails due to "ipa: ERROR: Server is unwilling to perform: Removal of Segment disconnects topology.Deletion not allowed."
- ipa-topologysegment-del
- ldapdelete cn=xx3.com-to-xx4.com,cn=ca,cn=topology,cn=ipa,cn=etc,dc=samsungsre,dc=com
And I also did "ipa-replica-manage del" command but some issues also occurred.
Could you guide me to disconnect replications between non-leaf replicas?
1 month, 3 weeks
Can CA system certificates be rekeyed?
by Sam Morris
Hi folks
I make use of certmonger's key_use_count to ensure that I don't use the
same private key more than once when issuing service certificates. I was
wondering what would happen if this was set on a FreeIPA server. Having
done a bit of reading I think this looks like a Very Bad Idea, but I was
wondering if someone could confirm the following:
1. It's fine to rekey the KDC/dirsrv/httpd service certificates -
there's nothing particularly special about them.
2. The Dogtag-related certificates are renewed on the CA renewal master,
and stashed into the directory in entries under
cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX so that the other servers can
retrieve them; but the private keys aren't stashed in the directory, so
transporting the new keys to the other servers would be a manual process.
3. One of these certificates is the CA certificate which you would never
want to re-key because that would cause absolute mayhem.
4. There's no way to have certmonger re-key the service certificates
(from the "IPA" CA) when renewing, but not the system certificates (from
the "dogtag-ipa-ca-renew-agent" CA); so setting key_use_count is a
really bad idea, never do it on a FreeIPA server.
Cheers,
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
1 month, 4 weeks
Re: upgrade idm servers rhel 7 to 8 problems
by Natxo Asenjo
hi,
posting back to the list.
Apparently the idm server cannot find a SID of a domain when trying to
resolve the user account. It does find the user account, but there are
sids coupled to the account correspondig to a domain wich cannot be
resolved.
It took me a while but the sid of that child domain is not the one not
resolved.
It turns out, the sid of the domain not resolving is the one of the idm
realm itself., we have some idm groups mapped to the AD groups we allow in
idm for rbac, and if I look at the ipaNTSecurityIdentifier attributes of
the id groups, those are the not resolved groups.
This is unexpected (to me at least).
so we have this trust (verified on two different idm servers, same value):
ipa trust-find
---------------
1 trust matched
---------------
Realm name: domain.local
Domain NetBIOS name: DOMAIN
Domain Security Identifier: S-1-5-21-1416133915-1866970209-3316290679
Trust type: Active Directory domain
----------------------------
Number of entries returned 1
but inside this idm domain, we have some idm posix groups with the
ipantsecurityidentifier of the not resolvable domain, for instance:
S-1-5-21-1214650608-3976977395-3073169311-101072
So basically, it is not matching because of this ipantsecurityidentifier, I
think.
I do not know how to fix this at this moment, or why it has happened. Any
ideas?
1 month, 4 weeks
CA_UNREACHABLE when requesting from Ubuntu 20.04 to FreeIPA v4.11.1
by Djerk Geurts
Hi,
A month or so ago we upgraded from Fedora 37 to 39. I guess this is the first time I’m getting round to requesting a new certificate, and it’s failing from a server we use to manage several certificates for non-IPA client hosts.
Output of ipa-getcert list:
Request ID '20240402190326':
status: CA_UNREACHABLE
ca-error: Server at https://ipa.domain.com/ipa/xml failed request, will retry: 903 (RPC failed at server. an internal error has occurred).
stuck: no
key pair storage: type=FILE,location='/etc/ssl/private/host.domain.com.key'
certificate: type=FILE,location='/etc/ssl/certs/host.domain.com.crt'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
The httpd log on the IPA server:
[Tue Apr 02 21:03:26.989287 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ipa: ERROR: non-public: ValueError: Only single-valued attributes are supported
[Tue Apr 02 21:03:26.989320 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] Traceback (most recent call last):
[Tue Apr 02 21:03:26.989326 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] File "/usr/lib/python3.12/site-packages/ipaserver/rpcserver.py", line 417, in wsgi_execute
[Tue Apr 02 21:03:26.989330 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] result = command(*args, **options)
[Tue Apr 02 21:03:26.989333 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ^^^^^^^^^^^^^^^^^^^^^^^^^
[Tue Apr 02 21:03:26.989337 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] File "/usr/lib/python3.12/site-packages/ipalib/frontend.py", line 471, in __call__
[Tue Apr 02 21:03:26.989341 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] return self.__do_call(*args, **options)
[Tue Apr 02 21:03:26.989345 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Tue Apr 02 21:03:26.989348 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] File "/usr/lib/python3.12/site-packages/ipalib/frontend.py", line 499, in __do_call
[Tue Apr 02 21:03:26.989353 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ret = self.run(*args, **options)
[Tue Apr 02 21:03:26.989358 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ^^^^^^^^^^^^^^^^^^^^^^^^^^
[Tue Apr 02 21:03:26.989371 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] File "/usr/lib/python3.12/site-packages/ipalib/frontend.py", line 816, in run
[Tue Apr 02 21:03:26.989376 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] return self.execute(*args, **options)
[Tue Apr 02 21:03:26.989381 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Tue Apr 02 21:03:26.989385 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] File "/usr/lib/python3.12/site-packages/ipaserver/plugins/cert.py", line 716, in execute
[Tue Apr 02 21:03:26.989389 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ext_san = csr.extensions.get_extension_for_oid(
[Tue Apr 02 21:03:26.989392 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ^^^^^^^^^^^^^^
[Tue Apr 02 21:03:26.989396 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ValueError: Only single-valued attributes are supported
[Tue Apr 02 21:03:26.989527 2024] [wsgi:error] [pid 1606:tid 1957] [remote 10.2.0.92:50078] ipa: INFO: [xmlserver] host/jump.domain.com(a)DOMAIN.COM: cert_request(‘MIID**********d1A==', principal='HTTP/host.domain.com(a)DOMAIN.COM', add=True, version='2.51'): InternalError
The requesting machine is allowed to manage both the host and the service. Requesting the certificate on the IPA server itself works fine. I’ve read elsewhere that this could be an incompatibility between the client and the server.
Client: Ubuntu 20.04 LTS, ipa-client: v4.8.6
Server: Fedora 39, ipa-server: v4.11.1
Thanks,
Djerk Geurts
1 month, 4 weeks
ACME certs fail to renew
by Antoine Gatineau
Hello,
I have a strange issue regarding acme service.
My acme certificates fail to renew. `ipa-acme-manage status`fails with
error:
Failed to authenticate to CA REST API
The ipa-acme-manage command failed.
certbot client fails with error "Failed to renew certificate
office.empire.lan with error: <Response [404]>"
$ ipa cert-show 49
Issuing CA: ipa
Certificate: "The certificate content"
Subject: CN=office.empire.lan
Subject DNS name: office.empire.lan
Issuer: CN=Certificate Authority,O=EMPIRE.LAN
Not Before: Sun Dec 24 14:05:50 2023 UTC
Not After: Sat Mar 23 14:05:50 2024 UTC
Serial number: 49
Serial number (hex): 0x31
Revoked: False
So last successful renewal was on Dec 24th. Since then I have not really
done anything appart updating.
I don't see any issue in ipaupgrade.log
I am running on centos stream 9
idm-jss.x86_64 5.5.0-1.el9
idm-jss-tomcat.x86_64 5.5.0-1.el9
idm-ldapjdk.noarch 5.5.0-1.el9
idm-pki-acme.noarch 11.5.0-1.el9
idm-pki-base.noarch 11.5.0-1.el9
idm-pki-ca.noarch 11.5.0-1.el9
idm-pki-java.noarch 11.5.0-1.el9
idm-pki-kra.noarch 11.5.0-1.el9
idm-pki-server.noarch 11.5.0-1.el9
idm-pki-tools.x86_64 11.5.0-1.el9
ipa-client.x86_64 4.11.0-9.el9
ipa-client-common.noarch 4.11.0-9.el9
ipa-common.noarch 4.11.0-9.el9
ipa-healthcheck.noarch 0.16-2.el9
ipa-healthcheck-core.noarch 0.16-2.el9
ipa-selinux.noarch 4.11.0-9.el9
ipa-server.x86_64 4.11.0-9.el9
ipa-server-common.noarch 4.11.0-9.el9
ipa-server-dns.noarch 4.11.0-9.el9
I have followed closely the update on centos stream 9
Running `ipa-acme-manage status` with the -d switch gives me
ipapython.ipaldap: DEBUG: retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-EMPIRE-LAN.socket
conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f123c07e2e0>
ipaserver.masters: DEBUG: Discovery: available servers for service 'CA'
are ipa-server-01.empire.lan, ipa-server-02.empire.lan
ipaserver.masters: DEBUG: Discovery: using ipa-server-01.empire.lan for
'CA' service
ipapython.dogtag: DEBUG: request POST
https://ipa-server-01.empire.lan:8443/acme/login
ipapython.dogtag: DEBUG: request body ''
ipapython.dogtag: DEBUG: response status 404
ipapython.dogtag: DEBUG: response headers Content-Type:
text/html;charset=utf-8
Content-Language: en
Content-Length: 765
Date: Thu, 28 Mar 2024 10:00:59 GMT
ipapython.dogtag: DEBUG: response body (decoded): b'<!doctype html><html
lang="en"><head><title>HTTP Status 404 \xe2\x80\x93 Not
Found</title><style type="text/css">body
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP
Status 404 \xe2\x80\x93 Not Found</h1><hr class="line" /><p><b>Type</b>
Status Report</p><p><b>Message</b> The requested resource
[/acme/login] is not available</p><p><b>Description</b> The
origin server did not find a current representation for the target
resource or is not willing to disclose that one exists.</p><hr
class="line" /><h3>Apache Tomcat/9.0.62</h3></body></html>'
ipapython.admintool: DEBUG: File
"/usr/lib/python3.9/site-packages/ipapython/admintool.py", line 180, in
execute
return_value = self.run()
File
"/usr/lib/python3.9/site-packages/ipaserver/install/ipa_acme_manage.py",
line 403, in run
with state as ca_api:
File
"/usr/lib/python3.9/site-packages/ipaserver/install/ipa_acme_manage.py",
line 103, in __enter__
raise errors.RemoteRetrieveError(
ipapython.admintool: DEBUG: The ipa-acme-manage command failed,
exception: RemoteRetrieveError: Failed to authenticate to CA REST API
ipapython.admintool: ERROR: Failed to authenticate to CA REST API
ipapython.admintool: ERROR: The ipa-acme-manage command failed.
So it looks like the acme subsystem is not started. But logs for the
acme subsystem in /var/log/pki/pki-tomcat/acme/debug.2024-03-28.log
don't show any issue. (see attached log)
How can I go further in troubleshooting/fixing this issue?
Thanks
2 months
