Actually I executed these commands before you replied on the replica server: [root@ipa-replica ~]# ipa-pkinit-manage status PKINIT is disabled The ipa-pkinit-manage command was successful [root@ipa-replica ~]# ipa-pkinit-manage enable Configuring Kerberos KDC (krb5kdc) [1/1]: installing X509 Certificate for PKINIT Done configuring Kerberos KDC (krb5kdc). The ipa-pkinit-manage command was successful [root@ipa-replica ~]# ipa-pkinit-manage status PKINIT is enabled The ipa-pkinit-manage command was successful

This means I didn't delete any kdc.key / kdc.crt file.

Now the content in directory looks this: [root@ipa-replica ~]# ls -l /var/kerberos/krb5kdc/ insgesamt 20 -rw-r--r--. 1 root root 1322 2. Dez 17:42 cacert.pem -rw-------. 1 root root 22 9. Okt 22:59 kadm5.acl -rw-------. 1 root root 666 2. Dez 17:21 kdc.conf -rw-r--r--. 1 root root 1480 2. Dez 17:26 kdc.crt -rw-------. 1 root root 1704 2. Dez 17:26 kdc.key

The files are different compared to ipa-master.

Should I repeat creating the files on replica server?

THX

Hi, this is the output that looks good to me... but I'm not the expert.

