Revoked certificates not appearing in CRL
by Sam Morris
It looks like my CRL renewal master (RHEL 8) is not producing the CRL
correctly.
I've got two certificates that were requested by certmonger running on
an ipa client. I'm pretty sure I revoked them as an admin logged into a
second ipa client.
Status of all replication agreements on all ipa servers is green.
The CRL renewal master knows the certificates were issued & revoked:
$ ipa cert-find --validnotbefore-from=2024-03-14 --status=REVOKED
----------------------
2 certificates matched
----------------------
Issuing CA: ipa
Subject: CN=myhost.example.com,O=EXAMPLE.COM
Issuer: CN=Certificate Authority,O=EXAMPLE.COM
Not Before: Thu Mar 14 20:29:31 2024 UTC
Not After: Wed Jul 17 20:29:31 2024 UTC
Serial number: 1342111806
Serial number (hex): 0x4FFF003E
Status: REVOKED
Revoked: True
Issuing CA: ipa
Subject: CN=myhost.example.com,O=EXAMPLE.COM
Issuer: CN=Certificate Authority,O=EXAMPLE.COM
Not Before: Thu Mar 14 20:35:03 2024 UTC
Not After: Wed Jul 17 20:35:03 2024 UTC
Serial number: 1342111807
Serial number (hex): 0x4FFF003F
Status: REVOKED
Revoked: True
----------------------------
Number of entries returned 2
----------------------------
* Both certificates are revoked
* Both certificates have 'not after' dates in the future.
But looking at the current CRL:
$ openssl crl -in /var/lib/ipa/pki-ca/publish/MasterCRL.bin -inform der -noout -text
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = EXAMPLE.COM, CN = Certificate Authority
Last Update: Mar 23 13:18:45 2024 GMT
Next Update: Mar 23 17:00:00 2024 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:1B:89:B8:D6:6F:4D:41:C1:BD:47:A3:9B:21:36:8C:71:10:59:8C:A6
X509v3 CRL Number:
10526
Revoked Certificates:
Serial Number: 2FFE002B
Revocation Date: May 19 17:01:12 2022 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Signature Algorithm: sha256WithRSAEncryption
0f:2f:59:9b:9c:1c:ac:fd:6a:e5:d7:87:94:97:e3:a8:cf:07:
fe:86:8b:4e:a6:37:dc:76:c1:ef:f3:69:9e:e3:5c:8a:dd:12:
cb:fa:4a:97:21:ae:fa:ee:91:bb:37:9e:cb:bb:49:10:58:95:
bd:24:98:df:a1:45:90:b3:f1:51:af:2b:c9:cb:c3:89:23:a8:
f5:8d:3f:d4:4e:4b:a6:ef:d6:96:94:36:da:a1:0c:ab:32:27:
85:24:0d:9c:52:17:17:4d:ae:3a:83:59:39:a9:08:33:7d:f4:
05:74:e3:7d:1e:df:8e:f8:4c:c0:fd:7f:8b:a2:b4:0a:a2:fc:
57:9b:00:c2:29:9e:74:0f:c2:4a:0e:5c:e6:f0:1e:ff:71:a9:
f9:cb:a1:6f:b4:48:16:59:42:78:2a:38:1d:14:b7:d3:58:cb:
21:ad:61:bb:c9:20:e6:c2:39:97:bf:a6:f8:fe:26:32:51:eb:
67:b4:0c:b9:ea:96:ea:b0:66:cf:7c:73:74:69:fc:08:d9:a7:
13:23:34:3e:a6:f1:b3:0d:0f:54:46:22:71:6c:16:81:a8:97:
79:c5:a0:20:03:5d:51:d7:fb:25:33:3b:7a:55:59:dd:a6:cb:
3e:00:1d:2a:c7:a3:7a:8b:3b:1f:d9:36:23:c5:c3:f4:ff:14:
86:0b:61:fc
* The CRL was just generated a few minutes ago
* The two revoked certificates are not present
* The certificate that is present in the list expired in July 2022,
according to 'ipa cert-show 0x2FFE002B'
To force CRL generation I'm running:
$ curl https://$HOSTNAME:8443/ca/agent/ca/updateCRL --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key
Nothing suspicious shows up in Dogtag's logs:
==> /var/log/pki/pki-tomcat/ca/debug.2024-03-23.log <==
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: Getting SSL client certificate.
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: CertUserDBAuthentication: UID ipara authenticated.
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: UGSubsystem: retrieving user uid=ipara,ou=People,o=ipaca
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: AAclAuthz: Granting update permission for certServer.ca.crl
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CRLIssuingPoint: Updating MasterCRL
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CASigningUnit: Getting algorithm context for SHA256withRSA RSASignatureWithSHA256Digest
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CASigningUnit: Signing Certificate
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CRLReposiotry: Updating CRL issuing point record
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: LDAPSession: Modifying LDAP entry cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: Getting crl publishing rules
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapXCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCaCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: FileCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: true
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: type: crl
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: predicate: null
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapUserCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing CRL 10529 to MasterCRL
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: Getting crl publishing rules
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapXCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCaCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: FileCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: true
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: type: crl
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: predicate: null
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapUserCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing rules:
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: - rule: FileCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: mapper: NoMap
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing to CN=Certificate Authority,O=EXAMPLE.COM
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: - publisher: FileBaseCRLPublisher
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Published CRL
==> /var/log/pki/pki-tomcat/ca/signedAudit/ca_audit <==
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=--][ServerIP=--][SubjectID=CN=IPA RA,O=EXAMPLE.COM][Outcome=Success] access session establish success
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=AUTH][SubjectID=ipara][Outcome=Success][AuthMgr=certUserDBAuthMgr] authentication success
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=AUTHZ][SubjectID=ipara][Outcome=Success][aclResource=certServer.ca.crl][Op=update] authorization success
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ROLE_ASSUME][SubjectID=ipara][Outcome=Success][Role=Certificate Manager Agents, Registration Manager Agents, Security Domain Administrators, Enterprise ACME Administrators] assume privileged role
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=SCHEDULE_CRL_GENERATION][SubjectID=ipara][Outcome=Success] schedule for CRL generation
0.https-jsse-nio-8443-exec-7 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=--][ServerIP=--][SubjectID=--][Outcome=Success][Info=serverAlertReceived: CLOSE_NOTIFY] access session terminated
0.https-jsse-nio-8443-exec-7 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=--][ServerIP=--][SubjectID=--][Outcome=Success][Info=serverAlertSent: CLOSE_NOTIFY] access session terminated
This may be related to <https://pagure.io/freeipa/issue/9505>. I've not
had the chance to test revocation on an ipa server yet.
Any other debugging I can do just let me know.
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
1 month, 2 weeks
upgrade idm servers rhel 7 to 8 problems
by Natxo Asenjo
hi,
at work we are having *interesting* problems with our migration from idm
servers running rhel 7 to new rhel 8 idm servers.
We have a AD -> idm trust in place, this is working properly.
AD is domain.local
IDM is idm.domain.local
We add replicas to the set, and this runs properly. No replication errors.
Basically the problem is we cannot log in to newly joined systems running
rhel 8 as trusted users from AD.
We have a new rhel 8 idm server which has also the trust agent and trust
controller role installed.
We want to login as a trusted AD user to a rhel 8 host which has this new
rhel 8 idm server as its ipa host, we have forced it using this sssd.conf:
[domain/idm.domain.local]
id_provider = ipa
ipa_server = ds.idm.domain.local
ipa_domain = idm.domain.local
ipa_hostname = host.idm.domain.local
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
dyndns_update = True
dyndns_iface = ens192
krb5_store_password_if_offline = True
[sssd]
services = nss, pam, ssh, sudo
domains = idm.domain.local
full_name_format = %1$s
debug = 9
[nss]
homedir_substring = /home
override_homedir = /home/%u
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[session_recording]
We also modified krb5.conf on the client to find the IDM realm only on the
rhel 8 idm server, not the rhel 7. So we disabled srv dns autodiscovery for
the IDM.DOMAIN.LOCAL realm:
# cat /etc/krb5.conf
#File modified by ipa-client-install
includedir /etc/krb5.conf.d/
[libdefaults]
default_realm = IDM.DOMAIN.LOCAL
dns_lookup_realm = true
rdns = false
dns_canonicalize_hostname = false
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
IDM.DOMAIN.LOCAL = {
kdc = ds.idm.domain.local:88
master_kdc = ds.idm.domain.local:88
admin_server = ds.idm.domain.local:749
kpasswd_server = ds.idm.domain.local:464
default_domain = idm.domain.local
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
[domain_realm]
.idm.domain.local = IDM.DOMAIN.LOCAL
idm.domain.local = IDM.DOMAIN.LOCAL
host.idm.domain.local = IDM.DOMAIN.LOCAL
On the rhel 8 client, I can kinit with the host keytab, this work, I get a
ticket with the host principal.
I can also kinit using a trusted AD user, this works, I get a ticket of the
AD domain.
But as soon as I try logging in from ssh, it does not work. It does not
recognize the user.
Running id trusteduser@ad does not wok either (no such user)
I have run out of ideas, to be honest. I do not know how to troubleshoot
this anymore. The rhel8 idm server finds the users, I can log in there
without any problem too thanks to the rbac rules, but this rhel8 client
simpley will not see the users.
Any ideas?
Thanks in advance.
--
Groeten,
natxo
1 month, 2 weeks
cannot login into account after migration to 4.10.x
by Piotr Miedzik
Hi
I have problem with some users after updating freeipa server.
As of freeipa 4.10 I'm not able to login if user was created with uid specified (ipa user-add testx --uid=1001 --first=p --last=m --password)
It also doesn't work for accounts created with previous freeipa versions.
steps to reproduce:
1) install
podman run --rm -p 10.58.0.45:53:53/udp -p 10.58.0.45:53:53 -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp --name ipa01 -ti -h ipa01.dev.example.com -v /srv/ipa01-data/:/data:Z -e freeipa/freeipa-server:fedora-36-4.9.11
2) create account testx with uid
ipa user-add testx --uid=1001 --first=p --last=m --password
3) create account testy without uid
ipa user-add testy --first=p --last=m --password
4) upgrade to newest version
podman run --rm -p 10.58.0.45:53:53/udp -p 10.58.0.45:53:53 -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp --name ipa01 -ti -h ipa01.dev.example.com -v /srv/ipa01-data/:/data:Z -e freeipa/freeipa-server:fedora-38-4.10.3
user testx cannot login, user testy is able to login
1 month, 2 weeks
admin password changes when joing new replica
by Schweiss, Chip
I'm building out a multisite installation. For unknown reasons, the 'admin'
user password needs to be reset each time I join a new FreeIPA replica.
It seems to happen a minute or two after the ipa-replica-install
completes. Attempts to kinit immediately afterward usually works.
Here's my ipa-replica install command I'm using:
ipa-replica-install -n {domain} -r {realm} -d \
--server={existing_ipa_server} \
--setup-adtrust --add-agents --mkhomedir \
--ntp-pool={my_ntp_pool} \
-p $otp
How do I track down the cause of this?
-Chip
1 month, 2 weeks
Re: Using ipa-ca-install on a replica
by Ian Kumlien
On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien <ian.kumlien(a)gmail.com> wrote:
>
> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud <flo(a)redhat.com> wrote:
> >
> > Hi,
> >
> > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien <ian.kumlien(a)gmail.com> wrote:
> >>
> >> On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien <ian.kumlien(a)gmail.com> wrote:
> >> >
> >> > So... this one's new:
> >> >
> >> > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> >> > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> >> > Unspecified GSS failure. Minor code may provide more information
> >> > (Credential cache is empty)
> >
> >
> > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
>
> Ah, ok, i did do kdestroy -A but only on the new machine...
>
> A new issue that appeared, no user from the old machines can
> authenticate at all - still looking in to why it doesn't work
Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
Any clues?
> > flo
> >>
> >> > ---
> >> >
> >> > Just haven't seen it before... and it seems like the replica can't
> >> > install, unlike the two that worked before...
> >>
> >> And all of the sudden it just works again... weird...
> >>
1 month, 2 weeks
ipa-getkeytab fails
by Dmitry Krasov
Hello.
Centos 9 client
Trying get new keytab from ipa (ubuntu), by this command (after kinit):
ipa-getkeytab -s ipa.dom.loc -p host/clienthost.l3874.ru -k /etc/krb5.keytab
Failed to get key table file
"update-crypto-policies --set DEFAULT:AD-SUPPORT-LEGACY" doesn't help
On ubuntu clients " ipa-getkeytab --permitted-enctypes" shows:
AES-256 CTS mode with 96-bit SHA-1 HMAC
AES-128 CTS mode with 96-bit SHA-1 HMAC
AES-256 CTS mode with 192-bit SHA-384 HMAC
AES-128 CTS mode with 128-bit SHA-256 HMAC
Triple DES cbc mode with HMAC/sha1
ArcFour with HMAC/md5
Camellia-128 CTS mode with CMAC
Camellia-256 CTS mode with CMAC
But on Centos 9 are AES types only.
How can I add other 4 types?
1 month, 2 weeks
Re: Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
by Rob Crittenden
Kroon PC, Peter via FreeIPA-users wrote:
> Thanks for the super fast reply! I'll do my best to reply in-line, but I'm bound to outlook, which doesn't like it too much.
>
>>> Hi all!
>>>
>>> I'm working on updating my freeipa server from rocky 8 to 9. I'm playing around with a virtual machines as playground server and client, since I'd rather not break my everything right away. As part of this, I first installed ipa-server version 4.10.2-8.el9_3 on the server. Then I did an ipa-restore with a backup from my production ipa server (rocky 8, 4.9.12-11.module+el8.9.0+1652+4ee71f6a), followed by an ipa-server-upgrade. All is well so far (I think).
>
>> I don't know how you achieved this. ipa-restore attempts to prevent
>> using restore as a backdoor upgrade mechanism.
>
> It didn't complain /too/ much honestly. It saw the version mismatch between the backup and the installed server, asked for a "yes", and then happily went on its way. Is there a better way to achieve what I want/need?
Create a replica and disconnect it from the topology to have a sandbox.
>>> The client is running Debian bookworm with backports, where the latest ipa-client version is 4.9.11-1. Then, I went with the usual ipa-client-install --no-ntp, which fails with "Joining realm failed: Failed to parse result: PrincipalName not found." after retrieving the CA cert.
>>> The logs don't tell me much more, but the --debug flag does. It negotiates a JSON-RPC response, in which it says '{... "principal": "admin(a)EXAMPLE.COM", ...}'. I note that principal != PrincipalName. Also note, that on the server, the host /is/ added.
>>>
>>> So I guess my question is: how much version skew between server and client is supported?
>
>> Plenty. There isn't much to client enrollment and the API hasn't changed
>> significantly in a long time.
>
> Ok. Is there any other place I can look for what's going wrong?
The server httpd error log should have something about the request as
well as the client install log.
To get more details on the server side you can create
/etc/ipa/server.conf with the contents:
[global]
debug = True
Then restart httpd. Warning, it can be very verbose so I wouldn't leave
it like that for long in production.
rob
1 month, 2 weeks
Using ipa-ca-install on a replica
by Ian Kumlien
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-<machine> 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.fedorah...
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: ERROR Unable 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
And the log says:
2024-03-11T15:00:24Z DEBUG [4/28]: creating installation admin user
2024-03-11T15:00:24Z DEBUG Waiting 300 seconds for
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca to appear on
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z ERROR Unable to log in as
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z INFO [hint] tune with replication_wait_timeout
2024-03-11T15:05:24Z DEBUG Traceback (most recent call last):
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 686, in start_creation
run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 672, in run_step
method()
File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py",
line 789, in setup_admin
raise errors.NotFound(
ipalib.errors.NotFound:
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG [error] NotFound:
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG Removing /root/.dogtag/pki-tomcat/ca
2024-03-11T15:05:24Z DEBUG File
"/usr/lib/python3.12/site-packages/ipaserver/install/installutils.py",
line 781, in run_script
return_value = main_function()
^^^^^^^^^^^^^^^
File "/usr/sbin/ipa-ca-install", line 320, in main
install(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 286, in install
install_replica(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 214, in install_replica
ca.install(True, config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py",
line 354, in install
install_step_0(standalone, replica_config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py",
line 422, in install_step_0
ca.configure_instance(
File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py",
line 505, in configure_instance
self.start_creation(runtime=runtime)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 686, in start_creation
run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 672, in run_step
method()
File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py",
line 789, in setup_admin
raise errors.NotFound(
2024-03-11T15:05:24Z DEBUG The ipa-ca-install command failed,
exception: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
did not replicate to ldap://freeipa-1.xerces.lan:389
1 month, 3 weeks
Support for Azure AD authentication with on-prem AD forest-trust identities
by Jonathan Calmels
We have several deployments of RHEL IdM consisting of a cross-forest trust with on-prem MS Active Directory.
Users are able to login to the IdM resources with their Corporate AD credentials (i.e. password or existing AD ticket).
Users identities (including Posix attributes) are fetched from AD along with all their group information.
Recently we've had the need to support Azure AD authentication motivated by several factors such as cloud-joined clients and FIDO2 requirements.
In our case, Azure AD is partially synced with the on-prem AD through Azure AD connect.
Given our current deployments how can we achieve this?
Namely, how can we support AAD authentication on top of our current authentication with our user identities sourced from on-prem AD?
The first thing that comes to mind is the external IdP integration in IPA, however given the nature of its implementation, this requires that IdP identities are managed through IdM.
So what we need is effectively a way to link an IdM user (referenced by the IdP association) to an external trust user, which doesn't seem possible today.
We've tried several things, and glancing at the various software pieces of the IdM stack, this doesn't look supported. We might have missed something obvious though.
Nonetheless, the main ideas we had were:
1. Add a reference to the AD trust user in the IdM user through the use of Kerberos enterprise principals.
Here the idea is to define the IdM user (for IdP) with a canonical principal name set to the fully qualified trust user (i.e. ipa user-add idm_user --principal ad_user\\@ad_domain --idp-user-id aad_user@aad_domain)
This way SSSD could theoretically detect and use the trust user instead of the IdM one during authentication.
We've personally tried this but hit a few roadblocks (and this list is probably non-exhaustive):
- KDB returns KRB5KDC_ERR_WRONG_REALM on enterprise principals consisting of a trusted domain
- krb5_child responder would need to return the new user translation (i.e. aname_to_lname of ad_user\@ad_domain@IDM_REALM -> ad_user@ad_domain)
- To support the above, sssd_krb5_localauth_plugin would need to be aware of this specific case, or be disabled to simply strip IDM_REALM as opposed to returning the IdM user back (i.e. ad_user\@ad_domain@IDM_REALM -> idm_user)
- pam_sss would need to set PAM_USER to the result of this translation and use the resulting name for subsequent queries (similar to user hints in certificates)
- getAccountInfo would probably need tweaking too (not exactly sure)
2. Modify the trust IDView to include the IdP association and signal the fact that IdP authentication should be done through IdM and not the trusted KDC.
From there, I'm not sure how this would work on the IdM KDC side since there wouldn't be any existing principal to authenticate against (maybe matching enterprise principals could be created dynamically similar to 1.)
Hopefully there exists a simple solution for this use-case already, if not, I hope that the ask was clear enough.
Finally, note that this is somewhat related to the recent talks at FOSDEM, specifically https://fosdem.org/2024/schedule/event/fosdem-2024-2587-posix-identities-....
Also, another way around this could be to support WHfB / Cloud Kerberos trust on Linux, but this is somewhat orthogonal to the above.
1 month, 3 weeks