Re: [Freeipa-users] DNS Module (DNSSEC) NSEC§

2016-01-21 Thread Martin Basti 

Hello,

you can try to set up NSEC3PARAM record for zone

ipa dnszone-mod example.com. --nsec3param-rec "  
 "


Martin

On 20.01.2016 20:33, Günther J. Niederwimmer wrote:

Hello,

I can't find a way to integrate NSEC3, all DOC's I found is only for DNSSEC,
but not including NSEC3.

Can any help me to set up this correct ?

Thanks for a answer,



--
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-21 Thread Martin Kosek 
On 01/21/2016 03:31 PM, 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.
> 
> I've got
> 
> NSSCipherSuite -all,-exp,+
> 
> I've restarted httpd and ipa but it still fails
> 
> Is there something I have overlooked
> 
> Thanks, Terry
> 
> 
> 
> The Manheim group of companies within the UK comprises: Manheim Europe 
> Limited (registered number: 03183918), Manheim Auctions Limited (registered 
> number: 00448761), Manheim Retail Services Limited (registered number: 
> 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time 
> Communications Limited (registered number: 04277845) and Complete Automotive 
> Solutions Limited (registered number: 05302535). Each of these companies is 
> registered in England and Wales with the registered office address of Central 
> House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies 
> operates under various brand/trading names including Manheim Inspection 
> Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim 
> Aftersales Solutions.
> 
> V:0CF72C13B2AC

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.

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

[Freeipa-users] FREAK Vulnerability

2016-01-21 Thread Terry John 
I've been trying to tidy the security on my FreeIPA and this is causing me some 
problems. I'm using OpenVAS vulnerability scanner and it is coming up with this 
issue

EXPORT_RSA cipher suites supported by the remote server:
TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006)
TLSv1.0: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0003)

It seems we have to disable export  TLS ciphers but I can't see how. I've 
edited /etc/httpd/conf.d/nss.conf and disabled all SSL and TLSV1.0.

I've got

NSSCipherSuite -all,-exp,+

I've restarted httpd and ipa but it still fails

Is there something I have overlooked

Thanks, Terry



The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC


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

Re: [Freeipa-users] ipa-client-install and nsslapd-allow-anonymous-access: off

2016-01-21 Thread Martin Kosek 
On 01/21/2016 02:29 PM, bahan w wrote:
> Hello Martin.
> 
> Thank you for your answer.

Adding freeipa-users list back, so that others can follow the thread.

> Excuse me for my ignorance, but may you tell me how the bug and resolution
> work for FreeIPA ?

This is probably not something that would require own upstream release, it is
too old version no longer developed upstream. It may be rather fixed
downstream, in RHEL (I cannot promise anything though).

I wonder, do RHEL-7.x clients work in your environment? RHEL-7.1+ should have
https://fedorahosted.org/freeipa/ticket/
applied which may fix the issue.

> Will there be a new release concerning IPA 3.0.0, or a patch to apply ?

There may be RHEL-6.x fix. If you have RHEL subscription, I would recommend
pointing your Support Representative to Bug 1300561 below, to get higher
priority for the bug.

> Best regards.
> 
> Bahan
> 
> 
> On Thu, Jan 21, 2016 at 8:21 AM, Martin Kosek  wrote:
> 
>> On 01/20/2016 05:55 PM, bahan w wrote:
>>> Ah sorry, for security reasons I didn't want to put the original name
>> and I
>>> made a mistake.
>>>
>>> Here we are, for the confusing lines :
>>> ###
>>> Assuming realm is the same as domain: 
>>> Generated basedn from realm: dc=
>>> Discovery result: NO_ACCESS_TO_LDAP; server=None, domain=,
>>> kdc=None, basedn=dc=
>>> Validated servers: 
>>> will use discovered domain: 
>>> Using servers from command line, disabling DNS discovery
>>> will use provided server: 
>>> will use discovered realm: 
>>> The provided realm name [] does not match discovered one
>>> []
>>> (: Assumed same as domain)
>>> Installation failed. Rolling back changes
>>> IPA client is not configured on this system.
>>> ###
>>>
>>> Is it more clear ? Sorry again for the confusion.
>>>
>>> I use a realm which is different than the domain.
>>
>> Ah, I see. I think you just found a bug. The problem is that given the
>> server
>> is not reachable, the realm is calculated based on the domain and then
>> rejected
>> as it is different from the option. In this case, ipa-client-install should
>> just accept the realm passed to the script. It is very specific condition,
>> but
>> we should be able to fix that easily
>>
>> I filed a bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1300561
>>
>> We will need to think if there is a workaround for you until the fix is
>> delivered.
>>
> 

-- 
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] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

2016-01-21 Thread Ludwig Krispenz 


