March 2020 - FreeIPA-users - Fedora mailing-lists

Re: So, I think I found a bug - Debian 10 ipa-client-install does not configure /etc/pam.d files properly (if at all)
by White, Daniel E. (GSFC-770.0)[NICS] 05 Mar '20

05 Mar '20

Many thanks, Sam. That was exactly the problem. Now that I knew what to look for, I found it in the ipa-client-install output. It says "Local modifications to /etc/pam.d/common-*, not updating. Run pam-auth-update --force to override." ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290 From: FreeIPA <freeipa-users(a)lists.fedorahosted.org> Reply-To: FreeIPA <freeipa-users(a)lists.fedorahosted.org> Date: Wednesday, March 4, 2020 at 18:20 To: FreeIPA <freeipa-users(a)lists.fedorahosted.org> Cc: Sam Morris <sam(a)robots.org.uk> Subject: [EXTERNAL] [Freeipa-users] Re: So, I think I found a bug - Debian 10 ipa-client-install does not configure /etc/pam.d files properly (if at all) See /var/lib/dpkg/info/libpam-sss.postinst; when the libpam-sss package is installed, "pam-auth-update" is run, which normally updates the various /etc/pam.d/common-* files based on the contents of /usr/share/pam-configs. If your PAM config files got screwed up for whatever reason, you should be able to run "pam-auth-update" to fix things. If it detects that any of the common-* files were modified outside of its control, it should print a warning advising you to re-run it with --force to blow those changes away and get things working again.

1 0

Directory server on a dedicated filesystem?
by Daniel PC 04 Mar '20

04 Mar '20

Hi all I noticed IPA install the DS on /var/lib/dirsrv. My question is: do you think it is necessary a dedicated filesystem to host the ldap database? I thought a dedicated file-system only for /var thank you

4 5

So, I think I found a bug - Debian 10 ipa-client-install does not configure /etc/pam.d files properly (if at all)
by White, Daniel E. (GSFC-770.0)[NICS] 04 Mar '20

04 Mar '20

Reference my earlier thread "A Debian Head-Scratcher" Do I file the bug here https://pagure.io/freeipa/issues ? Debian 10, freeipa-client 4.7.2-3 amd64 ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290

3 2

A Shameless Plea for FreeIPA Community Support - "RSA should support FreeIPA / Red Hat Identity Manager as an Identity Source"
by White, Daniel E. (GSFC-770.0)[NICS] 04 Mar '20

04 Mar '20

The end result (just today) for a support ticket opened on 10 Feb was the "suggestion" I create an "IDEA" in the RSA community. "Ideas on RSA Link provide a mechanism for requesting enhancements, per product, in one definitive area, and encourage registered RSA Link users to tap into the power of crowdsourcing. Once your idea is created, other community users will be able to vote on the enhancement and/or add comments to build upon the original idea in an effort to make the idea more appealing to a larger group of organizations.", says RSA Support. Here is the idea-link: https://community.rsa.com/ideas/3378 Please go vote it into reality. I doubt it will happen any other way, if it happens at all. And thanks to all the folks on the list that have provided help to N00Bz like me. ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290

1 0

Overriding the Default shell for Active Directory users
by White, David 04 Mar '20

04 Mar '20

We have a FreeIPA / IdM environment that talks to Active Directory, where the user accounts live. In the IdM GUI, I have navigated to: IPA Server -> Configuration And I configured the "Default Shell" to: /bin/bash However, whenever new users SSH to a server using their AD credentials, they are still put into a /bin/sh shell. I have created an ID Override for myself by going to: Identity -> ID Views, editing the "Default Trust View", and adding myself. In my ID Override, I have set my own shell to /bin/bash My guess is that the global option in IPA Server -> Configuration is only applied to local IPA accounts, and not AD accounts. Is that a correct assumption? Is there any way that we can change the default shell for AD users without having to manually and individually create an ID Override?

2 2

FreeIPA & Samba integration -- winbind issue?
by C T 04 Mar '20

04 Mar '20

I am trying to set up a samba server as part of a freeipa domain. I'd like users on windows machines from two trusted AD domains to access shares on the server (both users and computers are in the trusted AD domains). I've been through the docs (RHEL 8 "Setting up Samba on an IDM domain member", https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA) and built a couple of servers using CentOS 8; results are the same each time -- no worky. These servers integrate with Freeipa fine -- users from both trusted AD domains can SSH in etc. But errors are legion in samba. Both IPA and AD domains (and the trust relationshipts) have been in production for a while working fine so I'm pretty confident DNS is ok. Kerberos seems to be working fine too as I can kinit users in all domains OK from the samba box. I'm confident firewalls are not blocking anything. I'm thinking it's winbind that is the key problem, with it somehow not being able to auth to the AD domains, but I'm not experienced with Samba/winbind so I'm struggling after all day on it. Any guidance would be appreciated. ----- [root@ner-cont-tfer01 samba]# cat log.smbd [2020/03/03 18:49:25.650974, 0] ../../source3/smbd/server.c:1782(main) smbd version 4.10.4 started. Copyright Andrew Tridgell and the Samba Team 1992-2019 [2020/03/03 18:49:25.651595, 2] ../../source3/lib/tallocmsg.c:56(register_msg_pool_usage) Registered MSG_REQ_POOL_USAGE [2020/03/03 18:49:25.651616, 2] ../../source3/lib/dmallocmsg.c:78(register_dmalloc_msgs) Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED [2020/03/03 18:49:25.651658, 3] ../../source3/param/loadparm.c:3872(lp_load_ex) lp_load_ex: refreshing parameters [2020/03/03 18:49:25.651703, 3] ../../source3/param/loadparm.c:550(init_globals) Initialising global parameters [2020/03/03 18:49:25.651773, 3] ../../source3/param/loadparm.c:2786(lp_do_section) Processing section "[global]" [2020/03/03 18:49:25.651976, 2] ../../source3/param/loadparm.c:2803(lp_do_section) Processing section "[transfer]" [2020/03/03 18:49:25.652112, 3] ../../source3/param/loadparm.c:1621(lp_add_ipc) adding IPC service [2020/03/03 18:49:25.652353, 2] ../../source3/lib/interface.c:345(add_interface) added interface ens160 ip=10.13.10.46 bcast=10.13.10.255 netmask=255.255.255.0 [2020/03/03 18:49:25.652401, 3] ../../source3/smbd/server.c:1851(main) loaded services [2020/03/03 18:49:25.662297, 1] ../../source3/profile/profile.c:51(set_profile_level) INFO: Profiling turned OFF from pid 2872 [2020/03/03 18:49:25.662333, 3] ../../source3/smbd/server.c:1871(main) Standard input is not a socket, assuming -D option [2020/03/03 18:49:25.662347, 3] ../../source3/smbd/server.c:1883(main) Becoming a daemon. [2020/03/03 18:49:25.662669, 2] ../../source3/passdb/pdb_interface.c:161(make_pdb_method_name) No builtin backend found, trying to load plugin [2020/03/03 18:49:25.667658, 3] ../../lib/util/modules.c:167(load_module_absolute_path) load_module_absolute_path: Module '/usr/lib64/samba/pdb/tdbsam.so' loaded [2020/03/03 18:49:25.670380, 3] ../../source3/lib/util_procid.c:54(pid_to_procid) pid_to_procid: messaging_dgm_get_unique failed: No such file or directory [2020/03/03 18:49:25.708568, 3] ../../source3/rpc_server/svcctl/srv_svcctl_reg.c:565(svcctl_init_winreg) Initialise the svcctl registry keys if needed. [2020/03/03 18:49:25.710710, 3] ../../source3/rpc_server/eventlog/srv_eventlog_reg.c:59(eventlog_init_winreg) Initialise the eventlog registry keys if needed. [2020/03/03 18:49:25.711103, 0] ../../lib/util/become_daemon.c:136(daemon_ready) daemon_ready: daemon 'smbd' finished starting up and ready to serve connections [2020/03/03 18:49:25.711395, 3] ../../source3/libsmb/namequery.c:3112(get_dc_list) get_dc_list: preferred server list: "ld9-cont-idm2.idm.domain.lan, *" [2020/03/03 18:49:25.716447, 3] ../../source3/libads/ldap.c:636(ads_connect) Successfully contacted LDAP server 10.17.10.60 [2020/03/03 18:49:25.716507, 3] ../../source3/libsmb/namequery.c:3112(get_dc_list) get_dc_list: preferred server list: "ld9-cont-idm2.idm.domain.lan, *" [2020/03/03 18:49:25.717755, 3] ../../source3/libsmb/namequery.c:3112(get_dc_list) get_dc_list: preferred server list: "ld9-cont-idm2.idm.domain.lan, *" [2020/03/03 18:49:25.720066, 3] ../../source3/libads/ldap.c:636(ads_connect) Successfully contacted LDAP server 10.17.10.60 [2020/03/03 18:49:25.729787, 3] ../../source3/libads/ldap.c:679(ads_connect) Connected to LDAP server ld9-cont-idm2.idm.domain.lan [2020/03/03 18:49:25.733298, 3] ../../source3/printing/nt_printing_ads.c:650(check_published_printers) ads_connect failed: No results returned [2020/03/03 18:49:25.733672, 0] ../../source3/printing/nt_printing.c:249(nt_printing_init) nt_printing_init: error checking published printers: WERR_ACCESS_DENIED [2020/03/03 18:49:25.733738, 3] ../../source3/printing/queue_process.c:328(start_background_queue) start_background_queue: Starting background LPQ thread [2020/03/03 18:49:25.736685, 1] ../../source3/printing/printer_list.c:234(printer_list_get_last_refresh) Failed to fetch record! [2020/03/03 18:49:25.736760, 2] ../../source3/smbd/server.c:1415(smbd_parent_loop) waiting for connections [2020/03/03 18:49:25.737512, 3] ../../source3/printing/pcap.c:140(pcap_cache_reload) reloading printcap cache [2020/03/03 18:49:25.738321, 3] ../../source3/printing/pcap.c:194(pcap_cache_reload) reload status: ok [2020/03/03 18:49:25.739690, 3] ../../source3/printing/print_cups.c:158(cups_connect) Unable to connect to CUPS server localhost:631 - Bad file descriptor [2020/03/03 18:49:25.740315, 3] ../../source3/printing/print_cups.c:536(cups_async_callback) failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL [2020/03/03 18:49:25.740359, 2] ../../lib/util/tevent_debug.c:66(samba_tevent_debug) samba_tevent: EPOLL_CTL_DEL EBADF for fde[0x557b78295c20] mpx_fde[(nil)] fd[15] - disabling ----- [root@ner-cont-tfer01 samba]# cat log.winbindd [2020/03/03 18:49:25.540832, 0] ../../source3/winbindd/winbindd.c:1731(main) winbindd version 4.10.4 started. Copyright Andrew Tridgell and the Samba Team 1992-2019 [2020/03/03 18:49:25.541626, 2] ../../source3/lib/tallocmsg.c:56(register_msg_pool_usage) Registered MSG_REQ_POOL_USAGE [2020/03/03 18:49:25.541648, 2] ../../source3/lib/dmallocmsg.c:78(register_dmalloc_msgs) Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED [2020/03/03 18:49:25.541685, 3] ../../source3/param/loadparm.c:3872(lp_load_ex) lp_load_ex: refreshing parameters [2020/03/03 18:49:25.541729, 3] ../../source3/param/loadparm.c:550(init_globals) Initialising global parameters [2020/03/03 18:49:25.541748, 2] ../../source3/param/loadparm.c:322(max_open_files) rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) [2020/03/03 18:49:25.541812, 3] ../../source3/param/loadparm.c:2786(lp_do_section) Processing section "[global]" [2020/03/03 18:49:25.542292, 2] ../../source3/lib/interface.c:345(add_interface) added interface ens160 ip=10.13.10.46 bcast=10.13.10.255 netmask=255.255.255.0 [2020/03/03 18:49:25.542439, 2] ../../source3/lib/interface.c:345(add_interface) added interface ens160 ip=10.13.10.46 bcast=10.13.10.255 netmask=255.255.255.0 [2020/03/03 18:49:25.544253, 2] ../../source3/passdb/pdb_interface.c:161(make_pdb_method_name) No builtin backend found, trying to load plugin [2020/03/03 18:49:25.549553, 3] ../../lib/util/modules.c:167(load_module_absolute_path) load_module_absolute_path: Module '/usr/lib64/samba/pdb/tdbsam.so' loaded [2020/03/03 18:49:25.549763, 0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache) initialize_winbindd_cache: clearing cache and re-creating with version number 2 [2020/03/03 18:49:25.552125, 3] ../../source3/winbindd/winbindd_util.c:297(add_trusted_domain) add_trusted_domain: Added domain [BUILTIN] [(null)] [S-1-5-32] [2020/03/03 18:49:25.552184, 3] ../../source3/winbindd/winbindd_util.c:297(add_trusted_domain) add_trusted_domain: Added domain [NER-CONT-TFER01] [(null)] [S-1-5-21-3888470300-4080800567-3624582073] [2020/03/03 18:49:25.552238, 3] ../../source3/winbindd/winbindd_util.c:297(add_trusted_domain) add_trusted_domain: Added domain [IDM] [IDM.CONTENT.domain.lan] [S-1-5-21-2682878861-151095253-3776833076] [2020/03/03 18:49:25.552602, 0] ../../lib/util/become_daemon.c:136(daemon_ready) daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections [2020/03/03 18:49:25.704494, 3] ../../source3/winbindd/winbindd_misc.c:432(winbindd_interface_version) winbindd_interface_version: [smbd (2872)]: request interface version (version = 31) [2020/03/03 18:49:25.704604, 3] ../../source3/winbindd/winbindd_misc.c:407(winbindd_ping) winbindd_ping: [smbd (2872)]: ping [2020/03/03 18:49:25.795046, 1] ../../source3/winbindd/winbindd_util.c:442(trustdom_list_done) trustdom_list_done: Could not receive trusts for domain IDM ----- [root@ner-cont-tfer01 samba]# cat log.wb-IDM [2020/03/03 18:49:25.568371, 3] ../../source3/winbindd/winbindd_cm.c:2148(connection_ok) connection_ok: Connection to (null) for domain IDM is not connected [2020/03/03 18:49:25.580016, 3] ../../source3/libads/ldap.c:636(ads_connect) Successfully contacted LDAP server 10.17.10.60 [2020/03/03 18:49:25.580096, 3] ../../source3/libsmb/namequery.c:3112(get_dc_list) get_dc_list: preferred server list: "ld9-cont-idm2.idm.domain.lan, *" [2020/03/03 18:49:25.591042, 3] ../../source3/libsmb/namequery.c:3112(get_dc_list) get_dc_list: preferred server list: "ld9-cont-idm2.idm.domain.lan, *" [2020/03/03 18:49:25.613487, 3] ../../source3/lib/util_sock.c:515(open_socket_out_send) Connecting to 10.17.10.60 at port 445 [2020/03/03 18:49:25.658699, 3] ../../lib/ldb-samba/ldb_wrap.c:332(ldb_wrap_connect) ldb_wrap open of secrets.ldb [2020/03/03 18:49:25.658913, 3] ../../source3/libsmb/cliconnect.c:273(cli_session_creds_prepare_krb5) got OID=1.2.840.48018.1.2.2 [2020/03/03 18:49:25.696869, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'gssapi_spnego' registered [2020/03/03 18:49:25.696927, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'gssapi_krb5' registered [2020/03/03 18:49:25.696942, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'gssapi_krb5_sasl' registered [2020/03/03 18:49:25.696954, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'spnego' registered [2020/03/03 18:49:25.696970, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'schannel' registered [2020/03/03 18:49:25.696983, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'naclrpc_as_system' registered [2020/03/03 18:49:25.696996, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'sasl-EXTERNAL' registered [2020/03/03 18:49:25.697008, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'ntlmssp' registered [2020/03/03 18:49:25.697019, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'ntlmssp_resume_ccache' registered [2020/03/03 18:49:25.697031, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'http_basic' registered [2020/03/03 18:49:25.697043, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'http_ntlm' registered [2020/03/03 18:49:25.697055, 3] ../../auth/gensec/gensec_start.c:977(gensec_register) GENSEC backend 'http_negotiate' registered [2020/03/03 18:49:25.774922, 3] ../../source3/winbindd/winbindd_misc.c:291(winbindd_dual_list_trusted_domains) winbindd_dual_list_trusted_domains: [ 2869]: list trusted domains [2020/03/03 18:49:25.774969, 3] ../../source3/winbindd/winbindd_ads.c:1400(trusted_domains) ads: trusted_domains [2020/03/03 18:49:25.775303, 3] ../../lib/ldb-samba/ldb_wrap.c:332(ldb_wrap_connect) ldb_wrap open of secrets.ldb [2020/03/03 18:49:25.775766, 3] ../../source3/lib/util_sock.c:515(open_socket_out_send) Connecting to 10.17.10.60 at port 135 [2020/03/03 18:49:25.777290, 3] ../../source3/lib/util_sock.c:515(open_socket_out_send) Connecting to 10.17.10.60 at port 49152 [2020/03/03 18:49:25.790440, 3] ../../source3/lib/util_sock.c:515(open_socket_out_send) Connecting to 10.17.10.60 at port 135 [2020/03/03 18:49:25.792367, 3] ../../source3/lib/util_sock.c:515(open_socket_out_send) Connecting to 10.17.10.60 at port 49152 [2020/03/03 18:49:25.794491, 1] ../../source3/rpc_client/cli_pipe.c:569(cli_pipe_validate_current_pdu) ../../source3/rpc_client/cli_pipe.c:569: RPC fault code DCERPC_NCA_S_OP_RNG_ERROR received from host ld9-cont-idm2.idm.domain.lan! [2020/03/03 18:49:25.794528, 3] ../../source3/winbindd/winbindd_ads.c:1400(trusted_domains) ads: trusted_domains [2020/03/03 18:49:25.794913, 1] ../../source3/rpc_client/cli_pipe.c:569(cli_pipe_validate_current_pdu) ../../source3/rpc_client/cli_pipe.c:569: RPC fault code DCERPC_NCA_S_OP_RNG_ERROR received from host ld9-cont-idm2.idm.domain.lan! [2020/03/03 18:49:25.794945, 3] ../../source3/winbindd/winbindd_misc.c:297(winbindd_dual_list_trusted_domains) winbindd_dual_list_trusted_domains: trusted_domains returned NT_STATUS_RPC_PROCNUM_OUT_OF_RANGE ----- There are no users in the IDM domain, but there are groups, yet wbinfo doesn't turn them up: [root@ner-cont-tfer01 samba]# wbinfo -g [root@ner-cont-tfer01 samba]# ----- wbinfo can lookup the trusted domains, but doesn't show them as trusted: [root@ner-cont-tfer01 samba]# wbinfo --getdcname=AD dc2 (no domain portion) [root@ner-cont-tfer01 samba]# wbinfo --getdcname=MOPO dc1.mopo.lan [root@ner-cont-tfer01 samba]# wbinfo -m BUILTIN NER-CONT-TFER01 IDM ----- klist shows the principal correctly I think: [root@ner-cont-tfer01 samba]# klist -k /etc/samba/samba.keytab Keytab name: FILE:/etc/samba/samba.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 cifs/ner-cont-tfer01.idm.domain.lan(a)IDM.DOMAIN.LAN 1 cifs/ner-cont-tfer01.idm.domain.lan(a)IDM.DOMAIN.LAN 1 cifs/ner-cont-tfer01.idm.domain.lan(a)IDM.DOMAIN.LAN ----- Any pointers appreciated!

3 2

Re: Issues with certificates: X509: KEY_VALUES_MISMATCH
by Rob Crittenden 04 Mar '20

04 Mar '20

Dmitri Moudraninets wrote: > Hi Rob, > > I recovered the key file. Restarted FreeIPA and certmonger. Now issue > looks different: > image.png > > Subjects disappeared. If I click on a certificate 29 I see this: > cannot connect to > 'https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial': > [Errno 13] Permission denied Set the same ownership/permissions on the key as you did the cert and run restorecon on it. rob > > пн, 25 нояб. 2019 г. в 13:58, Rob Crittenden <rcritten(a)redhat.com > <mailto:rcritten@redhat.com>>: > > Dmitri Moudraninets wrote: > > Hi Rob, > > > > > > > > I did the following: > > I removed original ra-agent.pem and ra-agent key > > and > > openssl x509 -in /root/debug.cert -out /var/lib/ipa/ra-agent.pem > > chown root:ipaapi /var/lib/ipa/ra-agent.pem > > chmod 0440 /var/lib/ipa/ra-agent.pem > > restorecon /var/lib/ipa/ra-agent.pem > > You removed the key!? I sure hope you have a backup of it. > > Put it back and I think that will resolve things. > > > > > Successfully restarted FreeIPA: > > Directory Service: RUNNING > > krb5kdc Service: RUNNING > > kadmin Service: RUNNING > > named Service: RUNNING > > httpd Service: RUNNING > > ipa-custodia Service: RUNNING > > ntpd Service: RUNNING > > pki-tomcatd Service: RUNNING > > smb Service: RUNNING > > winbind Service: RUNNING > > ipa-otpd Service: RUNNING > > ipa-dnskeysyncd Service: RUNNING > > ipa: INFO: The ipactl command was successful > > The agent cert is not required for the CA to operate. > > > Now GUI shows different error: > > cannot connect to > > 'https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial': > > [Errno 2] No such file or directory > > > > > > [root@freeipa ~]# getcert list -f /var/lib/ipa/ra-agent.pem > > Number of certificates and requests being tracked: 16. > > Request ID '20180912151611': > > status: NEED_CSR > > stuck: no > > key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' > > certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem' > > CA: dogtag-ipa-ca-renew-agent > > issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE > <http://CORP.MYDOMAIN.DE> > > <http://CORP.MYDOMAIN.DE> > > subject: CN=IPA RA,O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE> > <http://CORP.MYDOMAIN.DE> > > expires: 2019-11-25 15:32:12 UTC > > 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 > > This shows that the certificate has the right subject now which is good > but you removed its private key so it won't work. > > rob > > > > > сб, 23 нояб. 2019 г. в 20:26, Rob Crittenden <rcritten(a)redhat.com > <mailto:rcritten@redhat.com> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>: > > > > Dmitri Moudraninets wrote: > > > Hi Rob, > > > > > > ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory manager' -W > > > -b uid=ipara,ou=People,o=ipaca usercertificate > > > > > > shows me the following: > > > > > > Issuer: O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE> > <http://CORP.MYDOMAIN.DE> > > <http://CORP.MYDOMAIN.DE>, > > > CN=Certificate Authority > > > Validity > > > Not Before: Dec 5 15:32:12 2017 GMT > > > Not After : *Nov 25 15:32:12 2019* GMT > > > > > > It's going to expire on Monday. Can it be a problem? > > > > You didn't provide the cert subject so I can't be sure this is > the right > > cert. If it contains CN = IPA RA then it is. > > > > And yes, it expires in two days. What you'd need to do is > restore it per > > my previous instruction into /var/lib/ipa/ra-agent.pem on the > renewal > > master (ipa config-show to see which one it is). > > > > Then run: > > > > # getcert resubmit -f /var/lib/ipa/ra-agent.pem > > > > That should renew the cert. > > > > On the other masters I'd run the same command and that may fix > things > > there as well. > > > > rob > > > > > I tried this command: > > > openssl x509 -text -in /var/lib/ipa/ra-agent.pem > > > > > > and it shows the following: > > > Certificate: > > > Data: > > > Version: 3 (0x2) > > > Serial Number: 28 (0x1c) > > > Signature Algorithm: sha256WithRSAEncryption > > > Issuer: O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE> > <http://CORP.MYDOMAIN.DE> > > <http://CORP.MYDOMAIN.DE>, > > > CN=Certificate Authority > > > Validity > > > Not Before: Oct 29 10:39:47 2019 GMT > > > Not After : Oct 29 09:39:47 2021 GMT > > > Subject: O=CORP.MYDOMAIN.DE > <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>, CN=dmud > > > Subject Public Key Info: > > > Public Key Algorithm: rsaEncryption > > > Public-Key: (2048 bit) > > > Modulus: > > > > 00:ba:09:81:99:9b:17:99:07:5a:10:28:c8:7a:03: > > > ... > > > > 18:db:02:ce:b4:66:ce:5a:e9:12:af:d3:da:bf:f7: > > > 66:5f > > > Exponent: 65537 (0x10001) > > > X509v3 extensions: > > > X509v3 Authority Key Identifier: > > > keyid:D2:...70:BF > > > > > > X509v3 Subject Key Identifier: > > > DE:...:51:0A > > > X509v3 Subject Alternative Name: > > > email:dmud@corp.mydomain.de > <mailto:email%3Admud@corp.mydomain.de> > > <mailto:email%3Admud@corp.mydomain.de > <mailto:email%253Admud@corp.mydomain.de>> > > > <mailto:email%3Admud@corp.mydomain.de > <mailto:email%253Admud@corp.mydomain.de> > > <mailto:email%253Admud@corp.mydomain.de > <mailto:email%25253Admud@corp.mydomain.de>>> > > > Authority Information Access: > > > OCSP - > URI:http://ipa-ca.corp.mydomain.de/ca/ocsp > > > > > > > > > I did nothing to /var/lib/ipa/ra-agent.pem yet. > > > > > > > > > чт, 21 нояб. 2019 г. в 16:54, Rob Crittenden > <rcritten(a)redhat.com <mailto:rcritten@redhat.com> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>> > > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>>: > > > > > > Dmitri Moudraninets wrote: > > > > Hi Rob, > > > > > > > > Yes both masters are failing the same way. Output > of openssl > > x509 > > > -noout > > > > -modulus -in /var/lib/ipa/ra-agent.pem is the same on both > > masters. > > > > Output of openssl rsa -noout -modulus -in > > /var/lib/ipa/ra-agent.key is > > > > also the same on both masters. But the output of the first > > command is > > > > not the same as the output of the second command. > > > > > > > > I can't remember that I troubleshoot any other > problems but we > > > tried to > > > > generate some personal certificates for some users. > Also we > > tried to > > > > generate certificates with key files for some of our > internal > > > services. > > > > We did that for the first time and it worked at the > end. Also I > > > changed > > > > the admin password not so long ago. > > > > > > > > > > > > Below you can find the output of the requested commands: > > > > > > > > > > > > [root@second_master ~]# getcert list -f > > /var/lib/ipa/ra-agent.pem > > > > Number of certificates and requests being tracked: 9. > > > > Request ID '20180912151730': > > > > status: MONITORING > > > > stuck: no > > > > key pair storage: > type=FILE,location='/var/lib/ipa/ra-agent.key' > > > > certificate: > type=FILE,location='/var/lib/ipa/ra-agent.pem' > > > > CA: dogtag-ipa-ca-renew-agent > > > > issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE > <http://CORP.MYDOMAIN.DE> > > <http://CORP.MYDOMAIN.DE> > > > <http://CORP.MYDOMAIN.DE> > > > > <http://CORP.MYDOMAIN.DE> > > > > subject: CN=dmud,O=CORP.MYDOMAIN.DE > <http://CORP.MYDOMAIN.DE> > > <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE> > > > <http://CORP.MYDOMAIN.DE> > > > > *<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I see a username here. > > Does it have > > > > to be like that?* > > > > expires: 2021-10-29 09:39:47 UTC > > > > email: dmud(a)corp.mydomain.de > <mailto:dmud@corp.mydomain.de> <mailto:dmud@corp.mydomain.de > <mailto:dmud@corp.mydomain.de>> > > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de> > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>>> > > > <mailto:dmud@corp.mydomain.de > <mailto:dmud@corp.mydomain.de> <mailto:dmud@corp.mydomain.de > <mailto:dmud@corp.mydomain.de>> > > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de> > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>>>> > > > > 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 > > > > > > Right, someone overwrote the RA agent certificate. > > > > > > Look to see if the user entry in the CA has the right cert: > > > > > > $ ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory > manager' > > -W -b > > > uid=ipara,ou=People,o=ipaca usercertificate > > > > > > Put the base64 value of the usercertificate attribute into a > > file and > > > add a prefix/suffix around it: > > > > > > -----BEGIN CERTIFICATE----- > > > MII....blah= > > > -----END CERTIFICATE----- > > > > > > $ openssl x509 -text -in /path/to/file > > > > > > If the Subject is O = CORP.MYDOMAIN.DE > <http://CORP.MYDOMAIN.DE> > > <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>, CN > > > = IPA RA then that's a good > > > start. Also look at the expires date to be sure it is > still valid. > > > > > > Assuming that is ok then re-run the openssl modulus commands > > to ensure > > > they are the same. > > > > > > Assuming that too is ok then you have the proper, valid RA > > agent cert. > > > In that case I'd move the current file out of the way, who > > knows what it > > > is, then run: > > > > > > # openssl x509 -in /path/to/file -out > > /var/lib/ipa/ra-agent.pem (just to > > > properly format the agent cert) > > > # chown root:ipaapi /var/lib/ipa/ra-agent.pem > > > # chmod 0440 /var/lib/ipa/ra-agent.pem > > > # restorecon /var/lib/ipa/ra-agent.pem > > > > > > Then try something like: ipa cert-show 1 > > > > > > This will exercise the RA agent cert and as long as you > don't > > get an > > > error back things are working again. > > > > > > The cert is common among all masters so you can copy the > file > > to your > > > other master(s), ensuring proper ownership, permissions and > > SELinux > > > context. > > > > > > rob > > > > > > > > > > > > -- > > > WBR > > > Dmitry > > > > > > > > -- > > With best regards/Mit freundlichen Grüßen > > > > Moudraninets Dmitry, RHCSA > > http://www.linkedin.com/in/moudraninets > > http://www.xing.com/profile/Dmitry_Mudraninets > > > > -- > With best regards/Mit freundlichen Grüßen > > Moudraninets Dmitry, RHCSA > http://www.linkedin.com/in/moudraninets > http://www.xing.com/profile/Dmitry_Mudraninets

