Re: [Freeipa-users] Kerberos hanging
>> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The >> problem manifests itself as no authentication, and no DNS. >> It seems Kerberos just stops responding to requests and requests just >> get queued up # netstat -tuna | grep SYN_RECV Active Internet >> connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address >> State >> tcp0 0 :88 > IP>:55440 SYN_RECV >> tcp0 0 :88 > IP>:40076SYN_RECV >> >> Looking at /var/log/krb5kdc.log >> The normal activity of AS_REQ and TGS_REC messages just stops. No error >> messages. Just no new messages. >The problem isn't in Kerberos or DNS, ns-slapd is hanging. See this, >http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs >rob Thanks for that. I've taken a look at the stacktrace of out ns-slapd for our realm. But the stacktrace doesn't give very much. Just lots of "no debugging symbols found" and "No symbol table info available" it seems. In the list of threads there are lots of calls to functions but again "No symbol table info available." Nothing jumps out. Similarly in the access log, while there is a lot of activity nothing is obviously wrong. I didn't change the log buffering for very long, due to the predicted performance issues and did not catch it when it was faulty. For some reason, apart from once last evening the issue seems to have gone away now.. Terry Cox Automotive group of companies within the UK comprises: Cox Automotive UK Limited (registered number: 03183918), Manheim Limited (registered number: 00448761), Cox Automotive Retail Solutions Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time Communications Limited (registered number: 04277845). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group of companies within the UK operates under various brand/trading names including Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime and Closeit. V:0CF72C13B2AD -- 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] Kerberos hanging
Thanks for that. I have an issue with NTP but I have got around that and spent many a happy hour updating the times on my clients. The errors were in /var/log/krb5kdc.log as "clock skew too great". It's only when I got rid of them, and there were many, could I clearly see the normal operation Terry John >Check time an date on all involved servers/workstations - if the difference is >more than 300 seconds , Kerberos might not work correctly. Apply the same time >to all involved >servers/workstations. >Gerald >> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The >> problem manifests itself as no authentication, and no DNS. >> It seems Kerberos just stops responding to requests and requests just >> get queued up # netstat -tuna | grep SYN_RECV Active Internet >> connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address >> State >> tcp0 0 :88 > IP>:55440 SYN_RECV >> tcp0 0 :88 > IP>:40076SYN_RECV >> tcp0 0 :88 > IP>:41525SYN_RECV >> tcp0 0 :88 > IP>:53958 SYN_RECV >> tcp0 0 :88 > IP>:54240 SYN_RECV >> Looking at /var/log/krb5kdc.log >> The normal activity of AS_REQ and TGS_REC messages just stops. No error >> messages. Just no new messages. >> In /var/log/messages the named server reports messages like Mar 1 >> 00:00:23 freeipa named[18989]: LDAP error: Can't contact LDAP server >> Mar 1 00:00:23 freeipa named[18989]: connection to the LDAP server >> was lost Mar 1 00:00:23 freeipa named[18989]: bind to LDAP server >> failed: Can't contact LDAP server >> The command "kinit" is totally unresponsive and will time out if you wait >> long enough. >> If I try to restart ipa with "service ipa restart", it hangs on the first >> stage, trying to stop DIRSRV. >> I have to do a "ps ax" and look for this line. >> 2758 ?Sl 2:13 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MY-REALM >> -i /var/run/dirsrv/slapd-MY-REALM.pid -w >> /var/run/dirsrv/slapd-MY-REALM.startpid >> Then I have to a "kill -9" on the pid >> Then I can do "service ipa restart" >> After that it works ok for a while. "A while" may be a few minutes or >> several hours. >> The filesystem is only 58% used and "free" shows no swap in use so there >> seems to be plenty of RAM available. >> "top" shows CPU(s) 96% idle with "dirsirv" typically using about 3%CPU at >> most Cox Automotive group of companies within the UK comprises: Cox Automotive UK Limited (registered number: 03183918), Manheim Limited (registered number: 00448761), Cox Automotive Retail Solutions Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time Communications Limited (registered number: 04277845). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group of companies within the UK operates under various brand/trading names including Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime and Closeit. V:0CF72C13B2AD -- 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] Kerberos hanging
I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The problem manifests itself as no authentication, and no DNS. It seems Kerberos just stops responding to requests and requests just get queued up # netstat -tuna | grep SYN_RECV Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 :88 :55440 SYN_RECV tcp0 0 :88 :40076SYN_RECV tcp0 0 :88 :41525SYN_RECV tcp0 0 :88 :53958 SYN_RECV tcp0 0 :88 :54240 SYN_RECV Looking at /var/log/krb5kdc.log The normal activity of AS_REQ and TGS_REC messages just stops. No error messages. Just no new messages. In /var/log/messages the named server reports messages like Mar 1 00:00:23 freeipa named[18989]: LDAP error: Can't contact LDAP server Mar 1 00:00:23 freeipa named[18989]: connection to the LDAP server was lost Mar 1 00:00:23 freeipa named[18989]: bind to LDAP server failed: Can't contact LDAP server The command "kinit" is totally unresponsive and will time out if you wait long enough. If I try to restart ipa with "service ipa restart", it hangs on the first stage, trying to stop DIRSRV. I have to do a "ps ax" and look for this line. 2758 ?Sl 2:13 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MY-REALM -i /var/run/dirsrv/slapd-MY-REALM.pid -w /var/run/dirsrv/slapd-MY-REALM.startpid Then I have to a "kill -9" on the pid Then I can do "service ipa restart" After that it works ok for a while. "A while" may be a few minutes or several hours. The filesystem is only 58% used and "free" shows no swap in use so there seems to be plenty of RAM available. "top" shows CPU(s) 96% idle with "dirsirv" typically using about 3%CPU at most I've no idea why this keeps happening, everything looks ok then it just stops Terry John System Administrator- Cox Automotive Software E: terry.j...@coxauto.co.uk Cox Automotive group of companies within the UK comprises: Cox Automotive UK Limited (registered number: 03183918), Manheim Limited (registered number: 00448761), Cox Automotive Retail Solutions Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time Communications Limited (registered number: 04277845). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group of companies within the UK operates under various brand/trading names including Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime and Closeit. V:0CF72C13B2AD -- 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] Announcing SSSD 1.13.4
>>I am plagued by the "sssd dereference processing failed : Input/output error" >>problem. Is there any news when this version of sssd will be released for >>RedHat/Centos? >If you are interested in testing of sssd-1.13.4 then you can test >upstream(backported from fedora) version in copr. >https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/ Ok thanks I'll see if I can give it a try Terry The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] Announcing SSSD 1.13.4
I am plagued by the "sssd dereference processing failed : Input/output error" problem. Is there any news when this version of sssd will be released for RedHat/Centos? My current version is: 1.12.4-47.el6 Terry -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: 14 April 2016 16:17 To: sssd-de...@lists.fedorahosted.org; sssd-us...@lists.fedorahosted.org; freeipa-users@redhat.com; freeipa-inter...@redhat.com Subject: [Freeipa-users] Announcing SSSD 1.13.4 == SSSD 1.13.4 === The SSSD team is proud to announce the release of version 1.13.4 of the System Security Services Daemon. As always, the source is available from https://fedorahosted.org/sssd RPM packages will be made available for Fedora shortly. == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * The IPA sudo provider was reimplemented. The new version reads the data from IPA's LDAP tree (as opposed to the compat tree populated by the slapi-nis plugin that was used previously). The benefit is that deployments which don't require the compat tree for other purposes, such as support for non-SSSD clients can disable those autogenerated LDAP trees to conserve resources that slapi-nis otherwise requires. There should be no visible changes to the end user. * SSSD now has the ability to renew the machine credentials (keytabs) when the ad provider is used. Please note that a recent version of the adcli (0.8 or newer) package is required for this feature to work. * The automatic ID mapping feature was improved so that the administrator is no longer required to manually set the range size in case a RID in the AD domain is larger than the default range size * A potential infinite loop in the NFS ID mapping plugin that was resulting in an excessive memory usage was fixed * Clients that are pinned to a particular AD site using the ad_site option no longer communicate with DCs outside that site during service discovery. * The IPA identity provider is now able to resolve external (typically coming from a trusted AD forest) group members during get-group-information requests. Please note that resolving external group memberships for AD users during the initgroup requests used to work even prior to this update. This feature is mostly useful for cases where an IPA client is using the compat tree to resolve AD trust users. * The IPA ID views feature now works correctly even for deployments without a trust relationship. Previously, the subdomains IPA provider failed to read the views data if no master domain record was created on the IPA server during trust establishment. * A race condition in the client libraries between the SSSD closing the socket as idle and the client application using the socket was fixed. This bug manifested with a Broken Pipe error message on the client. * SSSD is now able to resolve users with the same usernames in different OUs of an AD domain * The smartcard authentication now works properly with gnome-screensaver == Packaging Changes == * The krb5.include.d directory is now owned by the sssd user and packaged in the krb5-common subpackage == Documentation Changes == * A new option ldap_idmap_helper_table_size was added. This option can help tune allocation of new ID mapping slices for AD domains with a high RID values. Most deployments can use the default value of this option. * Several PAM services were added to the lists that are used to map Windows logon services to Linux PAM services. The newly added PAM services include login managers (lightdm, lxdm, sddm and xdm) as well as the cockpit service. * The AD machine credentials renewal task can be fine-tuned using the ad_machine_account_password_renewal_opts to change the initial delay and period of the credentials renewal task. In addition, the new ad_maximum_machine_account_password_age option allows the administrator to select how old the machine credential must be before trying to renew it. * The administrator can use the new option pam_account_locked_message to set a custom informational message when the account logging in is locked. == Tickets Fixed == https://fedorahosted.org/sssd/ticket/1041 [RFE] Support Automatic Renewing of Kerberos Host Keytabs https://fedorahosted.org/sssd/ticket/1108 [RFE] SUDO: Support the IPA schema https://fedorahosted.org/sssd/ticket/2188 automatically assign new slices for any AD domain https://fedorahosted.org/sssd/ticket/2522 [RFE] IPA:
Re: [Freeipa-users] 14: No supported authentication methods available
Thanks for that. From what I've read there is no simple right answer. In 2013 RedHat itself says to leave ChallengeResponseAuthentication set to no "due to security reasons". https://access.redhat.com/solutions/336773 Setting PasswordAuthentication yes seems to leave all the other settings within thee sshd_config file like "PermitRootLogin without-password" which may be overridden elsewhere if ChallengeResponseAuthentication is set to yes Terry -Original Message- From: Simo Sorce [mailto:s...@redhat.com] Sent: 25 February 2016 15:01 To: Terry John Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] 14: No supported authentication methods available On Thu, 2016-02-25 at 14:36 +, Terry John wrote: > This turned out to be a setting in /etc/ssh/sshd_config which gets > overridden by ipa-client-install. Needed to un-comment > > PasswordAuthentication yes This is disabled because we enable ChallengeResponseAuthentication which is a superset of PasswordAuthentication. PasswordAuthentication can't deal with PAM prompts, it is a oneshot only option (ie fails if PAM asks you to make a pasword change), while ChallengeResponseAuthentication is the more modern method that properly deals with PAM prompts. You should prefer ChallengeResponseAuthentication over PasswordAuthentication. HTH, Simo. > Terry > > From: freeipa-users-boun...@redhat.com > [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Terry John > Sent: 18 February 2016 11:41 > To: freeipa-users@redhat.com > Subject: [Freeipa-users] 14: No supported authentication methods > available > > I have an AWS instance running Centos 6.7 correctly configured for freeipa > but I needed to make a backup machine which would remain live. > > I created a clone of the machine and changed the host name and the settings > in /etc/hosts. When I tried to run ipa-client-install it told me to run the > uninstall which I did. This had the worrying effect of not being able to log > into my original live server but thankfully after a while it came good. I > don't know why. > > Back on the new server I ran 'ipa-client-install --enable-dns-updates > -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI > and I added it to the same host group as the original server. But when I try > to log in via SSH I get the error 'No supported authentication methods > available'. I do have root access via the AWS Key file. > > As far as I can tell all the relevant settings seem the same between the two > servers but one works and the other doesn't. I can kinit and klist using my > freeipa account. 'getent netgroup my-servergroup' works fine. > > I can't seem to find anything relevant in the sssd logs and > /var/log/secure just give me the same error of no supported > authentication methods available > > I have noticed in /var/log/messages when I restart sssd and error > which may be relevant but can't find anything useful so far > > sssd[be[my.domain.net]]: dereference processing failed : Input/output > error > > Thanks > > Terry > > > > The Manheim group of companies within the UK comprises: Manheim Europe > Limited (registered number: 03183918), Manheim Auctions Limited (registered > number: 00448761), Manheim Retail Services Limited (registered number: > 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time > Communications Limited (registered number: 04277845) and Complete Automotive > Solutions Limited (registered number: 05302535). Each of these companies is > registered in England and Wales with the registered office address of Central > House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies > operates under various brand/trading names including Manheim Inspection > Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim > Aftersales Solutions. > > V:0CF72C13B2AC > > > -- > 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 -- Simo Sorce * Red Hat, Inc * New York -- 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] 14: No supported authentication methods available
This turned out to be a setting in /etc/ssh/sshd_config which gets overridden by ipa-client-install. Needed to un-comment PasswordAuthentication yes Terry From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Terry John Sent: 18 February 2016 11:41 To: freeipa-users@redhat.com Subject: [Freeipa-users] 14: No supported authentication methods available I have an AWS instance running Centos 6.7 correctly configured for freeipa but I needed to make a backup machine which would remain live. I created a clone of the machine and changed the host name and the settings in /etc/hosts. When I tried to run ipa-client-install it told me to run the uninstall which I did. This had the worrying effect of not being able to log into my original live server but thankfully after a while it came good. I don't know why. Back on the new server I ran 'ipa-client-install --enable-dns-updates -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI and I added it to the same host group as the original server. But when I try to log in via SSH I get the error 'No supported authentication methods available'. I do have root access via the AWS Key file. As far as I can tell all the relevant settings seem the same between the two servers but one works and the other doesn't. I can kinit and klist using my freeipa account. 'getent netgroup my-servergroup' works fine. I can't seem to find anything relevant in the sssd logs and /var/log/secure just give me the same error of no supported authentication methods available I have noticed in /var/log/messages when I restart sssd and error which may be relevant but can't find anything useful so far sssd[be[my.domain.net]]: dereference processing failed : Input/output error Thanks Terry The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] 14: No supported authentication methods available
I have an AWS instance running Centos 6.7 correctly configured for freeipa but I needed to make a backup machine which would remain live. I created a clone of the machine and changed the host name and the settings in /etc/hosts. When I tried to run ipa-client-install it told me to run the uninstall which I did. This had the worrying effect of not being able to log into my original live server but thankfully after a while it came good. I don't know why. Back on the new server I ran 'ipa-client-install --enable-dns-updates -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI and I added it to the same host group as the original server. But when I try to log in via SSH I get the error 'No supported authentication methods available'. I do have root access via the AWS Key file. As far as I can tell all the relevant settings seem the same between the two servers but one works and the other doesn't. I can kinit and klist using my freeipa account. 'getent netgroup my-servergroup' works fine. I can't seem to find anything relevant in the sssd logs and /var/log/secure just give me the same error of no supported authentication methods available I have noticed in /var/log/messages when I restart sssd and error which may be relevant but can't find anything useful so far sssd[be[my.domain.net]]: dereference processing failed : Input/output error Thanks Terry The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] FREAK Vulnerability
Ok thanks for that but I've had to give up, our freeipa server is too critical to our business for me to continue even with outages of one or two minutes. The Ciphers below were not recognised and when I just tried to remove the export ciphers from the original list I got this error (Netscape Portable Runtime error -12266 - An unknown SSL cipher suite has been requested.) A type or a fundamental problem I don't know. I am working in an AWS environment and have tried making a clone and working on that but freeipa just gets confused and stops. I suppose another alternative is to build a freeipa server from scratch and work on that. Seems an awful lot of work to remove one cipher :-( terry -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: 28 January 2016 14:35 To: Terry John; Marat Vyshegorodtsev; freeipa-users@redhat.com Subject: Re: [Freeipa-users] FREAK Vulnerability Terry John wrote: > I'm really confused now. After the problem where my feeipa server would not > start and I had to use the backup I'm trying to do things in small steps. > > Listening to everything that has been said (thanks) I edited > slapd-/dse.ldif slapd-PKI-IPA/dse.ldif and changed the lines > > nsSSL3Ciphers: > to > nsSSL3Ciphers:+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_g > cm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ > ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_ > 128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes > _128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_25 > 6_sha > (There is a space after the colon) > > Then I did a 'service ip restart' and when I looked the dse.ldif files had > reverted back to their original settings.. > > Where am I going wrong? dse.ldif is written out when the server shuts down so any changes you make to it while 389-ds is running are lost. rob > > Terry > > > -Original Message- > From: Rob Crittenden [mailto:rcrit...@redhat.com] > Sent: 28 January 2016 04:49 > To: Marat Vyshegorodtsev; Terry John; freeipa-users@redhat.com > Subject: Re: [Freeipa-users] FREAK Vulnerability > > Marat Vyshegorodtsev wrote: >> My two cents: >> >> My "magic" string for NSS is like this (I had to move to Fedora 23 >> from CentOS in order to get more recent NSS version though): >> >> NSSProtocol TLSv1.2 >> NSSCipherSuite >> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_ae >> s >> _128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecds >> a >> _aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha_2 >> 5 >> 6,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ecds >> a >> _aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256 > > The -All is a syntax error (ignored). All ciphers are disabled by default > anyway. > > I'd suggest using the ticket already referenced as a starting point. > > /usr/lib[64]/nss/unsupported-tools/listsuites is also handy to see what is > enabled by default in NSS (though again, everything is disabled by mod_nss at > startup). > > rob > >> >> My cert is ECDSA private CA though. If you are interested, I can give >> you my chef recipe snippets to configure it. >> >> On Thu, Jan 28, 2016 at 11:02 AM, Marat Vyshegorodtsev >> <marat.vyshegorodt...@gmail.com> wrote: >>> My two cents: >>> >>> My "magic" string for NSS is like this (I had to move to Fedora 23 >>> from CentOS in order to get more recent NSS version though): >>> >>> NSSProtocol TLSv1.2 >>> NSSCipherSuite >>> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_a >>> e >>> s_128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ec >>> d >>> sa_aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sh >>> a >>> _256,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ >>> e >>> cdsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256 >>> >>> My cert is ECDSA private CA though. If you are interested, I can >>> give you my chef recipe snippets to configure it. >>> >>> Marat >>> >>> On Fri, Jan 22, 2016 at 1:54 AM, Terry John >>> <terry.j...@completeautomotivesolutions.co.uk> wrote: >>>>>> I've been trying to tidy the security on my FreeIPA and this is >>>>>> causing me some problems. I'm using OpenVAS vulnerability scanner >>>>>> and it is coming up with this issue >>>>>> >>>&
Re: [Freeipa-users] FREAK Vulnerability
I'm really confused now. After the problem where my feeipa server would not start and I had to use the backup I'm trying to do things in small steps. Listening to everything that has been said (thanks) I edited slapd-/dse.ldif slapd-PKI-IPA/dse.ldif and changed the lines nsSSL3Ciphers: to nsSSL3Ciphers:+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha (There is a space after the colon) Then I did a 'service ip restart' and when I looked the dse.ldif files had reverted back to their original settings.. Where am I going wrong? Terry -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: 28 January 2016 04:49 To: Marat Vyshegorodtsev; Terry John; freeipa-users@redhat.com Subject: Re: [Freeipa-users] FREAK Vulnerability Marat Vyshegorodtsev wrote: > My two cents: > > My "magic" string for NSS is like this (I had to move to Fedora 23 > from CentOS in order to get more recent NSS version though): > > NSSProtocol TLSv1.2 > NSSCipherSuite > -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_aes > _128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa > _aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha_25 > 6,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ecdsa > _aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256 The -All is a syntax error (ignored). All ciphers are disabled by default anyway. I'd suggest using the ticket already referenced as a starting point. /usr/lib[64]/nss/unsupported-tools/listsuites is also handy to see what is enabled by default in NSS (though again, everything is disabled by mod_nss at startup). rob > > My cert is ECDSA private CA though. If you are interested, I can give > you my chef recipe snippets to configure it. > > On Thu, Jan 28, 2016 at 11:02 AM, Marat Vyshegorodtsev > <marat.vyshegorodt...@gmail.com> wrote: >> My two cents: >> >> My "magic" string for NSS is like this (I had to move to Fedora 23 >> from CentOS in order to get more recent NSS version though): >> >> NSSProtocol TLSv1.2 >> NSSCipherSuite >> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_ae >> s_128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecd >> sa_aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha >> _256,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_e >> cdsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256 >> >> My cert is ECDSA private CA though. If you are interested, I can give >> you my chef recipe snippets to configure it. >> >> Marat >> >> On Fri, Jan 22, 2016 at 1:54 AM, Terry John >> <terry.j...@completeautomotivesolutions.co.uk> wrote: >>>>> I've been trying to tidy the security on my FreeIPA and this is >>>>> causing me some problems. I'm using OpenVAS vulnerability scanner >>>>> and it is coming up with this issue >>>>> >>>>> EXPORT_RSA cipher suites supported by the remote server: >>>>> TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006) >>>>> TLSv1.0: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0003) >>>>> >>>>> It seems we have to disable export TLS ciphers but I can't see how. I've >>>>> edited /etc/httpd/conf.d/nss.conf and disabled all SSL and TLSV1.0. >>>> >>>>> NSSCipherSuite -all,-exp,+ >>>>> >>>>> I've restarted httpd and ipa but it still fails >>>>> >>>>> Is there something I have overlooked >>> >>> >>>> Hi Terry, >>>> >>>> Please check >>>> https://fedorahosted.org/freeipa/ticket/5589 >>>> >>>> We are trying to come up with a better cipher suite right now. The fix >>>> should be in some of the next FreeIPA 4.3.x versions. >>>> >>>> The ticket has more details in it. >>> >>> Thanks for the info. I have tried nearly all the NSSCipherSuite settings in >>> that ticket but none so far has eliminated the FREAK report. >>> Christian thanks for the heads up on the syntax, I wasn't sure of >>> what I was doing >>> >>> Each time I've made a change I've run an sslscan from the OpenVAS scanner >>> and I do get a different result each time but the errors still remains in &g
Re: [Freeipa-users] FREAK Vulnerability
Thanks for this. I've had a look today We are running: ipa-server.x86_64 3.0.0-47.el6.centos and some of the directives did not work, namely allowWeakCipher, sslVersionMin and sslVersionMax . So I commented them out The ldapupdater then seems happy but when I went to restart IPA. The ldap server wasn't happy with cipher TLS_RSA_WITH_AES_256_CBC_SHA256 and would not start. Now I can't change anything and it doesn't work. Reaching for my backup. Terry -Original Message- From: Christian Heimes [mailto:chei...@redhat.com] Sent: 22 January 2016 10:03 To: Terry John; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] FREAK Vulnerability On 2016-01-21 17:54, Terry John wrote: > Thanks for the info. I have tried nearly all the NSSCipherSuite settings in > that ticket but none so far has eliminated the FREAK report. > Christian thanks for the heads up on the syntax, I wasn't sure of what > I was doing > > Each time I've made a change I've run an sslscan from the OpenVAS scanner and > I do get a different result each time but the errors still remains in OpenVAS. > Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd. > > Back to the drawing board :-) Hi Terry, you can give the attached file a try. It's a ldif file for ipa-ldap-updater. You need to run the command on the machine as root and restart 389-DS. The hardened TLS configuration is highly experimental and comes with no warranty whatsoever. The configuration works on my tests systems with Python's ldap client and Apache Directory Studio. It may not work with other clients, especially older clients or clients in FIPS mode. Christian The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] FREAK Vulnerability
I've been trying to tidy the security on my FreeIPA and this is causing me some problems. I'm using OpenVAS vulnerability scanner and it is coming up with this issue EXPORT_RSA cipher suites supported by the remote server: TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006) TLSv1.0: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0003) It seems we have to disable export TLS ciphers but I can't see how. I've edited /etc/httpd/conf.d/nss.conf and disabled all SSL and TLSV1.0. I've got NSSCipherSuite -all,-exp,+ I've restarted httpd and ipa but it still fails Is there something I have overlooked Thanks, Terry The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] FREAK Vulnerability
>> I've been trying to tidy the security on my FreeIPA and this is >> causing me some problems. I'm using OpenVAS vulnerability scanner and >> it is coming up with this issue >> >> EXPORT_RSA cipher suites supported by the remote server: >> TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006) >> TLSv1.0: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0003) >> >> It seems we have to disable export TLS ciphers but I can't see how. I've >> edited /etc/httpd/conf.d/nss.conf and disabled all SSL and TLSV1.0. > >> NSSCipherSuite -all,-exp,+ >> >> I've restarted httpd and ipa but it still fails >> >> Is there something I have overlooked >Hi Terry, > >Please check >https://fedorahosted.org/freeipa/ticket/5589 > >We are trying to come up with a better cipher suite right now. The fix should >be in some of the next FreeIPA 4.3.x versions. > >The ticket has more details in it. Thanks for the info. I have tried nearly all the NSSCipherSuite settings in that ticket but none so far has eliminated the FREAK report. Christian thanks for the heads up on the syntax, I wasn't sure of what I was doing Each time I've made a change I've run an sslscan from the OpenVAS scanner and I do get a different result each time but the errors still remains in OpenVAS. Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd. Back to the drawing board :-) The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] Unable to communicate with CMS (Service Unavailable)
>On Thu, Nov 12, 2015 at 08:55:25PM +0100, Martin Kosek wrote: >> On 11/12/2015 04:51 PM, Terry John wrote: >> > >> >I got a core dump of certmonger failing user abrt but it's huge. Is there >> >any particular part that would be useful. >> >> CCing Nalin and David for the core dump. More below. >My initial guess is that it's the same as the one reported in bug #1260871. >There's a fix for a problem that might be the cause in 0.77.6 and 0.78.5. If >you can try a 0.77.6 build from the COPR system >[1], it'll help us figure out >if we've correctly identified the cause, or if the problem you're running into >is a different one. >Nalin >[1] https://copr.fedoraproject.org/coprs/nalin/certmonger/build/139854/ I'm not sure updating certmonger would help us in this case. The problem was that the CMS service was not running which was a Java version issue. The Java installation in /usr/java/default/bin was version 1.6. Currently certmonger is and everything else is running fine. # yum list installed certmonger Installed Packages certmonger.x86_64 0.77.5-1.el6 @base # service certmonger status certmonger (pid 2288) is running... # ls -l /usr/java/default/bin/java lrwxrwxrwx. 1 root root 22 Nov 13 14:14 /usr/java/default/bin/java -> /etc/alternatives/java # ls -l /etc/alternatives/java lrwxrwxrwx. 1 root root 46 Nov 13 14:13 /etc/alternatives/java -> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] Unable to communicate with CMS (Service Unavailable)
I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. My current version of ipa-server is 3.0.0-47 Certmonger crashes with a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. If I stop ipa the start certmonger it starts ok and continues to run when I start ipa again but as soon as any requests are made like "getcert list" then it crashes again. With certmonger still running I can do a request # ipa cert-status Request id: 20140417164153 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Unavailable) # service certmonger status certmonger (pid 3030) is running... This fault with the "Service Unavailable" originally came up when I tried to delete a host from the freeip gui In the file /var/log/dirsrv/slapd-PKI-IPA/errors file there was a Warning about nsslapd-cachememsize not being big enough but I don't know how to change it if, indeed this is anything to do with it. Any pointers of where to look next would be much appreciated. The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -- 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] Unable to communicate with CMS (Service Unavailable)
I got a core dump of certmonger failing user abrt but it's huge. Is there any
particular part that would be useful.
On 11/12/2015 02:17 PM, Terry John wrote:
>> I had a working freeipa setup on a CentOS release 6.7 machine. All was well
>> until I did a yum update. Now I have multiple issue apparently based around
>> the CMS (Service Unavailable) issue.
>> My current version of ipa-server is 3.0.0-47
>> Certmonger crashes with a segmentation fault at boot time and crashes every
>> time I try to restart it when ipa is running.
>It of course should not crash, it would be useful to have a backtrace from the
>core file that was generated.
Here is the backtrace of the core file:
{ "signal": 11
, "executable": "/usr/sbin/certmonger"
, "stacktrace":
[ { "crash_thread": true
, "frames":
[ { "address": 140527158519285
, "build_id": "87a19a61dc011579f3e25de3ca9778c6fd9e4547"
, "build_id_offset": 1222133
, "function_name": "__strstr_sse42"
, "file_name": "/lib64/libc.so.6"
}
, { "address": 140527209363149
, "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3"
, "build_id_offset": 141005
, "file_name": "/usr/sbin/certmonger"
}
, { "address": 140527209301676
, "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3"
, "build_id_offset": 79532
, "file_name": "/usr/sbin/certmonger"
}
, { "address": 140527209287550
, "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3"
, "build_id_offset": 65406
, "file_name": "/usr/sbin/certmonger"
}
, { "address": 140527209291166
, "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3"
, "build_id_offset": 69022
, "file_name": "/usr/sbin/certmonger"
}
, { "address": 140527196303038
, "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11"
, "build_id_offset": 36542
, "file_name": "/usr/lib64/libtevent.so.0"
}
, { "address": 140527196295910
, "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11"
, "build_id_offset": 29414
, "file_name": "/usr/lib64/libtevent.so.0"
}
, { "address": 140527196279965
, "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11"
, "build_id_offset": 13469
, "function_name": "_tevent_loop_once"
, "file_name": "/usr/lib64/libtevent.so.0"
}
, { "address": 140527209278079
, "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3"
, "build_id_offset": 55935
, "function_name": "main"
, "file_name": "/usr/sbin/certmonger"
} ]
} ]
}
In /var/log/messages I get
freeipasvr kernel: certmonger[2611] general protection ip:7fb487fed5f5
sp:7ffd9df46898 error:0 in libc-2.12.so[7fb487ec3000+18a000]
This is the first error I get in /var/log/httpd/error_log when I try to delete
a host
[error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to
communicate with CMS (Service Unavailable)
>> If I stop ipa the start certmonger it starts ok and continues to run when I
>> start ipa again but as soon as any requests are made like "getcert list"
>> then it crashes again.
>> With certmonger still running I can do a request
>
>> # ipa cert-status
> >Request id: 20140417164153
> >ipa: ERROR: Certificate operation cannot be completed: Unable to
>> communicate with CMS (Service Unavailable) # service certmonger status
> >certmonger (pid 3030) is running...
>It looks like PKI cannot be contacted. I would recommend checking
>/var/log/httpd/error_log, it may have more details. I would also recommend
>checking "ipa cert-show 1", it will pr
