Re: [Freeipa-users] replication again :-(
On 05/19/2015 08:58 AM, thierry bordaz wrote: On 05/19/2015 07:47 AM, Martin Kosek wrote: On 05/19/2015 03:23 AM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. Hello Janelle, I am very sorry to hear about your troubles. Would you be still OK with helping us (mostly Ludwig and Thierry) investigate what is the root cause of the instability of the replication agreements? This is obviously something that should not be happening at this rate as in your deployment, so I would really like to be able to identity and fix this issue in the 389 DS. Hello Janelle, I can only join my voice to Martin to say how I am sorry to read this. Would you turn on replication logging level (8192) on the master/consumer and provide us the logs(access/error) and config (dse.ldif). The master is the instance where you can see the update and the that is linked (replica agreement) to a replica(aka consumer) where the update is not received. what puzzles me most, is that replication is working for quite some time and then breaks, so we need to find out about the dynamics which lead to that state. You reported errors about invalid credentials or about a bind dn entry not found, these credentials don't get changed by ds or entries are not deleted by ds, so what triggers these changes. also for the suggestion by Thierry to debug, we need to determine where replication breaks, if you add an account and it is propageted to some servers and not to others, where does it stop ? This depends on your replication topology, you said in anotehr post that you have a ring topology, does it mean all 16 servers are conencted in a ring only, and if two links break the topology is disconnected ? thanks thierry -- 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] replication again :-(
On 05/19/2015 07:47 AM, Martin Kosek wrote: On 05/19/2015 03:23 AM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. Hello Janelle, I am very sorry to hear about your troubles. Would you be still OK with helping us (mostly Ludwig and Thierry) investigate what is the root cause of the instability of the replication agreements? This is obviously something that should not be happening at this rate as in your deployment, so I would really like to be able to identity and fix this issue in the 389 DS. Hello Janelle, I can only join my voice to Martin to say how I am sorry to read this. Would you turn on replication logging level (8192) on the master/consumer and provide us the logs(access/error) and config (dse.ldif). The master is the instance where you can see the update and the that is linked (replica agreement) to a replica(aka consumer) where the update is not received. thanks thierry -- 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] replication again :-(
On 05/19/2015 03:42 AM, Janelle wrote: On 5/18/15 6:23 PM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J A new error: [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: Invalid credentials] can you see the update on ipa03.example.com ? It is looking like the replica agreement from this host is failing to bind to a replica. This could explain why the replica do not receive the update (disabled account, password/certificate expiration, ...) Again logs/config would help. thierry -- 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] Apache htaccess replacement
On Mon, May 18, 2015 at 12:38:47PM -0400, thewebbie wrote: I have been attempting to use my 4.1.4 FreeIPA server to authenticate folders on a web server as a replacement for the normal htaccess feature. I do require group authentication. I have tried just about online example and have only been able to get basic ldap and basic kerbos authentication. How do I go about getting group based authentication working. If you do not insist on group based authentication but can use the more generic host-based access control (which you should be able to do because you have IPA), you can use mod_authnz_pam: http://www.adelton.com/apache/mod_authnz_pam/ http://www.freeipa.org/page/Web_App_Authentication The module is packaged in Fedoras, RHEL, and CentOS. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)
Le 13/05/2015 10:15, Thibaut Pouzet a écrit : Le 12/05/2015 20:11, Nalin Dahyabhai a écrit : On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote: After doing what you recommended, the CSR have changed in the debug log : Certificate Request: Data: Version: 0 (0x0) Subject: O=ipa_domain, CN=ipa_server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: 1b:fb Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption 10:ef:cf:ff:6c:63:72:61:c3:b5:5e:8e:b0:20:f0:63:13:43: bb:3b:63:c8:4e:6f:34:63:33:cc:47:af:8a:dc:2d:13:2a:58: 87:7c:d7:5e:e9:b3:e7:f4:47:b7:7b:eb:77:0b:7c:0e:58:20: dd:62:a8:a0:8b:31:1e:54:f0:dd:3f:44:4a:e7:a2:a6:64:85: 9f:10:0e:06:75:33:94:82:f3:8f:89:66:e1:7f:65:21:85:b8: 69:6d:e7:35:a5:a7:08:1d:51:55:48:13:b8:e3:2d:6f:99:c1: ce:1e:81:e3:fb:93:3a:f0:86:0d:43:96:31:93:fb:87:fb:53: 46:02:e1:dd:05:55:85:72:35:fa:72:6d:c6:35:d4:6d:9e:be: db:ee:e6:8c:7b:b1:5a:cd:4d:cc:8e:3e:10:4e:a7:d3:61:36: ae:86:59:df:51:a3:0f:38:79:b8:e0:bd:eb:25:44:a4:43:b0: 93:7f:1e:43:aa:d5:30:d3:e3:a0:bd:ee:08:b7:88:9a:cd:a0: 8c:ac:2a:8f:71:ec:64:70:72:91:f8:d2:e8:55:5b:22:1f:2e: 60:6c:a4:be:ee:42:09:a6:71:25:ec:37:43:a1:e6:15:63:8f: 05:97:61:1d:8e:25:5d:76:df:8b:66:7f:85:27:8b:93:98:a9: 3e:cc:cb:d8 There is no more this weird friendlyName :unable to print attribute thing, but the NoSuchTokenException is still in the debug log of pki-ca Thank you for you answer though, we've still made some progress in identifying that I messed the CA used for this certificate ! Hmm, so what you've got there looks pretty normal for a renewal request. Just to rule out a problem with the request's signature or the encoding of the subject name in the request (the latter is a bug in versions of certmonger before 0.72), can you check the version of the certmonger package and show us the base64-encoded form of the signing request? Before going further and asking the ML, I got these packages updated 'just in case' : rpm -qa | egrep certmonger|jss tomcatjss-2.1.0-3.el6.noarch certmonger-0.75.13-1.el6.x86_64 jss-4.2.6-24.el6.x86_64 I'm just about grasping at straws here, but the NoSuchTokenException exception appears to be coming from the jss library, and is thrown when it can't find the software module that is used for accessing the server's keys. Can you verify that your /etc/pki-ca/CS.cfg file contains these lines? jss.configDir=/var/lib/pki-ca/alias/ jss.enable=true jss.secmodName=secmod.db These lines are exactly as is inside the CS.cfg file Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg? I don't have one. The Dogtag logic looks like it would try to use one set there rather than the default, but letting it use the default looks like the intended way of doing things. I cannot find this line, this is all I've got that seems somehow related to a token notion : fgrep token /etc/pki-ca/CS.cfg ca.audit_signing.tokenname=Internal Key Storage Token ca.ocsp_signing.tokenname=Internal Key Storage Token ca.signing.tokenname=Internal Key Storage Token ca.sslserver.tokenname=Internal Key Storage Token ca.subsystem.tokenname=Internal Key Storage Token cloning.module.token=Internal Key Storage Token Which version of the jss and tomcatjss packages are installed? I'm using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here. If none of this turns up anything, then I'm going to have to defer to the Dogtag team, too. Nalin I do not wish to give away too much
Re: [Freeipa-users] Reinstall ipa client, problem with old CA
Hello! On 05/19/2015 12:53 PM, Martin Kosek wrote: On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: Hello! I'm trying to reinstall ipa client, but have a problem with old/existing ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA server still on development and always reinstalled, I need to reproduce any possible problem/error on FreeIPA 4.x on CentOS 7. The error was : LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Currently, I was renamed ca.crt to ca.crt.old and the ipa client successfully reconnected to new FreeIPA Server using dns discovery. Is it normal? And why the ipa-client-install --uninstall didn't completely remove the old ca.crt? Hello, ipa-client-install uninstall the CA certificate properly since FreeIPA 3.2. This is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3537 CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x versions, you need to delete the certificate manually if you reinstalled the IPA server. HTH, Martin Could you gimme advice, which version is suitable on production? 3.x or 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). -- 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] Apache htaccess replacement
My requirements is to replace dozens of htaccess folders on one server. Each folder requiring a user group. So Host based will not work in this case Matthew Feinberg On May 19, 2015 4:03 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Mon, May 18, 2015 at 12:38:47PM -0400, thewebbie wrote: I have been attempting to use my 4.1.4 FreeIPA server to authenticate folders on a web server as a replacement for the normal htaccess feature. I do require group authentication. I have tried just about online example and have only been able to get basic ldap and basic kerbos authentication. How do I go about getting group based authentication working. If you do not insist on group based authentication but can use the more generic host-based access control (which you should be able to do because you have IPA), you can use mod_authnz_pam: http://www.adelton.com/apache/mod_authnz_pam/ http://www.freeipa.org/page/Web_App_Authentication The module is packaged in Fedoras, RHEL, and CentOS. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] certmonger + dogtag, bad parsing of returned certificate
Hi, all. I am trying to integrate certmonger with dogtag instance, and so far i've stumbled on one odd problem. Hopefully this is the right list. I've generated some random cert with getcert request, it has communicated with dogtag, and i approved it there. However, when certmonger retrieves it, it cannot save it to disk ( NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) Upon inspection of certmonger's request file (in /var/lib/certmonger/requests ), it turns out that there is an extra empty line before end certificate marker line. There is no such line when looking at the cert in dogtag web interface. Is there some method/hook i could use to post process such request files to fix them up? Currently i have to stop certmonger, remove the unnecessary blank line and restart it. Then it manages to save the cert to disk and starts tracking it correctly. -- 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] replication again :-(
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running for 6 days no issues. No new accounts or changes
(maybe a few users changing passwords) and again, 5 out of 16
servers are no longer in sync.
I can test it easily by adding an account and then waiting a few
minutes, then run ipa user-show --all username on all the
servers, and only a few of them have the account. I have now waited
15 minutes, still no luck.
Oh well.. I guess I will go look at alternatives. I had such high
hopes for this tool. Thanks so much everyone for all your help in
trying to get things stable, but for whatever reason, there is a
random loss of sync among the servers and obviously this is not
acceptable.
regards
~J
All the replicas are happy again. I found these again:
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 23} 5553e3a30017 555432430017
unable to decode {replica 24} 554d53d30018 554d54a400020018
What I also found to be interesting is that I have not deleted any
masters at all, so this was quite perplexing where the orphaned entries
came from. However I did find 3 of the replicas did not show complete
RUV lists... While most of the replicas had a list of all 16 servers, a
couple of them listed only 4 or 5. (using ipa-replica-manage list-ruv)
Once I re-initialized --from servers that showed the correct RUVS
everyone is happy again. I have tested replication by creating and
deleting accounts, changing group members and a few other things.
Everything is working fine. I have enabled additional logging.
Now we wait and when it happens again, hopefully we have something.
thanks
~Janelle
--
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] Problem installing external SSL Certificate
This is the verbose log, tried to convert them to p12 format (dont know it's right or not), still no luck. http://fpaste.org/223608/88775143/raw/ Ref: http://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html Any additional hints? On 05/19/2015 08:30 PM, Dewangga Bachrul Alam wrote: Hello! I was build FreeIPA 4.1.4 on CentOS 7.1, the deployment was done, but could I changes the HTTP and dirsv certificate? I have wildcard certificate (thawte SSL CA - G2). It is compatible for FreeIPA (http and dirsv)? I've tried to follow the instruction https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but no luck. $ ipa-server-certinstall -wd mydomain.co.id.key \ mydomain.co.id-bundled.crt Directory Manager password: Enter private key unlock password: The full certificate chain is not present in mydomain.co.id.key, mydomain.co.id-bundled.crt FYI, mydomain.co.id-bundled.crt chain have SIGNED then INTERMEDIATE certificate order. (2 chain) I've tried to bundling them using root certificate, still have no luck. (3 chain, SIGNEDCERT, INTERMEDIATE, ROOTCERT). Any comments will be appreciated :) Thanks -- 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] Reinstall ipa client, problem with old CA
On 05/19/2015 03:21 PM, Dewangga Bachrul Alam wrote: Thank you Martin, Yes, the IPA Server was built on CentOS 7.1. But, some client still using CentOS 6.x, but I have plan upgrade them to 7.x. Is it gave a problem if some client still on CentOS 6.x and the IPA Server built on CentOS 7.x ? No, I do not see a problem with this setup. Clients will just simply use the capabilities they can do. We still tend to backport client features to RHEL-6.x, so it keeps getting the selected functionality (server does not). On 05/19/2015 08:14 PM, Martin Kosek wrote: On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote: Hello! On 05/19/2015 12:53 PM, Martin Kosek wrote: On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: Hello! I'm trying to reinstall ipa client, but have a problem with old/existing ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA server still on development and always reinstalled, I need to reproduce any possible problem/error on FreeIPA 4.x on CentOS 7. The error was : LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Currently, I was renamed ca.crt to ca.crt.old and the ipa client successfully reconnected to new FreeIPA Server using dns discovery. Is it normal? And why the ipa-client-install --uninstall didn't completely remove the old ca.crt? Hello, ipa-client-install uninstall the CA certificate properly since FreeIPA 3.2. This is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3537 CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x versions, you need to delete the certificate manually if you reinstalled the IPA server. HTH, Martin Could you gimme advice, which version is suitable on production? 3.x or 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). All versions in RHEL should be suitable for production - RHEL is an OS targeting production/stable environment. For FreeIPA, I would recommend using environment built on top of RHEL-7.1 version (FreeIPA 4.1) as it contains the most fixes and most functionality to be offered. I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have limited capabilities of your infrastructure as most of the new server features are not backported to RHEL-6.x and clients connected to these servers could not use them. 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
[Freeipa-users] Problem installing external SSL Certificate
Hello! I was build FreeIPA 4.1.4 on CentOS 7.1, the deployment was done, but could I changes the HTTP and dirsv certificate? I have wildcard certificate (thawte SSL CA - G2). It is compatible for FreeIPA (http and dirsv)? I've tried to follow the instruction https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but no luck. $ ipa-server-certinstall -wd mydomain.co.id.key \ mydomain.co.id-bundled.crt Directory Manager password: Enter private key unlock password: The full certificate chain is not present in mydomain.co.id.key, mydomain.co.id-bundled.crt FYI, mydomain.co.id-bundled.crt chain have SIGNED then INTERMEDIATE certificate order. (2 chain) I've tried to bundling them using root certificate, still have no luck. (3 chain, SIGNEDCERT, INTERMEDIATE, ROOTCERT). Any comments will be appreciated :) Thanks -- 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] certmonger + dogtag, bad parsing of returned certificate
On 05/19/2015 12:34 PM, marcin kowalski wrote: Hi, all. I am trying to integrate certmonger with dogtag instance, and so far i've stumbled on one odd problem. Hopefully this is the right list. I've generated some random cert with getcert request, it has communicated with dogtag, and i approved it there. However, when certmonger retrieves it, it cannot save it to disk ( NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) Upon inspection of certmonger's request file (in /var/lib/certmonger/requests ), it turns out that there is an extra empty line before end certificate marker line. There is no such line when looking at the cert in dogtag web interface. Is there some method/hook i could use to post process such request files to fix them up? Currently i have to stop certmonger, remove the unnecessary blank line and restart it. Then it manages to save the cert to disk and starts tracking it correctly. CCing Nalin here. What is the your environment and versions of the FreeIPA/Dogtag packages you are using? Seeing your description, it looks you are following some own way - Certmonger for FreeIPA clients do not need any confirmation on Dogtag side, it is approved automatically. It looks like you are using Dogtag UI directly and not the FreeIPA integration. -- 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] Reinstall ipa client, problem with old CA
Well, thanks Martin for the info :) On 05/19/2015 08:23 PM, Martin Kosek wrote: On 05/19/2015 03:21 PM, Dewangga Bachrul Alam wrote: Thank you Martin, Yes, the IPA Server was built on CentOS 7.1. But, some client still using CentOS 6.x, but I have plan upgrade them to 7.x. Is it gave a problem if some client still on CentOS 6.x and the IPA Server built on CentOS 7.x ? No, I do not see a problem with this setup. Clients will just simply use the capabilities they can do. We still tend to backport client features to RHEL-6.x, so it keeps getting the selected functionality (server does not). On 05/19/2015 08:14 PM, Martin Kosek wrote: On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote: Hello! On 05/19/2015 12:53 PM, Martin Kosek wrote: On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: Hello! I'm trying to reinstall ipa client, but have a problem with old/existing ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA server still on development and always reinstalled, I need to reproduce any possible problem/error on FreeIPA 4.x on CentOS 7. The error was : LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Currently, I was renamed ca.crt to ca.crt.old and the ipa client successfully reconnected to new FreeIPA Server using dns discovery. Is it normal? And why the ipa-client-install --uninstall didn't completely remove the old ca.crt? Hello, ipa-client-install uninstall the CA certificate properly since FreeIPA 3.2. This is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3537 CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x versions, you need to delete the certificate manually if you reinstalled the IPA server. HTH, Martin Could you gimme advice, which version is suitable on production? 3.x or 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). All versions in RHEL should be suitable for production - RHEL is an OS targeting production/stable environment. For FreeIPA, I would recommend using environment built on top of RHEL-7.1 version (FreeIPA 4.1) as it contains the most fixes and most functionality to be offered. I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have limited capabilities of your infrastructure as most of the new server features are not backported to RHEL-6.x and clients connected to these servers could not use them. 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] replication again :-(
On 5/19/15 1:21 AM, David Kupka wrote: On 05/19/2015 09:04 AM, thierry bordaz wrote: On 05/19/2015 03:42 AM, Janelle wrote: On 5/18/15 6:23 PM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J A new error: [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: Invalid credentials] can you see the update on ipa03.example.com ? It is looking like the replica agreement from this host is failing to bind to a replica. This could explain why the replica do not receive the update (disabled account, password/certificate expiration, ...) Again logs/config would help. thierry Hello, maybe stupid question: Is time on all your replicas in sync? Usually when the time is not synced between KDC and client the ticket is rejected thus preventing login. within .5 seconds each other at most. -- 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] Reinstall ipa client, problem with old CA
Thank you Martin, Yes, the IPA Server was built on CentOS 7.1. But, some client still using CentOS 6.x, but I have plan upgrade them to 7.x. Is it gave a problem if some client still on CentOS 6.x and the IPA Server built on CentOS 7.x ? On 05/19/2015 08:14 PM, Martin Kosek wrote: On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote: Hello! On 05/19/2015 12:53 PM, Martin Kosek wrote: On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: Hello! I'm trying to reinstall ipa client, but have a problem with old/existing ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA server still on development and always reinstalled, I need to reproduce any possible problem/error on FreeIPA 4.x on CentOS 7. The error was : LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Currently, I was renamed ca.crt to ca.crt.old and the ipa client successfully reconnected to new FreeIPA Server using dns discovery. Is it normal? And why the ipa-client-install --uninstall didn't completely remove the old ca.crt? Hello, ipa-client-install uninstall the CA certificate properly since FreeIPA 3.2. This is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3537 CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x versions, you need to delete the certificate manually if you reinstalled the IPA server. HTH, Martin Could you gimme advice, which version is suitable on production? 3.x or 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc). All versions in RHEL should be suitable for production - RHEL is an OS targeting production/stable environment. For FreeIPA, I would recommend using environment built on top of RHEL-7.1 version (FreeIPA 4.1) as it contains the most fixes and most functionality to be offered. I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have limited capabilities of your infrastructure as most of the new server features are not backported to RHEL-6.x and clients connected to these servers could not use them. 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] replication again :-(
On 5/19/15 12:17 AM, Ludwig Krispenz wrote: On 05/19/2015 08:58 AM, thierry bordaz wrote: On 05/19/2015 07:47 AM, Martin Kosek wrote: On 05/19/2015 03:23 AM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. Hello Janelle, I am very sorry to hear about your troubles. Would you be still OK with helping us (mostly Ludwig and Thierry) investigate what is the root cause of the instability of the replication agreements? This is obviously something that should not be happening at this rate as in your deployment, so I would really like to be able to identity and fix this issue in the 389 DS. Hello Janelle, I can only join my voice to Martin to say how I am sorry to read this. Would you turn on replication logging level (8192) on the master/consumer and provide us the logs(access/error) and config (dse.ldif). The master is the instance where you can see the update and the that is linked (replica agreement) to a replica(aka consumer) where the update is not received. what puzzles me most, is that replication is working for quite some time and then breaks, so we need to find out about the dynamics which lead to that state. You reported errors about invalid credentials or about a bind dn entry not found, these credentials don't get changed by ds or entries are not deleted by ds, so what triggers these changes. also for the suggestion by Thierry to debug, we need to determine where replication breaks, if you add an account and it is propageted to some servers and not to others, where does it stop ? This depends on your replication topology, you said in anotehr post that you have a ring topology, does it mean all 16 servers are conencted in a ring only, and if two links break the topology is disconnected ? thanks thierry Let me see about getting some debug logs going to provide more info. As for topology -- yes, ring, but also within the DC - the 3 servers are connected in an internal ring. There have been no outages on the WAN connections, as I have logs showing network data at all times, so this is not an issue. If I did lose a WAN, dozens of other inter-DC apps would blow up too, and they have not. However, I guess you are right, I have not provided enough logging data to help diagnose this. Let me see what I can do. Not sure if this helps -- I do try and do all updates from a single master, never from different ones. Users are also forced to the same master to change passwords and update things. So the source of changes is always the same. Time to go do some log enabling... ~J -- 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] certmonger + dogtag, bad parsing of returned certificate
Thanks for the tip, I am using whatever is in current fedora, which is 0.76 or similar version. I'll give an updated version a shot. I had similar results with ubuntu's 0.75.x 2015-05-19 16:30 GMT+02:00 Nalin Dahyabhai na...@redhat.com: On Tue, May 19, 2015 at 12:34:47PM +0200, marcin kowalski wrote: Hi, all. I am trying to integrate certmonger with dogtag instance, and so far i've stumbled on one odd problem. Hopefully this is the right list. I've generated some random cert with getcert request, it has communicated with dogtag, and i approved it there. However, when certmonger retrieves it, it cannot save it to disk ( NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) Upon inspection of certmonger's request file (in /var/lib/certmonger/requests ), it turns out that there is an extra empty line before end certificate marker line. There is no such line when looking at the cert in dogtag web interface. Is there some method/hook i could use to post process such request files to fix them up? There's no hook for doing that with the data files themselves, because they're meant to be internal details of the implementation, but the data coming back from the enrollment helper, which is what's malformed to begin with, can be corrected at the point when the helper is run. Essentially, you'd replace the configured call to dogtag-submit with a script or other program that checked $CERTMONGER_OPERATION for the values SUBMIT and POLL, ran the dogtag-submit helper, filtered its output to fix this mistake, and returned the helper's exit status to keep things in line with the daemon's expectations. Though, if you're running something older than 0.77, please give 0.77.4 (currently in testing for Fedora 20 and 21) or a development snapshot (from the ipa-devel repo) a try. The 0.77 release had a lot of its parsing reworked as part of adding support for SCEP reply formats, which I think fixed this. The development snapshots add more authentication options to the generic Dogtag helper which you may also want, depending on the enrollment profile you're using. HTH, Nalin -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Sina Owolabi wrote: Hi Rob Ive been to the URL but its a little difficult applying these commands to RHEL6 systems. For instance there is no /etc/pki-tomcat directory in RHEL6, and I cannot find the ipa.crt Im sure as a noob I am overlooking some very obvious stuff, but could you please guide me on what to do? Sorry, I think I pointed you at the wrong page. Check out http://www.freeipa.org/page/IPA_2x_Certificate_Renewal Your CA subsystem are expired, or nearly expired. They are valid for two years. Based on the request ID in the snippet you posted at least some are valid for another few days. What I'd suggest is to send the machine back in time and restart the services. This should bring things up so that certmonger can do the renewal: # ipactl stop # /sbin/service ntpd stop # date 0501hhm where hhmm are the current hour and minute # ipactl start Hopefully ntpd isn't started by ipactl. If it is then it will undo your going back in time, and you'll need to start the services manually: # service dirsrv@YOURREALM start # service krb5kdc # service httpd start # service pki-tomcatd start Restart certmonger # service certmonger restart Wait a bit # getcert list Watch the status. They should go to MODIFIED Once done: # ipactl stop Return date to present, either by restarting ntpd or date or whatever method you'd like. I'm taking a completely wild guess on the date to go back to. The expiration date is listed in the getcert output. I'd go back a week before the oldest expiration. rob -- 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] certmonger + dogtag, bad parsing of returned certificate
On Tue, May 19, 2015 at 12:34:47PM +0200, marcin kowalski wrote: Hi, all. I am trying to integrate certmonger with dogtag instance, and so far i've stumbled on one odd problem. Hopefully this is the right list. I've generated some random cert with getcert request, it has communicated with dogtag, and i approved it there. However, when certmonger retrieves it, it cannot save it to disk ( NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) Upon inspection of certmonger's request file (in /var/lib/certmonger/requests ), it turns out that there is an extra empty line before end certificate marker line. There is no such line when looking at the cert in dogtag web interface. Is there some method/hook i could use to post process such request files to fix them up? There's no hook for doing that with the data files themselves, because they're meant to be internal details of the implementation, but the data coming back from the enrollment helper, which is what's malformed to begin with, can be corrected at the point when the helper is run. Essentially, you'd replace the configured call to dogtag-submit with a script or other program that checked $CERTMONGER_OPERATION for the values SUBMIT and POLL, ran the dogtag-submit helper, filtered its output to fix this mistake, and returned the helper's exit status to keep things in line with the daemon's expectations. Though, if you're running something older than 0.77, please give 0.77.4 (currently in testing for Fedora 20 and 21) or a development snapshot (from the ipa-devel repo) a try. The 0.77 release had a lot of its parsing reworked as part of adding support for SCEP reply formats, which I think fixed this. The development snapshots add more authentication options to the generic Dogtag helper which you may also want, depending on the enrollment profile you're using. HTH, Nalin -- 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] getting rid of nsds5ReplConflict
On 05/19/2015 10:10 AM, Megan . wrote: I'm struggling with a replication conflict. I had three masters, dir1, dir2, dir3. There were some weird issues with dir2 where I was getting error 49 (Invalid credentials) without any real information. Where did you see this? command line output? Of what command? In a log file? Which log file? Can you post the exact error message along with the context? When i did ipa-replica-manage list-ruv i saw dir2 twice. Can you post the output? I couldn't get it straight What does get it straight mean? Does it mean you ran some commands? If so, what commands did you run and what was the result? so i decided to try to re-create the replica. I disconnected the replica, ran the del for the replica. When i check for replication conflicts i still see it in there and I can't seem to get it to go away. Deleting and recreating the replica will not remove the replication conflict if the conflict has been replicated to other servers. This document doesn't say anything about resolving replica conflict entries by deleting and re-adding replicas: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html It only shows up on one of the remaining masters. I was trying to follow the documentation The link above? and use ldapmodify to change the dn to cn=olddir2.somewhere.example.something.com7475d90c but everything i seem to be trying doesn't work. What exactly did you do? I'm assuming this entry needs to be cleared up before i can successfully setup dir2 again as a replica. No, not necessarily. Any help would be greatly appreciated. Thanks! [root@dir1 ~]# ldapsearch -x -D cn=directory manager -W -b dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict=* \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=somewhere,dc=example,dc=something,dc=com with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # dir2.somewhere.example.something.com + 7475d90c-f34911e4-99a0ab24-58022cdf, masters , ipa, etc, somewhere.example.something.com dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict: namingConflict cn=dir2.somewhere.example.something.com,cn=masters,c n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com objectClass: top objectClass: nsContainer cn: dir2.somewhere.example.something.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- 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] getting rid of nsds5ReplConflict
Thank you for the reply. I think I just got frustrated. I uninstalled ipa on the dir2 replica then set it back up again as a replica. Everything seems to be replicating just fine without errors now. I know that this isn't the preferred or documented solution but i needed the server back online asap. When i run ipa-replica-manage list-ruv i see dir2 listed twice. Is this a concern? [root@dir1 ipa]# ipa-replica-manage list-ruv dir1.example.com:389: 4 dir3.example.com:389: 5 dir2.example.com:389: 6 dir2.example.com:389: 8 On Tue, May 19, 2015 at 12:37 PM, Rich Megginson rmegg...@redhat.com wrote: On 05/19/2015 10:10 AM, Megan . wrote: I'm struggling with a replication conflict. I had three masters, dir1, dir2, dir3. There were some weird issues with dir2 where I was getting error 49 (Invalid credentials) without any real information. Where did you see this? command line output? Of what command? In a log file? Which log file? Can you post the exact error message along with the context? When i did ipa-replica-manage list-ruv i saw dir2 twice. Can you post the output? I couldn't get it straight What does get it straight mean? Does it mean you ran some commands? If so, what commands did you run and what was the result? so i decided to try to re-create the replica. I disconnected the replica, ran the del for the replica. When i check for replication conflicts i still see it in there and I can't seem to get it to go away. Deleting and recreating the replica will not remove the replication conflict if the conflict has been replicated to other servers. This document doesn't say anything about resolving replica conflict entries by deleting and re-adding replicas: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html It only shows up on one of the remaining masters. I was trying to follow the documentation The link above? and use ldapmodify to change the dn to cn=olddir2.somewhere.example.something.com7475d90c but everything i seem to be trying doesn't work. What exactly did you do? I'm assuming this entry needs to be cleared up before i can successfully setup dir2 again as a replica. No, not necessarily. Any help would be greatly appreciated. Thanks! [root@dir1 ~]# ldapsearch -x -D cn=directory manager -W -b dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict=* \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=somewhere,dc=example,dc=something,dc=com with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # dir2.somewhere.example.something.com + 7475d90c-f34911e4-99a0ab24-58022cdf, masters , ipa, etc, somewhere.example.something.com dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict: namingConflict cn=dir2.somewhere.example.something.com,cn=masters,c n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com objectClass: top objectClass: nsContainer cn: dir2.somewhere.example.something.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- 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] getting rid of nsds5ReplConflict
On 05/19/2015 12:27 PM, Megan . wrote: Thank you for the reply. I think I just got frustrated. I uninstalled ipa on the dir2 replica then set it back up again as a replica. Everything seems to be replicating just fine without errors now. I know that this isn't the preferred or documented solution but i needed the server back online asap. When i run ipa-replica-manage list-ruv i see dir2 listed twice. Is this a concern? No. When you get a chance, you can remove the one that is no longer used with the documented clean ruv procedure. I believe there is an ipa command for that. [root@dir1 ipa]# ipa-replica-manage list-ruv dir1.example.com:389: 4 dir3.example.com:389: 5 dir2.example.com:389: 6 dir2.example.com:389: 8 On Tue, May 19, 2015 at 12:37 PM, Rich Megginson rmegg...@redhat.com wrote: On 05/19/2015 10:10 AM, Megan . wrote: I'm struggling with a replication conflict. I had three masters, dir1, dir2, dir3. There were some weird issues with dir2 where I was getting error 49 (Invalid credentials) without any real information. Where did you see this? command line output? Of what command? In a log file? Which log file? Can you post the exact error message along with the context? When i did ipa-replica-manage list-ruv i saw dir2 twice. Can you post the output? I couldn't get it straight What does get it straight mean? Does it mean you ran some commands? If so, what commands did you run and what was the result? so i decided to try to re-create the replica. I disconnected the replica, ran the del for the replica. When i check for replication conflicts i still see it in there and I can't seem to get it to go away. Deleting and recreating the replica will not remove the replication conflict if the conflict has been replicated to other servers. This document doesn't say anything about resolving replica conflict entries by deleting and re-adding replicas: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html It only shows up on one of the remaining masters. I was trying to follow the documentation The link above? and use ldapmodify to change the dn to cn=olddir2.somewhere.example.something.com7475d90c but everything i seem to be trying doesn't work. What exactly did you do? I'm assuming this entry needs to be cleared up before i can successfully setup dir2 again as a replica. No, not necessarily. Any help would be greatly appreciated. Thanks! [root@dir1 ~]# ldapsearch -x -D cn=directory manager -W -b dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict=* \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=somewhere,dc=example,dc=something,dc=com with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # dir2.somewhere.example.something.com + 7475d90c-f34911e4-99a0ab24-58022cdf, masters , ipa, etc, somewhere.example.something.com dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict: namingConflict cn=dir2.somewhere.example.something.com,cn=masters,c n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com objectClass: top objectClass: nsContainer cn: dir2.somewhere.example.something.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- 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] confused by ldapsearch results
Boyce, George Robert. (GSFC-762.0)[NICS] wrote: I don’t understand what is happening… If I use a compound OR filter to search for “cn” or “uid”, I only get back the match for uid. I expect to get both. If I add a search for a nonexistent attribute like “name”, I get nothing back. I expect to get back the entry matched by the other term. # l (cn=gboyce) dn dn: cn=gboyce,cn=groups,cn=accounts,dc=… # l (uid=gboyce) dn dn: uid=gboyce,cn=users,cn=accounts,dc=… # l (|(uid=gboyce)(cn=gboyce)) dn dn: uid=gboyce,cn=users,cn=accounts,dc=… # l (|(cn=gboyce)(uid=gboyce)) dn dn: uid=gboyce,cn=users,cn=accounts,dc=… # l (|(uid=gboyce)(name=gboyce)) dn # This is on a new deployment of ipa on centos, with just a couple of test records. I don’t have much recent experience with LDAP, but I don’t see what I’m doing wrong. Dirsrv on centos 6.5 works as expected. You don't get a separate entry back for each part of the filter that matches. If it matches on any one of the OR elements you get it back, otherwise you don't. In other words, for this type of search you're likely to get either one or zero entries back. I don't see why adding a non-existent attribute in the filter would cause it to do anything odd. That part of the filter should be a no-op. This worked for me: $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm (|(uid=admin)(name=admin)) dn SASL/GSSAPI authentication started SASL username: ad...@example.com SASL SSF: 56 SASL data security layer installed. dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com Note that cn is Common Name which is set to the user's full name, in this case likely George Boyce. So that will never match gboyce. rob -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Hi Rob Thanks! I noticed that the problematic records have their expiration in the future! And I also do not have pki-tomcatd, it's pki-cad. From getcert list, the troublesome IDs are: Request ID '20130524104828': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MYDOM-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:32 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104917': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes On Tue, May 19, 2015 at 4:25 PM, Rob Crittenden rcrit...@redhat.com wrote: Sina Owolabi wrote: Hi Rob Ive been to the URL but its a little difficult applying these commands to RHEL6 systems. For instance there is no /etc/pki-tomcat directory in RHEL6, and I cannot find the ipa.crt Im sure as a noob I am overlooking some very obvious stuff, but could you please guide me on what to do? Sorry, I think I pointed you at the wrong page. Check out http://www.freeipa.org/page/IPA_2x_Certificate_Renewal Your CA subsystem are expired, or nearly expired. They are valid for two years. Based on the request ID in the snippet you posted at least some are valid for another few days. What I'd suggest is to send the machine back in time and restart the services. This should bring things up so that certmonger can do the renewal: # ipactl stop # /sbin/service ntpd stop # date 0501hhm where hhmm are the current hour and minute # ipactl start Hopefully ntpd isn't started by ipactl. If it is then it will undo your going back in time, and you'll need to start the services manually: # service dirsrv@YOURREALM start # service krb5kdc # service httpd start # service pki-tomcatd start Restart certmonger # service certmonger restart Wait a bit # getcert list Watch the status. They should go to MODIFIED Once done: # ipactl stop Return date to present, either by restarting ntpd or date or whatever method you'd like. I'm taking a completely wild guess on the date to go back to. The expiration date is listed in the getcert output. I'd go back a week before the oldest expiration. rob -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Another key difference I noticed is that the problematic certs have CA:IPA in them, while the working certs have CA: dogtag-ipa-retrieve-agent-submit. getcert list Number of certificates and requests being tracked: 8. Request ID '20130524104636': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25 10:12:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104731': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=CA Audit,O=MYDOM.COM expires: 2015-04-29 23:48:46 UTC key usage: digitalSignature,nonRepudiation pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104732': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=OCSP Subsystem,O=MYDOM.COM expires: 2015-04-29 23:48:45 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104733': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=CA Subsystem,O=MYDOM.COM expires: 2015-04-29 23:48:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104734': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='386562502473' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2017-04-06 09:41:48 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130524104828': status: CA_UNREACHABLE ca-error: Server at https://dc.mydom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.mydom.com:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MYDOM-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MYDOM-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOM.COM subject: CN=dc.mydom.com,O=MYDOM.COM expires: 2015-05-25
Re: [Freeipa-users] getting rid of nsds5ReplConflict
Megan . wrote: Thank you for the reply. I think I just got frustrated. I uninstalled ipa on the dir2 replica then set it back up again as a replica. Everything seems to be replicating just fine without errors now. I know that this isn't the preferred or documented solution but i needed the server back online asap. When i run ipa-replica-manage list-ruv i see dir2 listed twice. Is this a concern? [root@dir1 ipa]# ipa-replica-manage list-ruv dir1.example.com:389: 4 dir3.example.com:389: 5 dir2.example.com:389: 6 dir2.example.com:389: 8 You should clean it up using the clean-ruv option of ipa-replica-manage. You should bind as Directory Manager and look in cn=mapping tree,cn=config for nsDS5ReplicaId you'll be able to see the active IDs. I'd guess that 6 is the one to be removed but a search will tell you for sure. rob -- 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] confused by ldapsearch results
On 05/19/2015 01:53 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: I don’t understand what is happening… If I use a compound OR filter to search for “cn” or “uid”, I only get back the match for uid. I expect to get both. If I add a search for a nonexistent attribute like “name”, I get nothing back. I expect to get back the entry matched by the other term. # l (cn=gboyce) dn dn: cn=gboyce,cn=groups,cn=accounts,dc=… # l (uid=gboyce) dn dn: uid=gboyce,cn=users,cn=accounts,dc=… # l (|(uid=gboyce)(cn=gboyce)) dn dn: uid=gboyce,cn=users,cn=accounts,dc=… # l (|(cn=gboyce)(uid=gboyce)) dn dn: uid=gboyce,cn=users,cn=accounts,dc=… # l (|(uid=gboyce)(name=gboyce)) dn # Does this give an error message or does ldapsearch exit with a non-zero value? Can you check the dirsrv access log to see what is the result of this operation? This is on a new deployment of ipa on centos, with just a couple of test records. I don’t have much recent experience with LDAP, but I don’t see what I’m doing wrong. Dirsrv on centos 6.5 works as expected. # ipa --version VERSION: 4.1.0, API_VERSION: 2.112 # cat /etc/centos-release CentOS Linux release 7.1.1503 (Core) George Boyce, SAIC/NICS GCC Systems Support NASA GSFC Code 762 -- 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] confused by ldapsearch results
I don't understand what is happening... If I use a compound OR filter to search for cn or uid, I only get back the match for uid. I expect to get both. If I add a search for a nonexistent attribute like name, I get nothing back. I expect to get back the entry matched by the other term. # l (cn=gboyce) dn dn: cn=gboyce,cn=groups,cn=accounts,dc=... # l (uid=gboyce) dn dn: uid=gboyce,cn=users,cn=accounts,dc=... # l (|(uid=gboyce)(cn=gboyce)) dn dn: uid=gboyce,cn=users,cn=accounts,dc=... # l (|(cn=gboyce)(uid=gboyce)) dn dn: uid=gboyce,cn=users,cn=accounts,dc=... # l (|(uid=gboyce)(name=gboyce)) dn # This is on a new deployment of ipa on centos, with just a couple of test records. I don't have much recent experience with LDAP, but I don't see what I'm doing wrong. Dirsrv on centos 6.5 works as expected. # ipa --version VERSION: 4.1.0, API_VERSION: 2.112 # cat /etc/centos-release CentOS Linux release 7.1.1503 (Core) George Boyce, SAIC/NICS GCC Systems Support NASA GSFC Code 762 -- 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] External Self Help Suggestions.
On 05/14/2015 07:09 PM, William Graboyes wrote: Hi Dmitri, No I am sticking to the 90 day, gotta start the change in the right direction somewhere :). So I am trying out LBT Self service password, and I am wondering if there is documentation anywhere on how to create a service style account that has the ability to change a password without forcing the user to reset thier password on next login. This would be for if a user forgets thier password and uses a mail token style auth. Sorry for a delay I know there is a way to create such an account. It is not exposed in the UI Here is the ticket to do it in UI/CLI https://fedorahosted.org/freeipa/ticket/2801 But I do not remember the procedure of top of my head. It might be found in the archives as it was explained couple times in the past. Thanks, Bill On 5/13/15 5:28 PM, Dmitri Pal wrote: On 05/13/2015 08:18 PM, William Graboyes wrote: Hi Dmitri, That is quite a bucket of stuff... On the CA-less install, basically I don't want to have my users change their passwords again (they are complaining about the every 90 day password rotation policy), we do not have an internal CA, most of our desk top support folks don't even have access to all of the desktops in the place. Like I said this place is mind bending when it comes to standard practices. The CA-less would be good if it were possible to make that change in place, or make the change by standing up a new IPA server and having the ability to import the current data set. I was looking at PWM, and may try to get that implemented. Another option is to reset expiration time in the user entry and set it some date close to 2038 which is the end of the 32-bit time. If the problem is 90 day policy you can just change the policy to be 5000 days and then next time people change password they would not be bother for another 5000 days or so (make sure it does not roll over). For people that already have 90 days in their entry you can run a script once and move the date into the future. People have done it for the same reason and in the same way. Thanks, Bill On 5/13/15 5:00 PM, Dmitri Pal wrote: On 05/13/2015 07:40 PM, William Graboyes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi List, I am trying to figure out a method of allowing users who do not have shell access to change their own passwords. The GUI that comes with FreeIPA is out of the question due to the untrusted CA (yes I know we are a strange shop, there is nothing I can do about it, and you would want to gouge you eyes out if I told you the full story) becoming a Bad habit forming method of changing one's password. I have been looking around for about a week now, and am somewhat lost and perplexed. The old documentation for FreeIPA basically says that it is not a good idea to manipulate the password directly in LDAP (and even then finding what hash is being used has been next to impossible). So the question is this, does anyone know of any tools out there that can happily, or even with some modification, allow me to set up a trusted external ssl site that allows users to change their passwords. There is no external password reset self service in IPA yet. We will be starting to look into this effort during summer. Take a look at the bucket of tickets in the FreeIPA Community Portal Release here https://fedorahosted.org/freeipa/report/3. What prevents you from making IPA trusted? You can chain IPA to your CA or use it CA-less with certs from your own CA. Then UI would be an option I assume. Other option is https://code.google.com/p/pwm/ Thanks, Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX kzyr3+tqYdDbgibcYyhd =5KCr -END PGP SIGNATURE- -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- 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] Replacing HTTP certs with public CA signed wildcard cert
On 05/14/2015 10:15 AM, David Little wrote: Hi there, I was reading this document regarding using 3rd party certificates in FreeIPA: https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP Which includes the information The certificate in mysite.crt must be signed by the CA used when installing FreeIPA. Also this thread: http://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html Which says at the end I'm wondering if it's because of this from the doc The certificate in mysite.crt must be signed by the CA used when installing FreeIPA. but it might not either... In this case you should get a file.p12 is not signed by /etc/ipa/ca.crt, or the full certificate chain is not present in the PKCS#12 file error in ipa-server-certinstall. This brings me to my question... If I have an existing multi-server FreeIPA setup with multiple IPA client installations, using a self-signed CA certificate for /etc/ipa/ca.crt, would I need to start over the FreeIPA installation from scratch using the public root CA, which signed the wildcard certificate? Thanks, Dave Did you get an answer? If not starting 4.1 IPA has a tool that can change the chaining and also convert from CA-less to CA-full. I am not sure it can do the reverse so you might in fact have to start over. http://www.freeipa.org/page/V4/CA-less_to_CA-full_conversion -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- 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] getting rid of nsds5ReplConflict
I'm struggling with a replication conflict. I had three masters, dir1, dir2, dir3. There were some weird issues with dir2 where I was getting error 49 (Invalid credentials) without any real information. When i did ipa-replica-manage list-ruv i saw dir2 twice. I couldn't get it straight so i decided to try to re-create the replica. I disconnected the replica, ran the del for the replica. When i check for replication conflicts i still see it in there and I can't seem to get it to go away. It only shows up on one of the remaining masters. I was trying to follow the documentation and use ldapmodify to change the dn to cn=olddir2.somewhere.example.something.com7475d90c but everything i seem to be trying doesn't work. I'm assuming this entry needs to be cleared up before i can successfully setup dir2 again as a replica. Any help would be greatly appreciated. Thanks! [root@dir1 ~]# ldapsearch -x -D cn=directory manager -W -b dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict=* \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=somewhere,dc=example,dc=something,dc=com with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # dir2.somewhere.example.something.com + 7475d90c-f34911e4-99a0ab24-58022cdf, masters , ipa, etc, somewhere.example.something.com dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict: namingConflict cn=dir2.somewhere.example.something.com,cn=masters,c n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com objectClass: top objectClass: nsContainer cn: dir2.somewhere.example.something.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- 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
