openldap-technical July 2010

openldap-technical@openldap.org

103 participants
126 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

tnsnames in openldap
by Stuart Cherrington 26 Aug '10

26 Aug '10

Hi, I was wondering if anyone here has had a good/bad experience of getting Openldap to provision tnsnames lookup for Oracle Databases? We're thinking of removing our current OID implementation which is very old and as I'm already running OpenLDAP 2.4 is makes sense to just roll it from there. I found a VERY useful article at http://oracle-cookies.blogspot.com/2007/01/get-tnsnamesora-from-openldap.ht… which I think will help enormously. Thanks, STuart. _________________________________________________________________ http://clk.atdmt.com/UKM/go/195013117/direct/01/

3 2

Re: How to check LDAP replication status?
by Gavin Henry 20 Aug '10

20 Aug '10

On 22/07/10 13:55, Paul Harvey wrote: > On 07/22/2010 02:34 PM, Priyesh Potdar wrote: >> Hi, >> >> Check out this link: >> http://docs.hp.com/en/5991-7504/ar01s08.html >> >> Refer to the section: >> Monitoring the Replication Status >> >> Hope this helps... >> >> On Thu, 2010-07-22 at 07:17 -0500, Proskurin Kirill wrote: >> >>> On 22/07/10 15:40, Priyesh Potdar wrote: >>> >>>> Hi, >>>> >>>> Two things you can do: >>>> 1) Check the replog file, if the data is getting pushed to slave from >>>> there or not. >>>> >>> As I understand it is deprecated and only used with Slurpd? >>> >>> I fogot to say - I use LDAP 2.4.11+ with Syncrepl. >>> >>> >>>> 2) Issue an ldapsearch command on the slave servers to check a newly >>>> updated data. >>>> >>> I don`t know what data is changing _now_ so what to search? >>> >>> >> > Precisely what i was after, thanks. > > Is there any way to manually create a hidden entry, in a similar style > to the contextCSN, or would this require the an overlay to be written? That's what the contextCSN is for. Just ldapsearch for it and if they match, they are up to date: http://blog.suretecsystems.com/archives/146-OpenLDAP-Quick-Tips-Checking-th… I really need to start those "Quick Tips" up again! If anyone wants to contribute some? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

3 2

Syncrepl: Reliable method to ask a server for its own URL
by Torsten Schlabach (Tascel eG) 20 Aug '10

20 Aug '10

Hi all! I do have a multi-master replication setup. So I do have an olcServerID attribute with multiple values, for example: dn: cn=config olcServerID: 1 ldap://ldapserver1.some.tld/ olcServerID: 2 ldap://ldapserver2.some.tld/ olcServerID: 3 ldap://ldapserver3.some.tld/ I understand that the meaning of this is: Each server will pick the attribute value which matches its own URL to determine the actual ServerID to be used in contextCSN generation, right? So if the server listening to ldap://ldapserver2.some.tld/ will come up, it will pick the attribute value "2 ldap://ldapserver2.some.tld/" and thus decide that its serverID is 2 in this case. I also understand that this mechanism has been created to allow the cn=config database to be replicated across all servers which are part of the cluster. Now obviously, if I made a mistake here, for example I make a typo: dn: cn=config olcServerID: 1 ldap://ldapserver1.some.tld/ olcServerID: 2 ldap://ldapsrever2.some.tld/ olcServerID: 3 ldap://ldapserver3.some.tld/ the server ldap://ldapserver2.some.tld/ will not find its entry and thus its serverID will default to 0, right? And I guess this will lead to results of the sychronization which are not what I expect. Of course I can carefully watch the config to guess what the effective ServerID *should* be. But would there be any way to actually query the server for what it thinks its ID is? I tried ldapsearch -x -D 'cn=admin,cn=config' -w XXXX -b '' -s base olcServerID but this also just gives me: # config dn: cn=config olcServerID: 1 ldap://192.168.5.11:389/ olcServerID: 2 ldap://192.168.5.12:389/ olcServerID: 3 ldap://192.168.9.2:389/ in my case. I guess I may have to query -b "", right? Any hints are welcome. I hope I was able to make my question clear. Regards, Torsten

2 1

pass-through authentication
by Brent Bice 20 Aug '10

20 Aug '10

