FreeIPA-users July 2023

freeipa-users@lists.fedorahosted.org

31 participants
57 discussions

Where is root CA private key stored?
by Ian Pilcher 05 Jul '23

05 Jul '23

(Hopefully Thunderbird will only send one copy of this. Sorry about the previous duplicate.) I run a single FreeIPA server (on CentOS 7) in my home network, and I'm thinking of migrating it to Fedora. AFAICT, doing this as an actual upgrade will require multiple cycles of creating a newer FreeIPA server, adding it as a replica, removing the older server, lather, rinse, repeat. I'm only using FreeIPA for its DNS, certificate authority, and LDAP authentication capabilities, and my home network isn't that large, so I'm considering simply installing a new server and re-creating the various users, hosts, services, and DNS zones/entries. (I don't have any systems that are truly managed with FreeIPA.) Thus, it would be nice if the new FreeIPA server could use the same root CA certificate as the existing one. I believe that I can do this by passing the --external-cert-file option to ipa-server-install, but I need both the certificate and the private key of the root CA to do so. Thus, I'm wondering how I can extract the root CA private key from my existing CentOS 7 (FreeIPA 4.6.8) server. Thanks! -- ======================================================================== Google Where SkyNet meets Idiocracy ========================================================================

2 4

Active Directory domain range with bad ID range
by Harald Dunkel 03 Jul '23

03 Jul '23

Hi folks, I have found an Active Directory domain range in my FreeIPA setup using -1 as the first Posix ID: Range name: EXAMPLE.COM_subid_range First Posix ID of the range: 2147483648 Number of IDs in the range: 2147352576 First RID of the corresponding RID range: 2147283648 Domain SID of the trusted domain: S-1-5-21-738065-838566-194929194 Range type: Active Directory domain range The GUI shows a warning about this, see https://pagure.io/freeipa/issue/9408. Is it save to kick out this ID range? AFAICS there are no users or groups defined using an ID out of this range. And there is not trust relationship to an AD server. Every insightful comment is highly appreciated Harri

2 1

struggling with RID base on migration from CentOS 7 to 8
by Harald Dunkel 03 Jul '23

03 Jul '23

Hi folks, still trying to migrate from Centos7 to 8 I get an error message from ipa-replica-install on the first CentOS 8 host saying : Finalize replication settings Restarting the KDC Configuring SID generation [1/7]: creating samba domain object Samba domain object already exists [2/7]: adding admin(group) SIDs Admin SID already set, nothing to do Admin group SID already set, nothing to do [3/7]: adding RID bases Found more than one local domain ID range with no RID base set. [error] RuntimeError: Too many ID ranges Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Too many ID ranges The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information The existing servers running CentOS 7 show a huge set of irritating error messages in their ipareplica-install.log, e.g. [01/Jul/2023:14:28:21.640127492 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:28:21.643664115 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:28:28.521873989 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:28:28.533330535 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:28:28.586507750 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToipaca8.example.com" (ipaca8:389) - Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) () [01/Jul/2023:14:28:28.592028265 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:28:28.596813608 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:28:28.634530928 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToipaca8.example.com" (ipaca8:389): Replication bind with GSSAPI auth resumed [01/Jul/2023:14:28:29.734133911 +0200] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=meToipaca8.example.com" (ipaca8:389)". [01/Jul/2023:14:28:29.879962503 +0200] - ERR - NSMMReplicationPlugin - check_flow_control_tot_init - agmt="cn=meToipaca8.example.com" (ipaca8:389) - Total update flow control gives time (2000 msec) to the consumer before sending more entries [ msgid sent: 1273, rcv: 272]) If total update fails you can try to increase nsds5ReplicaFlowControlPause and/or decrease nsds5ReplicaFlowControlWindow in the replica agreement configuration [01/Jul/2023:14:28:37.172991476 +0200] - INFO - NSMMReplicationPlugin - repl5_tot_run - Finished total update of replica "agmt="cn=meToipaca8.example.com" (ipaca8:389)". Sent 2450 entries. [01/Jul/2023:14:28:37.184680247 +0200] - ERR - NSMMReplicationPlugin - agmt="cn=meToipaca8.example.com" (ipaca8:389): Total update flow control triggered 2 times You may increase nsds5ReplicaFlowControlPause and/or decrease nsds5ReplicaFlowControlWindow in the replica agreement configuration [01/Jul/2023:14:28:39.292861041 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:28:42.238638987 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:28:45.252557867 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:28:48.099823076 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:28:51.115124375 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:28:54.569369909 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:28:55.372406568 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:28:55.375939992 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:28:55.401821331 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:28:55.405166233 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:28:57.163613285 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:29:00.163149244 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [01/Jul/2023:14:29:03.169779479 +0200] - WARN - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [01/Jul/2023:14:29:06.194564448 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToipaca8.example.com" (ipaca8:389): Replication bind with GSSAPI auth resumed [01/Jul/2023:14:29:12.781739365 +0200] - WARN - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [01/Jul/2023:14:29:15.828272021 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToipaca8.example.com" (ipaca8:389): Replication bind with GSSAPI auth resumed [01/Jul/2023:14:29:22.331677615 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:29:22.336648109 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:29:22.381929587 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:29:22.385856628 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:29:39.014631450 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:29:39.018564522 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:29:39.060413149 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:29:39.063778450 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:29:57.610268113 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:29:57.641460597 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:29:57.646901146 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:29:57.650273580 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:29:57.966813928 +0200] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=caToipaca8.example.com" (ipaca8:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [01/Jul/2023:14:29:58.254056287 +0200] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=caToipaca8.example.com" (ipaca8:389)". [01/Jul/2023:14:30:07.529903162 +0200] - INFO - NSMMReplicationPlugin - repl5_tot_run - Finished total update of replica "agmt="cn=caToipaca8.example.com" (ipaca8:389)". Sent 812 entries. [01/Jul/2023:14:30:21.240947781 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:30:21.258555098 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:30:21.265646281 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:30:21.269315594 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:30:30.822736296 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:30:30.826194504 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:31:23.431259302 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:31:23.434660242 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:31:23.460663707 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:31:23.463998899 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:31:27.728622122 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:31:27.731885674 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:32:21.101350084 +0200] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Attempting to release replica, but unable to receive endReplication extended operation response from the replica. Error -1 (Can't contact LDAP server) [01/Jul/2023:14:32:24.721580643 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToipaca8.example.com" (ipaca8:389): Replication bind with GSSAPI auth resumed [01/Jul/2023:14:32:36.926940968 +0200] - WARN - NSMMReplicationPlugin - acquire_replica - agmt="cn=caToipaca8.example.com" (ipaca8:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [01/Jul/2023:14:32:37.826884159 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:32:37.832202241 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:32:37.849761419 +0200] - ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct. [01/Jul/2023:14:32:37.853061285 +0200] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 140]: Failed to get ID ranges. [01/Jul/2023:14:32:43.233314167 +0200] - WARN - NSMMReplicationPlugin - acquire_replica - agmt="cn=meToipaca8.example.com" (ipaca8:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [01/Jul/2023:14:33:00.770698631 +0200] - ERR - repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "20100614120000" remote server: "(null)". [01/Jul/2023:14:33:01.189340299 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToipaca8.example.com" (ipaca8:389): Replication bind with GSSAPI auth resumed [01/Jul/2023:14:33:21.446637163 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=caToipaca8.example.com" (ipaca8:389): Replication bind with GSSAPI auth resumed Looking at this I don't have the impression that FreeIPA 4.6.8 (CentOS7) and 4.9.11 (CentOS8) work very well together. Esp I am concerned about the "Failed to convert LDAP entry to range struct". That seems to be exactly the item causing all that trouble. Just to be sure, I had increased the domainlevel to 1, as recommended in the migration gitelines: [root@ipa1 ~]# ipa domainlevel-get ----------------------- Current domain level: 1 ----------------------- Trying to manually set the base RID on CentOS7 I get: [root@ipa1 ~]# ipa idrange-find --raw ---------------- 3 ranges matched ---------------- cn: EXAMPLE.COM_id_range ipabaseid: 379400000 ipaidrangesize: 200000 iparangetype: ipa-local cn: EXAMPLE.COM_posix ipabaseid: 1000 ipaidrangesize: 99000 iparangetype: ipa-local cn: EXAMPLE.COM_subid_range ipabaseid: 2147483648 ipaidrangesize: 2147352576 ipabaserid: 2147283648 ipanttrusteddomainsid: S-1-5-21-738065-838566-194929194 iparangetype: ipa-ad-trust ---------------------------- Number of entries returned 3 ---------------------------- [root@ipa1 ~]# ipa idrange-mod --rid-base=1000 EXAMPLE.COM_posix ipa: ERROR: This command can not be used to change ID allocation for local IPA domain. Run `ipa help idrange` for more information Some doc on the net recommended to try setting the missing Base RID using ldapmodify. Won't that put my existing CentOS 7 hosts at risk? How can I get out of this nightmare? Every helpful comment is highly appreciated Harri

2 3

Broken plugin for FreeIPA Help Please
by Günther J. Niederwimmer 03 Jul '23

03 Jul '23

Hello FreeIPA list, I got the ipa module freeipa-user-mailalternateaddress-master from github, unfortunately the paths have apparently changed (version 9.2) with the IPA version 4.10.1 API version 2.251 one of YOU can change the script so that the files are back in the right PATHS come. I can't tell if it still works, but it's worth a try! Thanks for replies and help. -- mit freundlichen Grüssen / best regards, Günther J. Niederwimmer

2 3

Re: FIPs enabled Install Fails
by Entrepreneur AJ 02 Jul '23

02 Jul '23

Thank you for the response Christian. I would rather not use FIPs at all but looks like it's going to become a requirement with me going into the financial industry. I will submit it on Pagure 2 Jul 2023 18:04:52 Entrepreneur AJ <aj(a)eajglobal.com>: > Thank you for the response Christian. > > I would rather not use FIPs at all but looks like it's going to become a requirement with me going into the financial industry. > > I will submit it on Pagure > > 2 Jul 2023 17:59:20 Christian Heimes via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>: > >> On 02/07/2023 12.21, Entrepreneur AJ via FreeIPA-users wrote: >>> I today spun up a fresh Fedora 38 VPS on Vultr and started the FreeIPA Server install. >>> This VPS has been switched to FIPs enabled. >>> I have then tried to install the latest FreeIPA server from DNF without the DNS package. >>> All was going well until it got to step 17 of 30 and outputted the following: >>> [17/30]: requesting RA certificate from CA >>> [error] CalledProcessError: CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmpfufotvvx', '-passin', 'file:/tmp/tmpwdlfgkkt'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n') >>> CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmpfufotvvx', '-passin', 'file:/tmp/tmpwdlfgkkt'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n') >>> The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information >>> Any pointers on how to get passed this bit? >> >> Could you please report the problem at https://pagure.io/freeipa/issues ? The problem is probably to related to this PKCS#12 bug https://github.com/openssl/openssl/issues/19997 >> >> I recommend against installing FreeIPA in FIPS mode. Fedora is neither FIPS compliant nor FIPS certified. Fedora's FIPS mode doesn't give you any benefits, just more pain and trouble. In some cases it's also *less* secure, because some algorithms and features are disabled in FIPS mode. >> >> Further more there is very limited testing of FreeIPA in FIPS mode. A FreeIPA installation FIPS mode can break any time. You'll have more luck with CentOS Stream or a free developer license of RHEL. They'll get you closer to FIPS compliance. (IIRC even RHEL 9 isn't FIPS 140-3 certified, yet.) >> >> Christian >> >> -- >> Christian Heimes >> Principal Software Engineer, Identity Management and Platform Security >> >> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

2 1

FIPs enabled Install Fails
by Entrepreneur AJ 02 Jul '23

02 Jul '23

I today spun up a fresh Fedora 38 VPS on Vultr and started the FreeIPA Server install. This VPS has been switched to FIPs enabled. I have then tried to install the latest FreeIPA server from DNF without the DNS package. All was going well until it got to step 17 of 30 and outputted the following: [17/30]: requesting RA certificate from CA [error] CalledProcessError: CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmpfufotvvx', '-passin', 'file:/tmp/tmpwdlfgkkt'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n') CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmpfufotvvx', '-passin', 'file:/tmp/tmpwdlfgkkt'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n') The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information Any pointers on how to get passed this bit?

2 1

How does FreeIPA actually auth client behind the scenes?
by dweller dweller 01 Jul '23

01 Jul '23

Hi, I am interested in understanding the process of user authentication in the FreeIPA WebUI behind the scenes. However, the available information is scattered, and I am struggling to piece it all together. I have attached a diagram illustrating my current understanding, which I know is incorrect. To clarify my confusion, I will break down each point into specific questions: https://tinyurl.com/freeipa-auth - link to the scheme in draw.io https://imgur.com/mQEvred - scheme image 1. So user is already sees before him FreeIPA login form. He types his login/password and submits the form 2. Request goes to /ipa/login_password. /ipa/login_password location by itself does not offer much: <Location "/ipa/session/login_password"> Satisfy Any Require all granted </Location> The interesting part is actually at /ipa location which handled by mod_auth_gssapi: <Location "/ipa"> AuthType GSSAPI AuthName "Kerberos Login" GssapiUseSessions On Session On SessionCookieName ipa_session path=/ipa;httponly;secure; SessionHeader IPASESSION GssapiSessionKey file:/etc/httpd/alias/ipasession.key GssapiImpersonate On GssapiDelegCcacheDir /run/ipa/ccaches GssapiDelegCcachePerms mode:0660 GssapiDelegCcacheUnique On GssapiUseS4U2Proxy on GssapiAllowedMech krb5 Require valid-user ErrorDocument 401 /ipa/errors/unauthorized.html Header always append X-Frame-Options DENY Header always append Content-Security-Policy "frame-ancestors 'none'" Header unset Set-Cookie Header unset ETag FileETag None </Location> Here is where things become vague for me. We see *GssapiImpersonate On* and *GssapiUseS4U2Proxy on*. ``` GssapiImpersonate This option can be used even if AuthType GSSAPI is not used for given Location or LocationMatch, to obtain service ticket for a user that was already authenticated by different module ``` and ``` GssapiUseS4U2Proxy Enables the use of the s4u2Proxy Kerberos extension also known as constrained delegation This option allows an application running within Apache to operate on behalf of the user against other servers by using the provided ticket (subject to KDC authorization). ``` So why do we need both? Isn't GssapiUseS4U2Proxy enough to issue service tickets on behalf of user and use them? Also, is there is no TGT actually obtained for the client's principal, only service tickets? 3. Here I have basic understanding that Apache need somehow to talk to KDC. It does it with help of mod_auth_gssapi, which implements GSS-API interface for Apache. Apache itself does not aware of any KDC or other auth provider present, cause there is no settings in apache config about it. So let's say apache makes some gssapi function call to initiate exchange. - Does it start with SPNEGO negotioation, or directly "asks" for kerberos5 mechanism? (cause it is in the settings GssapiAllowedMech krb5). We have a /etc/gss file with following settings: [root@ipa-test conf.d]# cat /etc/gss/mech.d/gssproxy.conf # GSS-API mechanism plugins # # Mechanism Name Object Identifier Shared Library Path Other Options gssproxy_v1 2.16.840.1.113730.3.8.15.1 /usr/lib64/gssproxy/proxymech.so <interposer> I guess by it we can confirm that gssproxy intercept all the gssapi calls on the host? Next look at the gssproxy config for the ipa: [root@ipa-test ~]# cat /etc/gssproxy/10-ipa.conf #Installed and maintained by ipa update tools, please do not modify [service/ipa-httpd] mechs = krb5 cred_store = keytab:/var/lib/ipa/gssproxy/http.keytab cred_store = client_keytab:/var/lib/ipa/gssproxy/http.keytab allow_protocol_transition = true allow_client_ccache_sync = true cred_usage = both euid = apache [service/ipa-api] mechs = krb5 cred_store = keytab:/var/lib/ipa/gssproxy/http.keytab allow_constrained_delegation = true allow_client_ccache_sync = true cred_usage = initiate euid = ipaapi [service/ipa-sweeper] mechs = krb5 cred_store = keytab:/var/lib/ipa/gssproxy/http.keytab socket = /var/lib/gssproxy/ipa_ccache_sweeper.sock euid = ipaapi cred_usage = initiate Let's review options for ipa-httpd and ipa-api services: - allow_protocol_transition (This option controls whether s4u2self requests are allowed for the requesting client) Ok, understandable, we need it in conjuction with GssapiUseS4U2Proxy on of the Apache, otherways it won't work. Though it is present for service/ipa-api and not for the service/ipa-httpd. Why so? - allow_client_ccache_sync This one is kind of vague for me. This option allows the proxy, in certain circumstances, to send back an additional option in the response structure of certain calls when it determines that a new ticket may have been added to the internal ccache. Clients can then replace their (encrypted) copy with the updated ccache. So gssproxy injects option in response for a client (apache in our case?) to renew service tickets? What are the "certain calls"? - allow_protocol_transition So, this one is enabled only for ipa-httpd. This option controls whether s4u2self requests are allowed for the requesting client. This is shows that for some reason for ipa-httpd service we only have s4u2self allowed type of requests and for ipa-api service we have s4u2proxy. Mm, why not both? I guess those interaction between Apache and KDC through gssproxy are the most vague in all of this. 4. Somehow user getting autheticated. But there is no TGT, is it? So how is it done? 5. What next is gssapi calls are getting intercepted by gssproxy, and when service tickets are recieved they are encrypted by it, so httpd process has no direct access to it, it can't decrypt it. This design likely aims to protect credentials in case of a successful attack on the Apache process. 6. After ldap service tickets aquired (stored in the /run/ipa/ccaches), apache access ldap on behalf of the user. Or better I say python code make ldap request to LDAP server, in GSS context that was handled by apache. 7. Getting data from LDAP 8. Perfoming http response with data from LDAP, and setting a coockie ipa_session. What is in the cookie, by the way? I thought it was TGT but now I'm not that sure So each point highlight my areas of confusion, and I would appreciate any corrections or insights from anyone familiar with the FreeIPA client authentication process.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users July 2023