date:20160128

Re: [Freeipa-users] FREAK Vulnerability

2016-01-28 Thread Terry John

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 
>>  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 
>>>  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

Re: [Freeipa-users] FREAK Vulnerability

2016-01-28 Thread Prasun Gera

Can someone at RH update this article
https://access.redhat.com/articles/1467293 ? I found it to be fairly
useful, but I'm not sure if it's up to date.

On Thu, Jan 28, 2016 at 11:04 AM, Terry John <
terry.j...@completeautomotivesolutions.co.uk> wrote:

> 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
> >>  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
> >>>  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:

Re: [Freeipa-users] Kerberos process coredump | authentication fails

2016-01-28 Thread Prashant Bapat

Sure. Attached the stack trace with debuginfo installed.

Thanks much!

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)
> > >> >#10
> > >> 0x557684579fe3 dispatch (krb5kdc)
> > >> >#11
> > >> 0x55768458d8a0 process_packet (krb5kdc)
> > >> >#12
> > >> 0x7f99dec4cc78 verto_fire (libverto.so.1)
> > >> >#13
> > >> 0x7f99d6fb72a3 epoll_event_loop_once (libtevent.so.0)
> > >> >#14
> > >> 0x7f99d6fb5787 std_event_loop_once (libtevent.so.0)
> > >> >#15
> > >> 0x7f99d6fb1fed _tevent_loop_once (libtevent.so.0)
> > >> >#16
> > >> 0x7f99dec4c3f7 verto_run (libverto.so.1)
> > >> >#17
> > >> 0x5576845795ab main (krb5kdc)
> > >> >#18
> > >> 0x7f99de8acfe0 __libc_start_main (libc.so.6)
> > >> >#19
> > >> 0x5576845798f0 _start (krb5kdc)
> > >> >
> > >> > Jan 26 03:15:59 ipa.example.net systemd-coredump[4999]: Process
> 4473
> > >>

Re: [Freeipa-users] Client-Install failures

2016-01-28 Thread David Zabner

Any guess as what it would be then? 
The location that is “missing a file” is specified by the gssapi config in 
/etc/httpd/conf.d/ipa.conf. So I assumed that this would be a mod_gssapi 
failure…


Thanks for your help,
David
> On Jan 28, 2016, at 5:55 AM, Simo Sorce  wrote:
> 
> Doesn't look related to mod_auth_gssapi, it's past it.
> 
> - Original Message -
>> From: "Martin Kosek" 
>> To: "David Zabner" , freeipa-users@redhat.com, "Simo 
>> Sorce" 
>> Sent: Thursday, January 28, 2016 4:42:57 AM
>> Subject: Re: [Freeipa-users] Client-Install failures
>> 
>> On 01/26/2016 10:20 PM, David Zabner wrote:
>>> Hi All,
>>> I am working on automated deployment of ipa clients through a program
>>> called salt and have been seeing an issue.
>>> Specifically, calls to ipa.server.internal/ipa/json occasionally return a
>>> 500 error. This tends to occur while using ipa-client-install and ipa-dns
>>> commands.
>>> 
>>> I am on free-ipa v 4.2.0 running on Centos 7 and will include the offending
>>> httpd error log.
>>> Thanks for your help,
>>> David
>> 
>> CCing Simo, I wonder if this error could be some problem caused by
>> mod_auth_gssapi?
>> 
>> [Tue Jan 26 20:28:00.456181 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] mod_wsgi (pid=9535): Exception occurred processing WSGI
>> script '/usr/share/ipa/wsgi.py'.
>> [Tue Jan 26 20:28:00.456211 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] Traceback (most recent call last):
>> [Tue Jan 26 20:28:00.456223 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220]   File "/usr/share/ipa/wsgi.py", line 49, in application
>> [Tue Jan 26 20:28:00.456245 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] return api.Backend.wsgi_dispatch(environ,
>> start_response)
>> [Tue Jan 26 20:28:00.456251 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220]   File
>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 258, in
>> __call__
>> [Tue Jan 26 20:28:00.456263 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] return self.route(environ, start_response)
>> [Tue Jan 26 20:28:00.456268 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220]   File
>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 270, in
>> route
>> [Tue Jan 26 20:28:00.456276 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] return app(environ, start_response)
>> [Tue Jan 26 20:28:00.456281 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220]   File
>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 447, in
>> __call__
>> [Tue Jan 26 20:28:00.456288 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] response = super(jsonserver, self).__call__(environ,
>>  start_response)
>> [Tue Jan 26 20:28:00.456293 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220]   File
>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 647, in
>> __call__
>> [Tue Jan 26 20:28:00.456299 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] 'xmlserver', user_ccache, environ, start_response,
>> headers)
>> [Tue Jan 26 20:28:00.456304 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220]   File
>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 593, in
>> finalize_kerberos_acquisition
>> [Tue Jan 26 20:28:00.456310 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] session_data['ccache_data'] =
>> load_ccache_data(ccache_name)
>> [Tue Jan 26 20:28:00.456315 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220]   File
>> "/usr/lib/python2.7/site-packages/ipalib/session.py",
>> line1231, in load_ccache_data
>> [Tue Jan 26 20:28:00.456330 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] src = open(name)
>> [Tue Jan 26 20:28:00.456344 2016] [:error] [pid 9535] [remote
>> 10.11.135.180:220] IOError: [Errno 2] No such file or directory:
>> '/var/run/httpd/ipa/   clientcaches/admin@FOO.INTERNAL'
>> 
>> Martin
>> 


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

2016-01-28 Thread Izzo, Anthony

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

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

2016-01-28 Thread David Zabner

This sounds exactly like the problem I am having. I will attach my error log. 
Is this what yours looks like?


error_log
Description: error_log
On Jan 28, 2016, at 1:10 PM, Izzo, Anthony  wrote:I’m seeing what feels like a concurrency error.  I’m in a cloud environment and launching a group of instances which are all trying to join a domain at about the same time via ipa-client-install.  Some of these operations succeed, and others fail. The error message on those that fail is that they failed to join the domain, and the HTTP response was 500 instead of 200. The Apache error_log file on the server, shows a python stack trace (which unfortunately I can’t reproduce in its entirety here), which culminates in the complaint that a file (/var/run/httpd/ipa/clientcaches/@) was not found.  What it seems like is that multiple attempts to join the domain from different hosts are stepping on one another. I’m wondering if I am trying to do something that is not supported, or if I have something misconfigured.  I’m tempted to catch the error and retry after a random interval (the output of the failing command indicates that it is rolling back to the initial state) – that would be the easiest thing.  But if this is pointing to an underlying error on my part I’d rather fix it if possible. Additional info in case it helps – I’m running RHEL7/FreeIPA4.2 on the servers (two in a replication agreement).  I’m running RHEL6/FreeIPA3.0 on the clients (most recent attempt I tried to launch 7 instances, three of which failed).  Thanks. Tony  -- Manage your subscription for the Freeipa-users mailing list:https://www.redhat.com/mailman/listinfo/freeipa-usersGo 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] Kerberos process coredump | authentication fails

