September 2023 - FreeIPA-users - Fedora mailing-lists

RedHat and 2FA Problem
by Sirio Sannipoli 21 Sep '23

21 Sep '23

Hello everyone, I've already done searches without success, I need someone to point me in the direction of resolving a strange behavior I'm experiencing on servers with the RedHat/Centos operating system. I have installed FreeIPA 4.10.1 on Oracle Linux 9 and all users by default have Radius authentication via a Cisco server, users can access via SSH to 100 Servers configured, we have OS of all types (Debian, RedHat, Centos, Ubuntu). The behavior I get is the following: Debian based distro: SSH Login and SUDO work perfectly using the Radius credentials RedHat based distro: SSH Login prompt ask for 2FA, first factor & second factor (optional) and i can login by entering the Radius credentials and using the same password 2 times, SUDO ask for 2FA and authentication fails when entering the same password 2 times. I don't understand if the problem is on the FreeIPA client or server or why there is a difference in behavior between Debian and RedHat systems. Can anyone give me directions to understand what's happening? Note: I have never set up 2FA authentication on the FreeIPA server, the users are correctly configured and the "ipa user-show" command confirms "User authentication types: radius", if i change user configuration with the password, everything works fine.

4 4

External bind with certs with sysaccounts
by Tania Hagan 21 Sep '23

21 Sep '23

Hi Freeipa-users, Is is possible to create a binddn account in cn=sysaccounts and attach certs to the account so it can be used in scripts to bind using external bind with certs? I know how to create my sysaccount and I found https://www.freeipa.org/page/V4/User_Certificates which provides instructions on attaching certificates to user accounts but not sure how this references to attaching certs to sysaccounts. Many Thanks, Tania

2 3

not thinking with the design of bind-dyndb-ldap
by Marc 21 Sep '23

21 Sep '23

1. Wtf are you assuming the ldap server is writable? Why would you think that changing this opposed to the older version is an improvement? 2. wtf do you want to download the whole ldap via sync? What is even the point of having it in ldap? My old named is using < 500MB, your new version is 700MB + 500MB swap. Now everything is slow because you grab 99% data that is not even queried. This plugin was good and you fucked it up, on security and on performance!!!

2 1

Would like to set up a "least privilege" admin only capable of managing POSIX groups, not users.
by Chris Cowan 21 Sep '23

21 Sep '23

Reading through the docs carefully, but I'm just wondering if anyone else has done this, and if there are any "gotchas" I have to worry about?

4 9

getting error "serial (xxxxxxxx) write back to LDAP failed"
by Marc 21 Sep '23

21 Sep '23

getting errors like this "serial (xxxxxxxx) write back to LDAP failed" Probably because it is trying to write to ldap? How to turn of this?

1 0

Re: help troubleshooting AD auth issue with FreeIPA
by Rob Crittenden 20 Sep '23

20 Sep '23

Ostrom, Erik via FreeIPA-users wrote: > Hi, > > I've got a fresh FreeIPA server running on Rocky 9, and I'm having > trouble diagnosing issues with a one way incoming external trust with an > active directory server. > > It looks like the trust is properly created on both sides and verified, > but when I try to log in with an AD user to the FreeIPA server via SSH, > I get permission denied (after asking for my password 3 times). I'm also > having trouble finding where any of this login process is being logged > on the FreeIPA side. > > Could I get some help figuring out where to look for logs related to > this failed AD login and how to troubleshoot a failure like this? I'd suggest starting with https://sssd.io/troubleshooting/basics.html rob > > IPA server details: > > [root@freeipa1 ~]# ipa --version > VERSION: 4.10.1, API_VERSION: 2.251 > [root@freeipa1 ~]# cat /etc/*release* > NAME="Rocky Linux" > VERSION="9.2 (Blue Onyx)" > ID="rocky" > ID_LIKE="rhel centos fedora" > VERSION_ID="9.2" > PLATFORM_ID="platform:el9" > PRETTY_NAME="Rocky Linux 9.2 (Blue Onyx)" > ANSI_COLOR="0;32" > LOGO="fedora-logo-icon" > CPE_NAME="cpe:/o:rocky:rocky:9::baseos" > HOME_URL="https://rockylinux.org/" > BUG_REPORT_URL="https://bugs.rockylinux.org/" > SUPPORT_END="2032-05-31" > ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9" > ROCKY_SUPPORT_PRODUCT_VERSION="9.2" > REDHAT_SUPPORT_PRODUCT="Rocky Linux" > REDHAT_SUPPORT_PRODUCT_VERSION="9.2" > Rocky Linux release 9.2 (Blue Onyx) > Rocky Linux release 9.2 (Blue Onyx) > Derived from Red Hat Enterprise Linux 9.2 > Rocky Linux release 9.2 (Blue Onyx) > cpe:/o:rocky:rocky:9::baseos > [root@freeipa1 ~]# > > Thanks, > Erik > > > > _______________________________________________ > 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 >

