openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Core dump in ldap_unbind_ext_s
by sachinv1821＠gmail.com 03 Oct '11

03 Oct '11

I have a wrapper manager code on top of openldap stack(ver.2.4.11), there manager code is responsible for creating the ldap connecting to the LDAP servers by using the standard ldap API(). u32_t rc=ldap_sasl_bind(ld, loginDN, LDAP_SASL_SIMPLE, &cred, NULL, NULL, &msgid); //asynchronous bind if (rc != LDAP_SUCCESS ) { ldapErrorLog(":connect: LDAP Bind send Failed:%s \n ", ldap_err2string(rc)); ldap_unbind_ext_s(ld, NULL,NULL); m_connInitialized = false; return(LDAPRC_FAIL); } return LDAPRC_SUCCESS; by using this wrapper code I am creating many ldap links ,most of time this is working fine some times when the ldap_sasl_bind() returns -1 (can't contact server) or unknown error the code is crashing in ldap_unbind_ext_s. can anyone help out. the log and gdb trace are pasted below (gdb) bt #0 ldap_free_request (ld=0x16fd370, lr=0x1010001020001) at request.c:866 #1 0x00000000005372e8 in ldap_ld_free (ld=0x16fd370, close=1, sctrls=<value optimized out>, cctrls=<value optimized out>) at unbind.c:88 #2 0x000000000044b020 in LdapConnection::connect (this=0x157bcd0, loginDN=0x157b3ec "cn=TASuser", pwd=<value optimized out>) logs.. <18:06:56.414 **ERR** LDAP 22603:22470 3:0><LdapConnection.cpp(171)>:connect: LDAP Bind send Failed:Can't contact LDAP server <18:06:56.414 *WRN* MX 22603:22470 3:0>receive SEGV signal <18:06:56.414 *WRN* MX 22603:22470 3:0>Message dump is disabl Regards, Sachin Vastrad

2 1

ldapscripts
by Andreas Rudat 03 Oct '11

03 Oct '11

Hello, if I try to ad auser with ldapadduser I get the error >> 10/01/11 - 19:29 : Command : /usr/sbin/ldapadduser andi test ldap_add: No such object (32) matched DN: dc=foo,dc=intern Error adding user andi to LDAP but it's not a problem to add groups

2 1

translucent proxy add more then one group to user on proxy side
by joaosf 03 Oct '11

03 Oct '11

Hi All, I have a translucent proxy who connect's to other ldap server. I need this kind of solutions because I need to manage groups by my own. So, when a user connect over my translucent proxy everything goes ok, gets the password from the backend ldap server and groups, but user just see the prefered group of my translucent proxy (I have more) and the groups of the backend ldaps. I want the user to see all groups of my translucent proxy, is this possible, do I miss something? Thanks, João SF

1 0

[Re: ldap proxy acl filter problem]
by Ron Peterson 03 Oct '11

03 Oct '11

