User based access control to services?
by Dominik Vogt
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
3 years, 8 months
Re: ipa-server-upgrade failed after yum update on CentOS7
by Florence Blanc-Renaud
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.fedoraho...
>
3 years, 9 months
Freeipa and systemd-homed
by Markus Larsson
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
3 years, 9 months
Web Interface Limits on DNS
by Mark Potter
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
3 years, 9 months
API calls to IPA cluster
by Daniel PC
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 years, 9 months
ipa-server-upgrade failed after yum update on CentOS7
by Mariusz Stolarczyk
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
3 years, 9 months
Netapp SVM as IPA client
by Ronald Wimmer
Is there any way to make a NetApp SVM an IPA client in order to provide
a kerberized NFSv4-share?
Cheers,
Ronald
3 years, 9 months
Re: Last FreeIPA master is failing
by Rob Crittenden
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.fedorah...
>
>
> 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_anothe...
> 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-tom...
>
>
> - 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-resetdirmgrpas...
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.fedoraho...
>
3 years, 9 months
RuntimeError: Failed to start replication (ipa-replica-install)
by Christian Mertes
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
3 years, 9 months