openldap-technical September 2010

openldap-technical@openldap.org

111 participants
113 discussions

Virtual list view problem
by Venish Khant 31 May '16

31 May '16

Hi all I am using cpan Net::LDAP module to access LDAP entries. I want to search LDAP entries using Net::LDAP search method. When I do search, I want some limited number of entries from search result, for this(searching) process I am using Net::LDAP::Control::VLV module. But I get error on VLV response control. Please, any one have idea about this error. * Error:* Died at vlv.pl line 50, This is my example. I changed the font style of line 50 #!/usr/bin/perl -w use Net::LDAP; use Net::LDAP::Control::VLV; use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE ); use Net::LDAP::Control::Sort; sub procentry { my ( $mesg, $entry) = @_; # Return if there is no entry to process if ( !defined($entry) ) { return; } print "dn: " . $entry->dn() . "\n"; @attrs = $entry->attributes(); foreach $attr (@attrs) { #printf("\t%s: %s\n", $attr, $entry->get_value($attr)); $attrvalue = $entry->get_value($attr,asref=>1); #print $attr.":". $entry->get_value($attr)."\n"; foreach $value(@$attrvalue) { print "$attr: $value\n"; } } $mesg->pop_entry; print "\n"; } $ldap = Net::LDAP->new( "localhost" ); # Get the first 20 entries $vlv = Net::LDAP::Control::VLV->new( before => 0, # No entries from before target entry after => 19, # 19 entries after target entry content => 0, # List size unknown offset => 1, # Target entry is the first ); my $sort = Net::LDAP::Control::Sort->new( order => 'cn' ); @args = ( base => "dc=example,dc=co,dc=in", scope => "subtree", filter => "(objectClass=inetOrgPerson)", callback => \&procentry, # Call this sub for each entry control => [ $sort, $vlv ], ); $mesg = $ldap->search( @args ); # Get VLV response control *($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;* $vlv->response( $resp ); # Set the control to get the last 20 entries $vlv->end; $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); # Now get the previous page $vlv->scroll_page( -1 ); $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mes # Now page with first entry starting with "B" in the middle $vlv->before(9); # Change page to show 9 before $vlv->after(10); # Change page to show 10 after $vlv->assert("B"); # assert "B" $mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); -- Venish Khant www.deeproot.co.in

4 11

Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra 27 Dec '10

27 Dec '10

