Re: One account for modifying directory and wiki

2017-11-20 Thread John Lewis
On Mon, 2017-11-20 at 12:28 +0100, William Brown wrote:
> What do you mean by this? As in "make it so anyone can login to the
> wiki"? Just don't add access controls IE group membership or filter
> tests in the media wiki ldap config. Then "anyone with a valid ldap
> account" can login, with NO aci changes needed for openldap,
> 
> Hope that helps, if I recall, media wiki has great ldap connection
> docs,
> 


I mean a standard email account, like the kind in any Internet forum,
but the user can also manipulate the an LDAP tree using the same
credentials. 

I did a lot of research over the weekend including looking at the
slides of the LDAP conferences over the last couple years for clues.

The only already done thing that may do what I want seems to be the
proprietary version of LAM https://www.ldap-account-manager.org/lamcms/
.

I think I may be better off writing a plugin to web2ldap and or
mediawiki so I can be sure it does what I want because I can test and
fix it without asking for permission.



Re: ssf Security Question

2017-11-20 Thread William Brown
On Mon, 2017-11-20 at 11:22 +, Howard Chu wrote:
> William Brown wrote:
> > On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:
> > > William Brown wrote:
> > > > Just want to point out there are some security risks with ssf
> > > > settings.
> > > > I have documented these here:
> > > > 
> > > > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_tra
> > > > p.ht
> > > > ml
> > > 
> > > Nice writeup. I always considered SSF values to be naive and
> > > somewhat
> > > overrated. People expect too much when looking at these numbers -
> > > especially regarding the "strength" of cryptographic algorithms
> > > which
> > > changes over time anyway with new cryptanalysis results coming
> > > up.
> > > 
> > > Personally I always try to implement a TLS-is-must policy and
> > > prefer
> > > LDAPS (with correct protocol and ciphersuites configured) over
> > > LDAP/StartTLS to avoid this kind of pre-TLS leakage.
> > > Yes, I deliberately ignore "LDAPS is deprecated". ;-]
> > 
> > I agree. If only there was a standards working group that could
> > deprecate startTLS in favour of TLS  :)
> 
> I have to agree as well. On my own servers I also use TLS on other
> "plaintext" 
> ports too (such as pop3 and others) that no one has any business
> connecting to 
> in plaintext.

Yep. TLS and end-to-end is the way of the future. We need to update our
documents to support this :) 

> 
> > > Furthermore some LDAP server implementation (IIRC e.g. MS AD)
> > > refuse
> > > to
> > > accept SASL/GSSAPI bind requests sent over TLS-secured channel.
> > > Which
> > > is
> > > IMO also somewhat questionable.
> > 
> > Yes, I really agree. While a plain text port exists, data leaks are
> > possible. We should really improve this situation, where we have
> > TLS
> > for all data to prevent these mistakes.
> > 
> > I think a big part of the issue is that GSSAPI forces the
> > encryption
> > layer, and can't work via an already encrypted channel. The people
> > I
> > know involved in this space are really resistant to changing this
> > due
> > to the "kerberos centric" nature of the products.
> 
> Interesting. Our libldap/liblber works fine with GSSAPI's encryption
> layered 
> over TLS and vice versa.
> 

Sadly your libldap/liblber is not the only one we have to use. I'm told
that especially AD for IPA trust's is unable to do GSSAPI-over-TLS.

Really, IMO if the SSF is already > 1, then GSSAPI shouldn't install
encryption layer, but you know, I'm not the one who writes the SASL
code ... If you have some contacts in this space, I'm open to
suggestion as to how we can proceed to improve this, 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane




Re: One account for modifying directory and wiki

2017-11-20 Thread William Brown
On Fri, 2017-11-17 at 07:46 -0500, John Lewis wrote:
> On Fri, 2017-11-17 at 12:51 +1000, William Brown wrote:
> > On Thu, 2017-11-16 at 11:26 -0500, John Lewis wrote:
> > > I want to have one account for modifying both a LDAP directory
> > > and
> > > a
> > > Mediawiki. What tactic would you you use to do it?
> > 
> > I'm not sure this is a tough issue: the access controls are
> > seperate
> > in
> > these cases.
> > 
> > On one hand from the LDAP directory management side, you only need
> > the
> > ACI/ACL's in place on the config/tree that would allow writes to
> > appropriate locations. There is plenty of docs on aci/acl placement
> > and
> > construction for this.
> > 
> > From the mediawiki side, you can search users and use an ldap
> > backend
> > to do password checks (binds) and then use groups to provide
> > authorization control as to "who" can access the wiki.
> > 
> > I hope that helps you,
> 
> Is that configuration self serviceable, as in the user can request
> their own account with the permissions I deem them to have?