2 7

SOLVED !! - A Debian Head-Scratcher
by White, Daniel E. (GSFC-770.0)[NICS] 03 Mar '20

03 Mar '20

I found an answer - on a CACHED web page. The original link says, " This question was removed from Unix & Linux Stack Exchange for reasons of moderation." Here's the cached link: https://webcache.googleusercontent.com/search?q=cache:vlUMKhpD2ooJ:https://… but Murphy only knows how long it will stay available. Here are the important bits that fixed my problem: /etc/pam.d/common-account account [default=bad success=ok user_unknown=ignore] pam_sss.so forward_pass use_first_pass account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so account requisite pam_deny.so account required pam_permit.so account sufficient pam_localuser.so /etc/pam.d/common-auth auth [success=2 default=ignore] pam_sss.so forward_pass auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_deny.so auth required pam_permit.so /etc/pam.d/common-password password [success=2 default=ignore] pam_sss.so forward_pass password [success=1 default=ignore] pam_unix.so obscure sha512 password requisite pam_deny.so password required pam_permit.so /etc/pam.d/common-session session [default=1] pam_permit.so session requisite pam_deny.so session required pam_mkhomedir.so session required pam_permit.so session required pam_unix.so session optional pam_sss.so And some diff's : # diff common-account common-account-bak 1,5d0 < account [default=bad success=ok user_unknown=ignore] pam_sss.so forward_pass use_first_pass < account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so < account requisite pam_deny.so < account required pam_permit.so < account sufficient pam_localuser.so 6a2,4 > account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so > account requisite pam_deny.so > account required pam_permit.so # diff common-auth common-auth-bak 1,5c1,2 < auth [success=2 default=ignore] pam_sss.so forward_pass < auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass < auth requisite pam_deny.so < auth required pam_permit.so < --- > auth required pam_unix.so nullok_secure > auth required pam_tally.so onerr=fail deny=5 per_user # diff common-password common-password-bak 1,5c1,4 < password [success=2 default=ignore] pam_sss.so forward_pass < password [success=1 default=ignore] pam_unix.so obscure sha512 < password requisite pam_deny.so < password required pam_permit.so < --- > password requisite pam_cracklib.so retry=3 minlen=8 difok=3 > password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 > password requisite pam_deny.so > password required pam_permit.so # diff common-session common-session-bak 1,6d0 < session [default=1] pam_permit.so < session requisite pam_deny.so < session required pam_mkhomedir.so < session required pam_permit.so < session required pam_unix.so < session optional pam_sss.so 7a2,7 > session [default=1] pam_permit.so > session requisite pam_deny.so > session required pam_permit.so > session required pam_unix.so > session optional pam_systemd.so > session optional pam_ck_connector.so nox11 ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290 From: FreeIPA <freeipa-users(a)lists.fedorahosted.org> Reply-To: FreeIPA <freeipa-users(a)lists.fedorahosted.org> Date: Tuesday, March 3, 2020 at 11:37 To: Jochen Kellner <jochen(a)jochen.org>, FreeIPA <freeipa-users(a)lists.fedorahosted.org> Cc: Rob Crittenden <rcritten(a)redhat.com>, Daniel White <daniel.e.white(a)nasa.gov> Subject: [EXTERNAL] [Freeipa-users] Re: A Debian Head-Scratcher grep -rnI pam_sss /var/log /etc/pam.d returns nothing on this Debian system It is all over the CentOS system files. Might this be an issue with the Debian freeipa-client package ? Also, I am able to log in with my IdM credentials, just not as this test-user. ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290

