Re: [Freeipa-users] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain"

2016-01-29 Thread Rob Crittenden 
Harald Dunkel wrote:
> Hi folks,
> 
> Problem: ipa-client-install fails with
> 
> # rm -f /etc/ipa/ca.crt
> # ipa-client-install
> Discovery was successful!
> Hostname: srvl023.ac.example.com
> Realm: EXAMPLE.COM
> DNS Domain: example.com
> IPA Server: ipa1.example.com
> BaseDN: dc=example,dc=com
> 
> Continue to configure the system with these values? [no]: yes
> Synchronizing time with KDC...
> Unable to sync time with IPA NTP server, assuming the time is in sync. Please 
> check that 123 UDP port is opened.
> User authorized to enroll computers: admin
> Password for ad...@example.com:
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=example AG,C=COM
> Issuer:  CN=example Root CA,OU=example Certificate 
> Authority,O=example AG,C=COM
> Valid From:  Mon Dec 28 10:35:30 2015 UTC
> Valid Until: Mon Dec 31 23:59:59 2035 UTC
> 
> Joining realm failed: libcurl failed to execute the HTTP POST transaction, 
> explaining:  SSL certificate problem: self signed certificate in certificate 
> chain
> 
> Installation failed. Rolling back changes.
> IPA client is not configured on this system.
> 
> 
> ???
> Is this the chain sent from the ipa server to the new host?
> 
> Every helpful idea would be highly appreciated.
>

What version of server and client?

I gather you have installed with an external CA? How many certs are in
/etc/ipa/ca.crt?

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] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

2016-01-29 Thread Christian Heimes 
On 2016-01-29 13:03, Roderick Johnstone wrote:
> On 29/01/16 10:31, Christian Heimes wrote:
>> On 2016-01-28 19:56, Roderick Johnstone wrote:
>>> On 28/01/16 13:39, Christian Heimes wrote:
 On 2016-01-28 13:51, Roderick Johnstone wrote:
