June 2020 - FreeIPA-users - Fedora mailing-lists

User based access control to services?
by Dominik Vogt 02 Jul '20

02 Jul '20

In our setup, a service is running on some server machine, say, "sample/servername.domain" and a client for that service is running on a workstation (using the sample gssapi client and server code from the kerberos sources). Now, what is the proper way to do this in freeipa? 1. Allow users foo and bar to log in to the workstation but to no other machine of the kerberos real. 2. Deny access to sample/servername.domain from any host except from the workstation. 3. Allow user foo access the service. 4. Deny user bar access the service. 5. Deny both users access to anything else on the server. I don't quite understand how that fits into chapter 10/19 or 31 of the "Linux Domain Identity, Authentication, and Policy Guide" for RHEL 7". Chapter 10 deals with access to freeipa internal objects, and chapter 31 describes host based access control. But how is access control done for someuser@clientmachine -> service@servermachine? Ciao Dominik ^_^ ^_^ -- Dominik Vogt

2 2

Change password hash for LDAP
by Max Muller 01 Jul '20

01 Jul '20

Hi all! I want use FreeIPA with FreeRADIUS. As I can know, FreeIPA use PBKDF2_SHA256 hashes. But actual FreeRADIUS not support PBKDF2_SHA256 hashes. Is there way to change hash in FreeIPA? About FreeRADIUS and PBKDF2_SHA256 https://github.com/FreeRADIUS/freeradius-server/issues/2649

2 2

Re: ipa-server-upgrade failed after yum update on CentOS7
by Florence Blanc-Renaud 30 Jun '20

30 Jun '20

On 6/30/20 10:24 AM, Mariusz Stolarczyk via FreeIPA-users wrote: > All, > > I did a routine server updates last night on my IPA server. After the > reboot I first noticed the DNS was not resolving and the ipa.service > failed. The ipa.service failed to start so I ran the following: > > > # ipactl start > IPA version error: data needs to be upgraded (expected version > '4.6.6-11.el7.centos', current version '4.6.5-11.el7.centos.4') > Automatically running upgrade, for details see /var/log/ipaupgrade.log > Be patient, this may take a few minutes. > Automatic upgrade failed: Update complete > Upgrading the configuration of the IPA services > [Verifying that root certificate is published] > [Migrate CRL publish directory] > CRL tree already moved > [Verifying that CA proxy configuration is correct] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fix DS schema file syntax] > Syntax already fixed > [Removing RA cert from DS NSS database] > RA cert already removed > [Enable sidgen and extdom plugins by default] > [Updating HTTPD service IPA configuration] > [Updating HTTPD service IPA WSGI configuration] > Nothing to do for configure_httpd_wsgi_conf > [Updating mod_nss protocol versions] > Protocol versions already updated > [Updating mod_nss cipher suite] > [Updating mod_nss enabling OCSP] > [Fixing trust flags in /etc/httpd/alias] > Trust flags already processed > [Moving HTTPD service keytab to gssproxy] > [Removing self-signed CA] > [Removing Dogtag 9 CA] > [Checking for deprecated KDC configuration files] > [Checking for deprecated backups of Samba configuration files] > [Remove FILE: prefix from 'dedicated keytab file' in Samba configuration] > [Update 'max smbd processes' in Samba configuration to prevent unlimited > SMBLoris attack amplification] > [Add missing CA DNS records] > IPA CA DNS records already processed > [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] > [Updating GSSAPI configuration in DNS] > [Updating pid-file configuration in DNS] > [Checking global forwarding policy in named.conf to avoid conflicts with > automatic empty zones] > Changes to named.conf have been made, restart named > [Upgrading CA schema] > CA schema update complete (no changes) > [Verifying that CA audit signing cert has 2 year validity] > [Update certmonger certificate renewal configuration] > Certmonger certificate renewal configuration already up-to-date > [Enable PKIX certificate path discovery and validation] > PKIX already enabled > [Authorizing RA Agent to modify profiles] > [Authorizing RA Agent to manage lightweight CAs] > [Ensuring Lightweight CAs container exists in Dogtag database] > [Adding default OCSP URI configuration] > [Ensuring CA is using LDAPProfileSubsystem] > [Migrating certificate profiles to LDAP] > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > command ipa-server-upgrade manually. > Unexpected error - see /var/log/ipaupgrade.log for details: > NetworkError: cannot connect to > 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': > [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information > > See the upgrade log for more details and/or run > /usr/sbin/ipa-server-upgrade again > Aborting ipactl > > > The end of the /var/log/ipaupgrade.log file: > > 2020-06-29T22:43:38Z DEBUG stderr= > 2020-06-29T22:43:38Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2020-06-29T22:43:38Z DEBUG Starting external process > 2020-06-29T22:43:38Z DEBUG args=/usr/bin/certutil -d > dbm:/etc/pki/pki-tomcat/alias -L -f /etc/pki/pki-tomcat/alias/pwdfile.txt > 2020-06-29T22:43:38Z DEBUG Process finished, return code=0 > 2020-06-29T22:43:38Z DEBUG stdout= > Certificate Nickname Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Trust > Attributes > > Â SSL,S/MIME,JAR/XPI > > caSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â CTu,Cu,Cu > subsystemCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u > Server-Cert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u > ocspSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u > auditSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,Pu > > 2020-06-29T22:43:38Z DEBUG stderr= > 2020-06-29T22:43:38Z INFO Certmonger certificate renewal configuration > already up-to-date > 2020-06-29T22:43:38Z INFO [Enable PKIX certificate path discovery and > validation] > 2020-06-29T22:43:38Z DEBUG Loading StateFile from > '/var/lib/ipa/sysupgrade/sysupgrade.state' > 2020-06-29T22:43:38Z INFO PKIX already enabled > 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to modify profiles] > 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to manage lightweight CAs] > 2020-06-29T22:43:38Z INFO [Ensuring Lightweight CAs container exists in > Dogtag database] > 2020-06-29T22:43:38Z DEBUG Created connection context.ldap2_140346851657552 > 2020-06-29T22:43:38Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket from SchemaCache > 2020-06-29T22:43:38Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket > conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50c3e8e60> > 2020-06-29T22:43:39Z DEBUG Destroyed connection > context.ldap2_140346851657552 > 2020-06-29T22:43:39Z INFO [Adding default OCSP URI configuration] > 2020-06-29T22:43:39Z INFO [Ensuring CA is using LDAPProfileSubsystem] > 2020-06-29T22:43:39Z INFO [Migrating certificate profiles to LDAP] > 2020-06-29T22:43:39Z DEBUG Created connection context.ldap2_140346825804304 > 2020-06-29T22:43:39Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket from SchemaCache > 2020-06-29T22:43:39Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket > conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50ac19b90> > 2020-06-29T22:43:39Z DEBUG Destroyed connection > context.ldap2_140346825804304 > 2020-06-29T22:43:39Z DEBUG request GET > https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login > 2020-06-29T22:43:39Z DEBUG request body '' > 2020-06-29T22:43:39Z DEBUG httplib request failed: > Traceback (most recent call last): > Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line > 220, in _httplib_request > Â Â conn.request(method, path, body=request_body, headers=headers) > Â File "/usr/lib64/python2.7/httplib.py", line 1056, in request > Â Â self._send_request(method, url, body, headers) > Â File "/usr/lib64/python2.7/httplib.py", line 1090, in _send_request > Â Â self.endheaders(body) > Â File "/usr/lib64/python2.7/httplib.py", line 1052, in endheaders > Â Â self._send_output(message_body) > Â File "/usr/lib64/python2.7/httplib.py", line 890, in _send_output > Â Â self.send(msg) > Â File "/usr/lib64/python2.7/httplib.py", line 852, in send > Â Â self.connect() > Â File "/usr/lib64/python2.7/httplib.py", line 1275, in connect > Â Â server_hostname=sni_hostname) > Â File "/usr/lib64/python2.7/ssl.py", line 348, in wrap_socket > Â Â _context=self) > Â File "/usr/lib64/python2.7/ssl.py", line 609, in __init__ > Â Â self.do_handshake() > Â File "/usr/lib64/python2.7/ssl.py", line 831, in do_handshake > Â Â self._sslobj.do_handshake() > SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed > (_ssl.c:618) > 2020-06-29T22:43:39Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > 2020-06-29T22:43:39Z 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 2166, in upgrade > Â Â upgrade_configuration() > Â File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 2038, in upgrade_configuration > Â Â ca_enable_ldap_profile_subsystem(ca) > Â File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 425, 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 1311, in __enter__ > Â Â method='GET' > Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line > 167, in https_request > Â Â method=method, headers=headers) > Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line > 229, in _httplib_request > Â Â raise NetworkError(uri=uri, error=str(e)) > > 2020-06-29T22:43:39Z DEBUG The ipa-server-upgrade command failed, > exception: NetworkError: cannot connect to > 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': > [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) > 2020-06-29T22:43:39Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > NetworkError: cannot connect to > 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': > [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) > 2020-06-29T22:43:39Z ERROR The ipa-server-upgrade command failed. See > /var/log/ipaupgrade.log for more information > > > What should be my next debug steps? > Hi, I would check whether any certificate expired: $ getcert list Look specifically for the "status: " and "expires: " labels. If some certs have expired, you will need to find the CA renewal master and fix this host first. To find the CA renewal master: $ kinit admin $ ipa config-show | grep "CA renewal" If you need help, please mention: - the output of "ipa server-role-find" - the output of "getcert list" on all the server nodes - are the httpd and ldap server certificates issued by IPA CA or by an external Certificate Authority? HTH, flo > Thanks in advance, > -ms > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >

2 1

Freeipa and systemd-homed
by Markus Larsson 30 Jun '20

30 Jun '20

Hi venerable list I have been contemplating home directories a lot. Generally the homedirectory issues is solved via NFS or CIFS. Neither work well in the "take laptop and work from home" scenario. I have tried a myriad of clustered filesystems none of which worked really well. I have tried local homedirectories that are synced with central storage. Systemd-homed looks kinda interesting since it can be served as encrypted files via CIFS. That means the homedirectories can act pretty much like a local home but really be server side (I have seen the same done with union mounts and files served via NFS, it worked but was a bit wonky). I just wonder if there has been thoughts about how homed could work with freeipa? As far as I can tell homed deals with local users. Does anyone have thoughts about how it could eventually integrate or is it a dead end? Br Markus

1 0

Web Interface Limits on DNS
by Mark Potter 30 Jun '20

30 Jun '20

We have ~22000 DNS entries at present and more will be added. I have adjusted nsslapd-sizelimit to -1. This causes the web interface to return ~6000 and ~8000 entries with the number being different each time. I suspect this is due to a time limit but I cannot figure out which time limit affects this search. I can return all entries with 'ipa dnsrecord-find dugeo.com --sizelimit=30000 --timelimit=120' so I know all the records exist and as far as I can tell all records are resolving without any issues. The web interface results don't tax the server at all and I can increase both memory and available CPU if needed. Can anyone point me in to the time limit so that we can have all of our records show up in the web interface? -- *Mark Potter* Senior Linux Administrator DownUnder GeoSolutions

2 2

API calls to IPA cluster
by Daniel PC 30 Jun '20

30 Jun '20

Hi, I have an IPA culster with 4 servers with DNS integrated. SSSD client nativetely balances the load on 4 servers and that is OK. But what if I need to do curl calls to API end-point. Is there some mechanism to perform discovery and load balance? thank you

3 10

ipa-server-upgrade failed after yum update on CentOS7
by Mariusz Stolarczyk 30 Jun '20

30 Jun '20