2016-01-28 Thread Sumit Bose

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)
> > > >> >#10
> > > >> 0x557684579fe3 dispatch (krb5kdc)
> > > >> >#11
> > > >> 0x55768458d8a0 process_packet (krb5kdc)
> > > >> >#12
> > > >> 0x7f99dec4cc78 verto_fire (libverto.so.1)
> > > >> >#13
> > > >> 0x7f99d6fb72a3 epoll_event_loop_once (libtevent.so.0)
> > > >> >

Re: [Freeipa-users] SSSD Crash Causing Inaccessibility

2016-01-28 Thread Lukas Slebodnik

On (28/01/16 16:25), Jeff Hallyburton wrote:
>We saw the following happen on a system today, and wanted to follow up:
>
>System became unresponsive to ssh logins with the error:
>
>ssh -v incentives01
>
//snip

># cat /var/log/sssd/sssd.log
>
>(Thu Jan 28 20:15:56 2016) [sssd] [mt_svc_sigkill] (0x0010): [enervee.com][620]
>is not responding to SIGTERM. Sending SIGKILL.
>
>(Thu Jan 28 20:16:27 2016) [sssd] [talloc_log_fn] (0x0010): talloc: access
>after free error - first free may be at src/monitor/monitor.c:2760
>
>
>(Thu Jan 28 20:16:27 2016) [sssd] [talloc_log_fn] (0x0010): Bad talloc
>magic value - access after free
>
There was a crash in sssd. It might explain why you cannot login.
Which version of sssd do you have?

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] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

2016-01-28 Thread Endi Sukma Dewata

Hi,

If you're cloning from an IPA running on RHEL/CentOS 6 with CA signed by 
another CA you are likely hitting this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1291747

The bug has been fixed in this package: pki-ca-9.0.3-45. You'll need to install 
it on the master, then restart the server, then try cloning again.

The latest PKI available on RHEL/CentOS 7 is version 10.2.5, but it's patched 
with relevant bug fixes from newer versions.

If you're still having a problem, try enabling the debug log on the master and 
clone by setting the following property in CS.cfg:
debug.level=1

See also: http://pki.fedoraproject.org/wiki/PKI_Server_Logs

--
Endi S. Dewata

- Original Message -
> Hi Martin
> 
> I am happy to provide the necessary information. What packages should i check
> for? As for IPA we are IPA CA being signed with other CA
> 
> Thank You
> 
> On Wed, Jan 27, 2016 at 2:24 AM, Martin Kosek < mko...@redhat.com > wrote:
> 
> 
> On 01/26/2016 09:45 PM, Ash Alam wrote:
> > I didnt want to dig up an old thread but i am running into this issue. The
> > old thread points to Pki 10.2.6 as the solution but i am not seeing that
> > package on centos 7.2.
> > 
> > STDERR: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
> > configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f'
> > '/tmp/tmpHfdvFD'' returned non-zero exit status 1
> 
> CCing David and Endi, they might have an idea what is wrong. There were
> several
> recent fixes, to again fix RHEL-6 to RHEL-7 migration, we would need to check
> if you have them installed. As for your RHEL-6 IPA setup, is it running with
> External CA, i.e. IPA CA with being signed with other CA?
> 
> > 
> > On Tue, Jan 26, 2016 at 12:14 PM, Ash Alam < aa...@paperlesspost.com >
> > wrote:
> > 
> >> thank you! Out of curiosity has anyone been able to automate this using
> >> chef/puppet etc?
> >> 
> >> On Tue, Jan 26, 2016 at 10:56 AM, Martin Kosek < mko...@redhat.com >
> >> wrote:
> >> 
> >>> Did you follow the instructions in the error message? There is also a
> >>> longer
> >>> description here:
> >>> 
> >>> 
> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
> >>> 
> >>> Martin
> >>> 
> >>> On 01/26/2016 04:38 PM, Ash Alam wrote:
>  I wanted to follow up on this as i finally gotten around to doing the
>  upgrade. I an running into this error. I also found a bugzilla ticket.
> >>> Do
>  you have to do some type of schema upgrade like you do with active
>  directory?
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1235766
>  
>  STDERR: ipa : CRITICAL The master CA directory server does
> >>> not
>  have necessary schema. Please copy the following script to all CA
> >>> masters
>  and run it on them: /usr/share/ipa/copy-schema-to-ca.py
>  
>  If you are certain that this is a false positive, use
>  --skip-schema-check.
>  
>  ipa.ipapython.install.cli.install_tool(Replica): ERROR IPA schema
>  missing on master CA directory server
>  
>  
>  
>  Thank You
>  
>  
>  
>  
>  On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek < mko...@redhat.com >
> >>> wrote:
>  
> > On 11/20/2015 04:08 PM, Ash Alam wrote:
> > 
> >> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
> >> installed. I
> >> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then
> >>> start
> >> phasing out the older 3.0.0 servers. Will the client that are still
> >> running the
> >> older client software still work?
> >> 
> > 
> > It should, yes. It is expected that there are RHEL/CentOS-6 clients
> >>> with
> > RHEL-7 FreeIPA servers. The older clients just won't be able to use the
> > newest features.
> > 
> > 
> >> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek < mko...@redhat.com
> >> > wrote:
> >> 
> >> On 11/19/2015 11:03 PM, Ash Alam wrote:
> >> 
> >> Hello All
> >> 
> >> I am looking for some advice on upgrading. Currently our
> >>> FreeIPA
> >> servers are
> >> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7.
> >>> This
> >> upgrade path
> >> is not possible per IPA documentation. Minimum version
> >>> required
> >> is 3.3.x. I
> >> have also found that cenos6 does not provide anything past
> >>> 3.0.0.
> >> 
> >> 
> >> And it won't. There are no plans in updating FreeIPA version in
> >> RHEL/CentOS-6.x, we encourage people who want the new features to
> >> migrate
> >> to RHEL-7.x:
> >> 
> >> 
> >> 
> >>> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
> >> 
> >> 
> >> 
> >>>

[Freeipa-users] SSSD Crash Causing Inaccessibility

2016-01-28 Thread Jeff Hallyburton

We saw the following happen on a system today, and wanted to follow up:

System became unresponsive to ssh logins with the error:

ssh -v incentives01

OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 4: Applying options for *

debug1: Connecting to incentives01 [172.31.9.16] port 22.

