/etc/ipa/nssdb label
by Sam Morris
Hi folks
I've got a container image into which I bind mount /etc/ipa so that
freeipa-client works.
I noticed[0] that /etc/ipa/nssdb is not accessible inside the container,
because it is labelled with cert_t. SELinux policy prevents container_t
from reading files labelled with cert_t.
As I understand it /etc/ipa/nssdb is there so that clients using NSS can
find the IPA CA certificate. and /etc/ipa/ca.crt is there so that
OpenSSL-using clients can find the certificate.
If that is the case then I think both files/dirs should be labelled
consistently, with etc_t. If so shall I file an issue (and where,
FreeIPA or selinux-policy[1]?)
# matchpathcon /etc/ipa/*
/etc/ipa/ca.crt system_u:object_r:etc_t:s0
/etc/ipa/default.conf system_u:object_r:etc_t:s0
/etc/ipa/nssdb system_u:object_r:cert_t:s0
[0] <https://bugzilla.redhat.com/show_bug.cgi?id=2141311>
[1]
<https://github.com/fedora-selinux/selinux-policy/blob/a3b543d959064d8384e...>
Regards,
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
1 year, 5 months
External IDP Configuration with Okta
by Russ Long
Hello,
I am working on a test environment to test the integration of Okta as an external IDP. According to the docs, this is supported, however there is no okta-specific documentation that I can find.
I have okta configured as follows:
[root@ipa-primary ~]# ipa idp-show okta
Identity Provider server name: okta
Authorization URI: https://ORGNAME.okta.com/oauth2/v1/authorize
Device authorization URI: https://ORGNAME.okta.com/oauth2/v1/device/authorize
Token URI: https://ORGNAME.okta.com/oauth2/v1/token
User info URI: https://ORGNAME.okta.com/oauth2/v1/userinfo
Client identifier: CLIENTID
Scope: openid email
External IdP user identifier attribute: email
I also have the Secret configured, as the Okta side is configured to require the secret.
When I attempt to perform a login operation using a user configured for this external IDP, I get the following errors (partially redacted for brevity and security):
Nov 09 14:58:43 ipa-primary.ipa.DOMAIN.COM oidc_child[5749]: libcurl: > POST /oauth2/v1/device/authorize HTTP/2
Host: ORGNAME.okta.com
user-agent: SSSD oidc_child/0.0
accept: application/json
content-length: 49
content-type: application/x-www-form-urlencoded
Nov 09 14:58:43 ipa-primary.ipa.DOMAIN.COM oidc_child[5749]: {"error":"invalid_client","error_description":"Client authentication failed. Either the client or the client credentials are invalid."}
Is there any Okta-specific documentation I can reference, or does anyone know where my configuration issue may be?
Thanks,
Russ
1 year, 6 months
IPA-Error 903: InternalError on Certificate page
by Nico Maas
Dear all,
I am using FreeIPA, Version: 4.8.4 on CentOS 8
ipa-client.x86_64 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-client-common.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-common.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-healthcheck-core.noarch 0.4-4.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-server.x86_64 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-server-common.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-server-dns.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
Whenever I open the "Authentication" tab in the freeIPA webserver, I get the error
"IPA-Error 903: InternalError. An internal error has happend".
Retry does not help, within Authentication I can use all tabs, except from the Authentication -> Certificate -> Certificate one. This one gives the error. I can also not search for a certificate. The other areas of Authentication -> Certificate (Certificate Profiles, CA ACLS, Certificate Authorities) work without problems.
As a test I cloned the machine and updated it to the latest CentOS 8 version with a newer freeIPA version on it, but that did not solve the problem and I scrapped this vm and idea again.
Any idea on how to resolve the issue / what could be broken?
Which logs and things would be useful to look into?
Thanks a lot for your help and have a nice day
Nico
1 year, 6 months
IPA Client / access from another domain and realm possible ?
by Karim Bourenane
Hello Team
Im on CentOS 7.9, with IPA server under 4.6.8.
My IPA server manages a domain/realm AAA.com. I would like it to be
accessible also via ssh from another domain/realm BBB.com and also to use
Kerberos token from BBB.com to use sudo management.
It possible ?
How should I proceed? If you could help me please.
Bien à vous
Mr Karim Bourenane
1 year, 6 months
ds-replcheck error after updating today
by Steve Huston
I'm running Springdale 7 (a RHEL derivative). I have three IPA
servers in a multi-master configuration with schema-compat-plugin
turned on (old NIS-based netgroup authorization for NFS mounts which
has carried over to newer file servers as well).
Last week I updated these packages when they became available in the repo:
Nov 03 10:50:43 Updated: 389-ds-base-libs-1.3.10.2-17.el7_9.x86_64
Nov 03 10:50:59 Updated: 389-ds-base-1.3.10.2-17.el7_9.x86_64
Nov 03 10:50:59 Updated: 389-ds-base-snmp-1.3.10.2-17.el7_9.x86_64
This morning I updated these:
Nov 07 09:51:26 Updated: ipa-common-4.6.8-5.el7_9.12.noarch
Nov 07 09:51:27 Updated: ipa-client-common-4.6.8-5.el7_9.12.noarch
Nov 07 09:51:27 Updated: ipa-server-common-4.6.8-5.el7_9.12.noarch
Nov 07 09:51:27 Updated: python2-ipalib-4.6.8-5.el7_9.12.noarch
Nov 07 09:51:28 Updated: python2-ipaclient-4.6.8-5.el7_9.12.noarch
Nov 07 09:51:28 Updated: python2-ipaserver-4.6.8-5.el7_9.12.noarch
Nov 07 09:51:30 Updated: ipa-client-4.6.8-5.el7_9.12.x86_64
Nov 07 09:51:30 Updated: slapi-nis-0.60.0-1.el7_9.x86_64
Nov 07 09:51:31 Updated: ipa-server-4.6.8-5.el7_9.12.x86_64
Others were updated as well, but I don't believe they were relevant.
After updating the group of packages today, I ran a replication check
from the machine I consider the "primary master", which was not the
one that I'd updated. 'repl-monitor' completed successfully and
showed everything was connected and working. However, ds-replcheck
when involved with the newly-upgraded server reported differences in
the replication. Specifically everything in the "cn=compat" subtree
was missing from the upgraded host, and strangely so is "ou=sudoers"
which is empty anyway but I don't recall it being missing in the
replication check before.
I eventually checked the directory itself, and found that while
ds-replcheck reports those replicas as missing, they do exist on the
updated server and are retrievable. I picked one of the entries from
the output of ds-replcheck and used 'ldapsearch' to view it on both
the master and the replica, and got the same answer from both. So it
appears that the data does exist, but ds-replcheck isn't finding it.
If I limit the base DN for the replication check to "cn=compat" from
any of the hosts I get the error that it is not replicated.
After a bit of digging around I see that the slapi-nis upgrade may
include quite a bit of differences from 0.56.5 to 0.60.0 though I'm
not sure how many of those were backported to the RPM before.
I've halted updating machines until I figure out this discrepancy
since I don't want to make things worse. At the moment I'm not sure
how many (if any) hosts are querying this one server - I don't have
nearly as many on the network as I used to so the three servers is
more for redundancy than load balancing - but I'm not seeing errors
from machines so I'm leaving it up.
Can anyone shed some light on this? Is this a real problem or just an
indicator of a change in slapi-nis that means ds-replcheck will error
until I upgrade the other two hosts as well, and then they'll all
agree?
--
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
Princeton University | ICBM Address: 40.346344 -74.652242
345 Lewis Library |"On my ship, the Rocinante, wheeling through
Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1'
1 year, 6 months
using custom 389ds package
by dweller dweller
I need to use recompiled with "-fno-omit-frame-pointer" version of 389ds server for test purposes as a part of FreeIPA. How would I approach such installation.
I navigated through freeipa code on github and didn't find exactly the point where FreeIPA handles installation of packages (bind, 389-ds, dogtag etc).
Can someone give me a hint on how to approach this?
1 year, 6 months
Cannot obtain CA certificate
by Ronald Wimmer
When trying to enroll some IPA clients (RHEL 7.9) I do get the following
error:
Cannot obtain CA certificate
'ldap://pipag01.linux.gleis.at' doesn't have a certificate.
Installation failed. Rolling back changes.
LDAP(S)/HTTP(S) ports are open.
What's going on here? How can I debug further?
Cheers,
Ronald
1 year, 6 months
LoadBalancer vs. DNS
by Ronald Wimmer
IPA heavily relies on DNS entries. In my opinion, this design makes it
more difficult to quickly disable one or more IPA servers - especially
when using IPA in combination with external DNS (managed by a different
department).
Would it be possible to put all relevant DNS entries on a Loadbalancer
VIP and let the LB resolve to all IPA servers?
e.g. instead of having 8 DNS entries for
_kerberos-master._tcp.linux.oebb.at for every of our 8 IPA servers I
would have just one _kerberos-master._tcp.linux.oebb.at entry. The LB
would distribute requests in such a setup.
Is it possible to do that or would it break some IPA functionality?
Cheers,
Ronald
1 year, 6 months
IPA API - Fetch keytab
by Ronald Wimmer
In order to integrate our AIX clients we do have to take two steps manually:
1) Enrolling the host
2) Fetching the keytab file for this particular host
A quick search in the WebGUIs API browser revealed a host_add method but
I cannot find a method for fetching a keytab file. Did I miss something
here?
Cheers,
Ronald
1 year, 6 months
Migrating from RHEL 7 IDM to Fedora 36 FreeIPA: passwords and root CA
by Martin Gignac
Hello,
I would like to take a RedHat IDM installation running on RHEL 7 and migrate it to a Fedora 36 installation running FreeIPA. Since the jump in version is too big to simply make the Fedora 36 server a replica of the RHEL 7 installation, and since I'd like to change the domain name from 'country.example.com' to 'example.com', I've decided to use the API to extract users and groups from the RHEL installation and populate them in the Fedora 36 server. The Python script I wrote to run this seems to work fine. However I am left with two remaining things I would like to migrate: passwords and the root CA certificate.
1. Is there a way to transfer over the hashed passwords from the RHEL 7 install to the Fedora 36 one? (I expect that the answer will be "no", but I gotta ask anyway!)
2. Is there away to extract the root CA from the RHEL 7 install and use it as the root CA for all generated certificates on the Fedora 36 one? I would like to keep the same root CA so that I don't have to go and change that certificate on all of my LDAPS clients.
Thanks for any hints, tips or guidance you can provide!
-Martin
1 year, 6 months