openldap-technical April 2016

openldap-technical@openldap.org

40 participants
56 discussions

Re: slapd ACL - limit bind to employeeType=<various>
by Tim Watts 11 Apr '16

11 Apr '16

Hi Michael, On 11/04/16 07:31, Michael Ströder wrote: > Tim Watts wrote: > # some entries matching filter > access to > attrs=userPassword > filter=(!(employeeType=Archive)(employeeType=Delete)) > by ..some who clauses for setting password > by * auth > > # all other entries > access to > attrs=userPassword > by * none > > The second ACL is important! OK - I'm going to have to get my head around that :) On a test platform... Am I right in thinking the job of the 2nd ACL is because if employeeType is Archive|Delete, the first ACL will simple fall through - so the second ACL is semantically a "Deny All"? One other thing - I did not mention, which is retrospect might be important: I don't let slapd store password hashes - it passes through to Kerberos via saslauthd. So the attribute is of this form: userPassword: {SASL}someuser(a)MY.KERB.REALM I presume that blocking access to userPassword will still cause authentication to fail in this case as it won't be able to do that lookup? >> Current ACLs are fairly simple: >> >> access to dn.base="" by * read >> >> access to attrs=userPassword >> by peername.path="/var/run/slapd/ldapi" manage > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This is somewhat dangerous because it gives any process which has write access > to the LDAPI socket *manage* rights. I'd recommend not to do that. Rather use > authz-regexp mappings to explicitly map certain OS accounts to real LDAP entries. I thought you'd say that :) I'm OK with limiting access to the parent directory (in this case to the slapd user and root). For me, it feels simpler. You may disagree, but I just wanted to say it wasn't an oversight. >> by set="user/uid & >> [cn=sysadmin,ou=groups,dc=dighum,dc=kcl,dc=ac,dc=uk]/memberUid" manage > > Set-ACLs are slow. I'd recommend to use groupOfNames entries to achieve this. OK - I will have to study that - thanks for pointing it out. Off to clone a test server off the production one.... I could have done with getting a bit more of this right the first time, but it was sadly a rush job at the time. Now seems like a good time to put some polish on it. All that best! Tim -- Tim Watts Tel (VOIP): +44 (0)1580 848360 Systems Manager Kings Digital Lab (KDL), King's College London Systems Messages and Notifications: https://systemsblog.cch.kcl.ac.uk/

2 1

slapd ACL - limit bind to employeeType=<various>
by Tim Watts 10 Apr '16

10 Apr '16

Hi, Sorry - this is probably very basic, but I cannot get my head around how to write an ACL that prevents "auth" unless the user's employeeType attribute is in a particular list (or NOT in a shorter list). I have a slapd config line: constraint_attribute employeeType regex ^(Staff|External|MA|PhD|Intern|System|Archive|Delete)$ However, I'd like to limit the ability to bind (auth) to those users whose employeeType is NOT [regex ^(Archive|Delete)$] or, less preferable, IS Staff|External|MA|PhD|Intern|System At the moment I apply the constrain in pam-ldap, but that's not terribly elegant and of course does not work if apache2's mod_authnz_ldap checks directly with the LDAP server. Many thanks for pointers :) Tim PS Current ACLs are fairly simple: access to dn.base="" by * read access to attrs=userPassword by peername.path="/var/run/slapd/ldapi" manage by set="user/uid & [cn=sysadmin,ou=groups,dc=dighum,dc=kcl,dc=ac,dc=uk]/memberUid" manage by self write by * auth # Certain attributes that should not be publically readable access to attrs=bindTimestamp,modifyTimestamp,modifiersName,creatorsName,c reateTimestamp by peername.path="/var/run/slapd/ldapi" manage by set="user/uid & [cn=sysadmin,ou=groups,dc=dighum,dc=kcl,dc=ac,dc=uk]/memberUid" manage by self read by * none -- Tim Watts Tel (VOIP): +44 (0)1580 848360 Systems Manager Kings Digital Lab (KDL), King's College London Systems Messages and Notifications: https://systemsblog.cch.kcl.ac.uk/

3 2

LDAPI mechanism too weak for this user
by Frank Crow 08 Apr '16

08 Apr '16

I have locked down my server to disallow anonymous binds and set the SSF=128. I also have SaslSecProps: noplain,noanonymous,minssf=128 Which all seems to work fine for my usage with one exception. If I try to use any of the command line tools with "-Y EXTERNAL -H ldapi:///", I now get: additional info: SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak Is there some configuration item that I can change to allow that work while maintaining my existing policy of no anonymous binds for everything else, etc? Thanks, -- Frank