debug1: Connection established.

debug1: identity file /home/jeff.hallyburton/.ssh/id_rsa type -1

debug1: identity file /home/jeff.hallyburton/.ssh/id_rsa-cert type -1

debug1: identity file /home/jeff.hallyburton/.ssh/id_dsa type -1

debug1: identity file /home/jeff.hallyburton/.ssh/id_dsa-cert type -1

debug1: identity file /home/jeff.hallyburton/.ssh/id_ecdsa type -1

debug1: identity file /home/jeff.hallyburton/.ssh/id_ecdsa-cert type -1

debug1: identity file /home/jeff.hallyburton/.ssh/id_ed25519 type -1

debug1: identity file /home/jeff.hallyburton/.ssh/id_ed25519-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_6.6.1

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1

debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-ctr hmac-md5-...@openssh.com none

debug1: kex: client->server aes128-ctr hmac-md5-...@openssh.com none

debug1: kex: curve25519-sha...@libssh.org need=16 dh_need=16

debug1: kex: curve25519-sha...@libssh.org need=16 dh_need=16

debug1: sending SSH2_MSG_KEX_ECDH_INIT

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ECDSA
89:e0:f8:25:21:db:c9:46:67:14:38:0c:c1:f4:f7:51

debug1: Host 'incentives01' is known and matches the ECDSA host key.

debug1: Found key in /home/jeff.hallyburton/.ssh/known_hosts:7

debug1: ssh_ecdsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

This is a private computer system which is restricted to authorized
individuals.


Actual or attempted unauthorized use of this computer system will result in

criminal and/or civil prosecution.


We reserve the right to view, monitor and record activity on the system
without

notice or permission. Any information obtained by monitoring, reviewing or

recording is subject to review by law enforcement organizations in
connection

with the investigation or prosecution of possible criminal activity on this
system.


If you are not an authorized user of this system or do not consent to
continued

monitoring, disconnect at this time.

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic

debug1: Next authentication method: gssapi-keyex

debug1: No valid Key exchange context

debug1: Next authentication method: gssapi-with-mic

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic

Received disconnect from 172.31.9.16: 2: Too many authentication failures
for jeff.hallyburton

Ultimately we rebooted the node to restore connectivity.  After we were
back in, we're seeing that sssd crashed due what looks like a memory
allocation error:

/var/log/sssd/sssd.log

# cat /var/log/sssd/sssd.log

(Thu Jan 28 20:15:56 2016) [sssd] [mt_svc_sigkill] (0x0010): [enervee.com][620]
is not responding to SIGTERM. Sending SIGKILL.

(Thu Jan 28 20:16:27 2016) [sssd] [talloc_log_fn] (0x0010): talloc: access
after free error - first free may be at src/monitor/monitor.c:2760


(Thu Jan 28 20:16:27 2016) [sssd] [talloc_log_fn] (0x0010): Bad talloc
magic value - access after free

/var/log/secure

Jan 28 20:05:48 incentives01 sshd[26145]: Timeout, client not responding.

Jan 28 20:05:48 incentives01 sshd[26142]: pam_unix(sshd:session): session
closed for user

Jan 28 20:16:28 incentives01 sshd[14504]: Timeout, client not responding.

Jan 28 20:16:28 incentives01 sshd[14501]: pam_systemd(sshd:session): Failed
to release session: Connection timed out

Jan 28 20:16:28 incentives01 sshd[14501]: pam_unix(sshd:session): session
closed for user

Jan 28 20:16:28 incentives01 sshd[14501]: pam_sss(sshd:session): Request to
sssd failed. Bad address

Jan 28 20:16:29 incentives01 sshd[14501]: fatal: login_init_entry: Cannot
find user

Jan 28 20:21:40 incentives01 sshd[26882]: Invalid user from 172.31.8.34

The system may have simply run out of ram, but wanted to check to see if
there were any known or contributing issues.

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

Re: [Freeipa-users] SSSD Crash Causing Inaccessibility

2016-01-28 Thread Jeff Hallyburton

Application logs showed this to be due to an OOM error, so no need to chase
this further.  Thanks for the quick response!

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 Thu, Jan 28, 2016 at 6:22 PM, Lukas Slebodnik 
wrote:

> On (28/01/16 16:25), Jeff Hallyburton wrote:
> >We saw the following happen on a system today, and wanted to follow up:
> >
> >System became unresponsive to ssh logins with the error:
> >
> >ssh -v incentives01
> >
> //snip
>
> ># cat /var/log/sssd/sssd.log
> >
> >(Thu Jan 28 20:15:56 2016) [sssd] [mt_svc_sigkill] (0x0010): [enervee.com
> ][620]
> >is not responding to SIGTERM. Sending SIGKILL.
> >
> >(Thu Jan 28 20:16:27 2016) [sssd] [talloc_log_fn] (0x0010): talloc: access
> >after free error - first free may be at src/monitor/monitor.c:2760
> >
> >
> >(Thu Jan 28 20:16:27 2016) [sssd] [talloc_log_fn] (0x0010): Bad talloc
> >magic value - access after free
> >
> There was a crash in sssd. It might explain why you cannot login.
> Which version of sssd do you have?
>
> 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] Active Directory users are not controlled by HBAC

2016-01-28 Thread Sumit Bose

On Wed, Jan 27, 2016 at 06:53:43PM +, Birnbaum, Warren (ETW) wrote:
> I started this post with a simple question:  ³is it possible to have HBAC
> work with AD authenticated users².  I was not able from the tips provided
> to get any further with this.
> 
> What I have not been able to have addressed is, if there are no HBAC
> rules, there should be no access, or if there is no Allow_Access rule, no
> one should be able to login to any system.  Currently with this said
> configuration, everyone has access to every system.  My pam stack is
> exactly as recommended.  Is there someone who has FreeIPA with active
> directory authenticated users and HBAC working?  I don¹t have trust
> defined with AD but authentication is working fine.

The HBAC checks are done by SSSD. If there are issues SSSD logs would
help to identify the reason. Please see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details. With
respect to HBAC the sssd_pam.log and sssd_your.domain.log are the most
important. Setting debug_level=10 in the [pam] and [domain/...] section
of sssd.conf should produce the most details.

Feel free to send the logs to me directly if you think they may disclose
too many details of your environment on a public mailing-list.

HTH

bye,
Sumit

