openldap-technical

openldap-technical@openldap.org

1 participants
9868 discussions

Openldap
by Caldwell, Carmela 07 Jun '13

07 Jun '13

We are trying to install Open LDAP, but we are not sure if it will work with z/OS 1.13 mainframe. Does anyone have experience with z/OS mainframe? Thank you, Carmela C. Caldwell Data Security Analyst Bexar ccaldwell(a)bexar.org<mailto:ccaldwell@bexar.org>

2 1

Building 32-bit libraries on 64-bit machine
by Ashwin Kumar 07 Jun '13

07 Jun '13

I am using a 64 bit machine to build OpenLDAP libraries. Building 64-bit libraries works fine. Is there any switch for the configure script to build the 32-bit libraries. Is this documented anywhere? -- Ashwin kumar (http://ashwinkumar.me)

3 5

Per User Search Limits
by Jason Brandt 07 Jun '13

07 Jun '13

I have done some searching, and have been unable to come up with a solution/answer... I'm looking for a way to change the server side search limits on a per user basis. Currently, if we want to maintain global search result limit, it appears that we are required to use the administrator account to bypass the search result limit. Is there any way to enable a user to bypass the search limit? We have a few service accounts that we have created, which we would like to be able to bypass this limit, while still enforcing it for standard users and anonymous. Any suggestions would be greatly appreciated. We're using the olc configuration file format as well, if that matters. -- Jason K. Brandt Systems Administrator Bradley University

3 3

Unable to bind sample program to LDAP server via SSL (ldaps://)
by Ashwin Kumar 06 Jun '13

06 Jun '13

I have a sample program here that is trying to connect to LDAP server on the secured port (ldaps://) However, the sample program is not able to bind to the server. #define LDAP_DEPRECATED 1 #include <stdio.h> #include <ldap.h> #define HOSTNAME "192.168.1.51" #define PORTNUMBER 10389 #define BIND_DN "dc=example,dc=com" #define BIND_PW "secret" int main() { LDAP *ld; int rc; int reqcert = LDAP_OPT_X_TLS_NEVER; int version = LDAP_VERSION3; int ret(0); if (ldap_initialize (&ld, "ldaps://192.168.1.51:10636")) { perror("ldap_init"); /* no error here */ return(1); } ldap_set_option (ld, LDAP_OPT_PROTOCOL_VERSION, &version); ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); rc = ldap_bind_s(ld, BIND_DN, BIND_PW, LDAP_AUTH_SIMPLE); if( rc != LDAP_SUCCESS ) { fprintf(stderr, "ldap_simple_bind_s: %s\n", ldap_err2string(rc) ); return( 1 ); } printf("Initial Authentication successful\n"); ldap_unbind(ld); } However, with START_TLS the sample program successfully binds to LDAP server running on port 10389. ldapsearch client is able to connect to the server ans search the user base tree. But the sample program above does not. To get it working with START_TLS: Here is what I have added: ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); rc = ldap_start_tls_s(ld, NULL, NULL); if (rc != LDAP_SUCCESS) { printf("ldap_start_tls() %s",ldap_err2string(ret)); } *Can someone point out what I am missing here for binding to LDAP server via ldaps://??* -- Ashwin kumar (http://ashwinkumar.me)

1 0

Possible ppolicy override for other than rootDN
by Christian Kratzer 05 Jun '13

05 Jun '13

Hi, We have a customer setup where the corporate identity management applications provisions users to the directory, resets their passwords etc... The tool binds as a specific user and we permit write access to appropriate subtress via an acl. The customer also uses password policy to enforce policy in ldap. The problem we have is that the idm tool is obivously also subject to the pwdMinAge and pwdSafeModify policies. The tool never stores a users password so when pwdSafeModify is in effect it cannot provide the old password to satisfy the policy. It obviously also cannot reset the password until pwdMinAge has elapsed. Giving the rootDN credentials to the tool is also not an option as we would like to keep audit logs clean and have the acl in place to stop the tool from writing all over the place. So we would like to override password policy for the idm tools bind user similarly as the rootDN is already able to bypass policy. I found following section in ppolicy.c 1197 static int 1198 ppolicy_bind( Operation *op, SlapReply *rs ) 1199 { 1200 slap_overinst *on = (slap_overinst *)op->o_bd->bd_info; 1201 1202 /* Reset lockout status on all Bind requests */ 1203 if ( !BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) { 1204 ch_free( pwcons[op->o_conn->c_conn_idx].dn.bv_val); 1205 BER_BVZERO( &pwcons[op->o_conn->c_conn_idx].dn ); 1206 } 1207 1208 /* Root bypasses policy */ 1209 if ( !be_isroot_dn( op->o_bd, &op->o_req_ndn )) { 1210 Entry *e; 1211 int rc; I would think hacking line 1205 one could hardcode additional dn but I am searching for a cleaner more general solution. I was thinking on the lines of having a configurable olcPPolicyOverride with a list of dn that override password policy like the rootDN already does. If I attempted such a patch would it have changes of being accepted from the architectural point of view ? Any other ideas on how to solve above problem ? Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

3 5

SSHA as default password-hash in next password change
by cbulist＠gmail.com 05 Jun '13

05 Jun '13

Hi, All our users in LDAP database are under MD5 encryption. We want to change this to SSHA in the next user password change. We tried using: password-hash {SSHA} option in slapd.conf and restart the ldap service but it didn't work. The user password are still under MD5 encryption. We are using openldap 2.4.23-26 version. Any clue about this problem?. Thanks in advance! CBU

3 6

Re: extend groupOfURLs
by Michael Ströder 05 Jun '13

05 Jun '13

Carlos. please always follow-up on the mailing list so others can learn and answer as well. Carlos Santos wrote: > ################################################################################ > - # > - objectClass ( 1.3.6.1.4.1.5923.1.1.101 > - NAME 'dygroup' > - DESC 'dynamic group' > - SUP groupOfURLs > - STRUCTURAL > - MUST ( visibility $ groupname $ owner ) ) > - > - > - > ################################################################################ When using this and starting slapd with -d config,stats then it outputs: 51a8b922 line 53 (objectClass ( 1.3.6.1.4.1.5923.1.1.101 NAME 'dygroup' DESC 'dynamic group' SUP groupOfURLs STRUCTURAL MUST ( visibility $ groupname $ owner ) )) 51a8b922 /home/michael/ftp/Linux/Networking/LDAP/OpenLDAP/schema/experimental.schema: line 53 objectClass: AttributeType not found: "visibility" So where's the attribute type description for 'visibility'? => always use debug options when starting slapd after working on custom schema definitions. Ciao, Michael.

2 5

Substring Indexes on userPassword Attribute
by Tim Gustafson 04 Jun '13

04 Jun '13

Hi, I have a need to find out how many of my users are using different password hashing methods, so I went and tried to do this search: ldapsearch -D uid=tjg,ou=People,dc=com -W -b ou=People,dc=com 'userPassword={SHA}*' But that didn't return anything. So I figured maybe I needed to create a substr index on that attribute. When I did that, slapindex returned: slapd.conf: line 82: substr index of attribute "userPassword" disallowed Why is that? How can I do a search that would tell me which of my users is using an SHA-hashed password? -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

4 8

Usage of the LDAP_OPT_X_SASL_GSS_CREDS
by Bernardo Pastorelli 31 May '13

31 May '13

Not sure if this is the right mailing list. I'm developing an LDAP client that uses GSSAPI as the transport mechanism. I would like to set the credentials to use for binding my user, and it seems that it is possible to set them using the LDAP_OPT_X_SASL_GSS_CREDS option. So I create the ldap context using ldap_initialize and then try to set the credentials using the option above, before calling the ldap_sasl_interactive_bind_s function for binding my user. But the options setting operation fails. Looking at the code, I see that, to set the option, it is necessary that the pointers in the chain below are not null: ld->ld_defconn->lconn_sasl_authctx But they are null after initializing the ldap context. So, which function calls do I have to execute for being able to set credentials before calling the bind function? Any alternative way? Regards, Bernardo Pastorelli

1 0

How to make OpenLDAP use random (v4) UUIDs in entryUUID attribute
by dorian taylor 31 May '13

31 May '13

Hello, It is my understanding that OpenLDAP keys its entries on UUIDs under the hood. I have a system that makes extensive use of UUIDs as canonical (and sometimes public-facing) identifiers, and would like to tap into the UUIDs generated for the objects in the LDAP directory for certain operations over those objects. The problem is I'm using type 4 (random) UUIDs [1] everywhere, and OpenLDAP uses type 1 (time-based). It is important to the system to some extent that these identifiers be resistant to sequencing. As such, they really ought to be random. Since it hasn't been deployed in production yet, the sanest course of action seems to be to bend OpenLDAP to comply. (The alternative would be to maintain a dictionary of some kind, which I'm not keen about.) A survey of the code is as such: OpenLDAP doesn't appear to care which version of UUID it uses save for the generator function itself. The util library is hardcoded [2] to use type 1, and the entryUUID attribute itself is constrained in the schema [3] to not permit modification (where "modification" ostensibly also extends to adding new records). I'm not too familiar with the source but at a glance it appears to accommodate an entryUUID attribute as input [4]. I guess my question is: what's the best strategy? * Relax NO-USER-MODIFY on the entryUUID schema entry and set it at the application layer (easiest but most prone to problems) * Hack uuid.c to use uuid_generate_random instead of uuid_generate (easy, but introduces a maintenance problem) * Create an overlay (no idea where to start but can figure it out) * Figure out some way to make the UUID version configurable and send a patch upstream (most work and would it even be desirable?) Links: 1) http://tools.ietf.org/html/rfc4122#section-4.4 2) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… 3) http://tools.ietf.org/html/rfc4530#section-2.4 4) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… -- Dorian Taylor http://doriantaylor.com/

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical