October 2020 - FreeIPA-users - Fedora mailing-lists

Health Checks for RHEL7
by White, David 06 Oct '20

06 Oct '20

Are any of you aware of any way to get these health checks working on a RHEL 7 system? https://github.com/freeipa/freeipa-healthcheck IIRC, these checks weren't really introduced until a newer version of FreeIPA, so they are only included on RHEL 8 and above, but I'm wondering if there's a way to get these installed manually. Is this possible on RHEL 7? I tried doing the following a lab environment: - Downloaded the code and extracted it - pip3 install pytest-runner - python3 setup.py install Now, I do have an executable at /usr/local/bin/ipa-healthcheck However, when I go to run that, I'm getting the following error: [root@cha-cop-lab-mgt-ath-001 freeipa-healthcheck-master]# /usr/local/bin/ipa-healthcheck Traceback (most recent call last): File "/usr/local/bin/ipa-healthcheck", line 11, in <module> load_entry_point('ipahealthcheck==0.6', 'console_scripts', 'ipa-healthcheck')() File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 476, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2700, in load_entry_point return ep.load() File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2318, in load return self.resolve() File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2324, in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0) ModuleNotFoundError: No module named 'ipahealthcheck'

2 3

ipa migrate-ds not updating group memberships
by Alfred Victor 06 Oct '20

06 Oct '20

Hi FreeIPA, Maybe I've misunderstood how migrate-ds should work, worth mentioning the source directory is RFC2307 - if ipa migrate-ds migrates a user, then later that user is added more groups and the same migrate-ds command is run again, should it not add the user into the corresponding groups on IPA which did not have its memberUid prior? Alfred

2 1

Get list of IPA users
by Dominik Vogt 06 Oct '20

06 Oct '20

To get a list of Ipa users one can type something like $ ipa user-find | grep "User login:" | sed -e "/.* //" This works on any ipa client, but can take a couple of seconds. This is a bit clumsy when scripting because scripts are slow to respond. Is there a quicker way to get that list? Ciao Dominik ^_^ ^_^ -- Dominik Vogt

2 2

Privileges needed for ipa-client-install
by Ronald Wimmer 05 Oct '20

05 Oct '20

What are the least privileges an IPA user would need to run ipa-client-install? I added the permission "System: Add Hosts" to the "Host Enrollment" privilege but unfortunately that was not sufficient. Cheers, Ronald

2 1

Login "System error"
by Dominik Vogt 05 Oct '20

05 Oct '20