Hi, We have some problems with certificate authentication when the master server is behind a back-ldap proxy. We have openldap 2.4.21 on Suse Linux Enterprise Server 10 SP3 and these are the details of our scenario: The master server: server1.example.com has the following slapd.conf file: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by dn.exact="CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU" read by * auth access to attrs=shadowLastChange by self write by * read access to * by * read # # Security SSL # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /etc/ssl/certs/server1.example.com.pem TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key TLSCACertificatePath /etc/ssl/cacerts/ TLSVerifyClient demand # #Log level # loglevel 256 # Require authentication require authc ####################################################################### # HDB database definitions ####################################################################### database hdb suffix "dc=example,dc=com" checkpoint 1024 5 cachesize 10000 rootdn "cn=Manager,dc=example,dc=com" rootpw secret # Indices to maintain index objectClass eq # Overlay ppolicy overlay ppolicy ---------------------- Authentication is required, and we give access to the user passwords for the dn of a certificate. When we search for passwords using the certificate we get the following: root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://server1.example.com userPassword SASL/EXTERNAL authentication started SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU SASL SSF: 0 dn: uid=user_w_pass,ou=people,dc=example,dc=com userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0= ----------------------- The root user (ldap client) has a ~/.ldaprc file with: TLS_CACERTDIR /etc/ssl/cacerts/ TLS_CERT /etc/ssl/certs/admin_w_cert.pem TLS_KEY /etc/ssl/private/admin_w_cert.key TLS_REQCERT demand SASL_MECH EXTERNAL In /var/log/messages we get: ldap-master[22358]: conn=1000 fd=11 ACCEPT from IP=server1.example.com:40899 (IP=server1.example.com:636) ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256 ldap-master[22358]: conn=1000 op=0 BIND dn="" method=163 ldap-master[22358]: conn=1000 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-master[22358]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-master[22358]: conn=1000 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-master[22358]: conn=1000 op=2 UNBIND ldap-master[22358]: conn=1000 fd=11 closed This is the correct behavior for us. The problem appears when we introduce a back-ldap proxy between the client and the master. The proxy server (proxy-server1.example.com) is listening in port 1636 and its slapd.conf file is: # # Security SSL # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificatePath /etc/ssl/cacerts/ TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key TLSVerifyClient demand # Log level loglevel 256 ####################################################################### # Database definitions ####################################################################### database ldap rebind-as-user true suffix "dc=example,dc=com" uri "ldaps://server1.example.com" tls ldaps tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem tls_key=/etc/ssl/private/proxy-server1.example.com.key tls_cacertdir=/etc/ssl/cacerts/ ---------------------- If we search for passwords through the proxy we get: root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://proxy-server1.example.com:1636 userPassword SASL/EXTERNAL authentication started SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU SASL SSF: 0 Server is unwilling to perform (53) Additional information: authentication required In the /var/log/messages the following messages appear: ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636) ldap-proxy[22802]: conn=1001 fd=8 TLS established tls_ssf=256 ssf=256 ldap-proxy[22802]: conn=1001 op=0 BIND dn="" method=163 ldap-proxy[22802]: conn=1001 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[22802]: conn=1001 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-proxy[22802]: conn=1001 op=0 RESULT tag=97 err=0 text= ldap-proxy[22802]: conn=1001 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-proxy[22802]: conn=1001 op=1 SRCH attr=userPassword ldap-master[22358]: conn=1008 op=2 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-master[22358]: conn=1008 op=2 SRCH attr=userPassword ldap-master[22358]: conn=1008 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required ldap-proxy[22802]: conn=1001 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required ldap-proxy[22802]: conn=1001 op=2 UNBIND ldap-proxy[22802]: conn=1001 fd=8 closed The /root/.ldaprc file is the same than the previous one. When we increase the logging level we discover this: .... ldap-proxy[23008]: conn=1000 op=0 do_bind ldap-proxy[23008]: >>> dnPrettyNormal: <> ldap-proxy[23008]: <<< dnPrettyNormal: <>, <> ldap-proxy[23008]: conn=1000 op=0 BIND dn="" method=163 ldap-proxy[23008]: do_bind: dn () SASL mech EXTERNAL ldap-proxy[23008]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 ldap-proxy[23008]: SASL Canonicalize [conn=1000]: authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: slap_sasl_getdn: conn 1000 id=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au [len=61] ldap-proxy[23008]: ==>slap_sasl2dn: converting SASL name cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au to a DN ldap-proxy[23008]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[23008]: SASL Canonicalize [conn=1000]: slapAuthcDN="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: SASL proxy authorize [conn=1000]: authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: conn=1000 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" ldap-proxy[23008]: send_ldap_sasl: err=0 len=-1 ldap-proxy[23008]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-proxy[23008]: do_bind: SASL/EXTERNAL bind: dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" sasl_ssf=0 ldap-proxy[23008]: send_ldap_response: msgid=1 tag=97 err=0 ldap-proxy[23008]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[23008]: <== slap_sasl_bind: rc=0 .... ldap-proxy[23008]: conn=1000 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-proxy[23008]: conn=1000 op=1 SRCH attr=userPassword ldap-proxy[23008]: ==> limits_get: conn=1000 op=1 self="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" this="uid=user_w_pass,ou=people,dc=example,dc=com" ldap-master[22983]: daemon: activity on 1 descriptor ldap-master[22983]: daemon: activity on: ldap-master[22983]: ldap-master[22983]: slap_listener_activate(7): ldap-master[22983]: daemon: epoll: listen=7 busy ldap-master[22983]: >>> slap_listener(ldaps://server1.example.com) ..... ldap-master[22983]: conn=1000 op=0 do_bind ldap-master[22983]: >>> dnPrettyNormal: <> ldap-master[22983]: <<< dnPrettyNormal: <>, <> ldap-master[22983]: conn=1000 op=0 BIND dn="" method=128 ldap-master[22983]: do_bind: version=3 dn="" method=128 ldap-master[22983]: send_ldap_result: conn=1000 op=0 p=3 ldap-master[22983]: send_ldap_result: err=0 matched="" text="" ldap-master[22983]: send_ldap_response: msgid=1 tag=97 err=0 ldap-master[22983]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-master[22983]: do_bind: v3 anonymous bind ---------------- Therefore the proxy is binding anonymously in the master, instead of using the dn of the certificate. Is there any problem with the SASL EXTERNAL method? If we use SIMPLE authentication through the proxy, there is no problem: root # ldapsearch -LLL -x -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://proxy-server1.example.com:1636 -D 'uid=user_w_pass,ou=people,dc=example,dc=com' -W userPassword Enter LDAP Password: dn: uid=user_w_pass,ou=people,dc=example,dc=com userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0= Thanks in advance. --------------------------------------------------------------------------------------------- ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en