[root@ipa-replica ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt Number of certificates and requests being tracked: 4. Request ID '20181202164246': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' CA: IPA issuer: CN=ipa-replica.mydomain.de,O=MYDOMAIN.DE subject: CN=ipa-replica.mydomain.de,O=MYDOMAIN.DE expires: 2019-12-02 17:26:59 CET principal name: krbtgt/MYDOMAIN.DE@MYDOMAIN.DE certificate template/profile: KDCs_PKINIT_Certs pre-save command: post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert track: yes auto-renew: yes

THX for your advise.

On ma, 03 joulu 2018, 74cmonty via FreeIPA-users wrote:

OK... following your advise and delete the "old" files. Then run ipa-pkinit-manage enable and get this output: [root@ipa-replica ~]# rm /var/kerberos/krb5kdc/kdc.crt rm: reguläre Datei '/var/kerberos/krb5kdc/kdc.crt' entfernen? y [root@ipa-replica ~]# rm /var/kerberos/krb5kdc/kdc.key rm: reguläre Datei '/var/kerberos/krb5kdc/kdc.key' entfernen? y [root@ipa-replica ~]# ipa-pkinit-manage enable Configuring Kerberos KDC (krb5kdc) [1/1]: installing X509 Certificate for PKINIT PKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Error 7 connecting to https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient: Couldn't connect to server.)

As this line says, certmonger was unable to to talk to https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient

On ma, 03 joulu 2018, 74cmonty via FreeIPA-users wrote:

This is true, the connect error is clear.

However, I don't understand why there's a connection error to the replica-server? Please note that command ipa-pkinit-manage enable is executed on the replica-server, means the connection fails to itself. And there's no instruction to open port 8443 on the server (for whatever this port is used for).

I guess this is reincarnation of https://pagure.io/freeipa/issue/6016 (fixed in 4.3) as https://pagure.io/freeipa/issue/6878 which is fixed in 4.6.0 and above. Installers talk to local CA directly on 8443 but everything else should not. (See last set of comments in latter the ticket).

74cmonty via FreeIPA-users wrote:

I have installed freeipa-server-common=4.7.0, so I don't understand the relation to an issue that should be fixed with 4.6.0.

You never did say before which version you were using...

I have no restarted command ipa-pkinit-manage enable after opening port 8443 on both, master and replica server.

In my opinion the root cause is different. According to error message and log the connection to https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient fails, however there's no service listening on port 8443 on the replica server (192.168.100.201). On the master server (192.168.100.200) port 8443 is accessible:

So I assume there is no CA installed on this replica?

Can we see the current getcert output for the KDC cert?

rob

BTW your comments are coming in with zero context which makes more difficult to see what has gone on before.

74cmonty via FreeIPA-users wrote:

I was instructed to delete the existing cert before executing ipa-pkinit-manage enable.

And I have provided the output of getcert in an earlier response. I was told that this cert is incomplete/incorrect.

Again, no context :-(

Yes, I asked for the CURRENT tracking for it.

rob

On 12/6/18 8:59 AM, 74cmonty via FreeIPA-users wrote:

Well, then I will repeat the context...

After completing FreeIPA master (vm200; 192.168.100.200) installation I started setup of replica (vm201; 192.168.100.201). This means I first enrolled the replica server as a client successfully and then executed this command: ipa-replica-install

The installation log reports this error: Full PKINIT configuration did not succeed The setup will only install bits essential to the server functionality You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'

Is this an error or normal behavior of replica installation?

Hi,

1. Error message during ipa-replica-install it is an error that was tracked in pagure ticket 7655: PKINIT configuration fails while promoting a replica using IPA 4.7.0 [1]

In short, the replica is trying to contact itself in order to get a new KDC cert, while it should contact the master instead. The fix is delivered in IPA 4.7.1 and 4.7.2. Without the fix, a KDC cert is installed but it is self-signed (issuer shows the replica name instead of IPA CA).

2. running ipa-pkinit-manage enable afterwards: the command reports success but does not properly replace the self-signed KDC cert with a IPA-CA-signed KDC cert. This is tracked in pagure ticket 7200 ipa-pkinit-manage reports a switch from local pkinit to full pkinit configuration was successful although it was not. [2]

3. deletion of the KDC cert + re-run ipa-pkinit-manage: Here you are seeing an error CA_UNREACHABLE, certificate issuance failed. This is the part that needs to be investigated. In this step, the command ipa-pkinit-manage enable contacts certmonger in order to get a new cert. The error message shows connection to the replica itself, but certmonger should have contacted the master as the replica does not have any CA instance. I think this is a bug, as we can see in ipaserver/install/krbinstance.py:

if use_dogtag_submit: ca_args = [ paths.CERTMONGER_DOGTAG_SUBMIT, '--ee-url', 'https://%s:8443/ca/ee/ca' % self.fqdn, '--certfile', paths.RA_AGENT_PEM, '--keyfile', paths.RA_AGENT_KEY, '--cafile', paths.IPA_CA_CRT, '--agent-submit'

The code is always connecting locally (self.fqdn) but it should check on which host the CA is deployed. Could you please open an issue (https://pagure.io/freeipa/new_issue)? Thanks, flo

[1] https://pagure.io/freeipa/issue/7655 [2] https://pagure.io/freeipa/issue/7200

This is the full installation output in the console: Configuring certificate server (pki-tomcatd) [1/2]: configure certmonger for renewals [2/2]: Importing RA key Done configuring certificate server (pki-tomcatd). Configuring Kerberos KDC (krb5kdc) [1/1]: installing X509 Certificate for PKINIT Full PKINIT configuration did not succeed The setup will only install bits essential to the server functionality You can enable PKINIT after the setup completed using 'ipa-pkinit-manage' Done configuring Kerberos KDC (krb5kdc). Applying LDAP updates Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/10]: stopping directory server [2/10]: saving configuration [3/10]: disabling listeners [4/10]: enabling DS global lock [5/10]: disabling Schema Compat [6/10]: starting directory server [7/10]: upgrading server [8/10]: stopping directory server [9/10]: restoring configuration [10/10]: starting directory server Done. Finalize replication settings Restarting the KDC

And this is the output of getcert list -f /var/kerberos/krb5kdc/kdc.crt: [root@ipa-replica ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt Number of certificates and requests being tracked: 4. Request ID '20181206075804': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' CA: SelfSign issuer: CN=ipa-replica.biszumbitterenen.de,O=BISZUMBITTERENEN.DE subject: CN=ipa-replica.biszumbitterenen.de,O=BISZUMBITTERENEN.DE expires: 2019-12-06 08:58:04 CET principal name: krbtgt/BISZUMBITTERENEN.DE@BISZUMBITTERENEN.DE certificate template/profile: KDCs_PKINIT_Certs pre-save command: post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert track: yes auto-renew: yes _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...

On 12/6/18 1:26 PM, 74cmonty via FreeIPA-users wrote:

Hi Florence,

thank you for this detailed analysis. I fully support your conclusion. Before you replied to this ticket I have already opened a bug report: https://pagure.io/freeipa/issue/7795

Question: Is there any workaround to temporarily fix this issue and complete the setup of replica server?

The easiest is to also install a CA instance on the replica: # ipa-ca-install Moreover, it is better to have multiple hosts with a CA instance :)

Then repeat the steps removing the .crt and .key file, and ipa-pkinit-manage enable.

flo

THX _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...

On 12/7/18 6:33 PM, 74cmonty via FreeIPA-users wrote:

Hello Flo,

I've decided to follow your advise. This means I will install another CA instance on the replica server.

However I would prefer to upgrade FreeIPA to version 4.7.2 before. Unfortunately I failed on this task.

I've executed ipa-server-upgrade and this process finished successfully after a few minutes: The IPA services were upgraded The ipa-server-upgrade command was successful

Checking the installed packages revealed: no updated packages [root@ipa-replica ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server freeipa-server-4.7.0-3.fc29.x86_64 freeipa-client-4.7.0-3.fc29.x86_64 Das Paket ipa-server ist nicht installiert Das Paket ipa-client ist nicht installiert 389-ds-base-1.4.0.16-1.fc29.x86_64 pki-ca-10.6.6-2.fc29.noarch krb5-server-1.16.1-21.fc29.x86_64

Then I tried command dnf update freeipa-server w/o success: nothing to do

What am I doing wrong here?

Please see my answer in the other thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...

HTH, flo

---

FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...

On 12/11/18 11:23 AM, 74cmonty via FreeIPA-users wrote:

Hello Flo, I successfully installed FreeIPA 4.7.2 packages on replica server:

[root@ipa-replica ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 3                                                                                      89-ds-base pki-ca krb5-server
freeipa-server-4.7.2-1.fc29.x86_64
freeipa-client-4.7.2-1.fc29.x86_64
Das Paket ipa-server ist nicht installiert
Das Paket ipa-client ist nicht installiert
389-ds-base-1.4.0.16-1.fc29.x86_64
pki-ca-10.6.8-3.fc29.noarch

However, the upgrade is failing. When I execute this command `ipa-server-upgrade` manually I get this error:

ipaserver.install.service: DEBUG:   [5/9]: starting directory server
   [5/9]: starting directory server
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=['/bin/systemctl', 'start', 'dirsrv@BISZUMBITTERENE                                                                                      N-DE.service']
ipapython.ipautil: DEBUG: Process finished, return code=1
ipapython.ipautil: DEBUG: stdout=
ipapython.ipautil: DEBUG: stderr=Job for dirsrv@BISZUMBITTERENEN-DE.service failed                                                                                       because the control process exited with error code.
See "systemctl status dirsrv@BISZUMBITTERENEN-DE.service" and "journalctl -xe" for                                                                                       details.

So I checked log `/var/log/dirsrv/slapd-BISZUMBITTERENEN-DE/errors` and found this:

[root@ipa-replica ~]# tail -n 40 /var/log/dirsrv/slapd-BISZUMBITTERENEN-DE/errors
[11/Dec/2018:10:45:10.505923459 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=computers,cn=compat,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.515595444 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=ng,cn=compat,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.524433521 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target ou=sudoers,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.534653076 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=users,cn=compat,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.543444060 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.550404494 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.559231814 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.574312715 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.581500986 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.588207817 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.598901345 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.608874140 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.624449543 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.635198157 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.644514201 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.652438328 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=ad,cn=etc,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.666047779 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.676464447 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.758108000 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist
[11/Dec/2018:10:45:10.768519636 +0100] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=biszumbitterenen,dc=de--no CoS Templates found, which should be added before the CoS Definition.
[11/Dec/2018:10:45:10.807844822 +0100] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa-replica.biszumbitterenen.de@BISZUMBITTERENEN.DE] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm)
[11/Dec/2018:10:45:10.822417907 +0100] - INFO - slapd_daemon - slapd started.  Listening on /var/run/slapd-BISZUMBITTERENEN-DE.socket for LDAPI requests
[11/Dec/2018:10:45:10.991091930 +0100] - INFO - op_thread_cleanup - slapd shutting down - signaling operation threads - op stack size 3 max work q size 2 max work q stack size 2
[11/Dec/2018:10:45:11.001531238 +0100] - INFO - slapd_daemon - slapd shutting down - waiting for 2 threads to terminate
[11/Dec/2018:10:45:11.014214280 +0100] - INFO - slapd_daemon - slapd shutting down - closing down internal subsystems and plugins
[11/Dec/2018:10:47:10.908408935 +0100] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToipa-master.biszumbitterenen.de" (ipa-master:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()
[11/Dec/2018:10:47:11.147205700 +0100] - INFO - dblayer_pre_close - Waiting for 4 database threads to stop
[11/Dec/2018:10:47:13.151397617 +0100] - INFO - dblayer_pre_close - All database threads now stopped
[11/Dec/2018:10:47:13.174133191 +0100] - INFO - ldbm_back_instance_set_destructor - Set of instances destroyed
[11/Dec/2018:10:47:13.182242796 +0100] - INFO - connection_post_shutdown_cleanup - slapd shutting down - freed 2 work q stack objects - freed 3 op stack objects
[11/Dec/2018:10:47:13.193043173 +0100] - INFO - main - slapd stopped.
[11/Dec/2018:10:49:34.420307507 +0100] - ERR - init_schema_dse_ext - Could not add attribute type "objectClass" to the schema: attribute type objectClass: Unknown attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:49:34.436344560 +0100] - ERR - dse_read_one_file - The entry cn=schema in file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid syntax) - attribute type aci: Unknown attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:49:34.443437573 +0100] - ERR - setup_internal_backends - Please edit the file to correct the reported problems and then restart the server.
[11/Dec/2018:10:50:08.568553528 +0100] - ERR - init_schema_dse_ext - Could not add attribute type "objectClass" to the schema: attribute type objectClass: Unknown attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:50:08.580692294 +0100] - ERR - dse_read_one_file - The entry cn=schema in file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid syntax) - attribute type aci: Unknown attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:50:08.588399834 +0100] - ERR - setup_internal_backends - Please edit the file to correct the reported problems and then restart the server.
[11/Dec/2018:10:52:26.598725479 +0100] - ERR - init_schema_dse_ext - Could not add attribute type "objectClass" to the schema: attribute type objectClass: Unknown attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:52:26.610499920 +0100] - ERR - dse_read_one_file - The entry cn=schema in file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid syntax) - attribute type aci: Unknown attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:52:26.618930090 +0100] - ERR - setup_internal_backends - Please edit the file to correct the reported problems and then restart the server.