> Hi
>
> My netapp filer is happily doing ldap over ssl lookups for account
> information to my RHEL 6.7 testing ipa server
> (ipa-server-3.0.0-47.el6_7.1.x86_64).
>
> However, when I switch the filer to use my RHEL 7.2 ipa server
> (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work.
>
> In the dirsrv log file I see entries like this:
>
> [28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection
> from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy
> [28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot
> communicate securely with peer: no common encryption algorithm(s).
>
> (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the
> ipa
> server ip address).
>
> Looking in the ldap directory for fields with cipher in the name
> shows a
> very different set of nssslenabledciphers between the two ipa-server
> versions.
>
> I wonder if this might be the issue?
>
> Can the ldap server tell me what ciphers its being requested to use by
> the filer?

 Yes, it looks like it is the issue. The supported cipher suites were
 hardened a while ago. The ticket
 https://fedorahosted.org/freeipa/ticket/4395 contains more information.

 During the TLS handshake the client sends a list of supported cipher
 suites to the server. The server also has a list of supported cipher
 suites. But the server never sends this list to the client. Instead it
 picks one common cipher suite (usually the most secure) from the common
 set of cipher suites.

 I don't know if you can get 389 DS to print the cipher suites. But you
 can snoop the ciper suites from the TLS handshake with wireshark or
 tshark. The handshake isnt't encrypted and can be captures on either
 the
 host or the server.

 # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port
 ldaps

 Christian

>>>
>>> Thanks Christian. Thats really helpful.
>>>
>>> Now I have a list of ciphers being asked for and I found that the ldap
>>> server logs which ciphers its using when it starts up file
>>> /var/log/dirsrv/slapd-/error. There isn't any overlap.
>>>
>>> I noticed that there is a setting in the
>>> dn: cn=encryption,cn=config
>>> allowWeakCipher: off
>>>
>>> and
>>> nsSSL3Ciphers: +all
>>>
>>> and found some documentation on this here:
>>> http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html
>>>
>>>
>>> So, maybe I could add one (or several) of the required ciphers to
>>> nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on?
>>
>> Hi Roderick,
>>
>> I highly recommend against lowering the settings. Weak ciphers are
>> broken and insecure ciphers, some even with NULL encryption or no
>> authentication. At best weak ciphers may (!) protect your against a
>> passive sniffer and incompetent attacker. They won't protect you against
>> a serious attack.
>>
>> Are you able to reconfigure or update the client? Does the client even
>> speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3?
>>
>> If you show me the complete handshake, I can give you further advice.
>> The handshake output of tshark starts like this:
>>
>> Secure Sockets Layer
>>SSL Record Layer: Handshake Protocol: Client Hello
>>  Content Type: Handshake (22)
>>  Version: TLS 1.0 (0x0301)
>>
>> Christian
>>
>>
> 
> Christian
> 
> I don't think we have much control over the available client ciphers. We
> are running the latest Data OnTap version for our natapps so we have
> what we have. The netapp can do TLSv1 though.
> 
> We do have firewalling on the ipa servers so that will help until one of
> our trusted networks is compromised!
> 
> I'll send you the handshake output from tshark off list.

Hi Roderick,

thanks for the handshake. It looks like the application initiates a
SSLv2 handshake and then does a protocol upgrade to TLS 1.0. This alone
makes the connection vulnerable to a man-in-the-middle attacks. You
should disable SSLv2 and SSLv3 on the client app ASAP. The broken
versions must be disabled on both sides.

The cipher suite list is horrible, too. You don't want anything with
SSL2, RC2, RC4, DES, DSS, DHE, MD5 or EXPORT in its name.
TLS_RSA_WITH_3DES_EDE_CBC_SHA is the only cipher suite that is remotely
good. 3DES is slow but not entirely broken as RC4. TLS/SSL in CBC mode
has issues with padding, because TLS does MAC-then-encrypt.

Christian



signature.asc
Description: OpenPGP digital signature
-- 
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

[Freeipa-users] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain"

2016-01-29 Thread Harald Dunkel 
Hi folks,

Problem: ipa-client-install fails with

# rm -f /etc/ipa/ca.crt
# ipa-client-install
Discovery was successful!
Hostname: srvl023.ac.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: ipa1.example.com
BaseDN: dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync. Please 
check that 123 UDP port is opened.
User authorized to enroll computers: admin
Password for ad...@example.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=example AG,C=COM
Issuer:  CN=example Root CA,OU=example Certificate Authority,O=example 
AG,C=COM
Valid From:  Mon Dec 28 10:35:30 2015 UTC
Valid Until: Mon Dec 31 23:59:59 2035 UTC

Joining realm failed: libcurl failed to execute the HTTP POST transaction, 
explaining:  SSL certificate problem: self signed certificate in certificate 
chain

Installation failed. Rolling back changes.
IPA client is not configured on this system.


???
Is this the chain sent from the ipa server to the new host?

Every helpful idea would be highly appreciated.


Regards
Harri

-- 
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] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

2016-01-29 Thread Christian Heimes 
On 2016-01-28 19:56, Roderick Johnstone wrote:
> On 28/01/16 13:39, Christian Heimes wrote:
>> On 2016-01-28 13:51, Roderick Johnstone wrote:
>>> Hi
>>>
>>> My netapp filer is happily doing ldap over ssl lookups for account
>>> information to my RHEL 6.7 testing ipa server
>>> (ipa-server-3.0.0-47.el6_7.1.x86_64).
>>>
>>> However, when I switch the filer to use my RHEL 7.2 ipa server
>>> (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work.
>>>
>>> In the dirsrv log file I see entries like this:
>>>
>>> [28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection
>>> from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy
>>> [28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot
>>> communicate securely with peer: no common encryption algorithm(s).
>>>
>>> (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the ipa
>>> server ip address).
>>>
>>> Looking in the ldap directory for fields with cipher in the name shows a
>>> very different set of nssslenabledciphers between the two ipa-server
>>> versions.
>>>
>>> I wonder if this might be the issue?
>>>
>>> Can the ldap server tell me what ciphers its being requested to use by
>>> the filer?
>>
>> Yes, it looks like it is the issue. The supported cipher suites were
>> hardened a while ago. The ticket
>> https://fedorahosted.org/freeipa/ticket/4395 contains more information.
>>
>> During the TLS handshake the client sends a list of supported cipher
>> suites to the server. The server also has a list of supported cipher
>> suites. But the server never sends this list to the client. Instead it
>> picks one common cipher suite (usually the most secure) from the common
>> set of cipher suites.
>>
>> I don't know if you can get 389 DS to print the cipher suites. But you
>> can snoop the ciper suites from the TLS handshake with wireshark or
>> tshark. The handshake isnt't encrypted and can be captures on either the
>> host or the server.
>>
>> # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port
>> ldaps
>>
>> Christian
>>
> 
> Thanks Christian. Thats really helpful.
> 
> Now I have a list of ciphers being asked for and I found that the ldap
> server logs which ciphers its using when it starts up file
> /var/log/dirsrv/slapd-/error. There isn't any overlap.
> 
> I noticed that there is a setting in the
> dn: cn=encryption,cn=config
> allowWeakCipher: off
> 
> and
> nsSSL3Ciphers: +all
> 
> and found some documentation on this here:
> http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html
> 
> So, maybe I could add one (or several) of the required ciphers to
> nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on?

Hi Roderick,

I highly recommend against lowering the settings. Weak ciphers are
broken and insecure ciphers, some even with NULL encryption or no
authentication. At best weak ciphers may (!) protect your against a
passive sniffer and incompetent attacker. They won't protect you against
a serious attack.

Are you able to reconfigure or update the client? Does the client even
speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3?

If you show me the complete handshake, I can give you further advice.
The handshake output of tshark starts like this:

Secure Sockets Layer
  SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)

Christian




signature.asc
Description: OpenPGP digital signature
-- 
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] SSSD Crash Causing Inaccessibility

2016-01-29 Thread Lukas Slebodnik 
On (28/01/16 18:37), Jeff Hallyburton wrote:
>Application logs showed this to be due to an OOM error, so no need to chase
>this further.  Thanks for the quick response!
>
Even though it was OOM.
I would still be interested in version of sssd.
"access after free error" is bed error.

Do you have a coredump. It might be stored
by abrt or systemd-coredumpd (coredumpctl)

LS

-- 
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] Server error with multiple clients joining domain simultaneously

2016-01-29 Thread Petr Spacek 
Interesting, we have to investigate it!

Here is a ticket:
https://fedorahosted.org/freeipa/ticket/5653

You can Cc yourself to it and watch the progress.

Petr^2 Spacek

On 28.1.2016 20:17, David Zabner wrote:
> I was guessing that it was a problem with mod_auth_gssapi and so I tried 
> switching the auth method back to mod_auth_kerb which did not work. (although 
> it is entirely possible that I did not switch it correctly)
> 
> I did it by changing the gssapi settings in /etc/httpd/conf.d/ipa.conf to:
> 
>   AuthType Kerberos
>   AuthName "Kerberos Login"
>   KrbMethodNegotiate on
>   KrbMethodK5Passwd off
>   KrbServiceName HTTP
>   KrbAuthRealms $realm
>   Krb5KeyTab /etc/httpd/conf/ipa.keytab
>   KrbSaveCredentials on
>   KrbConstrainedDelegation on
>   Require valid-user
>   ErrorDocument 401 /ipa/errors/unauthorized.html
> 
> It just seemed to cause other problems...
> 
> On Jan 28, 2016, at 1:44 PM, Izzo, Anthony 
> > wrote:
> 
> I should add that some of my team members have tried serializing their 
> instance launches, and this problem does not seem to occur under those 
> circumstances.  (That’s not a solution, just a data point for those 
> interested in this behavior).  Thanks.
> 
> 
> From: Izzo, Anthony (U.S. Person)
> Sent: Thursday, January 28, 2016 1:35 PM
> To: freeipa-users@redhat.com
> Cc: 'David Zabner' >
> Subject: RE: [Freeipa-users] Server error with multiple clients joining 
> domain simultaneously
> 
> Yes, that’s it!
> 
> From: David Zabner [mailto:da...@cazena.com]
> Sent: Thursday, January 28, 2016 1:31 PM
> To: Izzo, Anthony (U.S. Person) 
> >
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Server error with multiple clients joining 
> domain simultaneously
> 
> This sounds exactly like the problem I am having. I will attach my error log. 
> Is this what yours looks like?
> --
> 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
> 
> 
> 


-- 
Petr^2 Spacek

-- 
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] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

2016-01-29 Thread Roderick Johnstone 

On 29/01/16 10:31, Christian Heimes wrote:

On 2016-01-28 19:56, Roderick Johnstone wrote:

On 28/01/16 13:39, Christian Heimes wrote:

On 2016-01-28 13:51, Roderick Johnstone wrote:

Hi

My netapp filer is happily doing ldap over ssl lookups for account
information to my RHEL 6.7 testing ipa server
(ipa-server-3.0.0-47.el6_7.1.x86_64).

However, when I switch the filer to use my RHEL 7.2 ipa server
(ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work.

In the dirsrv log file I see entries like this:

[28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection
from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy
[28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot
communicate securely with peer: no common encryption algorithm(s).

(xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the ipa
server ip address).

Looking in the ldap directory for fields with cipher in the name shows a
very different set of nssslenabledciphers between the two ipa-server
versions.

I wonder if this might be the issue?

Can the ldap server tell me what ciphers its being requested to use by
the filer?


Yes, it looks like it is the issue. The supported cipher suites were
hardened a while ago. The ticket
https://fedorahosted.org/freeipa/ticket/4395 contains more information.

During the TLS handshake the client sends a list of supported cipher
suites to the server. The server also has a list of supported cipher
suites. But the server never sends this list to the client. Instead it
picks one common cipher suite (usually the most secure) from the common
set of cipher suites.

I don't know if you can get 389 DS to print the cipher suites. But you
can snoop the ciper suites from the TLS handshake with wireshark or
tshark. The handshake isnt't encrypted and can be captures on either the
host or the server.

# tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port
ldaps

Christian



Thanks Christian. Thats really helpful.

Now I have a list of ciphers being asked for and I found that the ldap
server logs which ciphers its using when it starts up file
/var/log/dirsrv/slapd-/error. There isn't any overlap.

I noticed that there is a setting in the
dn: cn=encryption,cn=config
allowWeakCipher: off

and
nsSSL3Ciphers: +all

and found some documentation on this here:
http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html

So, maybe I could add one (or several) of the required ciphers to
nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on?


Hi Roderick,

I highly recommend against lowering the settings. Weak ciphers are
broken and insecure ciphers, some even with NULL encryption or no
authentication. At best weak ciphers may (!) protect your against a
passive sniffer and incompetent attacker. They won't protect you against
a serious attack.

Are you able to reconfigure or update the client? Does the client even
speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3?

If you show me the complete handshake, I can give you further advice.
The handshake output of tshark starts like this:

Secure Sockets Layer
   SSL Record Layer: Handshake Protocol: Client Hello
 Content Type: Handshake (22)
 Version: TLS 1.0 (0x0301)

Christian




Christian

I don't think we have much control over the available client ciphers. We 
are running the latest Data OnTap version for our natapps so we have 
what we have. The netapp can do TLSv1 though.


We do have firewalling on the ipa servers so that will help until one of 
our trusted networks is compromised!


I'll send you the handshake output from tshark off list.

Thanks

Roderick

--
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] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

2016-01-29 Thread Roderick Johnstone 

On 29/01/16 12:27, Christian Heimes wrote:

On 2016-01-29 13:03, Roderick Johnstone wrote:

On 29/01/16 10:31, Christian Heimes wrote:

On 2016-01-28 19:56, Roderick Johnstone wrote:

On 28/01/16 13:39, Christian Heimes wrote:

On 2016-01-28 13:51, Roderick Johnstone wrote:

Hi

My netapp filer is happily doing ldap over ssl lookups for account
information to my RHEL 6.7 testing ipa server
(ipa-server-3.0.0-47.el6_7.1.x86_64).

However, when I switch the filer to use my RHEL 7.2 ipa server
(ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work.

In the dirsrv log file I see entries like this:

[28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection
from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy
[28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot
communicate securely with peer: no common encryption algorithm(s).

(xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the
ipa
server ip address).

Looking in the ldap directory for fields with cipher in the name
shows a
very different set of nssslenabledciphers between the two ipa-server
versions.

I wonder if this might be the issue?

Can the ldap server tell me what ciphers its being requested to use by
the filer?


Yes, it looks like it is the issue. The supported cipher suites were
hardened a while ago. The ticket
https://fedorahosted.org/freeipa/ticket/4395 contains more information.

During the TLS handshake the client sends a list of supported cipher
suites to the server. The server also has a list of supported cipher
suites. But the server never sends this list to the client. Instead it
picks one common cipher suite (usually the most secure) from the common
set of cipher suites.

I don't know if you can get 389 DS to print the cipher suites. But you
can snoop the ciper suites from the TLS handshake with wireshark or
tshark. The handshake isnt't encrypted and can be captures on either
the
host or the server.

# tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port
ldaps

Christian



Thanks Christian. Thats really helpful.

Now I have a list of ciphers being asked for and I found that the ldap
server logs which ciphers its using when it starts up file
/var/log/dirsrv/slapd-/error. There isn't any overlap.

I noticed that there is a setting in the
dn: cn=encryption,cn=config
allowWeakCipher: off

and
nsSSL3Ciphers: +all

and found some documentation on this here:
http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html


So, maybe I could add one (or several) of the required ciphers to
nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on?


Hi Roderick,

I highly recommend against lowering the settings. Weak ciphers are
broken and insecure ciphers, some even with NULL encryption or no
authentication. At best weak ciphers may (!) protect your against a
passive sniffer and incompetent attacker. They won't protect you against
a serious attack.

Are you able to reconfigure or update the client? Does the client even
speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3?

If you show me the complete handshake, I can give you further advice.
The handshake output of tshark starts like this:

Secure Sockets Layer
SSL Record Layer: Handshake Protocol: Client Hello
  Content Type: Handshake (22)
  Version: TLS 1.0 (0x0301)

Christian




Christian

I don't think we have much control over the available client ciphers. We
are running the latest Data OnTap version for our natapps so we have
what we have. The netapp can do TLSv1 though.

We do have firewalling on the ipa servers so that will help until one of
our trusted networks is compromised!

I'll send you the handshake output from tshark off list.


Hi Roderick,

thanks for the handshake. It looks like the application initiates a
SSLv2 handshake and then does a protocol upgrade to TLS 1.0. This alone
makes the connection vulnerable to a man-in-the-middle attacks. You
should disable SSLv2 and SSLv3 on the client app ASAP. The broken
versions must be disabled on both sides.

The cipher suite list is horrible, too. You don't want anything with
SSL2, RC2, RC4, DES, DSS, DHE, MD5 or EXPORT in its name.
TLS_RSA_WITH_3DES_EDE_CBC_SHA is the only cipher suite that is remotely
good. 3DES is slow but not entirely broken as RC4. TLS/SSL in CBC mode
has issues with padding, because TLS does MAC-then-encrypt.

Christian



Hi Christian

Many thanks for the advice.

I might even open a call with netapp about this.

Will report back when I make some progress.

Roderick

--
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 process coredump | authentication fails

2016-01-29 Thread Prashant Bapat 
We will have to run with F21 for now. There are plans for moving to CentOS
7.x in the near future. Until then, I'm afraid I will have to live with
this.

Thanks much Sumit for all your help in identifying this.

Regards.
--Prashant​

On 28 January 2016 at 23:24, Sumit Bose  wrote:

> On Thu, Jan 28, 2016 at 09:36:55PM +0530, Prashant Bapat wrote:
> > Sure. Attached the stack trace with debuginfo installed.
> >
> > Thanks much!
>
> This looks very much like the issue Simo fixed recently, but
> unfortunately I think it is so recent that it is not available in any
> release package. Additionally it would be quite some effort for me the
> generate a F21 test build because as Lukas said F21 is already
> End-of-life and there is not infrastructure anymore to easily build F21
> package. If it would be possible to upgrade to a newer version of Fedora
> I'd be happy to provide a test build with the patch.
>
> bye,
> Sumit
>
> >
> > On 28 January 2016 at 16:53, Sumit Bose  wrote:
> >
> > > On Thu, Jan 28, 2016 at 04:42:20PM +0530, Prashant Bapat wrote:
> > > > gdb stacktrace attached.
> > >
> > > Can you install the debuginfo with
> > >
> > >  debuginfo-install krb5-server-1.12.2-19.fc21.x86_64
> > >
> > > as suggested by gdb and then call 'bt full' again to get more details.
> > > Additionally the debuginfo of the freeipa package might be missing as
> > > well.
> > >
> > > bye,
> > > Sumit
> > > >
> > > > On 28 January 2016 at 16:27, Prashant Bapat 
> wrote:
> > > >
> > > > > Thanks Sumit.
> > > > >
> > > > > From the logs there is nothing unusual around the time of core
> dump. I
> > > > > found this one line odd though.
> > > > >
> > > > > *Jan 26 03:15:58 ipa.example.net 
> > > > > krb5kdc[4471](Error): worker 4473 exited with status 134*
> > > > >
> > > > >
> > > > > Let me try to get the full BT.
> > > > >
> > > > > On 28 January 2016 at 13:54, Sumit Bose  wrote:
> > > > >
> > > > >> On Thu, Jan 28, 2016 at 10:25:53AM +0530, Prashant Bapat wrote:
> > > > >> > Hi,
> > > > >> >
> > > > >> > We have a FreeIPA 4.1.4 setup on F21 servers. There is 1 master
> and
> > > 7
> > > > >> > replicas in different regions. Earlier there was only 1 replica.
> > > Since I
> > > > >> > added new replicas, on the master node, once in a while the
> kerberos
> > > > >> > process dumps core and everything stops working -
> authentication,
> > > > >> > replication etc. If we restart everything using "ipactl restart"
> > > things
> > > > >> are
> > > > >> > back to normal.
> > > > >> >
> > > > >> > Attached is the output from journalctl for kerberos.
> > > > >> >
> > > > >> > Has anyone come across this ? Are there any pointers to
> > > troubleshooting
> > > > >> > this ?
> > > > >>
> > > > >> This might be fixed recently by a patch from Simo
> > > > >> (2144b1eeb789639b8a3df287b580aeb6196188a8). But to help to better
> > > > >> identify the issue the content of the kdc logs around the time of
> the
> > > > >> crash might be useful. Additionally a full backtrace which you
> can get
> > > > >> by calling
> > > > >>
> > > > >>   coredumpclt gdb 4475
> > > > >>
> > > > >> and then
> > > > >>
> > > > >>   bt full
> > > > >>
> > > > >> bye,
> > > > >> Sumit
> > > > >>
> > > > >> >
> > > > >> > Any help is appreciated.
> > > > >> >
> > > > >> > Thanks.
> > > > >> > --Prashant
> > > > >>
> > > > >> > Jan 26 03:15:59 ipa.example.net systemd-coredump[5000]: Process
> > > 4475
> > > > >> (krb5kdc) of user 0 dumped core.
> > > > >> >
> > > > >> >Stack
> trace
> > > of
> > > > >> thread 4475:
> > > > >> >#0
> > > > >> 0x7f99de8c18d7 raise (libc.so.6)
> > > > >> >#1
> > > > >> 0x7f99de8c353a abort (libc.so.6)
> > > > >> >#2
> > > > >> 0x7f99de8ba47d __assert_fail_base (libc.so.6)
> > > > >> >#3
> > > > >> 0x7f99de8ba532 __assert_fail (libc.so.6)
> > > > >> >#4
> > > > >> 0x7f99d783a78f ldap_get_values_len (libldap_r-2.4.so.2)
> > > > >> >#5
> > > > >> 0x7f99d7c8173e ipadb_ldap_attr_to_int (ipadb.so)
> > > > >> >#6
> > > > >> 0x7f99d7c83f9c ipadb_parse_ldap_entry (ipadb.so)
> > > > >> >#7
> > > > >> 0x7f99d7c849ab ipadb_get_principal (ipadb.so)
> > > > >> >#8
> > > > >> 0x7f99e0433b14 krb5_db_get_principal (libkdb5.so.7)
> > > > >> >#9
> > > > >> 0x55768457c230 process_tgs_req (krb5kdc)
> > > > >> >

Re: [Freeipa-users] Server error with multiple clients joining domain simultaneously

2016-01-29 Thread Rob Crittenden 
David Zabner wrote:
> Any guesses as to why I couldn’t revert to using the mod_auth_kerb library? 
> It seems like this is the only place where the library is referenced one way 
> or the other…
> 

You need to set this globally:

KrbConstrainedDelegationLock ipa

And I assume you replaced $realm with your actual realm, right?

It would also be useful to know how it doesn't work.

rob

> Thanks for all your help.
> 
>> On Jan 29, 2016, at 6:35 AM, Petr Spacek  wrote:
>>
>> Interesting, we have to investigate it!
>>
>> Here is a ticket:
>> https://fedorahosted.org/freeipa/ticket/5653
>>
>> You can Cc yourself to it and watch the progress.
>>
>> Petr^2 Spacek
>>
>> On 28.1.2016 20:17, David Zabner wrote:
>>> I was guessing that it was a problem with mod_auth_gssapi and so I tried 
>>> switching the auth method back to mod_auth_kerb which did not work. 
>>> (although it is entirely possible that I did not switch it correctly)
>>>
>>> I did it by changing the gssapi settings in /etc/httpd/conf.d/ipa.conf to:
>>> 
>>>  AuthType Kerberos
>>>  AuthName "Kerberos Login"
>>>  KrbMethodNegotiate on
>>>  KrbMethodK5Passwd off
>>>  KrbServiceName HTTP
>>>  KrbAuthRealms $realm
>>>  Krb5KeyTab /etc/httpd/conf/ipa.keytab
>>>  KrbSaveCredentials on
>>>  KrbConstrainedDelegation on
>>>  Require valid-user
>>>  ErrorDocument 401 /ipa/errors/unauthorized.html
>>> 
>>> It just seemed to cause other problems...
>>>
>>> On Jan 28, 2016, at 1:44 PM, Izzo, Anthony 
>>> > wrote:
>>>
>>> I should add that some of my team members have tried serializing their 
>>> instance launches, and this problem does not seem to occur under those 
>>> circumstances.  (That’s not a solution, just a data point for those 
>>> interested in this behavior).  Thanks.
>>>
>>>
>>> From: Izzo, Anthony (U.S. Person)
>>> Sent: Thursday, January 28, 2016 1:35 PM
>>> To: freeipa-users@redhat.com
>>> Cc: 'David Zabner' >
>>> Subject: RE: [Freeipa-users] Server error with multiple clients joining 
>>> domain simultaneously
>>>
>>> Yes, that’s it!
>>>
>>> From: David Zabner [mailto:da...@cazena.com]
>>> Sent: Thursday, January 28, 2016 1:31 PM
>>> To: Izzo, Anthony (U.S. Person) 
>>> >
>>> Cc: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] Server error with multiple clients joining 
>>> domain simultaneously
>>>
>>> This sounds exactly like the problem I am having. I will attach my error 
>>> log. Is this what yours looks like?
>>> --
>>> 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
>>>
>>>
>>>
>>
>>
>> -- 
>> Petr^2 Spacek
>>
>> -- 
>> 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] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain"

2016-01-29 Thread Harald Dunkel 
Hi Rob,

On 01/29/2016 04:12 PM, Rob Crittenden wrote:
> 
> What version of server and client?
> 

Server is freeipa 4.2 (Centos 7.2)

Client is freeipa 4.0.5 (Debian 8)

Sorry, I should have mentioned this in my first post.

I am running >200 clients in this environment, appr. 40% are
Debian Hosts with this freeipa version. One host cannot be
joined :-(.

> I gather you have installed with an external CA? How many certs are in
> /etc/ipa/ca.crt?
> 

Yes, its an external CA. There is one cert in ca.cert: It is
the certificate of the ipa CA, signed by the expected external
root CA. I see the same on the other hosts, but of course I
checked only a few (4).


Regards
Harri

-- 
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] Server error with multiple clients joining domain simultaneously

2016-01-29 Thread David Zabner 
Any guesses as to why I couldn’t revert to using the mod_auth_kerb library? It 
seems like this is the only place where the library is referenced one way or 
the other…

Thanks for all your help.

> On Jan 29, 2016, at 6:35 AM, Petr Spacek  wrote:
> 
> Interesting, we have to investigate it!
> 
> Here is a ticket:
> https://fedorahosted.org/freeipa/ticket/5653
> 
> You can Cc yourself to it and watch the progress.
> 
> Petr^2 Spacek
> 
> On 28.1.2016 20:17, David Zabner wrote:
>> I was guessing that it was a problem with mod_auth_gssapi and so I tried 
>> switching the auth method back to mod_auth_kerb which did not work. 
>> (although it is entirely possible that I did not switch it correctly)
>> 
>> I did it by changing the gssapi settings in /etc/httpd/conf.d/ipa.conf to:
>> 
>>  AuthType Kerberos
>>  AuthName "Kerberos Login"
>>  KrbMethodNegotiate on
>>  KrbMethodK5Passwd off
>>  KrbServiceName HTTP
>>  KrbAuthRealms $realm
>>  Krb5KeyTab /etc/httpd/conf/ipa.keytab
>>  KrbSaveCredentials on
>>  KrbConstrainedDelegation on
>>  Require valid-user
>>  ErrorDocument 401 /ipa/errors/unauthorized.html
>> 
>> It just seemed to cause other problems...
>> 
>> On Jan 28, 2016, at 1:44 PM, Izzo, Anthony 
>> > wrote:
>> 
>> I should add that some of my team members have tried serializing their 
>> instance launches, and this problem does not seem to occur under those 
>> circumstances.  (That’s not a solution, just a data point for those 
>> interested in this behavior).  Thanks.
>> 
>> 
>> From: Izzo, Anthony (U.S. Person)
>> Sent: Thursday, January 28, 2016 1:35 PM
>> To: freeipa-users@redhat.com
>> Cc: 'David Zabner' >
>> Subject: RE: [Freeipa-users] Server error with multiple clients joining 
>> domain simultaneously
>> 
>> Yes, that’s it!
>> 
>> From: David Zabner [mailto:da...@cazena.com]
>> Sent: Thursday, January 28, 2016 1:31 PM
>> To: Izzo, Anthony (U.S. Person) 
>> >
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] Server error with multiple clients joining 
>> domain simultaneously
>> 
>> This sounds exactly like the problem I am having. I will attach my error 
>> log. Is this what yours looks like?
>> --
>> 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
>> 
>> 
>> 
> 
> 
> -- 
> Petr^2 Spacek
> 
> -- 
> 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] Server error with multiple clients joining domain simultaneously

2016-01-29 Thread David Zabner 
Ok so I added the line "KrbConstrainedDelegationLock ipa” to ipa.conf (httpd 
configuration)


My error log is now full of network errors:

[Fri Jan 29 16:56:46.375490 2016] [:error] [pid 11772] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: host_add(u'postgres.foo.internal', 
random=False, force=True, no_reverse=False, all=False, raw=False, 
version=u'2.156', no_members=False): SUCCESS
[Fri Jan 29 16:57:37.823928 2016] [:error] [pid 11564] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_find(, 
None, idnsname=, structured=False, all=False, raw=False, 
version=u'2.156', pkey_only=False): SUCCESS
[Fri Jan 29 16:57:38.553971 2016] [:error] [pid 11566] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_add(, 
, arecord=(u'10.11.131.56',), a_extra_create_reverse=False, 
_extra_create_reverse=False, force=False, structured=False, all=False, 
raw=False, version=u'2.156'): SUCCESS
[Fri Jan 29 16:57:42.211016 2016] [:error] [pid 11563] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_find(, None, idnsname=, structured=False, 
all=False, raw=False, version=u'2.156', pkey_only=False): SUCCESS
[Fri Jan 29 16:57:42.963262 2016] [:error] [pid 11562] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_mod(, , ptrrecord=(u'sensu.foo.internal.',), 
rights=False, structured=False, all=False, raw=False, version=u'2.156'): SUCCESS
[Fri Jan 29 16:57:43.642293 2016] [:error] [pid 11565] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: host_find(None, 
fqdn=u'sensu.foo.internal', all=False, raw=False, version=u'2.156', 
no_members=False, pkey_only=False): SUCCESS
[Fri Jan 29 16:57:44.352675 2016] [:error] [pid 11772] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: host_add(u'sensu.foo.internal', 
random=False, force=True, no_reverse=False, all=False, raw=False, 
version=u'2.156', no_members=False): SUCCESS
[Fri Jan 29 17:08:21.855715 2016] [:error] [pid 11563] ipa: INFO: [xmlserver] 
admin@FOO.INTERNAL: join(u'ip-10-11-131-244.foo.internal', 
nshardwareplatform=u'x86_64', nsosversion=u'3.10.0-123.8.1.el7.x86_64', 
version=u'2.51'): SUCCESS
[Fri Jan 29 17:08:28.102555 2016] [:error] [pid 11562] ipa: INFO: 
[jsonserver_kerb] host/ip-10-11-131-244.foo.internal@FOO.INTERNAL: ping(): 
SUCCESS
[Fri Jan 29 17:08:28.150511 2016] [:error] [pid 11565] ipa: INFO: 
[jsonserver_kerb] host/ip-10-11-131-244.foo.internal@FOO.INTERNAL: 
ca_is_enabled(version=u'2.107'): SUCCESS
[Fri Jan 29 17:08:31.398500 2016] [:error] [pid 11772] ipa: INFO: 
[jsonserver_kerb] host/ip-10-11-131-244.foo.internal@FOO.INTERNAL: 
host_mod(u'ip-10-11-131-244.foo.internal', ipasshpubkey=(u'ssh-rsa 
B3NzaC1yc2EDAQABAAABAQDdg1ReyUGJo6nDvWgTZcRf3HaHft+1K5HGnT5Gqu1Zc0sqI7QzGWAkdRNDiPLzan29Y8UqtHt/EXEVNKoQSXdQogHMPIU9trZf/1jVWelK4bTqAlbRn9EDaN/CPdCnHLU34H6Zv5vYPM2maPBL/KqkaLkd6Kdyz0Giwtheh6ZEFcj7GcsB6ISljFixnuPMz8Ljjsyz+SE2DPU9eKarBrKof4YYykVwIckmqa+CnyysGVPjdb5+EwKPjndnq231ozoCKnoX4U/JyP6ysqZgTCPmHi36XKMvMgC/nZ1hOJlYZnDjv+jEFhiiT6Z/YGUUkqnFodkCYteTTWPDo6pvqWrv',
 u'ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBCNERA/2D3DtYISu5YdScCIQ6E2Uvc5A8QDDiMJGL/mJ+SXT4SBgq+ueXTyxBGushetdaBXtFwave4eetp4zYG0=',
 u'ssh-ed25519 
C3NzaC1lZDI1NTE5IPSvTYCp6Fj7JDEpjobXf5nsPiJILvkCbXGgCY1icM94'), 
updatedns=False, version=u'2.26'): SUCCESS
[Fri Jan 29 17:08:31.622190 2016] [:error] [pid 11564] ipa: INFO: [xmlserver] 
host/ip-10-11-131-244.foo.internal@FOO.INTERNAL: cert_request(u'STUFF', 
principal=u'host/ip-10-11-131-244.foo.internal@FOO.INTERNAL', add=True, 
version=u'2.51'): NetworkError
[Fri Jan 29 17:08:41.204307 2016] [:error] [pid 11566] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_find(, 
None, idnsname=, structured=False, all=False, raw=False, 
version=u'2.156', pkey_only=False): SUCCESS
[Fri Jan 29 17:08:41.922042 2016] [:error] [pid 11563] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_add(, 
, arecord=(u'10.11.131.244',), a_extra_create_reverse=False, 
_extra_create_reverse=False, force=False, structured=False, all=False, 
raw=False, version=u'2.156'): SUCCESS
[Fri Jan 29 17:08:44.983558 2016] [:error] [pid 11562] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_find(, None, idnsname=, structured=False, 
all=False, raw=False, version=u'2.156', pkey_only=False): SUCCESS
[Fri Jan 29 17:08:45.745427 2016] [:error] [pid 11565] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_add(, , a_extra_create_reverse=False, 
_extra_create_reverse=False, ptrrecord=(u'secgw.foo.internal.',), 
force=False, structured=False, all=False, raw=False, version=u'2.156'): SUCCESS
[Fri Jan 29 17:08:46.472084 2016] [:error] [pid 11772] ipa: INFO: 
[jsonserver_kerb] admin@FOO.INTERNAL: dnsrecord_find(, None, idnsname=, structured=False, 
all=False, raw=False, version=u'2.156', pkey_only=False): SUCCESS
[Fri Jan 29 17:08:47.120281 2016] [:error] [pid 11564] SSL Library Error: 
-12268 Cannot connect: SSL is disabled
[Fri Jan 29 17:08:47.801773 2016] [:error]

Re: [Freeipa-users] SSSD Crash Causing Inaccessibility

2016-01-29 Thread Jeff Hallyburton 
Understood.  Unfortunately, this event has been diagnosed and mitigated, so
re-occurance is unlikely.  Will respond to this thread if we see any
repeats however, totally understand the need for further information here.

Jeff

Jeff Hallyburton
Strategic Systems Engineer
Bloomip Inc.
Web: http://www.bloomip.com

Engineering Support: supp...@bloomip.com
Billing Support: bill...@bloomip.com
Customer Support Portal:  https://my.bloomip.com 

On Fri, Jan 29, 2016 at 5:44 PM, Jakub Hrozek  wrote:

> On Fri, Jan 29, 2016 at 01:49:15PM +0100, Lukas Slebodnik wrote:
> > On (28/01/16 18:37), Jeff Hallyburton wrote:
> > >Application logs showed this to be due to an OOM error, so no need to
> chase
> > >this further.  Thanks for the quick response!
> > >
> > Even though it was OOM.
> > I would still be interested in version of sssd.
> > "access after free error" is bed error.
> >
> > Do you have a coredump. It might be stored
> > by abrt or systemd-coredumpd (coredumpctl)
>
> This problem reminds me of:
> https://fedorahosted.org/sssd/ticket/2886
>
> Sadly, that one was also a one-time condition and we could never get to
> the root cause from the corefile.
>
> I agree with Lukas the core would be nice to see..
>
> --
> 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] SSSD Crash Causing Inaccessibility

2016-01-29 Thread Jakub Hrozek 
On Fri, Jan 29, 2016 at 01:49:15PM +0100, Lukas Slebodnik wrote:
> On (28/01/16 18:37), Jeff Hallyburton wrote:
> >Application logs showed this to be due to an OOM error, so no need to chase
> >this further.  Thanks for the quick response!
> >
> Even though it was OOM.
> I would still be interested in version of sssd.
> "access after free error" is bed error.
> 
> Do you have a coredump. It might be stored
> by abrt or systemd-coredumpd (coredumpctl)

This problem reminds me of:
https://fedorahosted.org/sssd/ticket/2886

Sadly, that one was also a one-time condition and we could never get to
the root cause from the corefile.

I agree with Lukas the core would be nice to see..

-- 
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] SSSD Crash Causing Inaccessibility