4 3

TLS error/warning messages output
by Frank Crow 07 Apr '16

07 Apr '16

I'm writing a "C" client that connects with SASL EXTERNAL and yesterday, when it ran it output the following: SASL/EXTERNAL authentication started > SASL username: cn=xxxx,ou=yyyy,ou=zzz,o=aaa,dc=bbbb,dc=ccc > SASL SSF: 0 Which is exactly what I was expecting. Actually is still what I'm expecting. So some changes occurred on the server and the client which resulted in this now being output: TLS: error: the certificate '/etc/openldap/certs/xxxxx.crt' could not be > found in the database - error -12285:Unable to find the certificate or key > necessary for authentication.. > TLS: certificate '/etc/openldap/certs/xxxxx.crt' successfully loaded from > PEM file. > TLS: no unlocked certificate for certificate > 'CN=xxxx,OU=yyyy,OU=zzz,O=aaa,DC=bbbb,DC=ccc'. > SASL/EXTERNAL authentication started > SASL username: cn=xxxx,ou=yyyy,ou=zzz,o=aaa,dc=bbbb,dc=ccc > SASL SSF: 0 I have verified that I am not setting LDAP_OPT_DEBUG_LEVEL and I even tried setting it to "0" explicitly but I still get the same thing! I have seen that before when I set debugging to ANY but I really rather not have this warning output if possible. Does anyone know why this would be occurring or what I can do to turn off those TLS warning/error messages? Thanks, -- Frank

1 0

Re: using ldap_sasl_interactive_bind_s() with EXTERNAL only
by Frank Crow 06 Apr '16

06 Apr '16

Oh cool! I'll give that a try! Thanks, Frank On Tue, Apr 5, 2016 at 5:37 PM, David Hawes <dhawes(a)vt.edu> wrote: > On 5 April 2016 at 16:44, Frank Crow <fjcrow2008(a)gmail.com> wrote: > > Hi, > > > > I'm only ever going to use sasl_mech="EXTERNAL" with my client code. I > > tried using ldap_sasl_bind_s() but that returned with > > LDAP_SASL_BIND_IN_PROGRESS. > > > > I then used ldap_sasl_interactive_bind_s() based on the example in > > clients/tools/common.c more or less. I don't actually need the > defaults > > struct, so I pass defaults=NULL and therefore don't use anything like > > lutil_sasl_defaults(), etc. > > > > I implemented a LDAP_SASL_INTERACT_PROC using the example in > > libraries/liblutil/sasl.c which is very similar to lutil_sasl_interact() > > except that it doesn't support LDAP_SASL_INTERACTIVE and my version of > the > > interaction() function does nothing but return LDAP_SUCCESS. > > > > Looking at it, I could probably shorten my version of the > > lutil_sasl_interact() to simply return LDAP_SUCCESS and not even bother > with > > an interaction() function. > > > > It appears to work just fine and the debug output says: > > > >> ldap_sasl_interactive_bind: user selected: EXTERNAL > >> ldap_int_sasl_bind: EXTERNAL > >> ldap_int_sasl_open: host=server1.paxriver.progeny.net > >> => ldap_dn2bv(16) > >> <= ldap_dn2bv(cn=xxxxxxx,ou=xxxxxxx,ou=xxx,o=xxx,dc=xxxx,dc=xxx)=0 > >> SASL/EXTERNAL authentication started > >> sasl_interact() > >> ldap_sasl_bind > >> ldap_send_initial_request > >> ldap_send_server_request > >> ldap_msgfree > >> ldap_result ld 0x1366940 msgid 2 > > > > > > So my questions: > > > > 1. Is there anything wrong with that approach? > > 2. Is there a better (simpler/easier) way to do this? > > Yes. Pass an empty cred to ldap_sasl_bind_s(): > > cred.bv_val = ""; > cred.bv_len = 0; > ldap_sasl_bind_s(ldap, NULL, "EXTERNAL", &cred, NULL, NULL, NULL); > -- Frank

1 1

Using slapo-rwm to change attribute
by Roel van Meer 06 Apr '16

06 Apr '16

