Virtual list view problem
by Venish Khant
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
7 years
Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra
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
12 years, 5 months
Re: How to check LDAP replication status?
by Gavin Henry
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-...
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/
12 years, 9 months
Syncrepl: Reliable method to ask a server for its own URL
by Torsten Schlabach (Tascel eG)
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
12 years, 9 months
pass-through authentication
by Brent Bice
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
12 years, 9 months
delta-sync replication slave quitting problem - not a single retry
by Alexander Ivanov
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
12 years, 9 months
comp match module has unusable X509 cert code
by Lehnert, Hartmut
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
12 years, 9 months
Client Configuration on Windows
by Wallus, Harald Dr.
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
12 years, 10 months
can't get slapd to do pass-through authentication
by Brent Bice
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
12 years, 10 months