1 0

help troubleshooting AD auth issue with FreeIPA
by Ostrom, Erik 20 Sep '23

20 Sep '23

Hi, I've got a fresh FreeIPA server running on Rocky 9, and I'm having trouble diagnosing issues with a one way incoming external trust with an active directory server. It looks like the trust is properly created on both sides and verified, but when I try to log in with an AD user to the FreeIPA server via SSH, I get permission denied (after asking for my password 3 times). I'm also having trouble finding where any of this login process is being logged on the FreeIPA side. Could I get some help figuring out where to look for logs related to this failed AD login and how to troubleshoot a failure like this? IPA server details: [root@freeipa1 ~]# ipa --version VERSION: 4.10.1, API_VERSION: 2.251 [root@freeipa1 ~]# cat /etc/*release* NAME="Rocky Linux" VERSION="9.2 (Blue Onyx)" ID="rocky" ID_LIKE="rhel centos fedora" VERSION_ID="9.2" PLATFORM_ID="platform:el9" PRETTY_NAME="Rocky Linux 9.2 (Blue Onyx)" ANSI_COLOR="0;32" LOGO="fedora-logo-icon" CPE_NAME="cpe:/o:rocky:rocky:9::baseos" HOME_URL="https://rockylinux.org/" BUG_REPORT_URL="https://bugs.rockylinux.org/" SUPPORT_END="2032-05-31" ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9" ROCKY_SUPPORT_PRODUCT_VERSION="9.2" REDHAT_SUPPORT_PRODUCT="Rocky Linux" REDHAT_SUPPORT_PRODUCT_VERSION="9.2" Rocky Linux release 9.2 (Blue Onyx) Rocky Linux release 9.2 (Blue Onyx) Derived from Red Hat Enterprise Linux 9.2 Rocky Linux release 9.2 (Blue Onyx) cpe:/o:rocky:rocky:9::baseos [root@freeipa1 ~]# Thanks, Erik

1 0

HowTo renew IPA certificate when IPA is acting as a Sub CA to MS Windows Certificate Authority Services
by John Doe 20 Sep '23

20 Sep '23

I'm currently trying to evaluate if we may use IPA server to help manage our park of Linux Clients When installing the IPA server I used the following commands; sudo ipa-server-install --external-ca --external-ca-type=ms-cs sudo ipa-server-install --external-cert-file=/home/$USER/ipa.cer --external-cert-file=/home/$USER/certnew.cer Now when the CA certificate in Windows expired, I used Certificate Authority Manager to renew the CA certificate. I'm now struggling trying to figure out how to renew the IPA certificate. This is what I've tried; sudo ipa-cacert-manage --external-ca --external-ca-type ms-cs renew On the Windows server I'm forced to use the certreq command in CLI as the GUI Manager only complains of the CSR being the wrong type. And I'm only having success in using the WebServer template. No other templates works. And I'm assuming the SubordinateCertificationAuthority template is the that should be used?; certreq -submit -attrib CertificateTemplate:WebServer Back on the IPA server, I try installing the signed certificate; sudo ipa-cacert-manage renew --external-cert-file=./ipa.cer --external-cert-file=./Root-CA.cer But this only complains on the cert missing som basic constraints. Comparing the CSR generated during the install of the IPA server and the CSR generated with the ipa-cacert-manage renew command, I see that they differ in that the renew CSR is missing the .S.u.b.C.A Does anyone have any insights into what's missing in the procedure? Thankful for any help that can help me progress on this.