On 01/21/2016 08:50 AM, Nathan Peters wrote:

I don't know if this makes a difference too, but I performed the same checks on 
a different completely working and joined FreeIPA master, against other 
masters, and even against itself directly.

It seems that no account, no keytab, and no host can see that mapping tree 
branch no matter who they search from or against if GSSAPI is used.
there should be no difference in the result, it should only depend on 
the acis and in one of your previous posts you said that you don't get a 
result bound as admin:

>>>

[root@dc2-ipa-dev-van ~]# ldapsearch -Hldaps://dc2-ipa-dev-nvan.mydomain.net  -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D 
"uid=admin,cn=users,cn=accounts,dc=mydomain,dc=net" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

2016-01-21 Thread Rich Megginson 

On 01/21/2016 12:50 AM, Nathan Peters wrote:

I don't know if this makes a difference too, but I performed the same checks on 
a different completely working and joined FreeIPA master, against other 
masters, and even against itself directly.

It seems that no account, no keytab, and no host can see that mapping tree 
branch no matter who they search from or against if GSSAPI is used.


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters
Sent: January-20-16 11:41 PM
To: Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists

All checks below were performed from the host we are trying to turn into a 
replica and they were performed against the master who logs I also show

The first check was to kinit admin and try the search.  Surprisingly, the 
GSSAPI bind returns no results when we search that.  In my previous email you 
can see that the standard bind gets a result as admin for that search.

Next, I tried as the host by kinit with its keytab.  Same result, nothing back.

Finally I tried as my own personal admin user.  Same result, nothing back.

For good measure, I tried a broad search against the base "cn=mydomain,cn=net" 
as each user as well and I'll spare you the ten thousand lines of screenshot but the 
results were as expected, several thousand entries in that tree.
Although the output differed slightly.  This is the total as admin or my 
personal user # numResponses: 3372 # numEntries: 3371

and this is the total as the host keytab account

# numResponses: 3371
# numEntries: 3370

To be even more thorough, I did searches farther and farther up the config tree 
using GSSAPI until I found something.  The only thing that is visible through 
GSSAPI searches is the base of the config tree.  Even the mapping tree branch 
doesn't seem to be visible.

At the very bottom of this email is the results of the search against cn=config 
directly as the attempted new replica and as admin.  Admin gets about 50 
results and the host only gets about 30 for some reason.  I get the same 
results as admin on my personal account so I've excluded those.

So if I got all that right I was able to determine that only the base of the 
config tree is available using GSSAPI for any account, users for some reason 
get slightly more results than hosts, and all accounts can see the 
dc=mydomain,dc=net tree just fine using GSSAPI.

So does that help shed some light on what the cause of this might be or why the 
server is not answering as expected?

Is there some way I can adjust this so everyone can see the results they do 
using regular binds as they do using GSSAPI binds ?

Is there some way I can check ACLS on stuff ?


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Viewing_the_ACIs_for_an_Entry.html

Note: There is a bug in the docs.  You have to also specify the suffix 
e.g. "-b cn=config", and make sure the search filter is quoted e.g. 
'(aci=*)'


If it is not aci related, I have no idea why you would get different 
results depending on if you did a simple bind vs. a gssapi bind with the 
same user that mapped to the same bind DN.




===
search as admin
===
[nathan.peters@dc2-ipa-dev-van ~]$ klist Ticket cache: 
KEYRING:persistent:756600344:756600344
Default principal: ad...@mydomain.net

Valid starting ExpiresService principal
20/01/16 22:53:18  21/01/16 22:53:08  krbtgt/mydomain@mydomain.net 
[nathan.peters@dc2-ipa-dev-van ~]$ ldapsearch -Y GSSAPI -H 
ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config"
SASL/GSSAPI authentication started
SASL username: ad...@mydomain.net
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] FREAK Vulnerability

2016-01-21 Thread Christian Heimes 
On 2016-01-21 15:51, Martin Kosek wrote:
> On 01/21/2016 03:31 PM, 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.
>>
>> I've got
>>
>> NSSCipherSuite -all,-exp,+
>>
>> I've restarted httpd and ipa but it still fails
>>
>> Is there something I have overlooked
>>
>> Thanks, Terry

Hi Terry,

the syntax of your NSSCipherSuite stanza is wrong. mod_nss has a
different syntax for NSSCipherSuite than mod_ssl has for SSLCipherSuite.
The native mod_nss syntax doesn't support qualifiers such as 'all' or
'exp'. You have to put in the NSS names of cipher suites. If you use the
native syntax, then mod_nss disables all ciphers suites that are not listed.