3 4

How to apply default ppolicy with cn=config
by sophie ailin 18 Oct '10

18 Oct '10

Hello, I was new to openldap, I try to use the default ppolicy with openldap 2.4.21 on suse linux, I didn't find much info in detail about how to config it when using cn=config. Could you take a look what I am missing here. I created and include the ldif file I think equivalent to slapd.conf , (convert the default ppolicy.shcema to ppolicy.ldif) : : include: file:///etc/openldap/schema/ppolicy.ldif : : dn: olcOverlay={1}ppolicy,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=example,dc=com Also I added the container and the policies : : dn: ou=policies,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: policies dn: cn=default,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy objectClass: person objectClass: top pwdAllowUserChange: TRUE pwdAttribute: 2.5.4.35 #pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 600 pwdFailureCountInterval: 30 pwdGraceAuthNLimit: 5 pwdInHistory: 5 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 0 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: FALSE pwdSafeModify: TRUE sn: dummy value the ppolicy.ldif look like this dn: cn=ppolicy,cn=schema,cn=config objectClass: olcSchemaConfig cn: ppolicy olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.42.2.27.8.1.2 NAME 'pwdMinAge' EQUALITY in tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {2}( 1.3.6.1.4.1.42.2.27.8.1.3 NAME 'pwdMaxAge' EQUALITY in tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {3}( 1.3.6.1.4.1.42.2.27.8.1.4 NAME 'pwdInHistory' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {16}( 1.3.6.1.4.1.42.2.27.8.1.5 NAME 'pwdCheckQuality' EQUAL ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {5}( 1.3.6.1.4.1.42.2.27.8.1.6 NAME 'pwdMinLength' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {6}( 1.3.6.1.4.1.42.2.27.8.1.7 NAME 'pwdExpireWarning' EQUA LITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {7}( 1.3.6.1.4.1.42.2.27.8.1.8 NAME 'pwdGraceAuthNLimit' EQ UALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {8}( 1.3.6.1.4.1.42.2.27.8.1.9 NAME 'pwdLockout' EQUALITY b ooleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {9}( 1.3.6.1.4.1.42.2.27.8.1.10 NAME 'pwdLockoutDuration' E QUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {10}( 1.3.6.1.4.1.42.2.27.8.1.11 NAME 'pwdMaxFailure' EQUAL ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {11}( 1.3.6.1.4.1.42.2.27.8.1.12 NAME 'pwdFailureCountInter val' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {12}( 1.3.6.1.4.1.42.2.27.8.1.13 NAME 'pwdMustChange' EQUAL ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {13}( 1.3.6.1.4.1.42.2.27.8.1.14 NAME 'pwdAllowUserChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {14}( 1.3.6.1.4.1.42.2.27.8.1.15 NAME 'pwdSafeModify' EQUAL ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: {15}( 1.3.6.1.4.1.4754.1.99.1 NAME 'pwdCheckModule' DESC 'L oadable module that instantiates "check_password() function' EQUALITY caseExa ctIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcObjectClasses: {0}( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' SUP top AUXILIARY MAY pwdCheckModule ) olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' SUP top AUXI LIARY MUST pwdAttribute MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheck Quality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) ) Somehow the policy didn't seems apply to my user entries, like the pwdMinLength or pwdExpireWarning not take effect at all. I tried with pwdCheckQuality 1 or 2 , both not working. I guess I am missing some config, the old way has a step to load the module, is there something similar I need to do the new way? Really appreciate your time and help! Sophie

3 2

High memory usage in provider server
by Claudio Cuqui 05 Oct '10

05 Oct '10

Hi there ! We are using two LDAP servers providers (openldap 2.4.23) in mirror mode: one just to receive modifies and the other, just to be "consumed" by 11 consumer servers. Both servers have almost 1MM objects with 10kb in size each. Id2entry.bdb has 21Gb and dn2id.bdb has 286Mb in size. When checking the first server we note that slapd is using ~4.0Gb of memory (RES). The problem is the second server, where all 11 consumers points to. Slapd in this server is using ~18.0Gb of memory (RES). We are using syncrepl to synchronize the 11 consumers with the 2nd server (RefreshandPersist). Openldap´s compile options are identical in both servers. Same for OS (Fedora 13 - x86_64 fully updated) and packages. Any ideas to reduce memory usage in the second server ? Regards, Claudio Cuqui

2 2

What attributes to authenticate (or) How to block the ldap tree for anonymous users
by Holger Schier 05 Oct '10

05 Oct '10

Hey guys, I am working with the LSEE 11 and trying to run a LDAP server. From scratch on everything went fine. With the standard configuration I can login, but if I use the LDAP Browser and hit anonymous access, I can see my whole LDAP tree. User name, mailaddresses and so on. And I am not happy with it. So I tried to change the access control from access to * by * read to access to * by * auth or access to * by * search The user password is already in auth mode. But with every other configuration instead of read, I cannot login anymore. Insufficient access. After the first try with auth I read the log files and saw that there is a search operation. So i switched to search. Now the server denies some read operations. So, my questions are: Is it just normal that anyone can see the LDAP tree? Is there any other option to hide my tree? And what attributes have to be readable to login? Thanks a lot. Holger

2 5

How can I monitore a mirror mode?
by Tiago Cruz 05 Oct '10

05 Oct '10

Hello folks, I have 2 OpenLDAP 2.4.11 running as Mirror Mode very well. But I would like to make sure that everything was replicated how should be forever :) so I would like to write some script to monitor it. I've searched around web, but I only found some about LDAP 2.2 and 2.3 (syncrep). Can you give me some tip about how I can do this? Many thanks! -- -- Tiago Cruz

2 2

back_meta and referrals authentication
by Javier Sanz 03 Oct '10

03 Oct '10

Hi, After upgrading from OpenLDAP 2.3.27 to 2.4.11, using back_meta, it looks like the bindings to the referrals of the external LDAP servers are no longer being made using the authentication information specified in pseudorootdn and pseudorootpw, but are being made anonymously. I have a backend meta that encapsulates a local LDAP server and some remote ones, mainly Active Directory ones not under my control. It also has a pcache overlay. Until now, pseudoroot* auth. info. was used both when binding to Active Directories and when chasing their referrals, but now it is only being used to bind to the ADs and the binds to their referrals are being made anonymously. Is that behavior still supported?. When slapd starts, it prints: line 75: "pseudorootdn", "pseudorootpw" are no longer supported; use "idassert-bind" and "idassert-authzFrom" instead. But slapd starts correctly. Does that mean that the directive works as it used to but it will be removed in the future, or that its functionality is deactivated until the user replaces it with idassert-bind?. If it is the former, then the problem should be related to some other change between 2.3 and 2.4, what could it be?. If it is the later and pseudorootdn must be replaced with ideassert-bind, I have tried it with all kinds of modes (none, self, legacy), flags, and different idassert-authzFrom's, with no sucess. I'm using OpenLDAP 2.4.11 under Debian 5.0 Lenny. I have tried upgrading to 2.4.17 with the same results. Bindings from clients to my server are always done using the same DN (rootdn). It has been some days now since I started looking into this, so any help is greatly appreciated. Here is the relevant config: (...includes...) loglevel config stats stats2 modulepath /usr/lib/ldap moduleload back_bdb moduleload back_ldap moduleload back_meta moduleload pcache allow update_anon access to * by * write database meta suffix "dc=myldap,dc=local" rootdn "cn=manager,dc=myldap,dc=local" rootpw "passwd" chase-referrals yes rebind-as-user no dncache-ttl forever network-timeout 5 nretries 5 idle-timeout 5m pseudoroot-bind-defer yes overlay pcache (...cache options..) uri "ldap://externalldap:389/dc=Directory_0,dc=myldap,dc=local" suffixmassage "dc=Directory_0,dc=myldap,dc=local" "DC=externalldap,DC=com" pseudorootdn "CN=Administrator,DC=Users,DC=externalldap,DC=com" pseudorootpw windowsadminpasswd (...maps...) Thanks, Javier