Had to turn away from this problem to deal w/ other stuff, but it's still an issue for me. Does anyone have a working example of a working proxy configuration they would be willing to share that: * includes a filter expression restricting the result set * allows you to query for the value of an individual attribute I would be very grateful. Right now I'm thinking I may try a different tack: put the filter expression on the master directory in an acl specific to the proxy base dn I'm dealing with. -Ron- ----- Forwarded message from Ron Peterson <rpeterso(a)mtholyoke.edu> ----- Date: Fri, 16 Sep 2011 09:25:41 -0400 From: Ron Peterson <rpeterso(a)mtholyoke.edu> To: Howard Chu <hyc(a)symas.com> Subject: Re: ldap proxy acl filter problem Organization: Mount Holyoke College X-Spam-Score: -0.504 () RP_MATCHES_RCVD Cc: openldap-technical(a)openldap.org 2011-09-15_08:22:54-0400 Ron Peterson <rpeterso(a)mtholyoke.edu>: > 2011-09-14_16:54:56-0400 Howard Chu <hyc(a)symas.com>: > > >I've turned my logging way up, and the hiccup seems to be that the DN > > >I've authenticated as > > >(uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu) needs read > > >access to the attributes in the filter expression. But how do I give > > >that account read access to those attributes, without then exposing the > > >objects that I'm trying to hide with the filter expression? > > > > Give it auth access, not read access. My previous example had too much going on for any sane person to wade through, so I've distilled this configuration down to illustrate the essence of the problem. No fancy rewrite rules, etc. The problem remains: adding a filter expression makes it impossible to query the value of particular attributes, although I can retrieve the entire object. It must be possible to filter the result set in a back-ldap proxy setup when querying for particular attributes, but how? ________________________________________________________________________ ldaprc like: BASE ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu BINDDN uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu URI ldap://dirt.mtholyoke.edu SIZELIMIT 40000 TLS_CACERT /local/etc/cert/ca/cacert.pem ________________________________________________________________________ proxy config like: database ldap suffix "ou=accounts,ou=prod,dc=mtholyoke,dc=edu" uri "ldapi://%2Fvar%2Frun%2Fslapd%2Fmastertest%2Fldapi" access to dn.sub="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" attrs="entry" by dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" read by * none # log file (see below) seems to indicate proxy wants search permission on this attribute, # but this doesn't help access to dn.sub="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" attrs="yApplicationPermission" by dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" search by * none access to dn.sub="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" filter="(yApplicationPermission=email)" by dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" read by * none ________________________________________________________________________ (1) This query works (returns all attributes): ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)' (2) This query does not (only returns DN, but not yPrimaryEmail): ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)' yPrimaryEmail ________________________________________________________________________ Log for both master and proxy database (loglevel 256 128 64 32), for query (2) above: pid 32160 = proxy server pid 24268 = master directory server Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 ACCEPT from IP=138.110.86.129:51010 (IP=138.110.86.129:389) Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 STARTTLS Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 RESULT oid= err=0 text= Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 TLS established tls_ssf=256 ssf=256 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" method=128 Sep 16 09:17:41 mid slapd[24268]: conn=1025 fd=13 ACCEPT from PATH=/var/run/slapd/mastertest/ldapi (PATH=/var/run/slapd/mastertest/ldapi) Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" method=128 Sep 16 09:17:41 mid slapd[24268]: => access_allowed: result not in cache (userPassword) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: auth access to "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "userPassword" requested Sep 16 09:17:41 mid slapd[24268]: => acl_get: [1] attr userPassword Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "userPassword" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to value by "", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: self Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: anonymous Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [2] applying auth(=xd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [2] mask: auth(=xd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: auth access granted by auth(=xd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: auth access granted by auth(=xd) Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" mech=SIMPLE ssf=0 Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 RESULT tag=97 err=0 text= Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 BIND dn="uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" mech=SIMPLE ssf=0 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 RESULT tag=97 err=0 text= Sep 16 09:17:41 mid slapd[32160]: begin get_filter Sep 16 09:17:41 mid slapd[32160]: EQUALITY Sep 16 09:17:41 mid slapd[32160]: end get_filter 0 Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=2 SRCH base="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" scope=2 deref=0 filter="(yUsername=rpeterso)" Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=2 SRCH attr=yPrimaryEmail Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=1 SRCH base="ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" scope=2 deref=0 filter="(yUsername=rpeterso)" Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=1 SRCH attr=yPrimaryEmail Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access to "ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "entry" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] attr entry Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "entry" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to all values by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yUsername" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => dn: [4] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] attr yUsername Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "yUsername" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to value by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: search access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "entry" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] attr entry Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "entry" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to all values by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid=[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: result not in cache (yPrimaryEmail) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yPrimaryEmail" requested Sep 16 09:17:41 mid slapd[24268]: => dn: [3] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[24268]: => dn: [4] dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] matched Sep 16 09:17:41 mid slapd[24268]: => acl_get: [4] attr yPrimaryEmail Sep 16 09:17:41 mid slapd[24268]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "yPrimaryEmail" requested Sep 16 09:17:41 mid slapd[24268]: => acl_mask: to value by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[24268]: <= check a_dn_pat: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: pattern: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: => acl_string_expand: expanded: ^uid[^,]*,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[24268]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => slap_access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: => access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 16 09:17:41 mid slapd[32160]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "entry" requested Sep 16 09:17:41 mid slapd[32160]: => dn: [1] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [1] matched Sep 16 09:17:41 mid slapd[32160]: => acl_get: [1] attr entry Sep 16 09:17:41 mid slapd[32160]: => acl_mask: access to entry "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", attr "entry" requested Sep 16 09:17:41 mid slapd[32160]: => acl_mask: to all values by "uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu", (=0) Sep 16 09:17:41 mid slapd[32160]: <= check a_dn_pat: uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: <= acl_mask: [1] applying read(=rscxd) (stop) Sep 16 09:17:41 mid slapd[32160]: <= acl_mask: [1] mask: read(=rscxd) Sep 16 09:17:41 mid slapd[32160]: => slap_access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[32160]: => access_allowed: read access granted by read(=rscxd) Sep 16 09:17:41 mid slapd[32160]: => access_allowed: result not in cache (yPrimaryEmail) Sep 16 09:17:41 mid slapd[32160]: => access_allowed: read access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yPrimaryEmail" requested Sep 16 09:17:41 mid slapd[32160]: => dn: [1] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [1] matched Sep 16 09:17:41 mid slapd[32160]: => dn: [2] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [2] matched Sep 16 09:17:41 mid slapd[32160]: => dn: [3] ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu Sep 16 09:17:41 mid slapd[32160]: => acl_get: [3] matched Sep 16 09:17:41 mid slapd[32160]: => test_filter Sep 16 09:17:41 mid slapd[32160]: EQUALITY Sep 16 09:17:41 mid slapd[32160]: => access_allowed: search access to "yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu" "yApplicationPermission" requested Sep 16 09:17:41 mid slapd[32160]: <= test_filter 5 Sep 16 09:17:41 mid slapd[32160]: <= acl_get: done. Sep 16 09:17:41 mid slapd[32160]: => slap_access_allowed: no more rules Sep 16 09:17:41 mid slapd[32160]: => access_allowed: no more rules Sep 16 09:17:41 mid slapd[32160]: send_search_entry: conn 1001 access to attribute yPrimaryEmail, value #0 not allowed Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=3 UNBIND Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=2 UNBIND Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 closed Sep 16 09:17:41 mid slapd[24268]: conn=1025 fd=13 closed Sep 16 09:17:41 mid slapd[24268]: connection_read(13): no connection! Sep 16 09:17:41 mid slapd[24268]: connection_read(13): no connection! -- Ron Peterson Network & Systems Administrator Mount Holyoke College http://www.mtholyoke.edu/~rpeterso ----- End forwarded message -----

1 0

back-sql usage
by Worgan, Craig (Craig) 02 Oct '11

02 Oct '11

Hi, The documentation for back-sql indicates that it is experimental and warns against using it in a production environment. It also says that it is not intended as a general purpose back-end for OpenLDAP. My organization is looking at doing both of those things and I am trying to convince them not to do so. It is proving to be a difficult thing to do. Initially, I found the results of a performance analysis of back-sql that showed it was significantly slower than BDB and used that as an argument. I was asked to prove it so I built a prototype. The prototype showed that, at least for our purposes, performance was not an issue. Now I am falling back on the documentation, but very few people are listening. I fear that if we continue down the path we are on we will face significant problems with back-sql. I was hoping someone on the list could provide me with more concrete technical information as to why back-sql should not be used as a general purpose backend for OpenLDAP and/or in a production environment. Any information is greatly appreciated. Thanks, Craig Worgan Avaya| System Management Solutions | 250 Sidney Street | Belleville, Ontario Canada K8N 5B7 | (613) 967-5233 | worganc(a)avaya.com<mailto:worganc@avaya.com>

1 0

Question to smbldap-tools
by Andreas Rudat 02 Oct '11

02 Oct '11

Hi, does anyone knows a patch for the "Password" problem? I mean that's saved in cleartext, I tried to add some code to ask for the pass instead of "read it from file" but I got errors after my input. I dont have any perl skills. Andreas

2 1

tunning search with less tha filter
by CHIROSSEL, Olivier 30 Sep '11

30 Sep '11

Hi i have to found entry with this filter in my ldap : (&(statusprefix=free)(datefinjachere<=20110926)) i defined the datefinjachere attribut like this attributetype ( 1.3.6.1.4.1.11594.1.2.5.1.7 NAME 'datefinjachere' DESC 'datefinjachere' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch ORDERING numericStringOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{8} SINGLE-VALUE ) and i declare in my slapd.conf : index datefinjachere eq index statusprefix eq in the base where i search there is 1024 entry which corresponding or not at the filter a search take 200 millisecondes for the moment, could someone tell me if there is some tunning configuration for better performances ? i see when i log with debug Sep 26 17:53:09 olivier slapd[3402]: => bdb_presence_candidates (datefinjachere) Sep 26 17:53:09 olivier slapd[3402]: <= bdb_presence_candidates: (datefinjachere) not indexed perhaps i have to put index datefinjachere pres,eq in my conf ? my *.bdb file take 2G on the disk and i declare 500M of cache berkeley in my myconf bdb4.8 openldap 2.4.23 in advance, thank you for your time Regards, Olivier

1 1

30 Sep '11

Hi,I am using openldap-2.4.26 on one machine, and pam_ldap-186 and nss_ldap-265 on another machine, both machines running Fedora-10. I am trying for a secure communication using TLS/SSL. when I try to connect to the LDAP client machine using SSH, after authentication success the shell prompt is returned after 3 min or 4 mins. I don't know why it is taking so much time. This is happening for the users which are present only in LDAP database i.e. this user is not created on the client machine. At the server side I am getting following errors. TLS: can't accept: (unknown).connection_read(18): TLS accept failure error=-1 id=1068, closingconnection_closing: readying conn=1068 sd=18 for closeconnection_close: conn=1068 sd=18daemon: removing 18conn=1068 fd=18 closed (TLS negotiation failure)daemon: epoll: listen=7 active_threads=0 tvp=NULLdaemon: activity on 1 descriptordaemon: activity on:daemon: epoll: listen=7 active_threads=0 tvp=NULL I have created the CA certificate with CA.sh script. I followed the procedure given below.http://octaldream.com/~scottm/talks/ssl/opensslca.html I copied the same cacert.pem file from server to the client machine afte running the above procedure on server machine. The configuration files are as follows.slapd.conf include         /usr/local/etc/openldap/schema/core.schemainclude         /usr/local/etc/openldap/schema/cosine.schemainclude         /usr/local/etc/openldap/schema/inetorgperson.schemainclude         /usr/local/etc/openldap/schema/nis.schema LSCipherSuite          HIGH:MEDIUM:+SSLv2:+SSLv3:RSATLSCACertificateFile    /etc/pki/CA/cacert.pemTLSCertificateFile      /etc/pki/tls/misc/newcert.pemTLSCertificateKeyFile   /etc/pki/tls/misc/newkey.pemTLSVerifyClient         allow pidfile         /usr/local/var/run/slapd.pidargsfile        /usr/local/var/run/slapd.args access to attrs=userPassword by self       write by anonymous  auth by *          none access to * by *         read######################################################################## BDB database definitions####################################################################### database        bdbsuffix          "dc=samsung,dc=com"rootdn          "cn=Manager,dc=samsung,dc=com"# Cleartext passwords, especially for the rootdn, should# be avoid.  See slappasswd(8) and slapd.conf(5) for details.# Use of strong authentication encouraged.rootpw          123qwe# The database directory MUST exist prior to running slapd AND# should only be accessible by the slapd and slap tools.# Mode 700 recommended.directory       /usr/local/var/openldap-data# Indices to maintain#unique id so equality match onlyindex   uid     eqindex   userPassword    eq#allows general searching on commonname,givenname and mailindex   cn,gn,sn,ou,o,mail eq,subindex   objectClass     eq and ldap.conf has the following configuration base dc=samsung,dc=comuri ldaps://localhost.localdomain/tls_cacertfile  /etc/pki/CA/cacert.pempam_password md5nss_map_attribute gecos description Please let me know where I am making mistake? how to fix this problem. Warm RegardsVijay S.

2 1

lastbind overlay issue
by Mudimbi, Satish (VDSS) 30 Sep '11

30 Sep '11

Hi, I have built the last bind overlay and followed the steps. I get an error line 63 (overlay lastbind) overlay "lastbind" not found /usr/local/etc/openldap/slapd.conf: line 63: <overlay> handler exited with 1! What did it do wrong? Here is the information of my LDAP Libexec/openldap has all the files [root@pacman openldap]# ls -l /usr/local/libexec/openldap total 28 -rwxr-xr-x 1 root root 808 Sep 29 09:18 lastbind.la -rwxr-xr-x 1 root root 324 Sep 29 09:18 lastbind.lo -rwxr-xr-x 1 root root 4440 Sep 29 09:18 lastbind.o slapd.conf file # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: [root@pacman openldap]# ls -l /usr/local/libexec/openldap total 28 -rwxr-xr-x 1 root root 808 Sep 29 09:18 lastbind.la -rwxr-xr-x 1 root root 324 Sep 29 09:18 lastbind.lo -rwxr-xr-x 1 root root 4440 Sep 29 09:18 lastbind.o modulepath /usr/local/libexec/openldap moduleload back_bdb.la moduleload back_hdb.la moduleload back_ldap.la moudleload lastbind.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "o=DSS,c=US" overlay lastbind lastbind-precision 604800 rootdn "cn=Manager,o=DSS,c=US" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND Thanks, Satish

1 0

Referral record presonse
by Roy Lam 30 Sep '11

30 Sep '11

Dear All, I have two ldap servers.sever a and server are two separate server. server a has a record refer to server b. After a search. server a indicate that b only have 1000 record which should more than that. How Can I fix it? Roy

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical