November 2021 - FreeIPA-users - Fedora mailing-lists

Academic 'dependency' research / freeipa
by Harry G. Coin 12 Nov '21

12 Nov '21

I think freeipa represents something of a research opportunity. Among all the 'functional subsystem packages' out there, freeipa is the 'tallest pyramid with the widest base' I'm aware of. By that I mean it has the largest number of dependencies which themselves are also subsystems (over against libraries with little more than libc/kernel dependencies); and that in order to be considered 'up and useful' all of the subsystems contribute to the necessary 'running properly' condition. In fact many of the subsystems freeipa relies upon are themselves reliant on what you might call 'functional subsystems'. You might argue a 'distro' or a GUI environment would be better, but that's more like a collection of shorter pyramids where the 'breakage' of one doesn't materially impact the others. A hypothesis worth getting actual metrics on would be how often it would appear 'freeipa breaks upon install' and 'freeipa breaks upon upgrade' when installed via a stream-style release, over against 'vm' or 'docker' releases, and that over against 'lts/rhel/centos' vs fedora. Over the coming decades, a question needs resolving-- how high a 'brick wall' is possible and sustainable (where each 'brick' is a dependency) and what can be done to make 'higher walls' more reliable? Because each subsystem represents thousands of hours of focused labor, and that packaged and made available to other developers faced with either re-creating the function or using the subsystem. Presently we're faced with the smallest changes in a dependency corrupting a database upon 'upgrade', or some seeming trifle breaking the ui, etc. I suppose it would lead to a 'so, then, with that, now what?' question -- and that would be really interesting as well. So, there's a Monday morning idea. Harry Coin

3 6

Trust between FreeIPA servers
by FreeIPA Question 12 Nov '21

12 Nov '21

Hi all, I was wondering if it would be possible to create a trust relation between two FreeIPA servers. I've read a lot about a trust relation between FreeIPA and Microsoft AD, however I'd like to set up a trust between FreeIPA and FreeIPA. The use case I'm trying to cover: I'm maintaining multiple environments at different clients and I'd like to be able to log in with my credentials in systems of clients while separating users at the client. Ideally I'd set up a FreeIPA for mycomany.com and make a trust with a FreeIPA for myclient.com. The users at mycompany.com should be able to log in on systems that are enrolled on myclient.com. The users of the client are stored in the IPA server of myclient.com. Thanks in advance for your help!

2 1

Trust between FreeIPA servers
by freeipaquestion 12 Nov '21

12 Nov '21

Hi all, I was wondering if it would be possible to create a trust relation between two FreeIPA servers. I've read a lot about a trust relation between FreeIPA and Microsoft AD, however I'd like to set up a trust between FreeIPA and FreeIPA. The use case I'm trying to cover: I'm maintaining multiple environments at different clients and I'd like to be able to log in with my credentials in systems of clients while separating users at the client. Ideally I'd set up a FreeIPA for mycomany.com and make a trust with a FreeIPA for myclient.com. The users at mycompany.com should be able to log in on systems that are enrolled on myclient.com. The users of the client are stored in the IPA server of myclient.com. Thanks in advance for your help! Sent with [ProtonMail](https://protonmail.com/) Secure Email.

1 0

Revert web cert from 3rd party to internal ca
by Dungan, Scott A. 11 Nov '21

11 Nov '21

Hi All After deploying FreeIPA with an embedded self-signed CA, the ipa servers were configured to use commercially signed, 3rd party certificates for the HTTP service only. The directory server was left default. This was accomplished by importing the external CA and then the signed certificate, following the instructions on freeipa.org: ipa-cacert-manage -t C,, install InCommon_interm.cer ipa-certupdate ipa-server-certinstall --http /var/lib/ipa/private/httpd.key /var/lib/ipa/private/InCommon_signed.cer ipactl restart A commercially signed web certificate on the ipa servers is no longer required and we would like to revert back to using certificates from the freeipa self-signed CA. Is there a way to do so? Regards, Scott

1 0

External CA causing issues on Ubuntu Clients
by Russ Long 11 Nov '21

11 Nov '21

I am using SSL issued by external CA (Godaddy) for my FreeIPA servers. I have installed the cert using the IPA cert installation tools, however on Ubuntu 20.04 clients, I receive the following error: ``` Setting up ca-certificates (20210119~20.04.2) ... Updating certificates in /etc/ssl/certs... sed: can't read /usr/local/share/ca-certificates/ipa-ca/CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US 0.crt: No such file or directory ``` This error is seen when trying to perform package updates on these servers. The only workaround I have found so far is to uninstall the freeipa client, run my package updates, then re-install the client. This is obviously not an ideal solution. Here's the commands used to install the certs: ipa-cacert-manage -p {{ ipa_dirman_pass }} -n GoDaddyBundle2019 -t C,, install /opt/ipa-ssl/godaddy.ca.crt ipa-server-certinstall -w -d /opt/ipa-ssl/ipa.domain.key /opt/ipa-ssl/ipa.domain.crt --dirman-password={{ ipa_dirman_pass }} --pin='' ipa-certupdate Certs and all other clients appear to work without issue. IPA Server version: ipa-server-4.6.8-5.el7.centos.7.x86_64 IPA Client version: freeipa-client 4.8.6-1ubuntu2

2 2

[SSSD] Announcing SSSD 2.6.1
by Pavel Březina 09 Nov '21

09 Nov '21

# SSSD 2.6.1 The SSSD team is proud to announce the release of version 2.6.1 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.6.1 See the full release notes at: https://sssd.io/release-notes/sssd-2.6.1.html RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users ## Highlights ### New features * New infopipe method `FindByValidCertificate()` which accepts the certificate as input, validates it against configured CAs, and outputs the user path on success. This is similar to the existing `FindByCertificate()`, but that does not do any trust validation. ### Packaging changes * `subid ranges` support was enabled by default. ### Configuration changes * Default value of `ssh_hash_known_hosts` setting was changed to false for the sake of consistency with OpenSSH that does not hash host names by default.

1 0

Cannot access IPA Web UI since the last update on RHEL 8
by Mathieu Baudier 09 Nov '21

09 Nov '21

Hello, On (self-supported) RHEL 8, since the last update, we are not able to login to the Web UI anymore. IPA package version is: 4.9.2-4.module+el8.4.0+11156+94d209c1 In Firefox we get: IPA Error 903: InternalError an internal error has occurred and then: Web UI got in unrecoverable state during "metadata" phase. In the httpd error log we see: [Sat Nov 06 07:05:05.971287 2021] ipa: ERROR: non-public: KeyError: 'ipatrustedaddomainrange' [Sat Nov 06 07:05:05.971311 2021] Traceback (most recent call last): [Sat Nov 06 07:05:05.971315 2021] File "/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 397, in wsgi_execute [Sat Nov 06 07:05:05.971317 2021] result = command(*args, **options) [Sat Nov 06 07:05:05.971320 2021] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 471, in __call__ [Sat Nov 06 07:05:05.971322 2021] return self.__do_call(*args, **options) [Sat Nov 06 07:05:05.971324 2021] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 499, in __do_call [Sat Nov 06 07:05:05.971327 2021] ret = self.run(*args, **options) [Sat Nov 06 07:05:05.971329 2021] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 821, in run [Sat Nov 06 07:05:05.971331 2021] return self.execute(*args, **options) [Sat Nov 06 07:05:05.971334 2021] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/internal.py", line 126, in execute [Sat Nov 06 07:05:05.971336 2021] (o.name, json_serialize(o)) for o in self.api.Object() [Sat Nov 06 07:05:05.971339 2021] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/internal.py", line 127, in <genexpr> [Sat Nov 06 07:05:05.971341 2021] if o is self.api.Object[o.name] [Sat Nov 06 07:05:05.971343 2021] File "/usr/lib/python3.6/site-packages/ipalib/util.py", line 106, in json_serialize [Sat Nov 06 07:05:05.971346 2021] return json_serialize(obj.__json__()) [Sat Nov 06 07:05:05.971348 2021] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/baseldap.py", line 889, in __json__ [Sat Nov 06 07:05:05.971351 2021] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) [Sat Nov 06 07:05:05.971353 2021] File "/usr/lib64/python3.6/site-packages/ldap/schema/subentry.py", line 378, in attribute_types [Sat Nov 06 07:05:05.971355 2021] object_class = self.sed[ObjectClass][object_class_oid] [Sat Nov 06 07:05:05.971368 2021] KeyError: 'ipatrustedaddomainrange' In order to analyse, we configured /etc/ipa/server.conf as: [global] debug=true and restarted IPA. And it is sometimes working again (not clear whether this is thanks to this file, or because of the restart), but then after a while it is failing again. We ran ipa-server-upgrade manually (successful). All ipa services are up, Kerberos login works fine. ipa-healthcheck does not return any warning or error. We are *not* using AD integration at all. The package ipa-server-trust-ad is not installed. Does this ring a bell to you? How should we analyse further? Thanks in advance for your help! Mathieu

2 5

cannot find name for group ID x when logging in
by Mark Johnson 07 Nov '21

07 Nov '21

Got my authentication working and I populated my directory with users and groups and assigned group memberships accordingly. I wasn't getting this issue originally, but now I'm suddenly getting the "cannot find name for group ID 10000" when I log in to my test server. The group with GID 10000 is a POSIX enabled group I created called "users" that all user accounts are a member of. My user account is a member of a handful of other POSIX enabled groups. Another of these groups is called "admins" and has a GID of 10001. There's also "serveradmins" (GID -> 500) and "devserveraccess" (GID -> 501). If I issue an "id", it shows all of these groups, but doesn't show the names of GID 10000 and GID 10001, eg $ id uid=1069(markj) gid=10000 groups=10000,2(daemon),500(serveradmins),501(devserveraccess),10001 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 However, if I do a "getent group" I can see all of these groups and their members, eg serveradmins:*:500:markj,user4 devserveraccess:*:501:markj,user1,user4 users:*:10000:user1,user2,markj,user4 admins:*:10001:admin,markj I have a suspicion as to what might be at play here. Keep in mind that I've set up the new directory using all the same info (usernames, groups, UIDs, GIDs etc) from the existing 389 DS directory. Just looking through this, I see we have a user with a UID of 10000, and another with a UID of 10001. We don't have any with UID of 500 or 501. If I look at the full "getent group" output, it shows the above groups I've already mentioned but also lists all the users, including the two with ID 10000 and 10001. I'm suspecting this is causing some kind of conflict. If I change my user account's GID to 100 (the normal built-in local 'users' group), I can log in without getting this error. The only issue with this is we've been running on this old 389 directory since well before I joined the company so there are many years worth of home directories and user files with the group owner of '10000' which is now not going to show a group name. Not sure if this is going to cause any issues dow n the line, probably only an aesthetics thing.