2016-01-29 Thread Jeff Hallyburton 
Lukas,

Installed versions of sssd:

# rpm -qa | grep -i sssd

sssd-common-1.13.0-40.el7_2.1.x86_64

sssd-ipa-1.13.0-40.el7_2.1.x86_64

sssd-1.13.0-40.el7_2.1.x86_64

sssd-krb5-common-1.13.0-40.el7_2.1.x86_64

sssd-ad-1.13.0-40.el7_2.1.x86_64

sssd-ldap-1.13.0-40.el7_2.1.x86_64

sssd-proxy-1.13.0-40.el7_2.1.x86_64

python-sssdconfig-1.13.0-40.el7_2.1.noarch

sssd-client-1.13.0-40.el7_2.1.x86_64

sssd-common-pac-1.13.0-40.el7_2.1.x86_64

sssd-krb5-1.13.0-40.el7_2.1.x86_64

No core dumps unfortunately.

Thanks,

Jeff


Jeff Hallyburton
Strategic Systems Engineer
Bloomip Inc.
Web: http://www.bloomip.com

Engineering Support: supp...@bloomip.com
Billing Support: bill...@bloomip.com
Customer Support Portal:  https://my.bloomip.com 

On Fri, Jan 29, 2016 at 7:49 AM, Lukas Slebodnik 
wrote:

> On (28/01/16 18:37), Jeff Hallyburton wrote:
> >Application logs showed this to be due to an OOM error, so no need to
> chase
> >this further.  Thanks for the quick response!
> >
> Even though it was OOM.
> I would still be interested in version of sssd.
> "access after free error" is bed error.
>
> Do you have a coredump. It might be stored
> by abrt or systemd-coredumpd (coredumpctl)
>
> LS
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] IPA Web Portal using outdated ciphers, breaking with some clients

2016-01-29 Thread Jeff Hallyburton 
Hi,

We're also seeing that the free-ipa web-portal is using TLS 1.2 by default,
which is being flagged as insecure / obsolete.  This also seems to be
causing some clients (some instances of Chrome) to fail logins:

[Fri Jan 29 18:34:26.638350 2016] [:error] [pid 6603] SSL Library Error:
-12286 No common encryption algorithm(s) with client

What do we need to do to update this to TLS 1.3?

Thanks,

Jeff

Jeff Hallyburton
Strategic Systems Engineer
Bloomip Inc.
Web: http://www.bloomip.com

Engineering Support: supp...@bloomip.com
Billing Support: bill...@bloomip.com
Customer Support Portal:  https://my.bloomip.com 
-- 
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] Server error with multiple clients joining domain simultaneously