All, I did a routine server updates last night on my IPA server. After the reboot I first noticed the DNS was not resolving and the ipa.service failed. The ipa.service failed to start so I ran the following: # ipactl start IPA version error: data needs to be upgraded (expected version '4.6.6-11.el7.centos', current version '4.6.5-11.el7.centos.4') Automatically running upgrade, for details see /var/log/ipaupgrade.log Be patient, this may take a few minutes. Automatic upgrade failed: Update complete Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved [Verifying that CA proxy configuration is correct] [Verifying that KDC configuration is using ipa-kdb backend] [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Enable sidgen and extdom plugins by default] [Updating HTTPD service IPA configuration] [Updating HTTPD service IPA WSGI configuration] Nothing to do for configure_httpd_wsgi_conf [Updating mod_nss protocol versions] Protocol versions already updated [Updating mod_nss cipher suite] [Updating mod_nss enabling OCSP] [Fixing trust flags in /etc/httpd/alias] Trust flags already processed [Moving HTTPD service keytab to gssproxy] [Removing self-signed CA] [Removing Dogtag 9 CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Remove FILE: prefix from 'dedicated keytab file' in Samba configuration] [Update 'max smbd processes' in Samba configuration to prevent unlimited SMBLoris attack amplification] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] [Ensuring minimal number of connections] [Updating GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Checking global forwarding policy in named.conf to avoid conflicts with automatic empty zones] Changes to named.conf have been made, restart named [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration] Certmonger certificate renewal configuration already up-to-date [Enable PKIX certificate path discovery and validation] PKIX already enabled [Authorizing RA Agent to modify profiles] [Authorizing RA Agent to manage lightweight CAs] [Ensuring Lightweight CAs container exists in Dogtag database] [Adding default OCSP URI configuration] [Ensuring CA is using LDAPProfileSubsystem] [Migrating certificate profiles to LDAP] IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: NetworkError: cannot connect to 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade again Aborting ipactl The end of the /var/log/ipaupgrade.log file: 2020-06-29T22:43:38Z DEBUG stderr= 2020-06-29T22:43:38Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2020-06-29T22:43:38Z DEBUG Starting external process 2020-06-29T22:43:38Z DEBUG args=/usr/bin/certutil -d dbm:/etc/pki/pki-tomcat/alias -L -f /etc/pki/pki-tomcat/alias/pwdfile.txt 2020-06-29T22:43:38Z DEBUG Process finished, return code=0 2020-06-29T22:43:38Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu 2020-06-29T22:43:38Z DEBUG stderr= 2020-06-29T22:43:38Z INFO Certmonger certificate renewal configuration already up-to-date 2020-06-29T22:43:38Z INFO [Enable PKIX certificate path discovery and validation] 2020-06-29T22:43:38Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2020-06-29T22:43:38Z INFO PKIX already enabled 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to modify profiles] 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to manage lightweight CAs] 2020-06-29T22:43:38Z INFO [Ensuring Lightweight CAs container exists in Dogtag database] 2020-06-29T22:43:38Z DEBUG Created connection context.ldap2_140346851657552 2020-06-29T22:43:38Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket from SchemaCache 2020-06-29T22:43:38Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50c3e8e60> 2020-06-29T22:43:39Z DEBUG Destroyed connection context.ldap2_140346851657552 2020-06-29T22:43:39Z INFO [Adding default OCSP URI configuration] 2020-06-29T22:43:39Z INFO [Ensuring CA is using LDAPProfileSubsystem] 2020-06-29T22:43:39Z INFO [Migrating certificate profiles to LDAP] 2020-06-29T22:43:39Z DEBUG Created connection context.ldap2_140346825804304 2020-06-29T22:43:39Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket from SchemaCache 2020-06-29T22:43:39Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50ac19b90> 2020-06-29T22:43:39Z DEBUG Destroyed connection context.ldap2_140346825804304 2020-06-29T22:43:39Z DEBUG request GET https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login 2020-06-29T22:43:39Z DEBUG request body '' 2020-06-29T22:43:39Z DEBUG httplib request failed: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 220, in _httplib_request conn.request(method, path, body=request_body, headers=headers) File "/usr/lib64/python2.7/httplib.py", line 1056, in request self._send_request(method, url, body, headers) File "/usr/lib64/python2.7/httplib.py", line 1090, in _send_request self.endheaders(body) File "/usr/lib64/python2.7/httplib.py", line 1052, in endheaders self._send_output(message_body) File "/usr/lib64/python2.7/httplib.py", line 890, in _send_output self.send(msg) File "/usr/lib64/python2.7/httplib.py", line 852, in send self.connect() File "/usr/lib64/python2.7/httplib.py", line 1275, in connect server_hostname=sni_hostname) File "/usr/lib64/python2.7/ssl.py", line 348, in wrap_socket _context=self) File "/usr/lib64/python2.7/ssl.py", line 609, in __init__ self.do_handshake() File "/usr/lib64/python2.7/ssl.py", line 831, in do_handshake self._sslobj.do_handshake() SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) 2020-06-29T22:43:39Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2020-06-29T22:43:39Z 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 2166, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2038, in upgrade_configuration ca_enable_ldap_profile_subsystem(ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 425, 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 1311, in __enter__ method='GET' File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 167, in https_request method=method, headers=headers) File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 229, in _httplib_request raise NetworkError(uri=uri, error=str(e)) 2020-06-29T22:43:39Z DEBUG The ipa-server-upgrade command failed, exception: NetworkError: cannot connect to 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) 2020-06-29T22:43:39Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: NetworkError: cannot connect to 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) 2020-06-29T22:43:39Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information What should be my next debug steps? Thanks in advance, -ms