And this is the relevant content of file `/usr/share/dirsrv/schema/00core.ldif`:

attributeTypes: ( 2.16.840.1.113730.3.1.55 NAME 'aci'
   DESC 'Netscape defined access control information attribute type'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   USAGE directoryOperation
   X-ORIGIN 'Netscape Directory Server' )

Comparing this content with `/usr/share/dirsrv/schema/00core.ldif` on master server there's no difference.

I thought to restart deployment of replica server from scratch, but I cannot delete the host ipa-replica in WebUI.Hi,

what is the error you are seeing?

If the replica is not a single point of failure for any service (CA, DNS, replication to other master...) you can do the following: (on replica) ipa-server-install --uninstall -U (on master) ipa-replica-manage del <replica> --force --cleanup

then retry the replica installation. flo

Any advise? _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...

On 12/11/18 12:59 PM, 74cmonty via FreeIPA-users wrote:

Hi Flo,

thanks for your reply.

I decided to start replica setup from scratch. This means I executed this command on master: ipa-replica-manage del ipa-replica.biszumbitterenen.de Then I restored the replica server to a previous state, installed freeipa-packages 4.7.2 (and its dependencies). Then I run this command on replica: ipa-server-install --uninstall

After this I was able to run this command ipa-client-install --mkhomedir successfully and the replica server is listed in WebUI.

Now I consider to run this command on replica: ipa-replica-install --setup-ca --setup-dns This would give me no single-point-of-failure for DNS and CA. However the installed is asking me this: ipa-replica-install: error: You must specify at least one of --forwarder, --auto-forwarders, or --no-forwarders options

I had setup master with this command ipa-server-install --setup-dns --allow-zone-overlap because I'm still using the DNS of my domain provider. To my (best) knowledge I have configured DNS forwarder on master.

Question: Is it correct to configure a DNS forwarder on replica, too? If yes, how can I verify what have been entered on master?

Yes, you can configure a DNS forwarder on the replica, too. In order to find the settings on the master, you can use # ipa dnsserver-show $master It will print the forwarder.

If you want to specify the same one on the replica, use --forwarder=<forwarder>. You can also let the installer find which forwarder to use with --auto-forwarder (it will read the content of /etc/resolv.conf and propose this DNS server as forwarder).

HTH, flo

THX _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...

In my opinion this issue is related to this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1493531

Based on this I would consider to open another bug report.