What do you mean by this? As in "make it so anyone can login to the
wiki"? Just don't add access controls IE group membership or filter
tests in the media wiki ldap config. Then "anyone with a valid ldap
account" can login, with NO aci changes needed for openldap,

Hope that helps, if I recall, media wiki has great ldap connection
docs,



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane




Re: ldap_sasl_interactive_bind_s: Can't contact LDAP server

2017-11-20 Thread Turbo Fredriksson
On 20 Nov 2017, at 11:06, Clément OUDOT  wrote:

> 2017-11-20 11:59 GMT+01:00 Turbo Fredriksson :
>> You’ve never had the issue I’m having? Or heard about it?
> 
> No but I don't use Kerberos authentication.

Ok, thanx for the info!!


signature.asc
Description: Message signed with OpenPGP


Re: ssf Security Question

2017-11-20 Thread Howard Chu

William Brown wrote:

On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:

William Brown wrote:

Just want to point out there are some security risks with ssf
settings.
I have documented these here:

https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht
ml


Nice writeup. I always considered SSF values to be naive and somewhat
overrated. People expect too much when looking at these numbers -
especially regarding the "strength" of cryptographic algorithms which
changes over time anyway with new cryptanalysis results coming up.

Personally I always try to implement a TLS-is-must policy and prefer
LDAPS (with correct protocol and ciphersuites configured) over
LDAP/StartTLS to avoid this kind of pre-TLS leakage.
Yes, I deliberately ignore "LDAPS is deprecated". ;-]


I agree. If only there was a standards working group that could
deprecate startTLS in favour of TLS  :)


I have to agree as well. On my own servers I also use TLS on other "plaintext" 
ports too (such as pop3 and others) that no one has any business connecting to 
in plaintext.



Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse
to
accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which
is
IMO also somewhat questionable.


Yes, I really agree. While a plain text port exists, data leaks are
possible. We should really improve this situation, where we have TLS
for all data to prevent these mistakes.

I think a big part of the issue is that GSSAPI forces the encryption
layer, and can't work via an already encrypted channel. The people I
know involved in this space are really resistant to changing this due
to the "kerberos centric" nature of the products.


Interesting. Our libldap/liblber works fine with GSSAPI's encryption layered 
over TLS and vice versa.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/



Re: ldap_sasl_interactive_bind_s: Can't contact LDAP server

2017-11-20 Thread Clément OUDOT
2017-11-20 11:59 GMT+01:00 Turbo Fredriksson :
> You’ve never had the issue I’m having? Or heard about it?

No but I don't use Kerberos authentication.



Re: ldap_sasl_interactive_bind_s: Can't contact LDAP server

2017-11-20 Thread Turbo Fredriksson
On 20 Nov 2017, at 08:07, Clément OUDOT  wrote:

> 2017-11-19 18:09 GMT+01:00 Turbo Fredriksson :
> 
>> Have anyone tried running OpenLDAP behind HAProxy?
> 
> I do this often, without any particular issue.

Ok, thanx. I thought so :(. I might be running an old version (v1.6.10) perhaps?

You’ve never had the issue I’m having? Or heard about it?


signature.asc
Description: Message signed with OpenPGP


Re: ldap_sasl_interactive_bind_s: Can't contact LDAP server

2017-11-20 Thread Clément OUDOT
2017-11-19 18:09 GMT+01:00 Turbo Fredriksson :

> Have anyone tried running OpenLDAP behind HAProxy? Anything special
> one needs to do?

I do this often, without any particular issue. If you use LDAPS, you
can add option ssl-hello-chk.

Here is a sample configuration file:

global
log 127.0.0.1 local5 notice
chroot /var/lib/haproxy
user haproxy
group haproxy
daemon
quiet

defaults
log global
option  dontlognull
option  ldap-check
retries 3
modetcp
balance roundrobin
option redispatch

listen  openldap :389
 server ldap1 IP_LDAP1:390 check
 server ldap2 IP_LDAP2:390 check
 server ldap3 IP_LDAP3:390 check

defaults
log global
option  dontlognull
retries 3
modetcp
balance roundrobin
option redispatch
option ssl-hello-chk

listen  openldap-ssl :636
 server ldap1 IP_LDAP1:637 check
 server ldap2 IP_LDAP2:637 check
 server ldap3 IP_LDAP3:637 check




Clément.