mod_nss also supports OpenSSL's / mod_ssl's syntax if you use ':'
instead of ',' as separator. But I advice against the alternative syntax
because it is not as well tested as the native syntax. For example '!'
prefix used to be broken (CVE-2015-5244) and '+' prefix causes another
issue (https://fedorahosted.org/mod_nss/ticket/20).

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

The NSSCipherSuite from
https://fedorahosted.org/freeipa/ticket/5589#comment:6 has been reviewed
by a couple of people and has been tested with ssllabs.com. The script
nssciphersuite.py​ in the ticket explains why certain algorithms and
cipher suites have been removed.

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] FREAK Vulnerability

2016-01-21 Thread Terry John 
>> I've been trying to tidy the security on my FreeIPA and this is
>> causing me some problems. I'm using OpenVAS vulnerability scanner and
>> it is coming up with this issue
>>
>> EXPORT_RSA cipher suites supported by the remote server:
>> TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006)
>> TLSv1.0: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0003)
>>
>> It seems we have to disable export  TLS ciphers but I can't see how. I've 
>> edited /etc/httpd/conf.d/nss.conf and disabled all SSL and TLSV1.0.
>
>> NSSCipherSuite -all,-exp,+
>>
>> I've restarted httpd and ipa but it still fails
>>
>> Is there something I have overlooked


>Hi Terry,
>
>Please check
>https://fedorahosted.org/freeipa/ticket/5589
>
>We are trying to come up with a better cipher suite right now. The fix should 
>be in some of the next FreeIPA 4.3.x versions.
>
>The ticket has more details in it.

Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
that ticket but none so far has eliminated the FREAK report.
Christian thanks for the heads up on the syntax, I wasn't sure of what I was 
doing

Each time I've made a change I've run an sslscan from the OpenVAS scanner and I 
do get a different result each time but the errors still remains in OpenVAS.
Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.

Back to the drawing board :-)




The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC



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

Re: [Freeipa-users] FREAK Vulnerability