1 0

Interesting Issue -- IPA HTTP calls all fail with certificate verify failed: unable to get local issuer certificate
by jhaygood86＠gmail.com 03 Mar '20

03 Mar '20

So, my IPA server rebooted last night (from dnf automatic updates -- Fedora Server 31) When it came back, IPA basically is unusable, since pretty much every action logs this: (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)'))) I think this is because the contents of /etc/httpd/alias/ are probably corrupted somehow (the only file there is ipasession.key) certutil -L -d /etc/httpd/alias/ results in: certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad database. Any help would be useful! Thank you :)

4 4

Re: A Debian Head-Scratcher
by White, Daniel E. (GSFC-770.0)[NICS] 03 Mar '20

03 Mar '20

grep -rnI pam_sss /var/log /etc/pam.d returns nothing on this Debian system It is all over the CentOS system files. Might this be an issue with the Debian freeipa-client package ? Also, I am able to log in with my IdM credentials, just not as this test-user. ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290 From: Jochen Kellner <jochen(a)jochen.org> Date: Tuesday, March 3, 2020 at 11:06 To: FreeIPA <freeipa-users(a)lists.fedorahosted.org> Cc: Rob Crittenden <rcritten(a)redhat.com>, Daniel White <daniel.e.white(a)nasa.gov> Subject: [EXTERNAL] Re: [Freeipa-users] Re: A Debian Head-Scratcher "White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users" <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> writes: SSSD does not seem to be the source of the glitch. The sssd_nss.log says that it successfully finds the user. All the error in /var/log/auth.log contain "pam_unix", so I tried adding "debug" to the end of every instance of "pam_unix/pam_unix.so" in /etc/pam.d, but it told me nothing new. Any other suggestions ? Local users are authenticated by pam_unix, IPA users with pam_sss. I do run a custom PAM configuration, because older IPA clients needed that. I dropped a special file in /usr/share/pam-configs and used that, but that doesn't seem to be needed any longer. So, pam_unix shouldn't be your problem when pam_sss is called also. Rob's troubleshooting link should help you along. Jochen -- This space is intentionally left blank.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users March 2020