1 0

Netapp SVM as IPA client
by Ronald Wimmer 26 Jun '20

26 Jun '20

Is there any way to make a NetApp SVM an IPA client in order to provide a kerberized NFSv4-share? Cheers, Ronald

2 3

Re: Last FreeIPA master is failing
by Rob Crittenden 25 Jun '20

25 Jun '20

Ricardo Mendes via FreeIPA-users wrote: > Hello again Rob, > > I really would like to express my appreciation for the feedback you've > been giving and trying to help man really amazing! > > I have detailed some of the issues I'm going through now here: > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahos… > > > But basically, I disabled DNSSEC Master on the first server (last lines > of the output on that link) that went reasonably well apart from the > can't connect to CMS error. So then when I tried to setup the DNSSEC on > the replica, it says there's already a DNSSEC key master. Basically > anything that's done is out of sync. See https://www.freeipa.org/page/Howto/DNSSEC#Migrate_DNSSEC_master_to_another_… > One thing I did actually was to run “ipa-cacert-manage renew > --self-signed” on the CA Master as I was looking to return to a more... > comfortable/default configuration and also I was looking to see if maybe > this would fix the pki-tomcat issue. It did not, but the command ran OK. > but I think the other servers don't know about it. Uhh. Your CA was already self-signed wasn't it? All you did before was replace the HTTP and LDAP certs right? > I also tried to setup another master. > > First installed ipa-client, output here: https://pastebin.com/4y8ipupc > has some errors. What is the server idi3? It reports as an IPA master but it wasn't verified. > Then when installing replica, got the following: > https://pastebin.com/JXVqSmLs > > So it fails with wrong credentials BUT that server (id01) is the server > that is accepting the correct DM password, and so I'm not being able to > create another replica. It isn't the DM password that is bad it's something else. Look at the log file as the output suggests, it may have additional details. > - If I removed the references to CA Master on the replica (id01) and for > the dnssec key master manually, deleting references, could I then re-add > that role to other replicas? You have to have a CA to clone from. For DNSSEC yes, see the link above. > - Is there any files I can copy from the replica that is working (and > accepting the correct DM password) to the first master, to restore some > functionality? Or even someway fix the pki-tomcat connection to LDAP? It is likely not something that straightforward. > Regarding the first master with the failing CMS, I've also been through > Florence's blog, particularly this article: > https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomca… > > > - the CS.cfg file seems normal with expected values > - the "subsystemCert cert-pki-ca" is present > - the private key can be read using the password > - certmap.conf looks all correct > - running the command "ldapsearch -LLL -D 'cn=directory manager' -W -b > uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso" > fails as DM password is rejected. But I am 100% on the DM password and > the DM password works on the replica. Then perhaps it really is different. The DM password isn't replicated. You might try copying the hash from the working to the non-working master. See https://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassw… And then follow https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > So I can't go past this on troubleshooting pki-tomcat. > > I've been with this issues for so long that I'm starting to thing if I > just should start a clean new setup and manually migrate things somehow > manually? Everything just looks out of sync, completely broken and I am > getting less hope each time. Been through the docs but the solutions > proposed are not working, I've been trying a couple. There's always some > errors, or it seems that something works, but then you realize it only > worked locally, but was not propagated. (like the dnssec key master). > Don't know where to turn next. It depends on how many entries you have. Migration in IPA is more meant from a pure-LDAP solution to IPA. There is currently no easy IPA to IPA migration, retaining everything as-it-was. rob > > Kind regards, > Ricardo > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >

2 1

RuntimeError: Failed to start replication (ipa-replica-install)
by Christian Mertes 25 Jun '20

25 Jun '20