2016-01-21 Thread Rob Crittenden 
Christian Heimes wrote:
> On 2016-01-21 15:51, Martin Kosek wrote:
>> On 01/21/2016 03:31 PM, 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.
>>>
>>> I've got
>>>
>>> NSSCipherSuite -all,-exp,+
>>>
>>> I've restarted httpd and ipa but it still fails
>>>
>>> Is there something I have overlooked
>>>
>>> Thanks, Terry
> 
> Hi Terry,
> 
> the syntax of your NSSCipherSuite stanza is wrong. mod_nss has a
> different syntax for NSSCipherSuite than mod_ssl has for SSLCipherSuite.
> The native mod_nss syntax doesn't support qualifiers such as 'all' or
> 'exp'. You have to put in the NSS names of cipher suites. If you use the
> native syntax, then mod_nss disables all ciphers suites that are not listed.
> 
> mod_nss also supports OpenSSL's / mod_ssl's syntax if you use ':'
> instead of ',' as separator. But I advice against the alternative syntax
> because it is not as well tested as the native syntax. For example '!'
> prefix used to be broken (CVE-2015-5244) and '+' prefix causes another
> issue (https://fedorahosted.org/mod_nss/ticket/20).

By that argument one would never use any software because of previous
bugs. It should work fine now, but it there are some differences, but
note that the F-22 fix hasn't been pushed to stable yet
(https://bodhi.fedoraproject.org/updates/FEDORA-2016-6aa4dd4f3a).

+ doesn't add ciphers, it only re-orders them so is a no-op since NSS
doesn't allow cipher re-ordering.

Given you just disabled all ciphers with -ALL, -EXP is a no-op. If you
want to ban anything from adding in export ciphers later use !EXP instead.

The string is also case-sensitive and needs to be all upper-case.

But yeah, I'd check out the referenced ticket and use those as your default.

rob

> 
>> 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.
> 
> The NSSCipherSuite from
> https://fedorahosted.org/freeipa/ticket/5589#comment:6 has been reviewed
> by a couple of people and has been tested with ssllabs.com. The script
> nssciphersuite.py​ in the ticket explains why certain algorithms and
> cipher suites have been removed.
> 
> Christian
> 
> 
> 

-- 
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-21 Thread Christian Heimes 
On 2016-01-21 17:54, 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 TLS/SSL configuration of the LDAP server is handled by a different
configuration file. It's on my radar, but I haven't touched it yet. LDAP
clients and browsers are different beasts. ssllabs.com makes it very
convenient to test a site against all relevant browsers. There is no
such service for LDAP.

By the way does OpenVAS also detect issues on 389/TCP for LDAP with
STARTTLS? 389/TCP talks plain TCP first but can be upgrade to TLS with
STARTTLS.

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] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

2016-01-21 Thread Nathan Peters 
Here are the results for that aci search using a non gssapi bind by directory 
manager on the old master that we are attempting to join agains.  I don't see 
anything in this list that would indicate that some users should or should not 
have access through a certain method.  Unless one of those sasl config settings 
is doing it ?

[root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b 
"cn=config" "(aci=*)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

2016-01-21 Thread Nathan Peters 
Ok, here are the logs and console session from those searches as admin and as 
the host on the new master against itself.  Same result, nothing in there.

See my email reply to Rich I sent a few minutes ago for the directory manager 
aci search results.

==
GSSAPI search using admin on old master searching old master (current host)
==

[root@dc2-ipa-dev-nvan ~]# kinit admin
Password for ad...@dev-mydomain.net:
[root@dc2-ipa-dev-nvan ~]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_swFzxQf
Default principal: ad...@dev-mydomain.net

Valid starting ExpiresService principal
21/01/16 19:54:14  22/01/16 19:54:05  krbtgt/dev-mydomain@dev-mydomain.net
[root@dc2-ipa-dev-nvan ~]# ldapsearch -Y GSSAPI -b 
"cn=replica,cn=dc\3Ddev-mydomain\2Cdc\3Dnet,cn=mapping tree,cn=config"
SASL/GSSAPI authentication started
SASL username: ad...@dev-mydomain.net
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] idoverride-add gives incorrect, inconsistant results?

2016-01-21 Thread Jakub Hrozek 

> On 22 Jan 2016, at 01:25, Lachlan Musicman  wrote:
> 
> The /var/log/sssd/ldap_child.log have one line repeated:
> 
>  [[sssd[ldap_child[9738 [ldap_child_get_tgt_sync] (0x0010): Failed to 
> init credentials: Cannot contact any KDC for realm UNIX.CO.ORG.AU
> 
> All other log files are 0 size.

Well, sssd only logs critical failures by default. If UNIX.CO.ORG.AU is your 
IPA domain, then chances are your clients are operating offline..nonetheless it 
might be a good idea to check out 
https://fedorahosted.org/sssd/wiki/Troubleshooting and see what the logs have 
to say..

> 
> 
> cheers
> L.
> 
> --
> The most dangerous phrase in the language is, "We've always done it this way."
> 
> - Grace Hopper
> 
> On 22 January 2016 at 11:17, Lachlan Musicman  wrote:
> No, I've not updated to 1.13.0-41 - I do the "yum upgrades" relatively 
> frequently, I don't think it's in the repos yet.
> 
> cheers
> L.
> 
> --
> The most dangerous phrase in the language is, "We've always done it this way."
> 
> - Grace Hopper
> 
> On 20 January 2016 at 19:42, Jakub Hrozek  wrote:
> On Wed, Jan 20, 2016 at 09:15:47AM +1100, Lachlan Musicman wrote:
> > 1.13.0
> 
> I suspect it's 7.2, then. Did you alrady update to the latest available
> version (1.13.0-41)? If yes, do you have logfiles?
> 
> See https://fedorahosted.org/sssd/wiki/Troubleshooting
> 
> 


-- 
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] Samba crashes with recent F23 update

2016-01-21 Thread John Obaterspok 
Hello,

I'm running F23 and now IPA fails to start due to crash in smb:


-- Unit smb.service has begun starting up.
jan 22 08:38:52 ipa.win.lan audit[7037]: ANOM_ABEND auid=4294967295 uid=0
gid=0 ses=4294967295 subj=system_u:system_r:smbd_t:s0 pid=7037 comm="smbd"
exe="/usr/sbin/smbd" sig=6
jan 22 08:38:58 ipa.win.lan systemd-coredump[7038]: Process 7037 (smbd) of
user 0 dumped core.

  Stack trace of thread
7037:
  #0
 0x7f1cb7bc8a98 raise (libc.so.6)
  #1
 0x7f1cb7bca69a abort (libc.so.6)
  #2
 0x7f1cbb5c060c smb_panic (libsamba-util.so.0)
  #3
 0x7f1cb8168675 _talloc_free (libtalloc.so.2)
  #4
 0x7f1cb87a206c lpcfg_string_free (libsamba-hostconfig.so.0)
  #5
 0x7f1cb87a20a5 lpcfg_string_set (libsamba-hostconfig.so.0)
  #6
 0x7f1cb9541208 lp_load_ex (libsmbconf.so.0)
  #7
 0x7f1cb9540d5d lp_load_ex (libsmbconf.so.0)
  #8
 0x7f1cb95415c0 lp_load_initial_only (libsmbconf.so.0)
  #9
 0x55df01d405fb main (smbd)
  #10
0x7f1cb7bb4580 __libc_start_main (libc.so.6)
  #11
0x55df01d41b79 _start (smbd)
-- Subject: Process 7037 (smbd) dumped core

Anyone seen this?

samba-4.3.4-0.fc23.x86_64
freeipa-server-4.2.3-1.1.fc23.x86_64

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