Re: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process
Hi, The Pki service is running and I cannot find any issues with it. I can run a curl request to the master hostname on port 8443 and communication works fine. Any other idea why this replica install code would fail and log CA_UNREACHABLE? Regards, David 2016-11-29 22:16 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com>: > On 11/29/2016 03:19 PM, David Dejaeghere wrote: > >> Can you give me a couple of test commands? >> I am not familiar with Dogtag. >> >> Hi, > > To reproduce the issue: > 1. install IPA server > 2. On the replica, run ipa-client-install > 3. On the server, stop dogtag with > $ systemctl stop pki-tomcatd@pki-tomcat.service > 4. On the replica, run ipa-replica-install > > When you want to restart dogtag, you can run > $ systemctl start pki-tomcatd@pki-tomcat.service > > If you want to check if dogtag is running: > $ systemctl status pki-tomcatd@pki-tomcat.service > > You may find more information on Dogtag here: > http://pki.fedoraproject.org/wiki/PKI_Main_Page > http://pki.fedoraproject.org/wiki/IPA > http://pki.fedoraproject.org/wiki/Debugging_the_state_of_dog > tag_in_an_ipa_install > > Flo > > Groeten, >> >> David >> >> 2016-11-29 14:57 GMT+01:00 David Kupka <dku...@redhat.com >> <mailto:dku...@redhat.com>>: >> >> On 29/11/16 13:55, David Dejaeghere wrote: >> >> Correct. Same symptoms. >> >> 2016-11-29T10:29:42Z DEBUG certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> >> Fedora 24 Server >> >> [root@ns02 ~]# dnf history userinstalled >> Packages installed by user >> freeipa-client-4.3.2-2.fc24.x86_64 >> freeipa-server-4.3.2-2.fc24.x86_64 >> grub2-1:2.02-0.34.fc24.x86_64 >> kernel-4.5.5-300.fc24.x86_64 >> kernel-4.8.8-200.fc24.x86_64 >> lvm2-2.02.150-2.fc24.x86_64 >> xfsprogs-4.5.0-2.fc24.x86_64 >> >> >> Ok. I've reproduced it by simply stopping dogtag on FreeIPA server >> while installing the replica. I see the exactly same errors as >> you've reported and are described in the ticket, now. >> >> Is dogtag running on your master? Is in responding (e.g. issuing >> certificates for users)? Is it accessible from the replica? >> >> >> >> 2016-11-29 13:41 GMT+01:00 Petr Vobornik <pvobo...@redhat.com >> <mailto:pvobo...@redhat.com>>: >> >> >> On 11/29/2016 12:43 PM, David Kupka wrote: >> >> On 29/11/16 12:15, David Dejaeghere wrote: >> >> Seems like it is but it does not show a server cert >> for dirsrv >> >> [root@ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ >> total 468 >> -rw---. 1 dirsrv root >> unconfined_u:object_r:dirsrv_config_t:s0 >> 65536 >> Nov 29 11:29 cert8.db >> -rw-rw. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 65536 >> Nov 29 11:29 cert8.db.orig >> -r--r-. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 1623 >> Nov 29 11:29 certmap.conf >> -rw---. 1 dirsrv dirsrv >> system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif >> -rw---. 2 dirsrv dirsrv >> system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif.bak >> -rw---. 2 dirsrv dirsrv >> system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif.startOK >> -r--r-. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 36228 >> Nov 29 11:28 dse_original.ldif >> -rw---. 1 dirsrv root >> unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 key3.db >> -rw-rw. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >
Re: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process
Can you give me a couple of test commands? I am not familiar with Dogtag. Groeten, David 2016-11-29 14:57 GMT+01:00 David Kupka <dku...@redhat.com>: > On 29/11/16 13:55, David Dejaeghere wrote: > >> Correct. Same symptoms. >> >> 2016-11-29T10:29:42Z DEBUG certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> >> Fedora 24 Server >> >> [root@ns02 ~]# dnf history userinstalled >> Packages installed by user >> freeipa-client-4.3.2-2.fc24.x86_64 >> freeipa-server-4.3.2-2.fc24.x86_64 >> grub2-1:2.02-0.34.fc24.x86_64 >> kernel-4.5.5-300.fc24.x86_64 >> kernel-4.8.8-200.fc24.x86_64 >> lvm2-2.02.150-2.fc24.x86_64 >> xfsprogs-4.5.0-2.fc24.x86_64 >> > > Ok. I've reproduced it by simply stopping dogtag on FreeIPA server while > installing the replica. I see the exactly same errors as you've reported > and are described in the ticket, now. > > Is dogtag running on your master? Is in responding (e.g. issuing > certificates for users)? Is it accessible from the replica? > > > >> 2016-11-29 13:41 GMT+01:00 Petr Vobornik <pvobo...@redhat.com>: >> >> On 11/29/2016 12:43 PM, David Kupka wrote: >>> >>>> On 29/11/16 12:15, David Dejaeghere wrote: >>>> >>>>> Seems like it is but it does not show a server cert for dirsrv >>>>> >>>>> [root@ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ >>>>> total 468 >>>>> -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 65536 >>>>> Nov 29 11:29 cert8.db >>>>> -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 65536 >>>>> Nov 29 11:29 cert8.db.orig >>>>> -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 1623 >>>>> Nov 29 11:29 certmap.conf >>>>> -rw---. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>>> 89977 >>>>> Nov 29 11:29 dse.ldif >>>>> -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>>> 89977 >>>>> Nov 29 11:29 dse.ldif.bak >>>>> -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>>> 89977 >>>>> Nov 29 11:29 dse.ldif.startOK >>>>> -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 36228 >>>>> Nov 29 11:28 dse_original.ldif >>>>> -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 key3.db >>>>> -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 key3.db.orig >>>>> -r. 1 dirsrv dirsrv >>>>> unconfined_u:object_r:dirsrv_config_t:s066 >>>>> Nov 29 11:29 pin.txt >>>>> -rw---. 1 dirsrv dirsrv >>>>> unconfined_u:object_r:dirsrv_config_t:s040 >>>>> Nov 29 11:29 pwdfile.txt >>>>> drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 4096 >>>>> Nov 29 11:29 schema >>>>> -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 secmod.db >>>>> -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 secmod.db.orig >>>>> -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 15142 >>>>> Nov 29 11:28 slapd-collations.conf >>>>> >>>>> [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >>>>> >>>>> Certificate Nickname Trust >>>>> Attributes >>>>> >>>>> SSL,S/MIME,JAR/XPI >>>>> >>>>> CN=something-PAPRIKA-CA,DC=something,DC=local >>>>> CT,C,C >>>>> SOMETHING.BE IPA CA CT,C,C >>>>> [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >>>>> >>>>> Certificate Nickname Trust >>>>> Attributes >>>>> >>>>> SSL,S/MIME,JAR/XPI >>>>> >>>>> CN=something-PAPRIKA-CA,DC=something,DC=local >>>>> CT,C,C >>>>> SOMETHING.BE IPA CA
Re: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process
Correct. Same symptoms. 2016-11-29T10:29:42Z DEBUG certmonger request is in state dbus.String(u'CA_UNREACHABLE', variant_level=1) Fedora 24 Server [root@ns02 ~]# dnf history userinstalled Packages installed by user freeipa-client-4.3.2-2.fc24.x86_64 freeipa-server-4.3.2-2.fc24.x86_64 grub2-1:2.02-0.34.fc24.x86_64 kernel-4.5.5-300.fc24.x86_64 kernel-4.8.8-200.fc24.x86_64 lvm2-2.02.150-2.fc24.x86_64 xfsprogs-4.5.0-2.fc24.x86_64 2016-11-29 13:41 GMT+01:00 Petr Vobornik <pvobo...@redhat.com>: > On 11/29/2016 12:43 PM, David Kupka wrote: > > On 29/11/16 12:15, David Dejaeghere wrote: > >> Seems like it is but it does not show a server cert for dirsrv > >> > >> [root@ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ > >> total 468 > >> -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 > >> 65536 > >> Nov 29 11:29 cert8.db > >> -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 65536 > >> Nov 29 11:29 cert8.db.orig > >> -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 1623 > >> Nov 29 11:29 certmap.conf > >> -rw---. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 > >> 89977 > >> Nov 29 11:29 dse.ldif > >> -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 > >> 89977 > >> Nov 29 11:29 dse.ldif.bak > >> -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 > >> 89977 > >> Nov 29 11:29 dse.ldif.startOK > >> -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 36228 > >> Nov 29 11:28 dse_original.ldif > >> -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 key3.db > >> -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 key3.db.orig > >> -r. 1 dirsrv dirsrv > >> unconfined_u:object_r:dirsrv_config_t:s066 > >> Nov 29 11:29 pin.txt > >> -rw---. 1 dirsrv dirsrv > >> unconfined_u:object_r:dirsrv_config_t:s040 > >> Nov 29 11:29 pwdfile.txt > >> drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 4096 > >> Nov 29 11:29 schema > >> -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 secmod.db > >> -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 secmod.db.orig > >> -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 15142 > >> Nov 29 11:28 slapd-collations.conf > >> > >> [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L > >> > >> Certificate Nickname Trust > >> Attributes > >> > >> SSL,S/MIME,JAR/XPI > >> > >> CN=something-PAPRIKA-CA,DC=something,DC=local > >> CT,C,C > >> SOMETHING.BE IPA CA CT,C,C > >> [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L > >> > >> Certificate Nickname Trust > >> Attributes > >> > >> SSL,S/MIME,JAR/XPI > >> > >> CN=something-PAPRIKA-CA,DC=something,DC=local > >> CT,C,C > >> SOMETHING.BE IPA CA CT,C,C > >> > >> [root@ns02 ~]# ausearch -m avc -i > >> > >> > >> > > > > Exactly, the NSSDB should be accessible to dirsrv and is missing the > > Server-Cert but I don't understand why there's "bad database" error in > > the errors log. I'll try to reproduce it. What version of FreeIPA are > > you using? On what system? > > Right. > > Seems bit similar to https://fedorahosted.org/freeipa/ticket/6514 would > be good to check if it has the same symptoms, mainly > certmonger request is in state dbus.String(u'CA_UNREACHABLE', > variant_level=1) > > in replica install log. > > > > > >> > >> 2016-11-29 12:09 GMT+01:00 David Kupka <dku...@redhat.com>: > >> > >>> On 29/11/16 11:51, David Dejaeghere wrote: > >>> > >>>> Hi, > >>>> > >>>> I have a setup where i want to add a replica. The first master > >>>> setup has > >>>> an externally signed cert for dirsrv and httpd. The replica is > >>>> prepapred > >>>> succesfully with ipa-cli
Re: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process
Seems like it is but it does not show a server cert for dirsrv [root@ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ total 468 -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 65536 Nov 29 11:29 cert8.db -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 65536 Nov 29 11:29 cert8.db.orig -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 1623 Nov 29 11:29 certmap.conf -rw---. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif.bak -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif.startOK -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 36228 Nov 29 11:28 dse_original.ldif -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 key3.db -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 key3.db.orig -r. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s066 Nov 29 11:29 pin.txt -rw---. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s040 Nov 29 11:29 pwdfile.txt drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 4096 Nov 29 11:29 schema -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 secmod.db -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 secmod.db.orig -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 15142 Nov 29 11:28 slapd-collations.conf [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=something-PAPRIKA-CA,DC=something,DC=localCT,C,C SOMETHING.BE IPA CA CT,C,C [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=something-PAPRIKA-CA,DC=something,DC=localCT,C,C SOMETHING.BE IPA CA CT,C,C [root@ns02 ~]# ausearch -m avc -i 2016-11-29 12:09 GMT+01:00 David Kupka <dku...@redhat.com>: > On 29/11/16 11:51, David Dejaeghere wrote: > >> Hi, >> >> I have a setup where i want to add a replica. The first master setup has >> an externally signed cert for dirsrv and httpd. The replica is prepapred >> succesfully with ipa-client-install but the replica install then keeps >> failing. It seems that during install dirserv is not configured correctly >> with a valid server certificate. Output from the dirsrv error added to >> this >> email as well. >> >> [root@ns02 ~]# ipa-replica-install --setup-ca >> WARNING: conflicting time synchronization service 'chronyd' will >> be disabled in favor of ntpd >> >> Run connection check to master >> Connection check OK >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> [2/4]: writing configuration >> [3/4]: configuring ntpd to start on boot >> [4/4]: starting ntpd >> Done configuring NTP daemon (ntpd). >> Configuring directory server (dirsrv). Estimated time: 1 minute >> [1/43]: creating directory server user >> [2/43]: creating directory server instance >> [3/43]: restarting directory server >> [4/43]: adding default schema >> [5/43]: enabling memberof plugin >> [6/43]: enabling winsync plugin >> [7/43]: configuring replication version plugin >> [8/43]: enabling IPA enrollment plugin >> [9/43]: enabling ldapi >> [10/43]: configuring uniqueness plugin >> [11/43]: configuring uuid plugin >> [12/43]: configuring modrdn plugin >> [13/43]: configuring DNS plugin >> [14/43]: enabling entryUSN plugin >> [15/43]: configuring lockout plugin >> [16/43]: configuring topology plugin >> [17/43]: creating indices >> [18/43]: enabling referential integrity plugin >> [19/43]: configuring certmap.conf >> [20/43]: configure autobind for root >> [21/43]: configure new location for managed entries >> [22/43]: configure dirsrv ccache >> [23/43]: enabling SASL mapping fallback >> [24/43]: restarting directory server >> [25/43]: creating DS keytab >> [26/43]: retrieving DS Certificate >> [27/43]: restarting directory server >> ipa : CRITICAL Failed to restart the directory server (Command >> '/bin/systemctl restart dirsrv@SOMETHING-BE.service' returned non-zero >> exit >> status 1). See the installation log for details. >> [28/43]: setting up initial replication &
[Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process
Hi, I have a setup where i want to add a replica. The first master setup has an externally signed cert for dirsrv and httpd. The replica is prepapred succesfully with ipa-client-install but the replica install then keeps failing. It seems that during install dirserv is not configured correctly with a valid server certificate. Output from the dirsrv error added to this email as well. [root@ns02 ~]# ipa-replica-install --setup-ca WARNING: conflicting time synchronization service 'chronyd' will be disabled in favor of ntpd Run connection check to master Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv). Estimated time: 1 minute [1/43]: creating directory server user [2/43]: creating directory server instance [3/43]: restarting directory server [4/43]: adding default schema [5/43]: enabling memberof plugin [6/43]: enabling winsync plugin [7/43]: configuring replication version plugin [8/43]: enabling IPA enrollment plugin [9/43]: enabling ldapi [10/43]: configuring uniqueness plugin [11/43]: configuring uuid plugin [12/43]: configuring modrdn plugin [13/43]: configuring DNS plugin [14/43]: enabling entryUSN plugin [15/43]: configuring lockout plugin [16/43]: configuring topology plugin [17/43]: creating indices [18/43]: enabling referential integrity plugin [19/43]: configuring certmap.conf [20/43]: configure autobind for root [21/43]: configure new location for managed entries [22/43]: configure dirsrv ccache [23/43]: enabling SASL mapping fallback [24/43]: restarting directory server [25/43]: creating DS keytab [26/43]: retrieving DS Certificate [27/43]: restarting directory server ipa : CRITICAL Failed to restart the directory server (Command '/bin/systemctl restart dirsrv@SOMETHING-BE.service' returned non-zero exit status 1). See the installation log for details. [28/43]: setting up initial replication [error] error: [Errno 111] Connection refused Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security Initialization: Can't find certificate (Server-Cert) for family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security Initialization: Unable to retrieve private key for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch
Can somebody help us how to move ahead with this issue? It seems like nobody is picking this up? Kind Regards, David 2016-10-26 13:43 GMT+02:00 David Dejaeghere <david.dejaegh...@gmail.com>: > Does anybody have a clue on how to continue with this? > > Kind Regards, > > David > > 2016-10-24 10:10 GMT+02:00 David Dejaeghere <david.dejaegh...@gmail.com>: > >> These are both the subjects for the old and new root ca cert. >> >> Subject: "CN=tokio-PAPRIKA-CA,DC=tokio,DC=local" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> d5:51:19:a0:7e:2f:b6:4b:cb:71:42:cb:38:bc:50:0a: >> 18:16:58:07:11:c6:d3:ea:66:91:a8:52:02:54:93:28: >> 78:a1:89:36:7a:0f:1e:2a:35:8a:da:85:05:c4:fe:de: >> e8:6a:e8:fd:1b:89:44:8f:8c:62:d6:56:f7:9e:16:d5: >> fd:b4:44:65:71:4f:1a:7d:d6:28:2d:5e:ad:c9:da:60: >> 54:98:02:87:d9:43:62:ab:1b:93:c1:af:0b:b9:80:2e: >> 08:f0:65:46:bf:de:78:c5:d2:19:b8:07:52:d6:01:ab: >> d0:b2:7d:0a:7f:9f:fa:e8:8c:55:86:e0:d3:d5:ef:e7: >> ad:6a:12:a2:b8:75:be:93:c2:05:df:99:a9:d8:a2:cc: >> 7c:2b:49:d6:a3:65:0c:c8:ef:c3:a4:b6:f6:86:1d:c2: >> 56:56:1b:0d:70:7a:67:15:49:2f:b7:92:8e:2a:94:57: >> 53:26:ef:9a:af:89:fe:cb:1e:e7:ac:72:9a:cd:b4:22: >> b1:22:02:fd:95:23:e0:65:d0:36:e8:e1:88:2b:35:02: >> 99:1c:ee:84:10:80:84:a8:e5:61:04:6b:a3:6b:da:c5: >> 49:36:ef:f6:48:09:2c:0d:7c:b2:52:4f:a6:72:cc:e6: >> 30:b5:dd:a0:5b:0e:96:49:78:9d:1e:27:4e:02:40:a1 >> Exponent: 65537 (0x10001) >> >> Subject: DC=local, DC=tokio, CN=tokio-PAPRIKA-CA >> Subject Public Key Info: >> Public Key Algorithm: rsaEncryption >> Public-Key: (2048 bit) >> Modulus: >> 00:ae:32:35:fa:b5:f4:2d:b8:0c:c3:d9:b0:9f:a8: >> 5d:21:90:58:a9:79:79:7d:85:7e:f1:f2:36:9d:ef: >> 9f:8c:a8:3a:bf:57:5c:2e:6b:5d:2e:91:ba:c6:b7: >> b2:b1:dd:45:de:e6:d4:fe:01:f4:d2:bd:99:9f:9a: >> 71:1d:d4:e4:a7:cd:9e:f3:36:a7:a0:73:55:6b:04: >> 66:ab:c3:63:b3:41:06:ac:c8:c8:3a:4c:eb:83:78: >> 6e:e8:b6:0f:94:fa:a8:7e:7d:89:44:d1:bd:be:14: >> df:0c:ce:4d:b4:e6:0a:e2:d7:84:95:4b:a1:3e:53: >> c9:04:3f:7b:de:1b:fd:7b:b5:b0:69:3b:f9:f2:b5: >> a7:fe:6d:9d:62:6e:9a:fc:1e:32:69:ad:4c:ae:e3: >> 61:dd:92:99:34:4b:bf:6b:02:88:18:88:a2:0f:ca: >> e8:6e:91:f0:e6:2e:4d:83:f6:05:7e:ed:f2:f1:3e: >> b2:36:3f:de:3f:db:93:73:5b:60:ee:8c:48:e0:c0: >> 4c:0e:6a:63:1a:16:af:9e:28:93:40:39:23:bf:d0: >> 77:9c:b7:80:d3:c3:42:d8:27:db:d7:4b:e5:3f:b4: >> d2:ad:57:c2:01:73:c8:45:26:f1:00:93:50:3e:cf: >> 7a:2d:25:d5:43:b6:a7:75:a1:ef:58:f9:c9:11:e8: >> 09:1d >> Exponent: 65537 (0x10001) >> >> 2016-10-24 5:49 GMT+02:00 Fil Di Noto <fdin...@gmail.com>: >> >>> Hi, >>> >>> Can you give an example of what's different between the two subjects? >>> >>> On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere < >>> david.dejaegh...@gmail.com> wrote: >>> >>>> Does somebody have an idea how to replace our certificates when the new >>>> ROOT ca certificate has a different subject? >>>> The UI is down because of this. >>>> >>>> 2016-10-19 11:42 GMT+02:00 David Dejaeghere <david.dejaegh...@gmail.com >>>> >: >>>> >>>>> Hello, >>>>> >>>>> When installing FreeIPA we used the CA from our Windows servers. >>>>> This one recently expired and we created a new one. It seems that the >>>>> new root CA has another subject name and this seems to be an issue when we >>>>> want to install new certs on our FreeIPA hosts. >>>>> >>>>> ipa-cacert-manage install certnew.pem -n mycert -t C,, >>>>> >>>>> Installing CA certificate, please wait >>>>> Failed to install the certificate: subject public key info mismatch >>>>> >>>>> After validating the subjects are indeed different. >>>>> >>>>> How can we replace the required certs for dirsrv and http when the ca >>>>> is not installable? >>>>> >>>>> Kind Regards, >>>>> >>>>> David >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project >>>> >>> >>> >> > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch
Does anybody have a clue on how to continue with this? Kind Regards, David 2016-10-24 10:10 GMT+02:00 David Dejaeghere <david.dejaegh...@gmail.com>: > These are both the subjects for the old and new root ca cert. > > Subject: "CN=tokio-PAPRIKA-CA,DC=tokio,DC=local" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > d5:51:19:a0:7e:2f:b6:4b:cb:71:42:cb:38:bc:50:0a: > 18:16:58:07:11:c6:d3:ea:66:91:a8:52:02:54:93:28: > 78:a1:89:36:7a:0f:1e:2a:35:8a:da:85:05:c4:fe:de: > e8:6a:e8:fd:1b:89:44:8f:8c:62:d6:56:f7:9e:16:d5: > fd:b4:44:65:71:4f:1a:7d:d6:28:2d:5e:ad:c9:da:60: > 54:98:02:87:d9:43:62:ab:1b:93:c1:af:0b:b9:80:2e: > 08:f0:65:46:bf:de:78:c5:d2:19:b8:07:52:d6:01:ab: > d0:b2:7d:0a:7f:9f:fa:e8:8c:55:86:e0:d3:d5:ef:e7: > ad:6a:12:a2:b8:75:be:93:c2:05:df:99:a9:d8:a2:cc: > 7c:2b:49:d6:a3:65:0c:c8:ef:c3:a4:b6:f6:86:1d:c2: > 56:56:1b:0d:70:7a:67:15:49:2f:b7:92:8e:2a:94:57: > 53:26:ef:9a:af:89:fe:cb:1e:e7:ac:72:9a:cd:b4:22: > b1:22:02:fd:95:23:e0:65:d0:36:e8:e1:88:2b:35:02: > 99:1c:ee:84:10:80:84:a8:e5:61:04:6b:a3:6b:da:c5: > 49:36:ef:f6:48:09:2c:0d:7c:b2:52:4f:a6:72:cc:e6: > 30:b5:dd:a0:5b:0e:96:49:78:9d:1e:27:4e:02:40:a1 > Exponent: 65537 (0x10001) > > Subject: DC=local, DC=tokio, CN=tokio-PAPRIKA-CA > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > 00:ae:32:35:fa:b5:f4:2d:b8:0c:c3:d9:b0:9f:a8: > 5d:21:90:58:a9:79:79:7d:85:7e:f1:f2:36:9d:ef: > 9f:8c:a8:3a:bf:57:5c:2e:6b:5d:2e:91:ba:c6:b7: > b2:b1:dd:45:de:e6:d4:fe:01:f4:d2:bd:99:9f:9a: > 71:1d:d4:e4:a7:cd:9e:f3:36:a7:a0:73:55:6b:04: > 66:ab:c3:63:b3:41:06:ac:c8:c8:3a:4c:eb:83:78: > 6e:e8:b6:0f:94:fa:a8:7e:7d:89:44:d1:bd:be:14: > df:0c:ce:4d:b4:e6:0a:e2:d7:84:95:4b:a1:3e:53: > c9:04:3f:7b:de:1b:fd:7b:b5:b0:69:3b:f9:f2:b5: > a7:fe:6d:9d:62:6e:9a:fc:1e:32:69:ad:4c:ae:e3: > 61:dd:92:99:34:4b:bf:6b:02:88:18:88:a2:0f:ca: > e8:6e:91:f0:e6:2e:4d:83:f6:05:7e:ed:f2:f1:3e: > b2:36:3f:de:3f:db:93:73:5b:60:ee:8c:48:e0:c0: > 4c:0e:6a:63:1a:16:af:9e:28:93:40:39:23:bf:d0: > 77:9c:b7:80:d3:c3:42:d8:27:db:d7:4b:e5:3f:b4: > d2:ad:57:c2:01:73:c8:45:26:f1:00:93:50:3e:cf: > 7a:2d:25:d5:43:b6:a7:75:a1:ef:58:f9:c9:11:e8: > 09:1d > Exponent: 65537 (0x10001) > > 2016-10-24 5:49 GMT+02:00 Fil Di Noto <fdin...@gmail.com>: > >> Hi, >> >> Can you give an example of what's different between the two subjects? >> >> On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere < >> david.dejaegh...@gmail.com> wrote: >> >>> Does somebody have an idea how to replace our certificates when the new >>> ROOT ca certificate has a different subject? >>> The UI is down because of this. >>> >>> 2016-10-19 11:42 GMT+02:00 David Dejaeghere <david.dejaegh...@gmail.com> >>> : >>> >>>> Hello, >>>> >>>> When installing FreeIPA we used the CA from our Windows servers. >>>> This one recently expired and we created a new one. It seems that the >>>> new root CA has another subject name and this seems to be an issue when we >>>> want to install new certs on our FreeIPA hosts. >>>> >>>> ipa-cacert-manage install certnew.pem -n mycert -t C,, >>>> >>>> Installing CA certificate, please wait >>>> Failed to install the certificate: subject public key info mismatch >>>> >>>> After validating the subjects are indeed different. >>>> >>>> How can we replace the required certs for dirsrv and http when the ca >>>> is not installable? >>>> >>>> Kind Regards, >>>> >>>> David >>>> >>>> >>>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go to http://freeipa.org for more info on the project >>> >> >> > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch
These are both the subjects for the old and new root ca cert. Subject: "CN=tokio-PAPRIKA-CA,DC=tokio,DC=local" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d5:51:19:a0:7e:2f:b6:4b:cb:71:42:cb:38:bc:50:0a: 18:16:58:07:11:c6:d3:ea:66:91:a8:52:02:54:93:28: 78:a1:89:36:7a:0f:1e:2a:35:8a:da:85:05:c4:fe:de: e8:6a:e8:fd:1b:89:44:8f:8c:62:d6:56:f7:9e:16:d5: fd:b4:44:65:71:4f:1a:7d:d6:28:2d:5e:ad:c9:da:60: 54:98:02:87:d9:43:62:ab:1b:93:c1:af:0b:b9:80:2e: 08:f0:65:46:bf:de:78:c5:d2:19:b8:07:52:d6:01:ab: d0:b2:7d:0a:7f:9f:fa:e8:8c:55:86:e0:d3:d5:ef:e7: ad:6a:12:a2:b8:75:be:93:c2:05:df:99:a9:d8:a2:cc: 7c:2b:49:d6:a3:65:0c:c8:ef:c3:a4:b6:f6:86:1d:c2: 56:56:1b:0d:70:7a:67:15:49:2f:b7:92:8e:2a:94:57: 53:26:ef:9a:af:89:fe:cb:1e:e7:ac:72:9a:cd:b4:22: b1:22:02:fd:95:23:e0:65:d0:36:e8:e1:88:2b:35:02: 99:1c:ee:84:10:80:84:a8:e5:61:04:6b:a3:6b:da:c5: 49:36:ef:f6:48:09:2c:0d:7c:b2:52:4f:a6:72:cc:e6: 30:b5:dd:a0:5b:0e:96:49:78:9d:1e:27:4e:02:40:a1 Exponent: 65537 (0x10001) Subject: DC=local, DC=tokio, CN=tokio-PAPRIKA-CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ae:32:35:fa:b5:f4:2d:b8:0c:c3:d9:b0:9f:a8: 5d:21:90:58:a9:79:79:7d:85:7e:f1:f2:36:9d:ef: 9f:8c:a8:3a:bf:57:5c:2e:6b:5d:2e:91:ba:c6:b7: b2:b1:dd:45:de:e6:d4:fe:01:f4:d2:bd:99:9f:9a: 71:1d:d4:e4:a7:cd:9e:f3:36:a7:a0:73:55:6b:04: 66:ab:c3:63:b3:41:06:ac:c8:c8:3a:4c:eb:83:78: 6e:e8:b6:0f:94:fa:a8:7e:7d:89:44:d1:bd:be:14: df:0c:ce:4d:b4:e6:0a:e2:d7:84:95:4b:a1:3e:53: c9:04:3f:7b:de:1b:fd:7b:b5:b0:69:3b:f9:f2:b5: a7:fe:6d:9d:62:6e:9a:fc:1e:32:69:ad:4c:ae:e3: 61:dd:92:99:34:4b:bf:6b:02:88:18:88:a2:0f:ca: e8:6e:91:f0:e6:2e:4d:83:f6:05:7e:ed:f2:f1:3e: b2:36:3f:de:3f:db:93:73:5b:60:ee:8c:48:e0:c0: 4c:0e:6a:63:1a:16:af:9e:28:93:40:39:23:bf:d0: 77:9c:b7:80:d3:c3:42:d8:27:db:d7:4b:e5:3f:b4: d2:ad:57:c2:01:73:c8:45:26:f1:00:93:50:3e:cf: 7a:2d:25:d5:43:b6:a7:75:a1:ef:58:f9:c9:11:e8: 09:1d Exponent: 65537 (0x10001) 2016-10-24 5:49 GMT+02:00 Fil Di Noto <fdin...@gmail.com>: > Hi, > > Can you give an example of what's different between the two subjects? > > On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere < > david.dejaegh...@gmail.com> wrote: > >> Does somebody have an idea how to replace our certificates when the new >> ROOT ca certificate has a different subject? >> The UI is down because of this. >> >> 2016-10-19 11:42 GMT+02:00 David Dejaeghere <david.dejaegh...@gmail.com>: >> >>> Hello, >>> >>> When installing FreeIPA we used the CA from our Windows servers. >>> This one recently expired and we created a new one. It seems that the >>> new root CA has another subject name and this seems to be an issue when we >>> want to install new certs on our FreeIPA hosts. >>> >>> ipa-cacert-manage install certnew.pem -n mycert -t C,, >>> >>> Installing CA certificate, please wait >>> Failed to install the certificate: subject public key info mismatch >>> >>> After validating the subjects are indeed different. >>> >>> How can we replace the required certs for dirsrv and http when the ca is >>> not installable? >>> >>> Kind Regards, >>> >>> David >>> >>> >>> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project >> > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch
Does somebody have an idea how to replace our certificates when the new ROOT ca certificate has a different subject? The UI is down because of this. 2016-10-19 11:42 GMT+02:00 David Dejaeghere <david.dejaegh...@gmail.com>: > Hello, > > When installing FreeIPA we used the CA from our Windows servers. > This one recently expired and we created a new one. It seems that the new > root CA has another subject name and this seems to be an issue when we want > to install new certs on our FreeIPA hosts. > > ipa-cacert-manage install certnew.pem -n mycert -t C,, > > Installing CA certificate, please wait > Failed to install the certificate: subject public key info mismatch > > After validating the subjects are indeed different. > > How can we replace the required certs for dirsrv and http when the ca is > not installable? > > Kind Regards, > > David > > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch
Hello, When installing FreeIPA we used the CA from our Windows servers. This one recently expired and we created a new one. It seems that the new root CA has another subject name and this seems to be an issue when we want to install new certs on our FreeIPA hosts. ipa-cacert-manage install certnew.pem -n mycert -t C,, Installing CA certificate, please wait Failed to install the certificate: subject public key info mismatch After validating the subjects are indeed different. How can we replace the required certs for dirsrv and http when the ca is not installable? Kind Regards, David -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] SOA Serial changes overnight and is inconsisstent with replica
Hello, I noticed on the couple of installs that I am running that my zones have different soa serial values on both master and replica. I also noticed that this value is changing without adding or removing a record some time during the night. What exactly is changing this and how come these values become inconsistant? For example: Serial on master: 1441509183 Serial on replica: 1441597213 Is this expected? Kind Regards, David -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Dns SOA MNAME not resolving from LDAP data
Hi, I noticed that changing the authoritarive nameserver in FreeIPA reflects correctly to its directory data but bind will not resolve the soa record with the updated mname details. For example I add a zone test.be and change the mname record. [root@ns02 ~]# ipa dnszone-add Zone name: test.be Zone name: test.be. Active zone: TRUE * Authoritative nameserver: ns02.tokiogroup.be http://ns02.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440070999 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TOKIOGROUP.BE krb5-self * A; grant TOKIOGROUP.BE krb5-self * ; grant TOKIOGROUP.BE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@ns02 ~]# ipa dnszone-mod --nameserver anaconda-ks.cfg .bash_logout .bashrc .ipa/.ssh/ .bash_history.bash_profile.cshrc .pki/.tcshrc [root@ns02 ~]# ipa dnszone-mod --name-server* ns7.tokiogroup.be http://ns7.tokiogroup.be*. Zone name: test.be ipa: WARNING: Semantic of setting Authoritative nameserver was changed. It is used only for setting the SOA MNAME attribute. NS record(s) can be edited in zone apex - '@'. Zone name: test.be. Active zone: TRUE *Authoritative nameserver: ns7.tokiogroup.be http://ns7.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440071001 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root@ns02 ~]# nslookup set q=SOA test.be Server: 127.0.0.1 Address:127.0.0.1#53 test.be * origin = ns02.tokiogroup.be http://ns02.tokiogroup.be* mail addr = hostmaster.test.be serial = 1440071001 refresh = 3600 retry = 900 expire = 1209600 minimum = 3600 As you can see the SOA record still shows the original default value. Kind Regards, David Dejaeghere -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Dns SOA MNAME not resolving from LDAP data
The reason I hit this issue was because I am testing out a setup where ldap etc are running on a private subnet but is hosting public zones. Therefor I change the nameservers of these zones and the primary nameserver soa record to a public reachable hostname. I agree this is no issue for the majority of users. There already is a warning in the UI and IPA CLI. It might be good to add an extra line to this warning regarding the fake_mname, altought this might also cause confusion. Regards, David 2015-08-20 15:09 GMT+02:00 Martin Basti mba...@redhat.com: On 08/20/2015 02:46 PM, David Dejaeghere wrote: confirmed working. Does this default value make any sense if this value is changeable in the UI and using the IPA client? Kind Regards, David IMHO (I'm not 100% sure) IPA DNS are master servers, which contains only authoritative zones. Each DNS server contains the same copy of zones synchronized with LDAP database, and each server is authoritative for that zone (multimaster DNS topology). So there is no reason to have listed different server than IPA DNS as authoritative servers. This works for majority users. This also works as fallback (on local network only without caching) when one replica is down, the one of IPA DNS servers left, may act as authoritative servers (primary master for DDNS). I agree that this is tricky (I forgot about fake_mname too) for users who want to change it, we may show warning for user or somehow let him know that fake_mname is used. Martin 2015-08-20 14:38 GMT+02:00 Martin Basti mba...@redhat.com: On 08/20/2015 02:35 PM, David Dejaeghere wrote: Aha, Correct. But i never set this. This option seems to be set by default. I verified this issue on multiple installs. It seems they all have this option set by default? Can i safely change named.conf without fearing my modifications will be lost on an update? Kind Regards, David (Adding freeipa-users back) I checked code, it is default. You can change named.conf, upgrade will not replace it. Martin 2015-08-20 14:32 GMT+02:00 Martin Basti mba...@redhat.com mba...@redhat.com: On 08/20/2015 02:22 PM, Martin Basti wrote: On 08/20/2015 01:48 PM, David Dejaeghere wrote: Hi, I noticed that changing the authoritarive nameserver in FreeIPA reflects correctly to its directory data but bind will not resolve the soa record with the updated mname details. For example I add a zone test.be and change the mname record. [root@ns02 ~]# ipa dnszone-add Zone name: test.be Zone name: test.be. Active zone: TRUE * Authoritative nameserver: ns02.tokiogroup.be http://ns02.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440070999 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TOKIOGROUP.BE krb5-self * A; grant TOKIOGROUP.BE krb5-self * ; grant TOKIOGROUP.BE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@ns02 ~]# ipa dnszone-mod --nameserver anaconda-ks.cfg .bash_logout .bashrc .ipa/.ssh/ .bash_history.bash_profile.cshrc .pki/ .tcshrc [root@ns02 ~]# ipa dnszone-mod --name-server* ns7.tokiogroup.be http://ns7.tokiogroup.be*. Zone name: test.be ipa: WARNING: Semantic of setting Authoritative nameserver was changed. It is used only for setting the SOA MNAME attribute. NS record(s) can be edited in zone apex - '@'. Zone name: test.be. Active zone: TRUE *Authoritative nameserver: ns7.tokiogroup.be http://ns7.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440071001 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root@ns02 ~]# nslookup set q=SOA test.be Server: 127.0.0.1 Address:127.0.0.1#53 test.be * origin = ns02.tokiogroup.be http://ns02.tokiogroup.be* mail addr = hostmaster.test.be serial = 1440071001 refresh = 3600 retry = 900 expire = 1209600 minimum = 3600 As you can see the SOA record still shows the original default value. Kind Regards, David Dejaeghere Thank you for this bug report. I opened bind-dyndb-ldap ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/159 https://fedorahosted.org/bind-dyndb-ldap/ticket/159 Martin I maybe found why do you have this issue, do you have fake_mname configured in bind_dyndb_ldap section of named.conf? If yes then remove this option to use SOA MNAME from LDAP. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
Hello Guys, I was able to resolve this today. My webserver and dirsrv certificate were expired yesterday and trying to replace them gave me the same error ERROR: (SEC_ERROR_LIBRARY_FAILURE) security library failure. So I tried some things to resolve this. The trick was to replace /etc/ipa/ca.crt with the godaddy file gdig2 which only has 1 certificare. This file you can get while downloading your certificate from godaddy. Then I had to add the bundle from godaddy, file gd_bundle-g2-g1 into my server cert. This made both the command ipa-server-certinstall and ipa-replicate-prepare finish as expected! Hope this helps. I saw somebody else with a very similar issue. Kind Regards, D 2015-04-23 7:40 GMT+02:00 Jan Cholasta jchol...@redhat.com: Hi, yes, you can definitely use a different certificate in the meantime, although it can't be self-signed. Honza Dne 20.4.2015 v 14:17 David Dejaeghere napsal(a): Hi, Let me know how I can assist. In the meantime could I setup a replica using a different certificate? Self signed or anything like that? Regards, D 2015-04-17 15:27 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com: Hi, I don't have any new information. I'm trying to reproduce the problem but had no luck so far. Honza Dne 17.4.2015 v 15:23 David Dejaeghere napsal(a): Hi, Any more things I can try out? How do we proceed? Kind Regards, D 2015-04-15 11:48 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com: Hi Honza, That gave me the exact same output. Any ideas? Regards, D 2015-04-15 7:33 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com mailto:jchol...@redhat.com mailto:jchol...@redhat.com: Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- Jan Cholasta -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Known issues with IPA on VM?
Running FreeIPA 4.1 on Fedora 21 on Xenserver 6.2 in HVM mode. No issues. Kind Regards, David 2015-05-06 11:15 GMT+02:00 Alexander Frolushkin alexander.frolush...@megafon.ru: Hello. We have periodically hanging and crashing dirsrv in our ipa servers. All of them running in VM on Vmware. WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 *From:* freeipa-users-boun...@redhat.com [mailto: freeipa-users-boun...@redhat.com] *On Behalf Of *Christoph Kaminski *Sent:* Wednesday, May 06, 2015 11:48 AM *To:* Freeipa-users *Subject:* [Freeipa-users] Known issues with IPA on VM? Hi we have some undefinably problems here with IPA inside a VM (rhev/kvm). We has often zombie processes (defunct) with certmonger and dirsrv and segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with same Install (rhel7.1). We see these problems only on the VM's. Is there something already known about such problems? (The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups) Greetz Christoph Kaminski -- Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, Let me know how I can assist. In the meantime could I setup a replica using a different certificate? Self signed or anything like that? Regards, D 2015-04-17 15:27 GMT+02:00 Jan Cholasta jchol...@redhat.com: Hi, I don't have any new information. I'm trying to reproduce the problem but had no luck so far. Honza Dne 17.4.2015 v 15:23 David Dejaeghere napsal(a): Hi, Any more things I can try out? How do we proceed? Kind Regards, D 2015-04-15 11:48 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com: Hi Honza, That gave me the exact same output. Any ideas? Regards, D 2015-04-15 7:33 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com: Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, Any more things I can try out? How do we proceed? Kind Regards, D 2015-04-15 11:48 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com: Hi Honza, That gave me the exact same output. Any ideas? Regards, D 2015-04-15 7:33 GMT+02:00 Jan Cholasta jchol...@redhat.com: Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust- source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
Hi Honza, That gave me the exact same output. Any ideas? Regards, D 2015-04-15 7:33 GMT+02:00 Jan Cholasta jchol...@redhat.com: Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust- source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Regards, David 2015-04-13 16:28 GMT+02:00 Rob Crittenden rcrit...@redhat.com: David Dejaeghere wrote: Hi, I get the same error when I use a pk12 with only the server certificate (and key) in it. Not sure what else I can try. I'd need to see the full output again. rob Regards, D 2015-04-11 0:23 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, I even tried the command using an export from the http service nss db, same issue. regarding SElinux: ausearch -m AVC -ts recent no matches Sending you the log personally. Ok, so the way the certs are imported is all the certs in the PKCS#12 file are loaded in, then marked as untrusted. certutil -O is executed against the server cert which prints out what the trust chain should be and those certs marked as trusted CA's. That part is working fine. Finally it makes another pass through the database to verify the chain. Looking at the output there are two certs with the subject CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US and different serial numbers. I wonder if this is confusing the cert loader. These certs are included in the PKCS#12 file (serial #0 and #1828629 AFAICT). I don't know which one is the right' one, or if there even is one. rob Regards, D 2015-04-10 17:03 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi Rob, Without the --http-pin the command will give a prompt to enter the password. Tried both. I am sending the output of the pk12util -l to you in another email. It holds the wildcard certificate and the godaddy bundle for as far as I can tell. I have to admit, I'm a bit stumped. (SEC_ERROR_LIBRARY_FAILURE) is a rather generic NSS error which can mean any number of things. It often means that the NSS database it is using is bad in some way but given that this is a temporary database created just for this purpose I doubt that's it. You may want to look for SELinux AVCs though: ausearch -m AVC -ts recent. At the point where it is blowing up, the PKCS#12 file has already been imported and IPA is walking through the results trying to ensure that the full cert trust chain is available. It does this by reading the certs out of the database, and at that point it's blowing up. The PKCS#12 output you sent me looks ok. I don't believe this is an issue with trust or missing parts of the chain. I created a simple PKCS#12 file and was able to prepare a replica using it, so AFAICT the code isn't completely broken. Can you provide the full output from ipa-replica-prepare? rob Regards, D 2015-04-09 21:39 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Sorry for the lack of details! You are indeed correct about the version its 4.1 The command I am using is this: ipa-replica-prepare ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com --http-cert-file /home/fedora/newcert.pk12 --dirsrv-cert-file /home/fedora/newcert.pk12 --ip-address 172.31.16.31 -v I was pretty sure a pin was required with those options as well. What do the PKCS#12 files look like: pk12util -l /home/fedora/newcert.pk12 rob Regards, D 2015-04-09 16:16 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, I get the same error when I use a pk12 with only the server certificate (and key) in it. Not sure what else I can try. Regards, D 2015-04-11 0:23 GMT+02:00 Rob Crittenden rcrit...@redhat.com: David Dejaeghere wrote: Hi, I even tried the command using an export from the http service nss db, same issue. regarding SElinux: ausearch -m AVC -ts recent no matches Sending you the log personally. Ok, so the way the certs are imported is all the certs in the PKCS#12 file are loaded in, then marked as untrusted. certutil -O is executed against the server cert which prints out what the trust chain should be and those certs marked as trusted CA's. That part is working fine. Finally it makes another pass through the database to verify the chain. Looking at the output there are two certs with the subject CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US and different serial numbers. I wonder if this is confusing the cert loader. These certs are included in the PKCS#12 file (serial #0 and #1828629 AFAICT). I don't know which one is the right' one, or if there even is one. rob Regards, D 2015-04-10 17:03 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi Rob, Without the --http-pin the command will give a prompt to enter the password. Tried both. I am sending the output of the pk12util -l to you in another email. It holds the wildcard certificate and the godaddy bundle for as far as I can tell. I have to admit, I'm a bit stumped. (SEC_ERROR_LIBRARY_FAILURE) is a rather generic NSS error which can mean any number of things. It often means that the NSS database it is using is bad in some way but given that this is a temporary database created just for this purpose I doubt that's it. You may want to look for SELinux AVCs though: ausearch -m AVC -ts recent. At the point where it is blowing up, the PKCS#12 file has already been imported and IPA is walking through the results trying to ensure that the full cert trust chain is available. It does this by reading the certs out of the database, and at that point it's blowing up. The PKCS#12 output you sent me looks ok. I don't believe this is an issue with trust or missing parts of the chain. I created a simple PKCS#12 file and was able to prepare a replica using it, so AFAICT the code isn't completely broken. Can you provide the full output from ipa-replica-prepare? rob Regards, D 2015-04-09 21:39 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Sorry for the lack of details! You are indeed correct about the version its 4.1 The command I am using is this: ipa-replica-prepare ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com --http-cert-file /home/fedora/newcert.pk12 --dirsrv-cert-file /home/fedora/newcert.pk12 --ip-address 172.31.16.31 -v I was pretty sure a pin was required with those options as well. What do the PKCS#12 files look like: pk12util -l /home/fedora/newcert.pk12 rob Regards, D 2015-04-09 16:16 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Does somebody have any pointers for me regarding this issue? It would help very much if you'd include the version you're working with. Based on line numbers I'll assume IPA 4.1. It's hard to say since you don't include the command-line you're using, or what those files consist of. It looks like it is blowing up trying to verify that the whole certificate chain is available. NSS unfortunately doesn't always provide the best error messages so it's hard to say why this particular cert can't be loaded. rob Regards, D 2015-04-07 13:34 GMT+02:00
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, Does somebody have any pointers for me regarding this issue? Regards, D 2015-04-07 13:34 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com: Hello, I am trying to setup a replica for my master which has been setup with an external CA to use our godaddy wildcard certificate. The ipa-replica-prepare is failing with the following debug information. I am using --http-cert and --dirsrv-cert with my pk12 server certificate. What can I verify to get an idea of what is going wrong? ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 169, in execute self.ask_for_options() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 276, in ask_for_options options.http_cert_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 176, in load_pkcs12 host_name=self.replica_fqdn) File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 785, in load_pkcs12 nss_cert = x509.load_certificate(cert, x509.DER) File /usr/lib/python2.7/site-packages/ipalib/x509.py, line 128, in load_certificate return nss.Certificate(buffer(data)) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: NSPRError: (SEC_ERROR_LIBRARY_FAILURE) security library failure. ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Regards, D -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, Sorry for the lack of details! You are indeed correct about the version its 4.1 The command I am using is this: ipa-replica-prepare ipa-r1.myobscureddomain.com --http-cert-file /home/fedora/newcert.pk12 --dirsrv-cert-file /home/fedora/newcert.pk12 --ip-address 172.31.16.31 -v Regards, D 2015-04-09 16:16 GMT+02:00 Rob Crittenden rcrit...@redhat.com: David Dejaeghere wrote: Hi, Does somebody have any pointers for me regarding this issue? It would help very much if you'd include the version you're working with. Based on line numbers I'll assume IPA 4.1. It's hard to say since you don't include the command-line you're using, or what those files consist of. It looks like it is blowing up trying to verify that the whole certificate chain is available. NSS unfortunately doesn't always provide the best error messages so it's hard to say why this particular cert can't be loaded. rob Regards, D 2015-04-07 13:34 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com: Hello, I am trying to setup a replica for my master which has been setup with an external CA to use our godaddy wildcard certificate. The ipa-replica-prepare is failing with the following debug information. I am using --http-cert and --dirsrv-cert with my pk12 server certificate. What can I verify to get an idea of what is going wrong? ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 169, in execute self.ask_for_options() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 276, in ask_for_options options.http_cert_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 176, in load_pkcs12 host_name=self.replica_fqdn) File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 785, in load_pkcs12 nss_cert = x509.load_certificate(cert, x509.DER) File /usr/lib/python2.7/site-packages/ipalib/x509.py, line 128, in load_certificate return nss.Certificate(buffer(data)) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: NSPRError: (SEC_ERROR_LIBRARY_FAILURE) security library failure. ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Regards, D -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipa-replica-prepare failing
Hello, I am trying to setup a replica for my master which has been setup with an external CA to use our godaddy wildcard certificate. The ipa-replica-prepare is failing with the following debug information. I am using --http-cert and --dirsrv-cert with my pk12 server certificate. What can I verify to get an idea of what is going wrong? ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 169, in execute self.ask_for_options() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 276, in ask_for_options options.http_cert_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 176, in load_pkcs12 host_name=self.replica_fqdn) File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 785, in load_pkcs12 nss_cert = x509.load_certificate(cert, x509.DER) File /usr/lib/python2.7/site-packages/ipalib/x509.py, line 128, in load_certificate return nss.Certificate(buffer(data)) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: NSPRError: (SEC_ERROR_LIBRARY_FAILURE) security library failure. ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Regards, D -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipa group-add mixed case?
Hi, I recently deployed FreeIPA but I stumbled upon a problem with migrating my groups. The groups in our old system are mixed case. Such as MyGroup. The application that syncs these groups is case sensitive. The problem is that when i create these groups using the webgui or the ipa admin tool it gets created using lowercase. I was wondering if there is a way around this? Even perhaps changing a small part in the code. I tried looking into the code of the ipa admin tool but could not find the part that change the group name to lowercase. Any tips or help? Kind Regards, David -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