3 4

Unable to authenticate with kinit or FreeIPA web GUI after upgrading from Fedora 37 to Fedora 38
by Martin Gignac 20 Sep '23

20 Sep '23

Hi, I'm currently running 3 Fedora 37 VMs (freeipa01, freeipa02 and freeipa03), running FreeIPA in a cluster. I decided today to upgrade the freeipa03 VM to Fedora 38. After the upgrade, I am no longer able to successfully login to the FreeIPA web GUI on this VM using my account credentials, nor am I able to 'kinit' successfully on the VM either with this account. Using the same account on the other two Fedora 37 VMs still works, so I would like to resolve this issue before upgrading the rest of the cluster. Note that the 'admin' account still works on freeipa03, though, both in the GUI and using 'kinit'. It also seems that pure LDAP authentication is unaffected (i.e. I can log in successfully with my account using the OpenLDAP client). Suspecting that the problem might be Kerberos-specific, I followed the instructions on this page (https://www.freeipa.org/page/Troubleshooting/Kerberos) and ran (user and domain names changed to protect the innocent): -------------- [root@freeipa03 log]# KRB5_TRACE=/dev/stdout kinit buddy [1542] 1695160597.889222: Matching buddy(a)EXAMPLE.COM in collection with result: 0/Success [1542] 1695160597.889223: Getting initial credentials for buddy(a)EXAMPLE.COM [1542] 1695160597.889225: Sending unauthenticated request [1542] 1695160597.889226: Sending request (170 bytes) to EXAMPLE.COM [1542] 1695160597.889227: Initiating TCP connection to stream 192.168.40.133:88 [1542] 1695160597.889228: Sending TCP request to stream 192.168.40.133:88 [1542] 1695160597.889229: Received answer (519 bytes) from stream 192.168.40.133:88 [1542] 1695160597.889230: Terminating TCP connection to stream 192.168.40.133:88 [1542] 1695160597.889231: Response was from primary KDC [1542] 1695160597.889232: Received error from KDC: -1765328359/Additional pre-authentication required [1542] 1695160597.889235: Preauthenticating using KDC method data [1542] 1695160597.889236: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-SPAKE (151), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133) [1542] 1695160597.889237: Selected etype info: etype aes256-cts, salt "a&591&^W'=$!B6#6", params "" [1542] 1695160597.889238: Received cookie: MIT1\x00\x00\x00\x01Q\xa3RO\xea\xa6\xc4Z\xa4\xd6_w\xacA\x05\x97J\xaf\x12\x1c*\xab\xa0vkGq\x88\xfa\xb3\x98\xb3v\xc02\xe2>\xebZ%g\x9e'7\xac\x97\xb5\x18w\x11e\x870**\xddvQs\xcd\x81\x95\x90\xd5\x0b\xd5\x9f\x11%\x88\xfb\xc7*l\xea\xceV\xc0%\xca{\x14\xe7\xbf\xbf\x9a\xef\x93\xa1\xe4v\x13\xe8C\xd9B\xceay\xe4U\x1e\x1b\x01V\xf9\xc45\x84\x1a\x99W\x18j\xed\xf1V\xc9\x08\xa98\x91\x14\xb1\x95L\xf4\xe2\xef\xc9\xff\xe2\xe95\xcb\xdf\xaa\xe4\x1e\xc7,G [1542] 1695160597.889239: PKINIT client has no configured identity; giving up [1542] 1695160597.889240: Preauth module pkinit (147) (info) returned: 0/Success [1542] 1695160597.889241: PKINIT client received freshness token from KDC [1542] 1695160597.889242: Preauth module pkinit (150) (info) returned: 0/Success [1542] 1695160597.889243: PKINIT client has no configured identity; giving up [1542] 1695160597.889244: Preauth module pkinit (16) (real) returned: 22/Invalid argument [1542] 1695160597.889245: SPAKE challenge received with group 1, pubkey E03357913D632FED4908863B7F43145F9A64BBE14921DA6C9FBD7C1C21F60E14 Password for buddy(a)EXAMPLE.COM: [1542] 1695160600.810901: SPAKE key generated with pubkey 75C14A0B07690CDCB14EE2580FD53E19BF28D7AC548CC276CE35A6EBE971E46C [1542] 1695160600.810902: SPAKE algorithm result: 53671BE2D5C567F80864741EF0C69555C3817303DEDA9A5F28E9823001438226 [1542] 1695160600.810903: SPAKE final transcript hash: 9C2818F938FDF8F916F7100C4A5426FCAE4FCE53A34BFDF82BF1F6BA55296513 [1542] 1695160600.810904: Sending SPAKE response [1542] 1695160600.810905: Preauth module spake (151) (real) returned: 0/Success [1542] 1695160600.810906: Produced preauth for next request: PA-FX-COOKIE (133), PA-SPAKE (151) [1542] 1695160600.810907: Sending request (441 bytes) to EXAMPLE.COM [1542] 1695160600.810908: Initiating TCP connection to stream 192.168.40.133:88 [1542] 1695160600.810909: Sending TCP request to stream 192.168.40.133:88 [1542] 1695160600.810910: Received answer (143 bytes) from stream 192.168.40.133:88 [1542] 1695160600.810911: Terminating TCP connection to stream 192.168.40.133:88 [1542] 1695160600.810912: Response was from primary KDC [1542] 1695160600.810913: Received error from KDC: -1765328324/Generic error (see e-text) kinit: Generic error (see e-text) while getting initial credentials -------------- Something I see different between the working Kerberos authentication on freeipa01 and freeipa02 and the non-working one on freeipa03 is the presence of this line in '/var/log/krb5kdc.log' on freeipa03: -------------- Sep 19 18:09:07 freeipa03.infra.example.com krb5kdc[888](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.40.133: HANDLE_AUTHDATA: buddy(a)EXAMPLE.COM for krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, No such file or directory -------------- On Fedora 38, I am running FreeIPA 4.10.2, whereas on Fedora 37 I am running 4.10.1. I found this RedHat article (https://access.redhat.com/solutions/7015184 "Cannot authenticate using Kerberos after upgrading Red Hat Identity Management") which describes the problem as: "After updating ipa-server to 4.10.1-3 or newer, domain users cannot login anymore with Kerberos" with the exact same 'kinit <user>' error I obtained, and the same error line in '/var/log/krb5kdc.log'. The article then suggests running the following: -------------- $ kinit admin $ ipa config-mod --enable-sid --add-sids Check if a SID has been generated for the user: $ ipa user-show <user> --all | grep ipantsecurityidentifier ipantsecurityidentifier: S-1-5-21-198193297-2287641477-1368658080-1001 -------------- So, I ran 'ipa config-mod --enable-sid --add-sids', but even after running this command 'ipa user-show buddy --all | grep ipantsecurityidentifier' still shows up empty. Since this seems to be the exact same problem I have, but it doesn't seem to fix my particular situation, is there anything else I need to do and/or check? Thank you, -Martin

2 4

kinit: KDC can't fulfill requested option while renewing credentials - which approach?
by Pieter Baele 19 Sep '23

19 Sep '23

I tried various approached to get Renewable tickets : modifying the kdc modifying krb5.conf using kadmin.local on every replica to modify the principal; which is not working - as designed (?)- in IPA What should I do to get a ticket with the correct R flag from IPA ? I don't think this is SSSD related (the service needing the renewable ticket this way is Apache Storm) Thanks a lot!

3 4

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users September 2023