2016-01-29 Thread Rob Crittenden 
David Zabner wrote:
> Ok so I added the line "KrbConstrainedDelegationLock ipa” to ipa.conf (httpd 
> configuration)
> 
> 
> My error log is now full of network errors:
> 

config looks right to me. Does this mean that some requests are
successful and others are not?

I'd set LogLevel debug in nss.conf and restart and you should get more
verbose info out of mod_auth_kerb.

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] IPA Web Portal using outdated ciphers, breaking with some clients

2016-01-29 Thread Rob Crittenden 
Jeff Hallyburton wrote:
> Hi,
> 
> We're also seeing that the free-ipa web-portal is using TLS 1.2 by
> default, which is being flagged as insecure / obsolete.  This also seems
> to be causing some clients (some instances of Chrome) to fail logins:
> 
> [Fri Jan 29 18:34:26.638350 2016] [:error] [pid 6603] SSL Library Error:
> -12286 No common encryption algorithm(s) with client
> 
> 
> What do we need to do to update this to TLS 1.3?

TLS 1.2 insecure/obsolete? Flagged by what? Need more info on what the
handshake looks like and what the server configuration is.

AFAIK 1.3 is still in draft form.

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] IPA Web Portal using outdated ciphers, breaking with some clients

2016-01-29 Thread Jeff Hallyburton 
Rob,

