openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

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

12 Apr '16

On 12/04/16 10:54, Michael Ströder wrote: > Writing OpenLDAP ACLs is a bit like functional > programming - at least to what I vaguely remember > from my time at University many years ago. > > I'd recommend to look into the OpenLDAP FAQ to > find some more not so obvious examples. :) It's something that takes time to "get" - bit like exim configuration. Very powerful, but a little bit of an art that's not quite like anything else! -- 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/

1 0

Help needed to migrate htpasswd APR1 hash to OpenLdap
by Michel Jouvin 11 Apr '16

11 Apr '16

Hi, We recently upgraded one of our Apache server from an htpasswd-based authentication to an OpenLdap-based one. As part of this, we had to move users identified by a username+password and faced the problem of converting the APR1 (Apache salted-MD5) hashes to OpenLDAP. We managed to migrate crypt and MD5 ($1$) hashes successfully as they are successfully managed by OpenLdap standard componenents. This is not the case for APR1 hashes, AFAIK. As documented on OpenLdap site, we built, installed and loaded pw-apr1.so from contrib/ in sources. With Perl Digest::MD5 + MIME::Base64::encode_base64, I have been able to generate a MD5 hash ({MD5} prefix in userPassword) that works with {MD5} so I'm pretty confident that pw-apr1.so works properly. But I'm stucked with APR1 password as I don't understand what should be done to transform a $apr1$... has into the {APR1}... format. According to an example given in the issue http://www.openldap.org/its/index.cgi/Contrib?id=7869;page=9;statetype=-1 (related to a former bug in apr1.c), $apr1$pepperon$VBD3GaYfoFXuIcZrTw/Y// should transform into {APR1}FK7q3pAf80k0Wh9BYZJ0FHBlcHBlcm9u but I have no clue how to get such a transformation done (does not seem to be a trivial encoding to base64). Any help would be very much appreciated! Cheers, Michel

3 3

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

11 Apr '16

Hi Michael, On 11/04/16 09:11, Michael Ströder wrote: >> >> 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"? > > Yepp. Thanks! That's clearer now. >> 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? > > Yes, I think so. But I never used saslauthd myself. I'll set up a test and confirm to this list (to make the archive of this thread more useful to someone else). >> 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. > > Your server, your attack vectors... :) Cheers! 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/

1 0

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 11 Apr '16

11 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 06 Apr '16

06 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical