September 2020 - FreeIPA-users - Fedora mailing-lists

Re: Renewing a failed to auto-renewal certificate
by Stuart McRobert 16 Sep '20

16 Sep '20

Dear flo, Thank you for your help with this, but something still seems to be preventing the renewal from actually happening even after going back in time, and waiting. My service slot is open until lunchtime today so hopefully be a quick additonal step required to get this fixed. Any ideas? Thanks Best wishes Stuart After a reboot... [root@freeipa01 ~]# ipactl start --ignore-service-failures Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting ipa_memcached Service Starting httpd Service Failed to start httpd Service Forced start, ignoring httpd Service, continuing normal operation Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Failed to start pki-tomcatd Service Forced start, ignoring pki-tomcatd Service, continuing normal operation Starting ipa-otpd Service ipa: INFO: The ipactl command was successful [root@freeipa01 ~]# [root@freeipa01 ~]# systemctl stop ntpd.service [root@freeipa01 ~]# date Wed 16 Sep 09:09:19 BST 2020 [root@freeipa01 ~]# date 08160838 Sun 16 Aug 08:38:00 BST 2020 [root@freeipa01 ~]# date Sun 16 Aug 08:38:04 BST 2020 [root@freeipa01 ~]# systemctl start httpd [root@freeipa01 ~]# systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Drop-In: /etc/systemd/system/httpd.service.d └─ipa.conf Active: active (running) since Sun 2020-08-16 08:38:33 BST; 7s ago Docs: man:httpd.service(8) Process: 1221 ExecStopPost=/usr/bin/kdestroy -A (code=exited, status=0/SUCCESS) Process: 1703 ExecStartPre=/usr/libexec/ipa/ipa-httpd-kdcproxy (code=exited, status=0/SUCCESS) Main PID: 1704 (httpd) Status: "Processing requests..." Tasks: 92 (limit: 4915) CGroup: /system.slice/httpd.service ├─1704 /usr/sbin/httpd -DFOREGROUND ├─1705 /usr/libexec/nss_pcache 589836 off /etc/httpd/alias ├─1706 (wsgi:kdcproxy) -DFOREGROUND ├─1707 (wsgi:kdcproxy) -DFOREGROUND ├─1708 (wsgi:ipa) -DFOREGROUND ├─1709 (wsgi:ipa) -DFOREGROUND ├─1710 /usr/sbin/httpd -DFOREGROUND ├─1711 /usr/sbin/httpd -DFOREGROUND ├─1712 /usr/sbin/httpd -DFOREGROUND ├─1713 /usr/sbin/httpd -DFOREGROUND └─1714 /usr/sbin/httpd -DFOREGROUND Aug 16 08:38:33 freeipa01.OUR_DOMAIN systemd[1]: Starting The Apache HTTP Server... Aug 16 08:38:33 freeipa01.OUR_DOMAIN ipa-httpd-kdcproxy[1703]: ipa : INFO KDC proxy enabled Aug 16 08:38:33 freeipa01.OUR_DOMAIN systemd[1]: Started The Apache HTTP Server. [root@freeipa01 ~]# getcert resubmit -i 20170405152512 Resubmitting "20170405152512" to "IPA". [root@freeipa01 ~]# sleep 200 [root@freeipa01 ~]# getcert list -i 20170405152512 Number of certificates and requests being tracked: 8. Request ID '20170405152512': status: CA_UNREACHABLE ca-error: Server at https://freeipa01.OUR_DOMAIN/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. ). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=OUR_DOMAIN_UC subject: CN=freeipa01.OUR_DOMAIN,O=OUR_DOMAIN_UC expires: 2020-09-04 17:46:56 BST principal name: HTTP/freeipa01.OUR_DOMAIN@OUR_DOMAIN_UC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes [root@freeipa01 ~]# date Sun 16 Aug 08:43:50 BST 2020 [root@freeipa01 ~]# [root@freeipa01 ~]# [root@freeipa01 ~]# getcert list -i 20170405152512 Number of certificates and requests being tracked: 8. Request ID '20170405152512': status: CA_UNREACHABLE ca-error: Server at https://freeipa01.OUR_DOMAIN/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. ). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=OUR_DOMAIN_UC subject: CN=freeipa01.OUR_DOMAIN,O=OUR_DOMAIN_UC expires: 2020-09-04 17:46:56 BST principal name: HTTP/freeipa01.OUR_DOMAIN@OUR_DOMAIN_UC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes [root@freeipa01 ~]# getcert list -i 20170405152512 Number of certificates and requests being tracked: 8. Request ID '20170405152512': status: CA_UNREACHABLE ca-error: Server at https://freeipa01.OUR_DOMAIN/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. ). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=OUR_DOMAIN_UC subject: CN=freeipa01.OUR_DOMAIN,O=OUR_DOMAIN_UC expires: 2020-09-04 17:46:56 BST principal name: HTTP/freeipa01.OUR_DOMAIN@OUR_DOMAIN_UC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes [root@freeipa01 ~]# date Sun 16 Aug 08:58:23 BST 2020

2 1

Re: ssh key issues
by Andrew Meyer 15 Sep '20

15 Sep '20

I tried this. I ran into this problem earlier this year but can't remember what I did to fix it.

1 0

Re: Problem with smartcard login when otp is enabled
by Radek Kujawa 15 Sep '20

15 Sep '20

Hi. I am able to reproduce this problem on Fedora 32 (sssd-2.2.3-20), however I am not able to reproduce this on CentOS 8 (sssd-2.3.1-2). This suggests the problem was introduced somewhere between sssd 2.2.3 and 2.3.1. Config on both systems is the same - machines added to IPA domain, user account has both cert configured for PKINIT and OTP. Attempting to log in on CentOS 8 displays prompt for Smart Card PIN, attempting to log in on Fedora 32 displays prompt for OTP factors. I've tried to analyze the problem and it seems that sss_krb5_prompter always tries otp on Fedora, even though p11_child finishes successfully and returns the correct user certificate. On CentOS 8: (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [get_and_save_tgt] (0x4000): Found Smartcard credentials, trying pkinit. (...) (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143791: Upgrading to FAST due to presence of PA_FX_FAST in reply (...) (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143815: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-P K-AS-REQ_OLD (14), PA-FX-FAST (136), PA-PKINIT-KX (147), PA-OTP-CHALLENGE (141), PA-FX-COOKIE (133), PA-FX-ERROR (137) (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143816: Received cookie: MIT (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_responder] (0x4000): Got question [pkinit]. (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [answer_pkinit] (0x4000): [0] Identity [PKCS11:module_name=/usr/lib64/pkcs11/opensc-pkcs11.so:slotid=0:token=rkujawa] flags [0]. (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [answer_pkinit] (0x4000): Setting pkinit_prompting. (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_child_krb5_trace_cb] (0x4000): [2185] 1599679459.143817: Preauth module pkinit (147) (info) returned: 0/Success (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_prompter] (0x4000): sss_krb5_prompter name [(null)] banner [(null)] num_prompts [1] EINVAL. (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_prompter] (0x4000): Prompt [0][rkujawa PIN]. (Wed Sep 9 21:24:19 2020) [[sssd[krb5_child[2185]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. On Fedora 32: (2020-09-09 21:18:16): [krb5_child[1823]] [get_and_save_tgt] (0x4000): Found Smartcard credentials, trying pkinit. (...) (2020-09-09 21:18:16): [krb5_child[1823]] [sss_child_krb5_trace_cb] (0x4000): [1823] 1599679096.050398: Upgrading to FAST due to presence of PA_FX_FAST in reply (...) (2020-09-09 21:18:16): [krb5_child[1823]] [sss_child_krb5_trace_cb] (0x4000): [1823] 1599679096.050422: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136), PA-PKINIT-KX (147), PA-OTP-CHALLENGE (141), PA-FX-COOKIE (133), PA-FX-ERROR (137) (2020-09-09 21:18:16): [krb5_child[1823]] [sss_child_krb5_trace_cb] (0x4000): [1823] 1599679096.050423: Received cookie: MIT (2020-09-09 21:18:16): [krb5_child[1823]] [sss_krb5_responder] (0x4000): Got question [otp]. (2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0] Vendor [(null)]. (2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0] Token-ID [(null)]. (2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0] Challenge [(null)]. (2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x4000): [0] Flags [1]. (2020-09-09 21:18:16): [krb5_child[1823]] [answer_otp] (0x2000): Exit answer_otp during pre-auth. (2020-09-09 21:18:16): [krb5_child[1823]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [11] during pre-auth. (2020-09-09 21:18:16): [krb5_child[1823]] [k5c_send_data] (0x0200): Received error code 0 (2020-09-09 21:18:16): [krb5_child[1823]] [pack_response_packet] (0x2000): response packet size: [15] (2020-09-09 21:18:16): [krb5_child[1823]] [k5c_send_data] (0x4000): Response sent. (2020-09-09 21:18:16): [krb5_child[1823]] [main] (0x0400): krb5_child completed successfully This results in PIN never being asked on Fedora. Unfortunately at this moment I am not able to deliver full logs. Hopefully Jan will send full logs from his setup ;). Best regards, Radoslaw

4 9

Can't reinstate replica from scratch after it was off for 6 months
by Konstantin M. Khankin 14 Sep '20

14 Sep '20

Hi! I run IPA on CentOS 7. I have two servers (Leader and Replica, though they changed roles couple times because of reinstalls), had ca and domain services on both of them, replication set up and working. I had to switch off Replica for 6 months. When I turned it on recently, I found expired certificates, couldn't fix them easily and lost the old Replica - at least I concluded it was easier to reinstate the Replica than to detangle the mess I made while was trying to back out of outdated certs. I hit the same error as I do now though - Invalid Credentials (49). So I did the following: 1) on Replica - ipa-server-install --uninstall. 2) on Leader - ipa-replica-manage del --force --clean Replica. 3) removed obsolete replication agreement meToReplica from Leader. 4) removed all traces of Replica from DNS. Then I started to install Replica from scratch: 1) ipa-client-install 2) ipa-replica-install --setup-ca --setup-dns --forwarder X --forwarder Y Installation consistently fails with: ''' Run connection check to master Connection check OK Configuring directory server (dirsrv). Estimated time: 30 seconds <...> [29/42]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 16 seconds elapsed [ldap://Leader:389] reports: Update failed! Status: [Error (49) - LDAP error: Invalid credentials] [error] RuntimeError: Failed to start replication ''' Logs from Leader, /var/log/dirsrv/slapd-DOMAIN/errors: ''' [<DATE>] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToReplica.domain" (Replica:389) - Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) () """ I verified clocks on both Replica and Leader - they show the same time (within 1-2 seconds diff window). In fact, at some point I had Replica taking time straight from Leader, before they were set up to use the other common source. I dumped traffic between Leader and Replica - indeed, Leader tried to authenticate on Replica and Replica replies "Invalid credentials". I googled this error and read multiple email threads but nothing helped so far. Replica works fine as IPA client but can't get promoted to a replica. What am I missing? Thanks! -- Khankin Konstantin

3 5

FreeIPA 2-way trust with MS AD
by Yuri Krysko 11 Sep '20

11 Sep '20

Hello, I know if the past (late 2018) there was a question about not enough clarity as to what is actually a 2-way trust between FreeIPA and MS AD. Technically, there does not seem to be any difference between 1-way and 2-way trusts. Question: is there a more concrete timeline when you guys plan to implement capability for IdM users to login to MS resources? Thanks, Yuri

2 2

Running external cert management on Ipa server?
by Dominik Vogt 10 Sep '20

10 Sep '20

Hi folks, a customer wants to use the Redhat certificate system instead of the one built into freeipa. AFAIK both use dogtag under the hood. The customer wants to run the certificate system on the same machine as the ipa server, if possible (because otherwise he needs more hardware). Redhat support had some unspecific concerns that RHCS might conflict with the one that is part of freeipa. Is it possible at all? Will it cause trouble? Has anybody some experience with that setup? Ciao Dominik ^_^ ^_^ -- Dominik Vogt

4 5

RHEL 7 IdM trust to AWS Managed MS AD
by Yuri Krysko 09 Sep '20

09 Sep '20

Hello, Is it possible to create a 2-way trust from RHEL 7 IdM to AWS Managed MS AD? So far, I have not had success creating such trust. My RHEL 7 IdM has FIPS enabled and FIPS set to enforcing. Ipa-server-4.6.6-11 Thanks much, Yuri

1 0

Delay in behavior when making changes to custom plugins
by Scott Serr 09 Sep '20

09 Sep '20

My environment is: CentOS 8.2, FreeIPA 4.8.4, single instance, no clients My minimal test case plugin looks like this: user.takes_params += ( Str('useraffiliation?', cli_name = 'useraffiliation', label = _('User Affiliation'), ), ) user.default_attributes.append('useraffiliation') Say I modify the label. That change isn't shown in IPA cli: ipa user-find foo --all Then about an hour later (go eat dinner) then the label has changed. Restarting the ipa service, another kinit, even rebooting doesn't hurry this process along. 2 Questions: 1. What is causing this delay in reflecting my changes? 2. Is there a way to force my changes to be reflected right away? Thank you!

3 4

Re: Problem with smartcard login when otp is enabled
by Sumit Bose 09 Sep '20

09 Sep '20

On Wed, Sep 09, 2020 at 01:56:23PM +0000, Jan Ufnalski via FreeIPA-users wrote: > >Configuration: OS:Kubuntu 20.04 LTS, Yubikey 5 with PIV, sssd version: 2.2.3-3, testing in terminal session without graphic interface to exclude problems from graphic interface >In case when OTP is disabled and yubikey inserted, in login process I get correct prompt for smartcard pin. >But when OTP is configured in IPA and yubikey inserted, instead getting prompt for smart card pin I get prompt for first factor and second factor. >In /etc/sssd/sssd.conf [pam] section I have enabled pam_cert_auth. I attatch 2 logs from sssd, one with enabled and one with disabled otp. >When I configured second computer the same way few weeks ago, everything works okey, but now I have to disable otp to make smartcard work correctly Hi, please add 'debug_level = 9' to the [domain/...] section of sssd.conf, restart SSSD and run the tests again. The please send the domain log and krb5_child.log. bye, Sumit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ># ># /etc/pam.d/common-auth - authentication settings common to all services ># ># This file is included from other service-specific PAM config files, ># and should contain a list of the authentication modules that define ># the central authentication scheme for use on the system ># (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the ># traditional Unix authentication mechanisms. ># ># As of pam 1.0.1-6, this file is managed by pam-auth-update by default. ># To take advantage of this, it is recommended that you configure any ># local modules either before or after the default block, and use ># pam-auth-update to manage selection of other modules. See ># pam-auth-update(8) for details. ># here are the per-package modules (the "Primary" block) >auth [default=1 success=ok] pam_localuser.so >auth [success=2 default=ignore] pam_unix.so nullok_secure >#auth [success=1 default=ignore] pam_sss.so use_first_pass >auth sufficient pam_sss.so forward_pass prompt_always # here's the fallback if no module succeeds >auth requisite pam_deny.so ># prime the stack with a positive return value if there isn't one already; ># this avoids us returning an error just because nothing sets a success code ># since the modules above will each just jump around >auth required pam_permit.so ># and here are more per-package modules (the "Additional" block) >auth optional pam_cap.so ># end of pam-auth-update config >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >Jan Ufnalski

1 0

Re: Renewing a failed to auto-renewal certificate
by Stuart McRobert 09 Sep '20

09 Sep '20

Dear flo, Thanks for the update. > The IPA services are probably stopped. Can you try > # ipactl start --ignore-service-failures That has I believe worked as desired and I can now kinit on the first server. Cut and paste # ipactl start --ignore-service-failures Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting ipa_memcached Service Starting httpd Service Failed to start httpd Service Forced start, ignoring httpd Service, continuing normal operation Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service ^Z [1]+ Stopped ipactl start --ignore-service-failures [root@freeipa01 sm]# bg [1]+ ipactl start --ignore-service-failures & [root@freeipa01 sm]# kinit sm Password for sm@OUR_DOMAIN [root@freeipa01 sm]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: sm@OUR_DOMAIN Valid starting Expires Service principal 09/09/20 14:29:14 10/09/20 14:29:08 krbtgt/OUR_DOMAIN@OUR_DOMAIN Meanwhile in the background comes Failed to start pki-tomcatd Service Forced start, ignoring pki-tomcatd Service, continuing normal operation Starting ipa-otpd Service ipa: INFO: The ipactl command was successful [1]+ Done ipactl start --ignore-service-failures > # ldapsearch -H ldap://`hostname` -LLL -o ldif-wrap=no -D 'cn=Directory Manager' -W '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn > > This should return an entry dn which contains the name of the renewal > master, for instance: > dn: cn=CA,cn=hostname.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com That does indeed return our first server 01 as I hoped. dn: cn=CA,cn=freeipa01... etc > > Warning, if the replication got broken, the result may be different on > other servers. Make sure all the nodes have the same view of who is CA > renewal master. I have checked on the other two production freeipa servers and all point to the first. > Once you identify the CA renewal master, the repair procedure needs to > be applied on this node first. Okay, so I think I need to book a repair slot as I assume our authentication will fail during the time travel. Thanks Best wishes Stuart

1 0

Problem with smartcard login when otp is enabled
by Jan Ufnalski 09 Sep '20

09 Sep '20

Configuration: OS:Kubuntu 20.04 LTS, Yubikey 5 with PIV, sssd version: 2.2.3-3, testing in terminal session without graphic interface to exclude problems from graphic interface In case when OTP is disabled and yubikey inserted, in login process I get correct prompt for smartcard pin. But when OTP is configured in IPA and yubikey inserted, instead getting prompt for smart card pin I get prompt for first factor and second factor. In /etc/sssd/sssd.conf [pam] section I have enabled pam_cert_auth. I attatch 2 logs from sssd, one with enabled and one with disabled otp. When I configured second computer the same way few weeks ago, everything works okey, but now I have to disable otp to make smartcard work correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> # # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) auth [default=1 success=ok] pam_localuser.so auth [success=2 default=ignore] pam_unix.so nullok_secure #auth [success=1 default=ignore] pam_sss.so use_first_pass auth sufficient pam_sss.so forward_pass prompt_always # here's the fallback if no module succeeds auth requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around auth required pam_permit.so # and here are more per-package modules (the "Additional" block) auth optional pam_cap.so # end of pam-auth-update config >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jan Ufnalski

1 0

Re: Renewing a failed to auto-renewal certificate
by Stuart McRobert 09 Sep '20

09 Sep '20

Dear flo, > there is only one certificate that failed to renew, and the repair > should (hopefully) be straightforward. > > First of all, please confirm that the server is the CA renewal master: > # ipa config-show | grep "CA renewal" Although I can kinit on other hosts this fails on what I consider to be our CA master. kinit sm kinit: Cannot contact any KDC for realm 'OUR_REALM' while getting initial credentials and would normally work up until the expiry. Now if I try from one of our clients kinit works ipa config-show | grep "CA renewal" ipa: ERROR: cannot connect to 'https://PRIMARY_SERVER/ipa/json': [Errno 111] Connection refused which has happened since the expiry and web services etc being unavailable which seems to make sense. Attempt on one of the other freeipa servers, kinit works, but ipa command fails with: ipa: ERROR: cannot connect to 'https://THIS_SERVER/ipa/json': (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > The output should display your hostname. If that's not the case, we need > more information (which host is CA renewal master, are all the certs > valid on this host?) What would you like me to gather next? I am being cautious as I don't want the user service to fail, but worry not everything is working as it should be. Thanks. Best wishes Stuart

2 1

Renewing a failed to auto-renewal certificate
by Stuart McRobert 09 Sep '20

09 Sep '20

Hi, Although I thought these certificates would all happily auto-renew, and auto-renew: yes is shown, one of them clearly hasn't with an obvious impact on services. I recognise this is now a fairly old version of freeipa. As I don't wish to break anything further, what is the correct way to safely and successfully renew this one certificate? Thanks Best wishes Stuart ------------------------------------------------------- ipa --version VERSION: 4.4.4, API_VERSION: 2.215 getcert list | grep -i expi expires: 2022-06-13 17:57:38 BST expires: 2022-06-13 17:57:48 BST expires: 2022-06-13 17:57:28 BST expires: 2036-09-08 17:57:09 BST expires: 2022-06-13 17:57:50 BST expires: 2022-06-13 17:57:22 BST expires: 2022-07-16 17:58:18 BST expires: 2020-09-04 17:46:56 BST <<<<<<<<<<<<<<<<<<<< I've changed strings to be OUR_DOMAIN and our_server below. getcert list Number of certificates and requests being tracked: 8. Request ID '20170405152505': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=CA Audit,O=OUR_DOMAIN expires: 2022-06-13 17:57:38 BST key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170405152506': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=OCSP Subsystem,O=OUR_DOMAIN expires: 2022-06-13 17:57:48 BST eku: id-kp-OCSPSigning pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170405152507': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=CA Subsystem,O=OUR_DOMAIN expires: 2022-06-13 17:57:28 BST key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170405152508': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=Certificate Authority,O=OUR_DOMAIN expires: 2036-09-08 17:57:09 BST key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20170405152509': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=IPA RA,O=OUR_DOMAIN expires: 2022-06-13 17:57:50 BST key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20170405152510': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=our_server,O=OUR_DOMAIN expires: 2022-06-13 17:57:22 BST key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca" track: yes auto-renew: yes Request ID '20170405152511': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-OUR_DOMAIN',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-OUR-DOMAIN/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-OUR_DOMAIN',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=our_server,O=OUR_DOMAIN expires: 2022-07-16 17:58:18 BST principal name: ldap/our_server@OUR_DOMAIN key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv OUR_DOMAIN track: yes auto-renew: yes Request ID '20170405152512': status: CA_UNREACHABLE ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for requested realm. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=OUR_DOMAIN subject: CN=our_server,O=OUR_DOMAIN expires: 2020-09-04 17:46:56 BST <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< principal name: HTTP/our_server@OUR_DOMAIN key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes

2 1

Solaris 10 client setup. Works for user not groups
by Lois Blood Bennett 08 Sep '20

08 Sep '20

Hi! I am probably missing something really obvious. I have an IPA server that is still in development. I have created two test clients that are clones of existing VMs. One is Centos 7.7 and the other is Solaris10. The Centos 7.7 one is working great. The Solaris one works now for getent passwd user and. for logging in but the groups command is returning the list from the old LDAP server and I can't figure out how it is getting that. The content of the /var/ldap/ldap_client_file is : root # cat ldap_client_file # # Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead. # NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 172.27.104.187 NS_LDAP_SEARCH_BASEDN= dc=channing,dc=harvard,dc=edu NS_LDAP_AUTH= tls:simple NS_LDAP_SEARCH_SCOPE= sub NS_LDAP_SERVER_PREF= chanidm.bwh.harvard.edu NS_LDAP_CACHETTL= 0 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=channing,dc=harvard,dc=edu NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=accounts,dc=channing,dc=harvard,dc=edu NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber NS_LDAP_OBJECTCLASSMAP= group:posixGroup=posixgroup NS_LDAP_SERVICE_AUTH_METHOD= pam_ldap:tls:simple NS_LDAP_SERVICE_AUTH_METHOD= passwd-cmd:tls:simple Any suggestions? Thank you all. Lois Bennett, MSEE Senior System Administrator Channing Division of Network Medicine, Brigham & Women's Hospital A Teaching Affiliate of Harvard Medical School and Harvard School of Public Health

2 1

FreeIPA DNS (named-pkcs11) failover
by Peter Larsen 07 Sep '20

07 Sep '20

I have two FreeIPA servers both are working as DNS servers for the network. Each IPA server is in the DNS server list, so they serve as "backup" for one another. I had one of the server's named-pkcs11 fail last night and somehow the second server failed resolving as it could not reach the first one. The zone they're hitting has forwarding disabled. I could get internal addresses resolved but when it came to external, the server that was running would not forward out of the network - only to the server that no longer was open. I'm struggling to see what would cause this dependency. Since the zone definition is the same on both systems, what causes this dependency? Is there a setting I need to look at that's not in the LDAP DB? Each IPA server has a resolve that lists localhost (them-self) and the IP address of the other IPA server. So I understand if there's attempt to reach the other, but if the first IPA server can do a global forward, why can't the other? I use "forwarding disabled" because it turned out when there was no external access the "forward first" would fail and hence I would have no DNS just because my ISP decided not to reply - even the internal DNS would fail this way. Forwarding disabled seems to work - and it's my expectation that it simply looks up the NS record directly when it doesn't have a zone that matches. So why does one of the IPA servers not seem to be able to do this? -- Regards Peter Larsen

2 1

Seeking ALL server datafile/database file/dir paths on Ubuntu 18.04
by Johnny Utahh 05 Sep '20

05 Sep '20

We are seeking ALL the FreeIPA file/database file paths created in the |ipa-server-install| command in the |freeipa-server| package on Ubuntu 18.04. We're looking for a /comprehensive/ list. Is this feasible? Details: https://www.reddit.com/r/FreeIPA/comments/im6zjs/where_are_all_the_freeipa_… Regards, ~Johnny -- //

2 4

migrate IPA server to new OS
by Boris Behrens 04 Sep '20

04 Sep '20

Hi, just a short question: Is it possible to migrate a freeIPA server to a new host? I'd like to move from fedora 26 to centos8, but I wouldn't like to "add a new master, then remove the older master, test everything, move ip addresses and fw rules" and all that stuff. Cheers Boris -- Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groÃƒ¼en Saal.

3 4

CentOS 7 --> 8 migration for FreeIPA with external CA?
by Harald Dunkel 04 Sep '20

04 Sep '20

Hi folks, I have found several migration guidelines from Centos 7 to 8. AFAIU the procedure is to setup a new CentOS 8 FreeIPA server, and then to migrate the "master" from the old to the new host. See [1], for example. Having myself burned with the CA stuff in FreeIPA before, I wonder if there are any pitfalls wrt having an external root CA and external DNS? Thats the part not described in [1]. Every helpful comment is highly appreciated Harri [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht…

2 1

FreeIPA Role Management
by John Burns 04 Sep '20

04 Sep '20

What exactly should be granted to enable a user to view /edit freeIPA roles? Specifically, what enables a user to view anything under "IPA Server" > "Role-Based Access Control?" Context: roles, privileges, permissions are all populated for one non-"admin" login but not for another.

2 1

Delegation (S4U2Proxy) with apache's mod_auth_gssapi
by Aurelien Bompard 02 Sep '20

02 Sep '20

Hey folks! I have a Kerberos issue when using s4u2proxy with mod_auth_gssapi and IPA, and I don't know where to look. Basically, I've setup delegation in IPA (with servicedelegationrules and targets) and in Apache's config for mod_auth_gssapi, but the directory where the CCaches are supposed to be created remains empty (GssapiDelegCcacheDir). In the apache log I only see: GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ( SPNEGO cannot find mechanisms to negotiate)] For context, the webapp running in Apache is delegating for IPA's ldap service, and if I contact it directly with ldapwhoami I get the right result, so it's really the delegation I think. Also, the webapp is running in openshift, but that should not be a big issue (besides for debugging) because I've already made it work elsewhere. I have keytabs for the host and the HTTP service: $ klist -k /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/fasjson.stg.fedoraproject.org(a)STG.FEDORAPROJECT.ORG 1 host/fasjson.stg.fedoraproject.org(a)STG.FEDORAPROJECT.ORG $ klist -k /etc/keytabs/http Keytab name: FILE:/etc/keytabs/http KVNO Principal ---- -------------------------------------------------------------------------- 1 HTTP/fasjson.stg.fedoraproject.org(a)STG.FEDORAPROJECT.ORG 1 HTTP/fasjson.stg.fedoraproject.org(a)STG.FEDORAPROJECT.ORG And the section in Apache's config file is: AuthType GSSAPI AuthName "Kerberos Login" GssapiUseSessions On Session On SessionCookieName ipa_session path=/;httponly;secure; SessionHeader IPASESSION GssapiSessionKey file:/httpdir/run/session.key GssapiCredStore keytab:/etc/keytabs/httpd GssapiImpersonate On GssapiDelegCcacheDir /httpdir/run/ccaches GssapiDelegCcachePerms mode:0660 GssapiUseS4U2Proxy on GssapiAllowedMech krb5 Here's what I'm seeing. When I'm authenticated with kerberos: $ klist Ticket cache: KEYRING:persistent:1000290000:1000290000 Default principal: abompard(a)STG.FEDORAPROJECT.ORG Valid starting Expires Service principal 09/02/20 12:55:59 09/03/20 12:55:47 krbtgt/STG.FEDORAPROJECT.ORG(a)STG.FEDORAPROJECT.ORG and I contact the web app with curl: curl --negotiate -u : https://fasjson.stg.fedoraproject.org/v1/ I get a 401 response with the log pasted above. The /httpdir/run/ccaches/ directory remains empty, but I do get the service's entry in klist: $ klist Ticket cache: KEYRING:persistent:1000290000:1000290000 Default principal: abompard(a)STG.FEDORAPROJECT.ORG Valid starting Expires Service principal 09/02/20 12:57:12 09/03/20 12:55:47 HTTP/fasjson.stg.fedoraproject.org(a)STG.FEDORAPROJECT.ORG 09/02/20 12:55:59 09/03/20 12:55:47 krbtgt/STG.FEDORAPROJECT.ORG(a)STG.FEDORAPROJECT.ORG I don't know what I'm doing wrong and where I could dig. Could you point me in the right direction? I'm also on IRC in the freeipa channel as abompard. Thanks! Aurélien

2 1

freeIPA : AD trust
by Christophe BERGER 02 Sep '20

02 Sep '20

I created a trust relationship between my IPA server, and an Active Directory. From any machine connected to freeIPA, I can : - sudo su - ADuser(a)ad.example.com - id ADuser(a)ad.example.com ( I get things like uid=167644279(ADuser(a)ad.example.com) gid=167644279(ADuser(a)ad.example.com) groups=167644279(ADuser@ad.example.com),167616854(groupXXX@ad.example.com), .................... - getent passwd ADuser(a)ad.example.com ADuser@ad.example.com:*:167644279:167644279:ADuser:/home/example.com/ADuser The connection between IPA and AD looks fine. Then I created : - An external group, with my ADuser(a)ad.example.com user (external) - An POSIX group, with my external group as a user group member - A HBAC rule to allow the POSIX group to connect to a server However, I can't ssh this server with my AD account, I get this : Sep 01 15:15:18 myServer.example.com systemd[1]: Starting SSSD Kerberos Cache Manager... Sep 01 15:15:18 myServer.example.com systemd[1]: Started SSSD Kerberos Cache Manager. Sep 01 15:15:18 myServer.example.com sssd[kcm][1730]: Starting up Sep 01 15:15:18 myServer.example.com [sssd[krb5_child[1727]]][1727]: Cannot find KDC for realm "EXAMPLE.COM" Sep 01 15:15:18 myServer.example.com [sssd[krb5_child[1727]]][1727]: Cannot find KDC for realm "EXAMPLE.COM" Sep 01 15:15:18 myServer.example.com [sssd[krb5_child[1731]]][1731]: Cannot find KDC for realm "EXAMPLE.COM" Sep 01 15:15:18 myServer.example.com [sssd[krb5_child[1731]]][1731]: Cannot find KDC for realm "EXAMPLE.COM" Sep 01 15:15:18 myServer.example.com sshd[1723]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=X.X.X.X user=ADuser(a)EXAMPLE.COM Sep 01 15:15:18 myServer.example.com sshd[1723]: pam_sss(sshd:auth): received for user ADuser(a)EXAMPLE.COM: 6 (Permission denied) Sep 01 15:15:20 myServer.example.com sshd[1723]: Failed password for ADuser(a)EXAMPLE.COM from X.X.X.X port 57320 ssh2

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users September 2020