Chrome is flagging this, and given the error (I've attached a copy) its
probably due to the cipher suite (possibly specifically that it uses
SHA1).  This article has more details and is consistent with what we're
seeing:

http://security.stackexchange.com/questions/83831/google-chrome-your-connection-to-website-is-encrypted-with-obsolete-cryptograph

We've also seen similar issues come up with other applications during
penetration scans (e.g., Qualys) which is why I've noted it here.

Thanks,

Jeff

Jeff Hallyburton
Strategic Systems Engineer
Bloomip Inc.
Web: http://www.bloomip.com

Engineering Support: supp...@bloomip.com
Billing Support: bill...@bloomip.com
Customer Support Portal:  https://my.bloomip.com 

On Fri, Jan 29, 2016 at 2:36 PM, Rob Crittenden  wrote:

> Jeff Hallyburton wrote:
> > Hi,
> >
> > We're also seeing that the free-ipa web-portal is using TLS 1.2 by
> > default, which is being flagged as insecure / obsolete.  This also seems
> > to be causing some clients (some instances of Chrome) to fail logins:
> >
> > [Fri Jan 29 18:34:26.638350 2016] [:error] [pid 6603] SSL Library Error:
> > -12286 No common encryption algorithm(s) with client
> >
> >
> > What do we need to do to update this to TLS 1.3?
>
> TLS 1.2 insecure/obsolete? Flagged by what? Need more info on what the
> handshake looks like and what the server configuration is.
>
> AFAIK 1.3 is still in draft form.
>
> 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