Hi! I have an application that uses the 'c' attribute to store a string describing a country name. The syntax of 'c' only allows a two-letter country code, but the application uses full country names. Therefore the attribute it *should* be using is 'co', or 'friendlyCountryName'. Unfortunately I cannot change this application. (It's Mozilla). I have tried using the rwm overlay to map 'c' onto 'co', which works, but then the syntax of 'c' is still enforced. I can, of course, change the schema definition of 'c' to that of 'co', but that seems bad practice. I could also disable schema schecking, but that is even worse. Are there better ways to work around this? Thanks a lot, Roel

1 0

ldap_set_options() not working but environment variables do work
by Frank Crow 05 Apr '16

05 Apr '16

Hi, I've got some code that uses ldap_start_tls_s() and the server requires client-side certificates. If I set them in the environment, e.g., # export LDAPTLS_CERT="/etc/openldap/some.crt" > # export LDAPTLS_KEY="/etc/openldap/some.key" Then everything works fine. However, if I use: const char* tls_cert="/etc/openldap/some.crt"; > const char* tls_key="/etc/openldap/some.key"; > ldap_set_option( ld, LDAP_OPT_X_TLS_CERTFILE, tls_cert ); > ldap_set_option( ld, LDAP_OPT_X_TLS_KEYFILE, tls_key ); Then it doesn't work. What am I doing wrong? Should it be "&tls_cert" and "&tls_key"? I did do an ldap_get_option() using both methods to verify and I get the value that I'm expecting either way. Thanks, -- Frank

1 1

using ldap_sasl_interactive_bind_s() with EXTERNAL only
by Frank Crow 05 Apr '16

05 Apr '16

Hi, I'm only ever going to use sasl_mech="EXTERNAL" with my client code. I tried using ldap_sasl_bind_s() but that returned with LDAP_SASL_BIND_IN_PROGRESS. I then used ldap_sasl_interactive_bind_s() based on the example in clients/tools/common.c more or less. I don't actually need the defaults struct, so I pass defaults=NULL and therefore don't use anything like lutil_sasl_defaults(), etc. I implemented a LDAP_SASL_INTERACT_PROC using the example in libraries/liblutil/sasl.c which is very similar to lutil_sasl_interact() except that it doesn't support LDAP_SASL_INTERACTIVE and my version of the interaction() function does nothing but return LDAP_SUCCESS. Looking at it, I could probably shorten my version of the lutil_sasl_interact() to simply return LDAP_SUCCESS and not even bother with an interaction() function. It appears to work just fine and the debug output says: ldap_sasl_interactive_bind: user selected: EXTERNAL > ldap_int_sasl_bind: EXTERNAL > ldap_int_sasl_open: host=server1.paxriver.progeny.net > => ldap_dn2bv(16) > <= ldap_dn2bv(cn=xxxxxxx,ou=xxxxxxx,ou=xxx,o=xxx,dc=xxxx,dc=xxx)=0 > SASL/EXTERNAL authentication started > sasl_interact() > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ldap_msgfree > ldap_result ld 0x1366940 msgid 2 So my questions: 1. Is there anything wrong with that approach? 2. Is there a better (simpler/easier) way to do this? Any advice is highly appreciated! Thanks, Frank

1 0

Openldap 2.4.44 syncprov delays
by Frank Swasey 04 Apr '16

04 Apr '16

Folks, I have recently upgraded my ldap servers (RHEL6, locally built RPM) from 2.4.42 to 2.4.44. After several days of chasing why our nagios checks for syncrepl performance were reporting long delays, I gave up and rolled the primary server back to 2.4.42. This week I have built a primary and replica on RHEL7 with 2.4.44 (again locally built) and have just discovered through some intensive testing and log crawling that the syncprov log entries (with loglevel sync) show up lacking the csn about every hour, and if there are outstanding changes to be replicated when that happens, the syncrepl check on the replica server starts reporting it has fallen behind. This behavior does not exhibit with the 2.4.42 code base. Is this the new normal? Is there something (that has not yet made it into the guide) that I need to change in my syncprov/syncrepl configuration to get around this? This is a “normal” syncprov log entry: Apr 1 18:18:40 ldap7p slapd[10061]: syncprov_sendresp: cookie=rid=100,csn=20160401221840.842942Z#000000#000#000000 This is one of the new ones: Apr 1 18:14:28 ldap7p slapd[10061]: syncprov_sendresp: cookie=rid=100 -- Frank Swasey Sr Systems Administrator Systems Architecture & Administration University of Vermont

2 4

Securing an LADP server.
by Jerry 01 Apr '16

01 Apr '16

I am looking for easy to implement suggestions for securing an LDAP server. First, this is an OpenLDAP-2.4 server running on a FreeBSD-11 machine. The two laptops I carry are both running Windows 10 PRO. I want to be able to access the LDAP server from these machines when I am traveling; however, I want to make sure that not just anyone could gain access to the LDAP server. Primarily, the server would be accessed by my MUA to lookup email addresses. -- Jerry

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2016