1 1

Glued Entries.
by karthik kumar 01 Oct '10

01 Oct '10

Hi .. Few of my ldap entries got changed like this objectClass: glue objectClass: top structuralObjectClass: glue Those glued entries are not showing up in the ldapsearch. I took a dump and from the ldif file, realized the objectClass/ structuralObjectClass got changed. I wanted to recover my ldap. So removed all those entries ( including the childnodes ). ldapadd them back from a previous dump ( which wasnt glued). But after some time when I access those entries from application, they get glued. Can you please advice how do I recover my ldap from this.

2 3

ACL Question
by Diego Lima 30 Sep '10

30 Sep '10

Hello all, I have the following structure on my LDAP server: ou=Misc,dc=diegolima,dc=org ou=Users,dc=diegolima,dc=org Under users I have some user accounts, such as cn=user1,ou=Users,dc=diegolima,dc=org. I'd like to allow users to create an OU under ou=Misc as long as the OU had the user's name, such as ou=user1,ou=Misc,dc=diegolima,dc=org for user1 or ou=user2,ou=Misc,dc=diegolima,dc=org for user2, however I wouldn't like to simply create an ACL such as: access to dn.exact="ou=Misc,dc=diegolima,dc=org" by * add as this ultimately allows user1 to create an ou named "ou=user2,ou=Misc". What I first tried was adding an ACL like this: access to dn.regex="^ou=([^,]+),ou=Misc,dc=diegolima,dc=org" by dn.exact,expand="cn=$1,dc=diegolima,dc=org" write by * none However I receive an error telling me that I need write access to the parent entry to create this, and if I use the first ACL I seem to be able to create OUs without any naming restriction. Is there even a way to accomplish this? Thank you very much! -- Diego Lima

2 2

AD authentication over open ldap
by Florian Harmuth 30 Sep '10

30 Sep '10

Hello all, at the moment i try to realize an authentication against an active directory over a ldap server. With my attached config this to works if i provide the a bind dn like this "username(a)mydom.lan". A few of our servers try to authenticate the users with a dn like this "uid=username,dc=mydom,dc=lan". Is it possible to convert this dn to the other format before sending it to the aactive directory server? Best regards and sorry for my terrible english flo <slapd.conf> include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel 65535 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_ldap moduleload rwm database ldap suffix "dc=mydom,dc=lan" rebind-as-user yes uri "ldap://10.1.2.210 ldap://10.2.2.210" protocol-version 3 overlay rwm rwm-map attribute uid samaccountname rwm-map attribute member memberOf rwm-map objectclass inetOrgPerson user </slapd.conf>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2010