2 2

Fail to restart ipa server after ipa packages updates
by MERCIER Jonathan 07 Nov '21

07 Nov '21

Dear, After a package update from ipa-server-4.9.2-4.module+el8.4.0+589+9650b94f.x86_64 to ipa-server-4.9.2-4.module+el8.4.0+664+1636a961.x86_64 I am unable to restart ipa server services indeed the command /usr/sbin/ipa-server-upgrade fail as it is not able to reach 'https://ipa.somewhere.com:8443/ca/rest/account/login' . Indeed the dns service is on the same server and is started by ipa services. below a piece of log Thanks for your help Best regards -------- IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: NetworkError: cannot connect to 'https://ipa.somewhere.com:8443/ca/rest/account/login': [Errno 113] No route to host The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade again Stopping ipa-dnskeysyncd Service Stopping ipa-otpd Service Stopping pki-tomcatd Service Stopping ipa-custodia Service Stopping httpd Service Stopping named Service Stopping kadmin Service Stopping krb5kdc Service Stopping Directory Service ----

3 6

RA Agent certificate authorisation fails – how to debug?
by Tomasz Torcz 05 Nov '21

05 Nov '21

Hi, I've encountered some authentication problems with my FreeIPA installation, which I've traced to RA Agent certification auth problems. I've done typical steps to verify certs in LDAP and hit a wall. Please suggest further steps. My setup is 2 masters on Fedora 34: freeipa-server-4.9.6-2.fc34.x86_64 pki-base-10.10.6-1.fc34.noarch Steps I've done: First I noticed problems when enabling ACME: $ ipa-acme-manage enable Failed to authenticate to CA REST API The ipa-acme-manage command failed. This is caused by authentication failure (401 return code), which I confirmed using curl: $ curl -X POST https://kaitain.pipebreaker.pl:8443/acme/enable --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key <!doctype html><html lang="en"><head><title>HTTP Status 401 – Unauthorized</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 401 – Unauthorized</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Description</b> The request has not been applied because it lacks valid authentication credentials for the target resource.</p><hr class="line" /><h3>Apache Tomcat/9.0.52</h3></body></html> Errors from catalina.out: 02-Oct-2021 16:29:39.618 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ExternalAuthenticationValve.invoke ExternalAuthenticationValve: authType: null 02-Oct-2021 16:29:39.618 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ExternalAuthenticationValve.invoke ExternalAuthenticationValve: principal: null 02-Oct-2021 16:29:39.620 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate PKIAuthenticator: Authenticate with client certificate authentication 02-Oct-2021 16:29:39.620 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ProxyRealm.authenticate Authenticating certificate chain: 02-Oct-2021 16:29:39.621 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ProxyRealm.authenticate - CN=IPA RA,O=PIPEBREAKER.PL 02-Oct-2021 16:29:39.621 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ProxyRealm.authenticate - CN=Certificate Authority,O=PIPEBREAKER.PL 02-Oct-2021 16:29:39.624 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate PKIAuthenticator: Result: false I've made sure that /var/lib/ipa/ra-agent.pem is the same as in LDAP. $ openssl x509 -in /var/lib/ipa/ra-agent.pem -noout -text | grep Serial Serial Number: 105 (0x69) $ ldapsearch -o ldif_wrap=no -D "cn=directory manager" -W -b o=ipaca "(uid=ipara)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <o=ipaca> with scope subtree # filter: (uid=ipara) # requesting: ALL # # ipara, people, ipaca dn: uid=ipara,ou=people,o=ipaca description: 2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O=PIPEBREAKER.PL userCertificate;binary:: <SNIPPED> cn: ipara objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser usertype: agentType sn: ipara uid: ipara userstate: 1 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem. This is the same certificate; serial number matches, too. Certificate is NOT expired: $ openssl x509 -in /var/lib/ipa/ra-agent.pem -noout -dates notBefore=Jun 16 04:34:42 2021 GMT notAfter=Jun 6 04:34:42 2023 GMT What should I do next to resolve this authentication issue? -- Tomasz Torcz Morality must always be based on practicality. tomek(a)pipebreaker.pl — Baron Vladimir Harkonnen

3 19

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2021