> 
> >From the following link:
> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-gro
> ups.html
> It says in the second paragraph:
> 
> "However, Active Directory users cannot be added directly to FreeIPA user
> groups. This means that Active Directory users require special
> configuration in order to access FreeIPA domain resources."
> 
> There is then a procedure given to create user groups that work with HBAC.
>  I don¹t see how this work help me since adding a user to a group could
> only be used to further allow access to systems, but already have total
> access to all systems by all users.
> 
> Thanks for your help!
> 
> Warren
> 
> 
> 
> 
> 
> 
> On 1/25/16, 2:47 PM, "Alexander Bokovoy"  wrote:
> 
> >On Mon, 25 Jan 2016, Birnbaum, Warren (ETW) wrote:
> >>OK.  I have done this and am using the pam stack that is the result of
> >>what you here describe.
> >>
> >>A few threads back you mentioned that this could be a reason why my hbac
> >>are not restricting access.  I have no hbac rules currently and any
> >>active
> >>directory user can access any host.  Is there something else I could look
> >>at to see why this is happening?
> >https://fedorahosted.org/sssd/wiki/Troubleshooting is your friend.
> >
> >-- 
> >/ Alexander Bokovoy
> 
> 
> -- 
> 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 and DNS

2016-01-28 Thread Jakub Hrozek