I tried to send this yesterday but didn't see it come back from the list (and didn't see any replies). So I'll try once more. Apologies if anyone gets this twice. I've been trying to get Pass-Through authentication to work using a userPassword attribute of the form {SASL}username@realm. Is there a way to tell slapd what pathspec to use to talk to saslauthd? (I'm guessing maybe it's using one path but saslauthd is using a different one for the socket file) I've got saslauthd running ok and can authenticate using testsaslauthd so I'm fairly sure saslauthd is configured right and working. And I've got openldap compiled with --enable-spasswd option so it ought to support the SASL pass-through option, right? I ran saslauthd with debugging on so I can see every auth request and whether it succeeds or fails and I can see it when testsaslauth connects and succeeds. But when I try to bind to slapd using the DN whose userPassword is {SASL}bbice@ldap the authentication to slapd fails and saslauthd doesn't show any authentication attempt at all. It's as if it's not even trying (or can't find) saslauthd. I ran slapd with the -d 255 option and saved the output to a file. Here's all the lines containing the string sasl: >>> dnPretty: <cn=SASL> => ldap_bv2dn(cn=SASL,0) <= ldap_bv2dn(cn=SASL)=0 <= ldap_dn2bv(cn=SASL)=0 <<< dnPretty: <cn=SASL> >>> dnNormalize: <cn=SASL> <<< dnNormalize: <cn=sasl> ldap_sasl_bind_s ldap_sasl_bind SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" So if I'm reading that right, slapd does see that it's supposed to hand off the authentication to saslauthd and it has picked out the username and realm. But it doesn't seem to be connecting to or using saslauthd. Any ideas? What am I missing here? Brent Bice bbice(a)sgi.com

2 1

delta-sync replication slave quitting problem - not a single retry
by Alexander Ivanov 12 Aug '10

12 Aug '10

Hello guys, I have a problem with delta-syn replication (all set up according to 'official' guide - http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl I have master instance with logs 'shipped' to a client - it all works fine as long as connection is good. Getting ready to move into production I'm trying to emulate connectivity problems and here where I got problems. Specifically - even though I have mirror instance set up as: syncrepl rid=101 provider=ldap://192.168.22.62:389 type=refreshAndPersist bindmethod=simple binddn="cn=replicator,xxxxx" credentials="xxxxxx" searchbase="xxxxxxx" filter="(objectClass=*)" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" scope=sub attrs="*,+" schemachecking=off * retry="1 +"* syncdata=accesslog once I have server disconnected (I sumply restart slapd on master), the client not even tries to re-connect, the log below shows modificatin operation at 18:34:18 that went fine and 11 seconds later I restart master's ldap service (which became immediately available again): Jul 28 18:34:18 newton slapd[20353]: => entry_encode(0x00000032): mail=xxxxxxxxxxxxxxxxxxxxxxxxxx. Jul 28 18:34:18 newton slapd[20353]: bdb_modify: updated id=00000032 dn="yyyyyyyyyyyyyyyyyyyyyyyy" Jul 28 18:34:18 newton slapd[20353]: send_ldap_result: conn=-1 op=0 p=0 Jul 28 18:34:18 newton slapd[20353]: send_ldap_result: err=0 matched="" text="" Jul 28 18:34:18 newton slapd[20353]: syncrepl_entry: rid 101 be_modify (0) Jul 28 18:34:18 newton slapd[20353]: bdb_modify: xxxxxxxxxxxxxxxxxx. Jul 28 18:34:18 newton slapd[20353]: bdb_dn2entry("oxxxxxxxxxxxxxxx") Jul 28 18:34:18 newton slapd[20353]: bdb_modify_internal: 0x00000001: o=xxxxxxxxxxxxxxxxx. Jul 28 18:34:18 newton slapd[20353]: <= acl_access_allowed: granted to database root Jul 28 18:34:18 newton slapd[20353]: bdb_modify_internal: replace contextCSN Jul 28 18:34:18 newton slapd[20353]: => entry_encode(0x00000001): o=xxxxxxxxxxxxxxxxxxxxx. Jul 28 18:34:18 newton slapd[20353]: bdb_modify: updated id=00000001 dn="xxxxxxxxxxxxxxxx" Jul 28 18:34:18 newton slapd[20353]: send_ldap_result: conn=-1 op=0 p=0 Jul 28 18:34:18 newton slapd[20353]: send_ldap_result: err=0 matched="" text="" Jul 28 18:34:18 newton slapd[20353]: daemon: activity on 1 descriptor Jul 28 18:34:18 newton slapd[20353]: daemon: activity on: Jul 28 18:34:18 newton slapd[20353]: Jul 28 18:34:18 newton slapd[20353]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 28 18:34:29 newton slapd[20353]: daemon: activity on 1 descriptor Jul 28 18:34:29 newton slapd[20353]: daemon: activity on: Jul 28 18:34:29 newton slapd[20353]: 14r Jul 28 18:34:29 newton slapd[20353]: Jul 28 18:34:29 newton slapd[20353]: daemon: read active on 14 Jul 28 18:34:29 newton slapd[20353]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 28 18:34:29 newton slapd[20353]: connection_get(14) Jul 28 18:34:29 newton slapd[20353]: connection_get(14): got connid=0 Jul 28 18:34:29 newton slapd[20353]: =>do_syncrepl rid 101 Jul 28 18:34:29 newton slapd[20353]: =>do_syncrep2 rid 101 Jul 28 18:34:29 newton slapd[20353]: do_syncrep2: rid 101 Can't contact LDAP server Jul 28 18:34:29 newton slapd[20353]: connection_get(14) Jul 28 18:34:29 newton slapd[20353]: connection_get(14): got connid=0 Jul 28 18:34:29 newton slapd[20353]: daemon: removing 14 Jul 28 18:34:29 newton slapd[20353]: daemon: activity on 1 descriptor Jul 28 18:34:29 newton slapd[20353]: daemon: activity on: Jul 28 18:34:29 newton slapd[20353]: Jul 28 18:34:29 newton slapd[20353]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 28 18:34:29 newton slapd[20353]: do_syncrepl: rid 101 quitting I'm running openldap 2.3.43-12.el5_5.1 from standard CentOS 5.4 installation. Do I get something wrong and slave not supposed to re-connect after master service restart or is this some kind of a problem that was fixed in later versions? Thank you, Alex

4 7

comp match module has unusable X509 cert code
by Lehnert, Hartmut 10 Aug '10

10 Aug '10

Hi all! I have performed some tests with the comp match module (yes it runs if you work around ITS 6556 ;-)). The result is that the comp match module only works with very simple X509 certs that use old algorithms! For example if you use X509 certificates with long serial numbers the snacc generated asn.1 parser (contained in file certificate.c) fails decoding the serial number. Another drawback: The attributes in Name components subject and issuer (cn, c, o, ou) have to be PrintableStrings; if for example there is an UTF8String present in the issuer the asn.1 parser fails decoding the issuer. All modern algorithms (sha256WithRSA, sha512WithRSA) are not recognized by the parser; if your X509 certificate is signed with sha256WithRSA the asn.1 parser fails decoding the AlgorithmIdentifier. In modern times these drawbacks aren't acceptable. Another appropriate asn.1 module for the X509 certificate structure has to be compiled with the openldap esnacc compiler. I would have done this but the openldap esnacc fails parsing its own modules!!! See something like this: openldap@ocsp-openldap24:~/Certificate> ~/openldap-snacc-2.3.6/compiler/esnacc -E BER_COMP -E GSER -t -d -f -I /home/openldap/openldap-snacc-2.3.6/asn1specs -I . Certificate.asn1 /home/openldap/openldap-snacc-2.3.6/asn1specs/asn1module.asn1(91) : parse error at symbol ""OID"" Parsing errors---cannot proceed The code in the asn.1 module: 88 ModuleId ::= SEQUENCE 89 { 90 name MyString, 91 oid OBJECT IDENTIFIER OPTIONAL --snacc cTypeName:"OID" isPtr:"TRUE" 92 } 93 Does anybody know how the esnacc error can be avoided? Regards, Hartmut

5 33

Client Configuration on Windows
by Wallus, Harald Dr. 06 Aug '10

06 Aug '10

Hi all, I just ty to figure out client certificates for the access to ldap. My problem I can't configure e.g. ldapsearch on windows properly. If I understood it right, I must define and store some directives within a ldap.conf (see an example at the bottom), But what I must do that e.g. ldapsearch will read the configuration? Harald URI ldaps://myldap.mydomain.de BASE OU=myOrg,O=mydomain,C=DE BINDDN CN=me,OU=USERS,OU=myorg,O=mydomain,C=DE TLS_CACERT C:/OpenSSL-Win32/bin/demoCA/cacert.pem TLS_CERT C:/app/H23232/product/11.2.0/client_2/BIN/owm/wallets/H23232/clientcert.pem TLS_KEY C:/app/ H23232/product/11.2.0/client_2/BIN/owm/wallets/H23232/privateKeyOhnePass.pem TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLS_REQCERT never #TLS_REQCERT allow #TLS_REQCERT try TLS_REQCERT demand

2 2

can't get slapd to do pass-through authentication
by Brent Bice 05 Aug '10

05 Aug '10

I've been trying to get Pass-Through authentication to work using a userPassword attribute of the form {SASL}username@realm. At this point I'm guessing but is there a way to tell slapd what pathspec to use to talk to saslauthd? (I'm guessing maybe it's using one path but saslauthd is using a different one for the socket file) I've got saslauthd running ok and can authenticate using testsaslauthd so I'm fairly sure I'm ok there. And I've got openldap compiled with --enable-spasswd option so it ought to support the SASL pass-through option, right? I ran saslauthd with debugging on so I can see every auth request and whether it succeeds or fails and I can see it when testsaslauth connects and succeeds. But when I try to bind to slapd using the DN whose userPassword is {SASL}bbice@ldap the authentication to slapd fails and saslauthd doesn't show any authentication attempt at all. It's as if it's not even trying (or can't find) saslauthd. I ran slapd with the -d 255 option and saved the output to a file. Here's all the lines containing the string sasl: >>> dnPretty: <cn=SASL> => ldap_bv2dn(cn=SASL,0) <= ldap_bv2dn(cn=SASL)=0 <= ldap_dn2bv(cn=SASL)=0 <<< dnPretty: <cn=SASL> >>> dnNormalize: <cn=SASL> <<< dnNormalize: <cn=sasl> ldap_sasl_bind_s ldap_sasl_bind SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" So if I'm reading that right, slapd does see that it's supposed to hand off the authentication to saslauthd and it has picked out the username and realm. But it doesn't seem to be connecting to or using saslauthd. Any ideas? What am I missing here? Brent Bice bbice(a)sgi.com

4 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2010