Somehow I've managed to damage the ipa server configuration so that ipal users cannot login anymore. Local users work fine. Using the console on the ipa server: Login: ... Password: ... System error Messages in /var/log/secure say: -- ... login[25478]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=USERNAME ... login[25478]: pam_sss(login:auth): received for user USERNAME: 12 (Authentication token is no longer valid; new one required) ... login[25478]: pam_sss(login:account): Access denied for user USERNAME: 4 (System error) ... login[25478]: System error -- I've no idea what the problem could be. (The "no longer valid" message is because it's the initial password that needs to be changed.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt

1 1

POSIX ids of all AD users
by Ronald Wimmer 03 Oct '20

03 Oct '20

How could I possibly find the POSIX ids of all mapped Active Directory users? I do neither see them in LDAP nor do I find them with IPA user find. Cheers, Ronald

4 6

Re: POSIX ids of all AD users
by Ronald Wimmer 03 Oct '20

03 Oct '20

On 03.10.20 08:45, Angus Clarke wrote: > Hi Ronald > > Look at the "Attribute Editor" tab against a user account in "Active > Directory users and computers." It should be in the list there > (uidNumber) amongst other useful things. > > I'm no Microsoft administrator but am aware that this "Attribute > Editor" tab is not listed if you search for the user; rather you have > to browse to the user through the tree. Unfortunately, I do only have LDAP access to our AD. AD is managed by a separate department.

1 1

yum update problem
by Natxo Asenjo 02 Oct '20

02 Oct '20

hi, after patching our centos 7 hosts to the latest version today, one of the two replicas is having trouble. [root@kdc2 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: STOPPED kadmin Service: STOPPED named Service: STOPPED httpd Service: RUNNING ipa-custodia Service: STOPPED ntpd Service: STOPPED pki-tomcatd Service: RUNNING smb Service: STOPPED winbind Service: STOPPED ipa-otpd Service: STOPPED ipa-dnskeysyncd Service: STOPPED ipa: INFO: The ipactl command was successful and after digging in the logs I come across this in /var/log/ipaupgrade.log: 2019-11-20T18:18:29Z DEBUG stderr= 2019-11-20T18:18:31Z INFO Certmonger certificate renewal configuration already up-to-date 2019-11-20T18:18:31Z INFO [Enable PKIX certificate path discovery and validation] 2019-11-20T18:18:31Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2019-11-20T18:18:31Z INFO PKIX already enabled 2019-11-20T18:18:31Z INFO [Authorizing RA Agent to modify profiles] 2019-11-20T18:18:31Z INFO [Authorizing RA Agent to manage lightweight CAs] 2019-11-20T18:18:31Z INFO [Ensuring Lightweight CAs container exists in Dogtag database] 2019-11-20T18:18:31Z DEBUG Created connection context.ldap2_139740162547472 2019-11-20T18:18:31Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket from SchemaCache 2019-11-20T18:18:31Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f17cc24b638> 2019-11-20T18:18:31Z DEBUG Destroyed connection context.ldap2_139740162547472 2019-11-20T18:18:31Z INFO [Adding default OCSP URI configuration] 2019-11-20T18:18:31Z INFO [Ensuring CA is using LDAPProfileSubsystem] 2019-11-20T18:18:31Z INFO [Migrating certificate profiles to LDAP] 2019-11-20T18:18:31Z DEBUG Created connection context.ldap2_139740160021648 2019-11-20T18:18:31Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket from SchemaCache 2019-11-20T18:18:31Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f17cc289b00> 2019-11-20T18:18:31Z DEBUG Destroyed connection context.ldap2_139740160021648 2019-11-20T18:18:31Z DEBUG request GET https://kdc2.l.domain.it:8443/ca/rest/account/login 2019-11-20T18:18:31Z DEBUG request body '' 2019-11-20T18:18:31Z DEBUG response status 401 2019-11-20T18:18:31Z DEBUG response headers Server: Apache-Coyote/1.1 Cache-Control: private Expires: Thu, 01 Jan 1970 01:00:00 CET WWW-Authenticate: Basic realm="Certificate Authority" Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 951 Date: Wed, 20 Nov 2019 18:18:31 GMT 2019-11-20T18:18:31Z DEBUG response body '<html><head><title>Apache Tomcat/7.0.76 - Error report</title><style></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.76</h3></body></html>' 2019-11-20T18:18:31Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2019-11-20T18:18:31Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 54, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2146, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2018, in upgrade_configuration ca_enable_ldap_profile_subsystem(ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 406, in ca_enable_ldap_profile_subsystem cainstance.migrate_profiles_to_ldap() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 2027, in migrate_profiles_to_ldap _create_dogtag_profile(profile_id, profile_data, overwrite=False) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 2033, in _create_dogtag_profile with api.Backend.ra_certprofile as profile_api: File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1315, in __enter__ raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) 2019-11-20T18:18:31Z DEBUG The ipa-server-upgrade command failed, exception: RemoteRetrieveError: Failed to authenticate to CA REST API 2019-11-20T18:18:31Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: RemoteRetrieveError: Failed to authenticate to CA REST API In this kdc I see these errors in getcert list: Request ID '20190220182014': status: MONITORING ca-error: Invalid cookie: u'' 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=L.DOMAIN.IT subject: CN=CA Audit,O=L.DOMAIN.IT expires: 2019-12-05 13:58:24 UTC 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 '20190220182015': status: MONITORING ca-error: Invalid cookie: u'' 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=L.DOMAIN.IT subject: CN=OCSP Subsystem,O=L.DOMAIN.IT expires: 2019-12-05 13:58:24 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign 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 '20190220182016': status: MONITORING ca-error: Invalid cookie: u'' 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=L.DOMAIN.IT subject: CN=CA Subsystem,O=L.DOMAIN.IT expires: 2019-12-05 13:58:24 UTC 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 '20190220182018': status: MONITORING ca-error: Invalid cookie: u'' 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=L.DOMAIN.IT subject: CN=IPA RA,O=L.DOMAIN.IT expires: 2019-12-05 13:58:44 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 Request ID '20190220182019': status: MONITORING ca-error: Server at " https://kdc2.l.domain.it:8443/ca/agent/ca/profileProcess" replied: 1: Invalid Credential. 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-ca-renew-agent issuer: CN=Certificate Authority,O=L.DOMAIN.IT subject: CN=kdc2.l.domain.it,O=L.DOMAIN.IT expires: 2019-12-10 10:57:52 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth,id-kp-emailProtection 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 I still have a working replica, so I could just reinstall and have a working set in a couple of minutes, but I would like to find out what has gone wrong. The systems are running ipa-server-4.6.5-11.el7.centos.3.x86_64 Any help welcome ;-) Thanks, -- Groeten, natxo

4 12

Principal name change
by Kobus Bensch 02 Oct '20

02 Oct '20

Hi I can find anything on search so here goes: I installed freeipa with domain: company.com, but this now needs to change to newcompany.net Can someone please direct me to docs that i can read to make this change? Thank you Kobus

2 1

Re: Renewing a failed to auto-renewal certificate
by Stuart McRobert 02 Oct '20

02 Oct '20

Dear flo, Thanks for the helpful links. To check whether replication is possible between the three freeipa servers, via the web interface on each, I have successfully created three new users: + On server 1 create a new user 1 and check they appear on servers 2 & 3 - yes + On server 2 create a new user 2 and check they appear on servers 1 & 3 - yes + On server 3 create a new user 3 and check they appear on servers 1 & 2 - yes Then for each user remove them from a different server to where they were created. This worked as expected. However I do appear to have one user whose information failed to correctly replicate some time ago, causing an inconsistency that I am uncertain on the best way to fix. On server 1 via web attempt to view this specific user: Operations Error Some operations failed. XXX: user not found which should be displayed as a preserved user entry but lacks any details shown other than the "user login". On server 2 this user appears as an active user, with details, status disabled. On server 3 this user appears as a preserved user, with full details, and a note I added to the Class field a few days ago to see whether it would then just replicate but failed. In logs, searching for the user in question on server 1 ./httpd/error_log:[Sun Sep 20 10:34:14.256333 2020] [wsgi:error] [pid 29637] [remote IP_ADDRESS:56930] ipa: INFO: [jsonserver_session] sm@OUR_DOMAIN: user_find(u'USER_XXX', sizelimit=0, version=u'2.215', pkey_only=True): SUCCESS ./httpd/error_log:[Sun Sep 20 10:34:28.721951 2020] [wsgi:error] [pid 29637] [remote IP_ADDRESS:56932] ipa: INFO: [jsonserver_session] sm@OUR_DOMAIN: user_find(u'USER_XXX', preserved=True, sizelimit=0, version=u'2.215', pkey_only=True): SUCCESS ./httpd/error_log:[Sun Sep 20 10:34:28.738772 2020] [wsgi:error] [pid 29636] [remote IP_ADDRESS:56932] ipa: INFO: sm@OUR_DOMAIN: batch: user_show(u'USER_XXX', no_members=True): NotFound ./httpd/error_log:[Sun Sep 20 10:34:28.738952 2020] [wsgi:error] [pid 29636] [remote IP_ADDRESS:56932] ipa: INFO: [jsonserver_session] sm@OUR_DOMAIN: batch(({u'params': ((u'USER_XXX',), {u'no_members': True}), u'method': u'user_show'},), version=u'2.215'): SUCCESS Which just confirms what was seen via the web interface. Next go looking in /var/log/dirsrv/slapd-OUR-DOMAIN/errors and find lots of these messages: [20/Sep/2020:11:18:12.449932996 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=caToserver2" (server2:389): CSN 5bb473ef000000070000 not found, we aren't as up to date, or we purged [20/Sep/2020:11:18:12.452051936 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=caToserver2" (server2:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. [20/Sep/2020:11:18:15.479226915 +0100] - ERR - agmt="cn=caToserver2" (server2:389) - clcache_load_buffer - Can't locate CSN 5bb473ef000000070000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [20/Sep/2020:11:18:15.481677959 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=caToserver2" (server2:389): CSN 5bb473ef000000070000 not found, we aren't as up to date, or we purged [20/Sep/2020:11:18:15.483458741 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=caToserver2" (server2:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. But is that the only CSN found to be missing, seems to be based on this search: grep -v 5bb473ef000000070000 ./dirsrv/slapd-OUR-DOMAIN/errors | grep -v "If the error persists" 389-Directory/1.3.6.6 B2017.145.2031 server1.OUR-DOMAIN:636 (/etc/dirsrv/slapd-OUR-DOMAIN) [18/Sep/2020:05:57:26.038958649 +0100] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meToserver3" (server3:389): Unable to parse the response to the endReplication extended operation. [18/Sep/2020:17:45:55.236862951 +0100] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=caToserver2" (server2:389): Unable to parse the response to the endReplication extended operation. Turning next to server 2 and the dirsrv logs there, lots of messages of the form: [17/Sep/2020:19:33:24.075845464 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773158 (rc: 32) [17/Sep/2020:19:33:24.076296207 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773159 (rc: 32) [17/Sep/2020:19:33:24.077311010 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773160 (rc: 32) [17/Sep/2020:19:33:24.077830624 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773161 (rc: 32) [19/Sep/2020:19:59:28.091654453 +0100] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meToserver1" (server1:389): Unable to parse the response to the endReplication extended operation. Finally for server 3, dirsrv logs appear to be more about getting started after certificate problems the other day, rather than issues seen on the other servers, but this server does appear to display the user fully as would be desired everywhere. Our old version appears to lack the 389 command dsconf so not been able to use that to help. Summary: + Replication appears to work for e.g. new users + I guess one entry has failed to be replicated correctly causing the inconsistent state on the other two servers + This should ideally be corrected to avoid further issues??? + Uncertain about the best way to do this, suggestions very welcome as first time fixing such problems and I don't want to make it any worse, after all replications seems to be working for everything else. Thanks Best wishes Stuart

2 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users October 2020