On Wed, Jan 27, 2016 at 10:53:00AM -0700, Sean Hogan wrote:
> 
> 
> Hi All,
> 
> Tue Jan 26 19:01:32 2016) [sssd] [ping_check] (0x0020): A service PING
> timed out on [ssh]. Attempt [0]
> (Tue Jan 26 19:06:50 2016) [sssd] [ping_check] (0x0020): A service PING
> timed out on [sudo]. Attempt [0]
> (Tue Jan 26 19:06:50 2016) [sssd] [ping_check] (0x0020): A service PING
> timed out on [ssh]. Attempt [0]
>  Everything recovers and all is good for a while then;
> 
> (Tue Jan 26 19:14:11 2016) [sssd] [ping_check] (0x0020): A service PING
> timed out on [foo.local]. Attempt [2]
> (Tue Jan 26 19:14:21 2016) [sssd] [tasks_check_handler] (0x0020): Killing
> service [foo.local], not responding to pings!
> (Tue Jan 26 19:14:21 2016) [sssd] [ping_check] (0x0020): A service PING
> timed out on [foo.local]. Attempt [3]
> (Tue Jan 26 19:14:25 2016) [sssd] [mt_svc_exit_handler] (0x0040): Child
> [foo.local] exited with code [0]
> (Tue Jan 26 19:14:25 2016) [sssd] [sbus_dispatch] (0x4000): dbus conn:
> 0x10022c42aa0
> (Tue Jan 26 19:14:25 2016) [sssd] [sbus_dispatch] (0x0080): Connection is
> not open for dispatching.
> (Tue Jan 26 19:14:25 2016) [sssd] [mt_svc_restart] (0x0400): Scheduling
> service foo.local for restart 1
> (Tue Jan 26 19:14:25 2016) [sssd] [get_ping_config] (0x0100): Time between
> service pings for [foo.local]: [10]
> (Tue Jan 26 19:14:25 2016) [sssd] [get_ping_config] (0x0100): Time between
> SIGTERM and SIGKILL for [foo.local]: [60]
> (Tue Jan 26 19:14:25 2016) [sssd] [start_service] (0x0100): Queueing
> service foo.local for startup
> (Tue Jan 26 19:18:44 2016) [sssd] [service_send_ping] (0x0100): Pinging pam
> (Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
> 0x10022c47f60
> (Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging ssh
> (Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
> 0x10022c54600
> (Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging pac
> (Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
> 0x10022c307c0
> (Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging
> sudo
> (Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
> 0x10022c488b0
> (Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging nss
> (Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
> 0x10022c47710
> (Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x2000): Service not
> yet initialized
> (Tue Jan 26 19:19:26 2016) [sssd] [tasks_check_handler] (0x0020): Child
> (foo.local) not responding! (yet)
> (Tue Jan 26 19:21:33 2016) [sssd] [tasks_check_handler] (0x0020): Child
> (foo.local) not responding! (yet)

These are IPC pings between sssd subprocesses, not network traffic. I
would look at the pstack of the sssd processes to see what's going on. I
guess one of them is stuck performing some blocking operation (do you
have enumeration enabled maybe?)

-- 
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] Cross Domain Trust

2016-01-28 Thread Zoske, Fabian

Thank you Jakub, this solves the issue.

Best regards,
Fabian

-Ursprüngliche Nachricht-
Von: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] 
Im Auftrag von Jakub Hrozek
Gesendet: Montag, 18. Januar 2016 18:46
An: freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] Cross Domain Trust

On Mon, Jan 18, 2016 at 06:02:43PM +0100, Lukas Slebodnik wrote:
> On (12/01/16 11:11), Lukas Slebodnik wrote:
> >On (12/01/16 08:25), Zoske, Fabian wrote:
> >>We recently upgraded our IPA-Server from CentOS 7.1 to CentOS 7.2. So far 
> >>no differences.
> >>
> >Then please provide sssd logfiles (1.13.3) from client and also log 
> >files from sssd on freeipa server (sssd on freeipa server is used 
> >indirectly by extop plugin in 389-ds)
> >
> >Please provide log files from the same time when you reproduced an issue.
> >
> Thank you very much for log files.
> 
> Authentication on client failed Due to following error:
> (Thu Jan 14 12:58:36 2016) [[sssd[krb5_child[992 
> [sss_child_krb5_trace_cb] (0x4000): [992] 1452772716.736098: Sending 
> request (173 bytes) to EUROIMMUN.TEST (master)
> 
> (Thu Jan 14 12:58:37 2016) [[sssd[krb5_child[992 
> [get_and_save_tgt] (0x0020): 1232: [-1765328230][Cannot find KDC for 
> realm "EUROIMMUN.TEST"] (Thu Jan 14 12:58:37 2016) 
> [[sssd[krb5_child[992 [map_krb5_error] (0x0020): 1301: 
> [-1765328230][Cannot find KDC for realm "EUROIMMUN.TEST"] (Thu Jan 14 
> 12:58:37 2016) [[sssd[krb5_child[992 [k5c_send_data] (0x0200): Received 
> error code 1432158209 (Thu Jan 14 12:58:37 2016) [[sssd[krb5_child[992 
> [pack_response_packet] (0x2000): response packet size: [4] (Thu Jan 14 
> 12:58:37 2016) [[sssd[krb5_child[992 [k5c_send_data] (0x4000): Response 
> sent.
> (Thu Jan 14 12:58:37 2016) [[sssd[krb5_child[992 [main] (0x0400): 
> krb5_child completed successfully
> 
> 
> Do you have defineded the realm "EUROIMMUN.TEST" in your krb5.conf?
> 
> It is possible that sssd wrote snippet to the directory 
> /var/lib/sss/pubconf/krb5.include.d/
> but this directory is not included in krb5.conf.
> 
> $ grep includedir /etc/krb5.conf
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> BTW you can test the same operation as sssd did from command line.
> 
> KRB5_TRACE=/dev/stderr kinit f.zo...@euroimmun.test
> 
> or is this principal name an enterprise name?

IIRC this came up in a private conversation, too. In short, enterprise 
principals are not supported in a IPA-AD trust scenario, but one can work 
around that by using:
subdomain_inherit = ldap_user_principal
ldap_user_principal = nosuchattr
and thus tricking sssd into 'deriving' the UPN from the domain name.

--
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] Client-Install failures

2016-01-28 Thread Martin Kosek


On 01/26/2016 10:20 PM, David Zabner wrote:

Hi All,
I am working on automated deployment of ipa clients through a program called 
salt and have been seeing an issue.
Specifically, calls to ipa.server.internal/ipa/json occasionally return a 500 
error. This tends to occur while using ipa-client-install and ipa-dns commands.

I am on free-ipa v 4.2.0 running on Centos 7 and will include the offending 
httpd error log.
Thanks for your help,
David


CCing Simo, I wonder if this error could be some problem caused by 
mod_auth_gssapi?

[Tue Jan 26 20:28:00.456181 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] mod_wsgi (pid=9535): Exception occurred processing WSGI 
script '/usr/share/ipa/wsgi.py'.
[Tue Jan 26 20:28:00.456211 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] Traceback (most recent call last):
[Tue Jan 26 20:28:00.456223 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File "/usr/share/ipa/wsgi.py", line 49, in application
[Tue Jan 26 20:28:00.456245 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] return api.Backend.wsgi_dispatch(environ, start_response)
[Tue Jan 26 20:28:00.456251 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 258, in __call__
[Tue Jan 26 20:28:00.456263 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] return self.route(environ, start_response)
[Tue Jan 26 20:28:00.456268 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 270, in route
[Tue Jan 26 20:28:00.456276 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] return app(environ, start_response)
[Tue Jan 26 20:28:00.456281 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 447, in __call__
[Tue Jan 26 20:28:00.456288 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] response = super(jsonserver, self).__call__(environ, 
 start_response)
[Tue Jan 26 20:28:00.456293 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 647, in __call__
[Tue Jan 26 20:28:00.456299 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] 'xmlserver', user_ccache, environ, start_response, headers)
[Tue Jan 26 20:28:00.456304 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 593, in 
finalize_kerberos_acquisition
[Tue Jan 26 20:28:00.456310 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] session_data['ccache_data'] = load_ccache_data(ccache_name)
[Tue Jan 26 20:28:00.456315 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File "/usr/lib/python2.7/site-packages/ipalib/session.py", 
line1231, in load_ccache_data
[Tue Jan 26 20:28:00.456330 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] src = open(name)
[Tue Jan 26 20:28:00.456344 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] IOError: [Errno 2] No such file or directory: 
'/var/run/httpd/ipa/   clientcaches/admin@FOO.INTERNAL'


Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Centos 7, CA log files, bug report?

2016-01-28 Thread Martin Basti




On 27.01.2016 22:20, Lachlan Musicman wrote:

Hi,

Not sure if this is a bug or if I'm ignorant of the RH world, but when 
I try to do a fresh IPA install on Centos 7.2, I'm getting failures here:


  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to 
configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' 
'/tmp/tmpAGdITu'' returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the 
installation logs and the following files/directories for more 
information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL 
/var/log/pki-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL 
/var/log/pki/pki-tomcat

  [error] RuntimeError: CA configuration failed.
ipa.ipapython.install.cli.install_tool(Server): ERROR CA configuration 
failed.



[root@emts-centos71-7f ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

CentOS Linux release 7.2.1511 (Core)

Most importantly for me, /var/log/pki-ca-install.log doesn't exist and 
there is no file that looks like it anywhere on my system. Is this a bug?


cheers
L.


--
The most dangerous phrase in the language is, "We've always done it 
this way."


- Grace Hopper



Hello,

do

/var/log/pki/pki-ca-spawn.*.log
/var/log/pki/pki-tomcat/ca/debug

exist?

There might be details.
-- 
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] ERROR: missing attribute "ipaNTSecurityIdentifier" required by object class "ipaNTUserAttrs"

2016-01-28 Thread Sumit Bose

On Wed, Jan 27, 2016 at 02:51:07PM -0600, Anil Kommareddy wrote:
> Hi All,
> 
> 
> 
> I have an ipa-server-4.2.0-15.el7_2.3.x86_64 on which I installed 
> ipa-server-trust-ad-4.2.0-15.el7_2.3.x86_64 and ran "ipa-adtrust-install 
> --add-sids" command.  After some initial issues it started working fine.
> This has created  ipaNTSecurityIdentifier to existing user accounts fine.  It 
> seem to create ipaNTHash on changing the password of the existing users.  
> But when add new users, i am getting this error.   Is there any way to fix 
> this issue?
> ERROR: missing attribute "ipaNTSecurityIdentifier" required by object class 
> "ipaNTUserAttrs"

How do you add the new user? Can you send the command line you use?

bye,
Sumit

> Greatly appreciate your help.
> Regards,Anil

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

2016-01-28 Thread Sumit Bose

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)
>#10 0x557684579fe3 
> dispatch (krb5kdc)
>#11 0x55768458d8a0 
> process_packet (krb5kdc)
>#12 0x7f99dec4cc78 
> verto_fire (libverto.so.1)
>#13 0x7f99d6fb72a3 
> epoll_event_loop_once (libtevent.so.0)
>#14 0x7f99d6fb5787 
> std_event_loop_once (libtevent.so.0)
>#15 0x7f99d6fb1fed 
> _tevent_loop_once (libtevent.so.0)
>#16 0x7f99dec4c3f7 
> verto_run (libverto.so.1)
>#17 0x5576845795ab 
> main (krb5kdc)
>#18 0x7f99de8acfe0 
> __libc_start_main (libc.so.6)
>#19 0x5576845798f0 
> _start (krb5kdc)
> 
> Jan 26 03:15:59 ipa.example.net systemd-coredump[4999]: Process 4473 
> (krb5kdc) of user 0 dumped core.
> 
>Stack trace of thread 
> 4473:
>#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)
>#10 0x557684579fe3 
> dispatch (krb5kdc)
>#11 0x55768458d8a0 
> process_packet (krb5kdc)
>

Re: [Freeipa-users] FREAK Vulnerability

2016-01-28 Thread Christian Heimes

On 2016-01-28 13:32, 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_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?

There is another catch. The SSL module of 389-DS uses different names
for ciphers than mod_nss. Both have their own nick name table for the
official TLS suite names. Recent versions of 389-DS also support the
official cipher suite names. I don't know which version of 389-DS
introduced the feature. I only looked at the most recent code.

https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/slapd/ssl.c#n150

https://git.fedorahosted.org/cgit/mod_nss.git/tree/nss_engine_cipher.c#n23

Regards,
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

[Freeipa-users] ipa replica is ad trust controller but refuses ad users

2016-01-28 Thread Rob Verduijn

Hello,

I've set up an ipa-server with an one way trust to a windows 2012r2 controller.
All works on this server.
I can login with ad accounts on this server.

I added an ipa replica, and checked it all worked.

Now I tried
ipa-trust-add --add-agents on the first ipa server.
restarted ipa on both servers

but this did not help
then i did a
ipa-adtrust-install on the second ipa server
and a ipa trust-add --type=ad windows.domain

all dns queries from the docs work
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#verify-dns-configuration

I get both ipa servers returned in the queries.
On the windows server and the ipa server.

On the first ipaserver I can issue : id WINDOWS.DOMAIN\\ad-user
and get an answer
On the second I get : unknown user

What could be the cause of this, why does the second server not do
ad-authentication ?

Rob Verduijn

-- 
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

2016-01-28 Thread Terry John

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 
>  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 
>>  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 
>>> 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

[Freeipa-users] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

2016-01-28 Thread Roderick Johnstone


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?


Thanks

Roderick Johnstone




--
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-28 Thread Prashant Bapat

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)
> >#10
> 0x557684579fe3 dispatch (krb5kdc)
> >#11
> 0x55768458d8a0 process_packet (krb5kdc)
> >#12
> 0x7f99dec4cc78 verto_fire (libverto.so.1)
> >#13
> 0x7f99d6fb72a3 epoll_event_loop_once (libtevent.so.0)
> >#14
> 0x7f99d6fb5787 std_event_loop_once (libtevent.so.0)
> >#15
> 0x7f99d6fb1fed _tevent_loop_once (libtevent.so.0)
> >#16
> 0x7f99dec4c3f7 verto_run (libverto.so.1)
> >#17
> 0x5576845795ab main (krb5kdc)
> >#18
> 0x7f99de8acfe0 __libc_start_main (libc.so.6)
> >#19
> 0x5576845798f0 _start (krb5kdc)
> >
> > Jan 26 03:15:59 ipa.example.net systemd-coredump[4999]: Process 4473
> (krb5kdc) of user 0 dumped core.
> >
> >Stack trace of
> thread 4473:
> >#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
>

Re: [Freeipa-users] Kerberos process coredump | authentication fails

2016-01-28 Thread Sumit Bose

On Thu, Jan 28, 2016 at 04:27:52PM +0530, Prashant Bapat wrote:
> Thanks Sumit.
> 
> From the logs there is nothing unusual around the time of core dump. I

ah sorry, I wasn't clear here. I was not looking for unusual messages
but I wanted to find out which request might have caused the crash.

bye,
Sumit

> 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)
> > >#10
> > 0x557684579fe3 dispatch (krb5kdc)
> > >#11
> > 0x55768458d8a0 process_packet (krb5kdc)
> > >#12
> > 0x7f99dec4cc78 verto_fire (libverto.so.1)
> > >#13
> > 0x7f99d6fb72a3 epoll_event_loop_once (libtevent.so.0)
> > >#14
> > 0x7f99d6fb5787 std_event_loop_once (libtevent.so.0)
> > >#15
> > 0x7f99d6fb1fed _tevent_loop_once (libtevent.so.0)
> > >#16
> > 0x7f99dec4c3f7 verto_run (libverto.so.1)
> > >#17
> > 0x5576845795ab main (krb5kdc)
> > >#18
> > 0x7f99de8acfe0 __libc_start_main (libc.so.6)
> > >#19
> > 0x5576845798f0 _start (krb5kdc)
> > >
> > > Jan 26 03:15:59 ipa.example.net systemd-coredump[4999]: Process 4473
> > (krb5kdc) of user 0 dumped core.
> > >
> > >Stack trace of
> > thread 4473:
> > >#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

Re: [Freeipa-users] Kerberos process coredump | authentication fails

2016-01-28 Thread Prashant Bapat

gdb stacktrace attached.

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)
>> >#10
>> 0x557684579fe3 dispatch (krb5kdc)
>> >#11
>> 0x55768458d8a0 process_packet (krb5kdc)
>> >#12
>> 0x7f99dec4cc78 verto_fire (libverto.so.1)
>> >#13
>> 0x7f99d6fb72a3 epoll_event_loop_once (libtevent.so.0)
>> >#14
>> 0x7f99d6fb5787 std_event_loop_once (libtevent.so.0)
>> >#15
>> 0x7f99d6fb1fed _tevent_loop_once (libtevent.so.0)
>> >#16
>> 0x7f99dec4c3f7 verto_run (libverto.so.1)
>> >#17
>> 0x5576845795ab main (krb5kdc)
>> >#18
>> 0x7f99de8acfe0 __libc_start_main (libc.so.6)
>> >#19
>> 0x5576845798f0 _start (krb5kdc)
>> >
>> > Jan 26 03:15:59 ipa.example.net systemd-coredump[4999]: Process 4473
>> (krb5kdc) of user 0 dumped core.
>> >
>> >Stack trace of
>> thread 4473:
>> >#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

Re: [Freeipa-users] Kerberos process coredump | authentication fails

2016-01-28 Thread Prashant Bapat

Thanks Lukas.

I'm exploring moving to CentOS for our setup so that I get the advantage of
longer release cycles.

On 28 January 2016 at 16:41, Lukas Slebodnik  wrote:

> On (28/01/16 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
> Fedora 21 is not supprted since 2015-12-01.
> http://fedoraproject.org/wiki/End_of_life
>
> As Sumit wrote there is a high change that it's already fixed.
> I would recommend to upgrade to Fedora 22.
> There is freeipa-4.1.4-4.fc22. So it shoudl not be a big change for you.
>
> 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] Client-Install failures

2016-01-28 Thread Simo Sorce

Doesn't look related to mod_auth_gssapi, it's past it.

- Original Message -
> From: "Martin Kosek" 
> To: "David Zabner" , freeipa-users@redhat.com, "Simo Sorce" 
> 
> Sent: Thursday, January 28, 2016 4:42:57 AM
> Subject: Re: [Freeipa-users] Client-Install failures
> 
> On 01/26/2016 10:20 PM, David Zabner wrote:
> > Hi All,
> > I am working on automated deployment of ipa clients through a program
> > called salt and have been seeing an issue.
> > Specifically, calls to ipa.server.internal/ipa/json occasionally return a
> > 500 error. This tends to occur while using ipa-client-install and ipa-dns
> > commands.
> >
> > I am on free-ipa v 4.2.0 running on Centos 7 and will include the offending
> > httpd error log.
> > Thanks for your help,
> > David
> 
> CCing Simo, I wonder if this error could be some problem caused by
> mod_auth_gssapi?
> 
> [Tue Jan 26 20:28:00.456181 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] mod_wsgi (pid=9535): Exception occurred processing WSGI
> script '/usr/share/ipa/wsgi.py'.
> [Tue Jan 26 20:28:00.456211 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] Traceback (most recent call last):
> [Tue Jan 26 20:28:00.456223 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220]   File "/usr/share/ipa/wsgi.py", line 49, in application
> [Tue Jan 26 20:28:00.456245 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] return api.Backend.wsgi_dispatch(environ,
> start_response)
> [Tue Jan 26 20:28:00.456251 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 258, in
> __call__
> [Tue Jan 26 20:28:00.456263 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] return self.route(environ, start_response)
> [Tue Jan 26 20:28:00.456268 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 270, in
> route
> [Tue Jan 26 20:28:00.456276 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] return app(environ, start_response)
> [Tue Jan 26 20:28:00.456281 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 447, in
> __call__
> [Tue Jan 26 20:28:00.456288 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] response = super(jsonserver, self).__call__(environ,
>   start_response)
> [Tue Jan 26 20:28:00.456293 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 647, in
> __call__
> [Tue Jan 26 20:28:00.456299 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] 'xmlserver', user_ccache, environ, start_response,
> headers)
> [Tue Jan 26 20:28:00.456304 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 593, in
> finalize_kerberos_acquisition
> [Tue Jan 26 20:28:00.456310 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] session_data['ccache_data'] =
> load_ccache_data(ccache_name)
> [Tue Jan 26 20:28:00.456315 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220]   File
> "/usr/lib/python2.7/site-packages/ipalib/session.py",
> line1231, in load_ccache_data
> [Tue Jan 26 20:28:00.456330 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] src = open(name)
> [Tue Jan 26 20:28:00.456344 2016] [:error] [pid 9535] [remote
> 10.11.135.180:220] IOError: [Errno 2] No such file or directory:
> '/var/run/httpd/ipa/   clientcaches/admin@FOO.INTERNAL'
> 
> Martin
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos process coredump | authentication fails

2016-01-28 Thread Lukas Slebodnik

On (28/01/16 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
Fedora 21 is not supprted since 2015-12-01.
http://fedoraproject.org/wiki/End_of_life

As Sumit wrote there is a high change that it's already fixed.
I would recommend to upgrade to Fedora 22.
There is freeipa-4.1.4-4.fc22. So it shoudl not be a big change for you.

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

2016-01-28 Thread Izzo, Anthony

I'm seeing what feels like a concurrency error.  I'm in a cloud environment and 
launching a group of instances which are all trying to join a domain at about 
the same time via ipa-client-install.  Some of these operations succeed, and 
others fail.

The error message on those that fail is that they failed to join the domain, 
and the HTTP response was 500 instead of 200.

The Apache error_log file on the server, shows a python stack trace (which 
unfortunately I can't reproduce in its entirety here), which culminates in the 
complaint that a file (/var/run/httpd/ipa/clientcaches/@) 
was not found.  What it seems like is that multiple attempts to join the domain 
from different hosts are stepping on one another.

I'm wondering if I am trying to do something that is not supported, or if I 
have something misconfigured.  I'm tempted to catch the error and retry after a 
random interval (the output of the failing command indicates that it is rolling 
back to the initial state) - that would be the easiest thing.  But if this is 
pointing to an underlying error on my part I'd rather fix it if possible.

Additional info in case it helps - I'm running RHEL7/FreeIPA4.2 on the servers 
(two in a replication agreement).  I'm running RHEL6/FreeIPA3.0 on the clients 
(most recent attempt I tried to launch 7 instances, three of which failed).  
Thanks.

Tony


-- 
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

2016-01-28 Thread Rob Crittenden

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_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?

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_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 
>>  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 
>>>  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 
 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

Re: [Freeipa-users] ipa replica is ad trust controller but refuses ad users

2016-01-28 Thread Jakub Hrozek

On Thu, Jan 28, 2016 at 02:39:47PM +0100, Rob Verduijn wrote:
> hmmm
> It suddenly started to work.weird.
> 
> On both servers I changed  dns_lookup_realm = true (was false)
> stoped sssd and cleared the sssd cache
> rm /var/lib/sss/db/*
> started sssd and it works now

it's hard to tell w/o logs but the sssd re-fetches the keytab it uses to
establish the connection to the AD DCs on sssd restart (we implemeted
this precisely so that admins have a known point -- sssd restart) when
things go wrong. Maybe sssd just picked the trust keytab only after
restart, not sure..

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa replica is ad trust controller but refuses ad users

2016-01-28 Thread Rob Verduijn

hmmm
It suddenly started to work.weird.

On both servers I changed  dns_lookup_realm = true (was false)
stoped sssd and cleared the sssd cache
rm /var/lib/sss/db/*
started sssd and it works now

But I find it hard to believe that was the cause.
Is there a cache involved somewhere ?

Rob Verduijn

2016-01-28 13:26 GMT+01:00 Rob Verduijn :
> Hello,
>
> I've set up an ipa-server with an one way trust to a windows 2012r2 
> controller.
> All works on this server.
> I can login with ad accounts on this server.
>
> I added an ipa replica, and checked it all worked.
>
> Now I tried
> ipa-trust-add --add-agents on the first ipa server.
> restarted ipa on both servers
>
> but this did not help
> then i did a
> ipa-adtrust-install on the second ipa server
> and a ipa trust-add --type=ad windows.domain
>
> all dns queries from the docs work
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#verify-dns-configuration
>
> I get both ipa servers returned in the queries.
> On the windows server and the ipa server.
>
> On the first ipaserver I can issue : id WINDOWS.DOMAIN\\ad-user
> and get an answer
> On the second I get : unknown user
>
> What could be the cause of this, why does the second server not do
> ad-authentication ?
>
> Rob Verduijn

-- 
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-28 Thread Christian Heimes

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

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] Client-Install failures

2016-01-28 Thread Simo Sorce

It is where mod_auth_gssapi drops the ccache file indeed.
But if it failed to do so you should have an authentication error in the logs.

Can you check if you see anything in the error log, perhaps rasing logging 
level to debug.

Simo.

- Original Message -
> From: "David Zabner" 
> To: "Simo Sorce" 
> Cc: "Martin Kosek" , freeipa-users@redhat.com
> Sent: Thursday, January 28, 2016 10:18:06 AM
> Subject: Re: [Freeipa-users] Client-Install failures
> 
> Any guess as what it would be then?
> The location that is “missing a file” is specified by the gssapi config in
> /etc/httpd/conf.d/ipa.conf. So I assumed that this would be a mod_gssapi
> failure…
> 
> 
> Thanks for your help,
> David
> > On Jan 28, 2016, at 5:55 AM, Simo Sorce  wrote:
> > 
> > Doesn't look related to mod_auth_gssapi, it's past it.
> > 
> > - Original Message -
> >> From: "Martin Kosek" 
> >> To: "David Zabner" , freeipa-users@redhat.com, "Simo
> >> Sorce" 
> >> Sent: Thursday, January 28, 2016 4:42:57 AM
> >> Subject: Re: [Freeipa-users] Client-Install failures
> >> 
> >> On 01/26/2016 10:20 PM, David Zabner wrote:
> >>> Hi All,
> >>> I am working on automated deployment of ipa clients through a program
> >>> called salt and have been seeing an issue.
> >>> Specifically, calls to ipa.server.internal/ipa/json occasionally return a
> >>> 500 error. This tends to occur while using ipa-client-install and ipa-dns
> >>> commands.
> >>> 
> >>> I am on free-ipa v 4.2.0 running on Centos 7 and will include the
> >>> offending
> >>> httpd error log.
> >>> Thanks for your help,
> >>> David
> >> 
> >> CCing Simo, I wonder if this error could be some problem caused by
> >> mod_auth_gssapi?
> >> 
> >> [Tue Jan 26 20:28:00.456181 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] mod_wsgi (pid=9535): Exception occurred processing WSGI
> >> script '/usr/share/ipa/wsgi.py'.
> >> [Tue Jan 26 20:28:00.456211 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] Traceback (most recent call last):
> >> [Tue Jan 26 20:28:00.456223 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220]   File "/usr/share/ipa/wsgi.py", line 49, in
> >> application
> >> [Tue Jan 26 20:28:00.456245 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] return api.Backend.wsgi_dispatch(environ,
> >> start_response)
> >> [Tue Jan 26 20:28:00.456251 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220]   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 258, in
> >> __call__
> >> [Tue Jan 26 20:28:00.456263 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] return self.route(environ, start_response)
> >> [Tue Jan 26 20:28:00.456268 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220]   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 270, in
> >> route
> >> [Tue Jan 26 20:28:00.456276 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] return app(environ, start_response)
> >> [Tue Jan 26 20:28:00.456281 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220]   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 447, in
> >> __call__
> >> [Tue Jan 26 20:28:00.456288 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] response = super(jsonserver,
> >> self).__call__(environ,
> >>  start_response)
> >> [Tue Jan 26 20:28:00.456293 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220]   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 647, in
> >> __call__
> >> [Tue Jan 26 20:28:00.456299 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] 'xmlserver', user_ccache, environ, start_response,
> >> headers)
> >> [Tue Jan 26 20:28:00.456304 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220]   File
> >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 593, in
> >> finalize_kerberos_acquisition
> >> [Tue Jan 26 20:28:00.456310 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] session_data['ccache_data'] =
> >> load_ccache_data(ccache_name)
> >> [Tue Jan 26 20:28:00.456315 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220]   File
> >> "/usr/lib/python2.7/site-packages/ipalib/session.py",
> >> line1231, in load_ccache_data
> >> [Tue Jan 26 20:28:00.456330 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] src = open(name)
> >> [Tue Jan 26 20:28:00.456344 2016] [:error] [pid 9535] [remote
> >> 10.11.135.180:220] IOError: [Errno 2] No such file or directory:
> >> '/var/run/httpd/ipa/   clientcaches/admin@FOO.INTERNAL'
> >> 
> >> Martin
> >> 
> 
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa replica is ad trust controller but refuses ad users

2016-01-28 Thread Jakub Hrozek

On Thu, Jan 28, 2016 at 03:36:04PM +0100, Jakub Hrozek wrote:
> On Thu, Jan 28, 2016 at 02:39:47PM +0100, Rob Verduijn wrote:
> > hmmm
> > It suddenly started to work.weird.
> > 
> > On both servers I changed  dns_lookup_realm = true (was false)
> > stoped sssd and cleared the sssd cache
> > rm /var/lib/sss/db/*
> > started sssd and it works now
> 
> it's hard to tell w/o logs but the sssd re-fetches the keytab it uses to
> establish the connection to the AD DCs on sssd restart (we implemeted
> this precisely so that admins have a known point -- sssd restart) when
> things go wrong. Maybe sssd just picked the trust keytab only after

oops, sorry, wrong parens. sssd always re-fetches the keytab from IPA
master it's running on, not only when things go wrong. The sssd restart
just is just a way for the admin to trigger this.

> restart, not sure..

-- 
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

Re: [Freeipa-users] FREAK Vulnerability

Re: [Freeipa-users] Kerberos process coredump | authentication fails

Re: [Freeipa-users] Client-Install failures

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

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

Re: [Freeipa-users] Kerberos process coredump | authentication fails

Re: [Freeipa-users] SSSD Crash Causing Inaccessibility

Re: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Freeipa-users] SSSD Crash Causing Inaccessibility

Re: [Freeipa-users] SSSD Crash Causing Inaccessibility

Re: [Freeipa-users] Active Directory users are not controlled by HBAC

Re: [Freeipa-users] SSSD and DNS

Re: [Freeipa-users] Cross Domain Trust

Re: [Freeipa-users] Client-Install failures

Re: [Freeipa-users] Centos 7, CA log files, bug report?

Re: [Freeipa-users] ERROR: missing attribute "ipaNTSecurityIdentifier" required by object class "ipaNTUserAttrs"

Re: [Freeipa-users] Kerberos process coredump | authentication fails

Re: [Freeipa-users] FREAK Vulnerability

[Freeipa-users] ipa replica is ad trust controller but refuses ad users

Re: [Freeipa-users] FREAK Vulnerability

[Freeipa-users] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

Re: [Freeipa-users] Kerberos process coredump | authentication fails

Re: [Freeipa-users] Kerberos process coredump | authentication fails

Re: [Freeipa-users] Kerberos process coredump | authentication fails

Re: [Freeipa-users] Kerberos process coredump | authentication fails

Re: [Freeipa-users] Client-Install failures

Re: [Freeipa-users] Kerberos process coredump | authentication fails

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

Re: [Freeipa-users] FREAK Vulnerability

Re: [Freeipa-users] ipa replica is ad trust controller but refuses ad users

Re: [Freeipa-users] ipa replica is ad trust controller but refuses ad users

Re: [Freeipa-users] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

Re: [Freeipa-users] Client-Install failures

Re: [Freeipa-users] ipa replica is ad trust controller but refuses ad users

35 matches

Site Navigation

Mail list logo

Footer information