Dear all, we tried to setup our first replica for our current ipa installation but failed with RuntimeError: Failed to start replication Our main instance is running on Scientific Linux 7 and is already 4 years old but kept always up-to-date and served us with no problems. We followed the steps lined out in the documentation: https://www.freeipa.org/page/V4/Replica_Setup But we always fail at the point where the replication starts. ~# ipa-replica-install Run connection check to masterConnection check OKConfiguring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpdDone configuring NTP daemon (ntpd).Configuring directory server (dirsrv). Estimated time: 30 seconds [1/42]: creating directory server instance [2/42]: enabling ldapi [3/42]: configure autobind for root [4/42]: stopping directory server [5/42]: updating configuration in dse.ldif [6/42]: starting directory server [7/42]: adding default schema [8/42]: enabling memberof plugin [9/42]: enabling winsync plugin [10/42]: configure password logging [11/42]: configuring replication version plugin [12/42]: enabling IPA enrollment plugin [13/42]: configuring uniqueness plugin [14/42]: configuring uuid plugin [15/42]: configuring modrdn plugin [16/42]: configuring DNS plugin [17/42]: enabling entryUSN plugin [18/42]: configuring lockout plugin [19/42]: configuring topology plugin [20/42]: creating indices [21/42]: enabling referential integrity plugin [22/42]: configuring certmap.conf [23/42]: configure new location for managed entries [24/42]: configure dirsrv ccache [25/42]: enabling SASL mapping fallback [26/42]: restarting directory server [27/42]: creating DS keytab [28/42]: ignore time skew for initial replication [29/42]: setting up initial replicationStarting replication, please wait until this has completed.Update in progress, 15 seconds elapsed[ldap://freeipa.xxx.xxx.xxx:389] reports: Update failed! Status: [Error (-2) - LDAP error: Local error] [error] RuntimeError: Failed to start replicationYour system may be partly configured.Run /usr/sbin/ipa-server-install --uninstall to clean up. ipapython.admintool: ERROR Failed to start replicationipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information We tried to debug it a bit but did not come far. Somehow our master fails to acquire the replica for a total update (error log from dirsrv on main): [16/Jun/2020:01:26:00.049005795 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 1 seconds.[16/Jun/2020:01:26:01.080674785 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 2 seconds.[16/Jun/2020:01:26:03.115527897 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 3 seconds.[16/Jun/2020:01:26:06.137927640 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 4 seconds.[16/Jun/2020:01:26:10.167358832 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 5 seconds. I guess the error log on the replica is intended, since we just started to replicate it [16/Jun/2020:01:26:00.674747749 +0200] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTofreeipa.i12g.informatik.tu-muenchen.de" (freeipa:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. As we do not know if this is a bug or just a configuration issue on our side, we would appreciate any help or hints on this. The times are synchronized btw. To make sure we, did the the right things we tried successfully everything with a fresh installation within a VM network using CentOS 7 images. For more details I attached the install log and the error log from our dirsrv. If you need further logs please let me know. Some additional information from our system (our main instance): # lsb_release -aLSB Version: :core-4.1-amd64:core-4.1- noarchDistributor ID: ScientificDescription: Scientific Linux release 7.8 (Nitrogen)Release: 7.8Codename: Nitrogen# ipa --versionVERSION: 4.8.7, API_VERSION: 2.239# yum list installed "ipa- server"Loaded plugins: fastestmirror, langpacksLoading mirror speeds from cached hostfile * epel * sl * sl-fastbugs * sl-securityInstalled Packagesipa-server.x86_64 4.6.6-11.sl7 @sl And from our replica system: # lsb_release -aLSB Version: :core-4.1-amd64:core-4.1- noarchDistributor ID: CentOSDescription: CentOS Linux release 7.8.2003 (Core)Release: 7.8.2003Codename: Core# ipa -- versionVERSION: 4.6.6, API_VERSION: 2.231# yum list installed ipa- serverLoaded plugins: fastestmirrorLoading mirror speeds from cached hostfile * base: * elrepo: * epel: * extras: * updates:Installed Packagesipa-server.x86_64 4.6.6-11.el7.centos @base I'm just puzzled a bit by the difference in version number on the master. Could that be an issue and if so how to solve this? Best, Christian -- Christian Mertes | PhD Student / Lab Administrator Gagneur Lab - Computational Genomics I12 - Department of Informa ti Technical University of Munich Boltzmannstr. 3, 85748 Garching, Germany mertes(a)in.tum.de | https://in.tum.de/gagneurlab

2 2

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2020