openLDAP paged response problem
by Navaneetha Subramanian
Hi,
I'm using OpenLDAP backend with .NET 2.0
System.DirectoryServices.Protocols API in my application. I'm trying to
issue PagedResult control as part of my request to get results in
multiple pages that code can navigate. This would use rfc2696 which is
already supported in OpenLDAP. But when I run my code it comes back with
exception that ''critical control unavailable in context'.
I've attached the capture from OpenLDAP server
##
T 10.218.5.27:33236 -> 10.217.94.154:389 [AP]
0........c....s.!dc=openldap,dc=dev,dc=net6,dc=com......................
.objectClass..person0....
..distinguishedName..sn..manager...../0....)..1.2.840.1
13556.1.4.319.....0...........
#
T 10.217.94.154:389 -> 10.218.5.27:33236 [AP]
03...e...5...'critical control unavailable in context
#
But OpenLDAP does support the control 1.2.840.113556.1.4.319 as listed
in my query response against rootDSE below
DB2-95-02:~ # ldapsearch -x -h 10.217.94.154 -b "" -s base
'(objectclass=*)' +
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: +
#
#
dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=openldap,dc=dev,dc=net6,dc=com
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.334810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedFeatures: 1.3.6.1.1.14
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
supportedLDAPVersion: 3
entryDN:
subschemaSubentry: cn=Subschema
Any idea why the server responds with ''critical control unavailable in
context' message? I'm using OpenLDAP v 2.3.19
[root@labvmware ~]# slapd -V
@(#) $OpenLDAP: slapd 2.3.19 (Feb 13 2006 11:19:24) $
root@ls20-bc1-14.build.redhat.com:/usr/src/build/708086-i386/BUILD/openl
dap-2.3.19/openldap-2.3.19/build-servers/servers/slapd
Thanks,
Navaneetha
14 years, 3 months
Problem using ldapsearch with TLS (-ZZ)
by Eric Johanson
I am trying to get a basic TLS connection working on my Linux server
using OpenLDAP and the ldapsearch command, but it does not connect with
TLS.
I've created an SSL certificate with the usual command:
openssl req -new -x509 -nodes -out ldcert.pem -keyout ldkey.pem
-days 3650
I've added the requisite lines to slapd.conf (TLSCertificateFile
TLSCertificateKeyFile) and to ldap.conf (TLS_CACERT) (since my
certificate is self-signed).
I've started the OpenLDAP server with the command:
slapd -d 10
If I issue the command:
ldapsearch -x -b 'dc=com' -H 'ldap://localhost/' -D 'uid=root'
-W -v
And everything works and I see a list of all the directory entries in
the server.
However, if I issue the same command except with the -ZZ option to use
TLS:
ldapsearch -x -b 'dc=com' -H 'ldap://localhost/' -D 'uid=root'
-W -v -ZZ
Then I get an error that reads:
ldap_start_tls: Connect error (-11)
So I analyzed the debug log coming from the server (during the
ldapsearch ... -ZZ command) and I get the debug log below (I've snipped
out the actual buffer exchanges for brevity). As you can see, it goes
through several handshakes successfully, but then suddenly the server is
looking for more data but the client doesn't send it, so the server
closes the connection.
Can someone please help to analyze this problem so I can get this
working. LDAP 2.4.12, OpenSSL 0.9.8i. Thank you in advance for any
advice you can offer me.
-Eric
slap_listener_activate(8):
>>> slap_listener(ldap:///)
connection_get(12): got connid=0
connection_read(12): checking for input on id=0
ber_get_next
ldap_read: want=8, got=8
0000: 30 1d 02 01 01 77 18 80 0....w..
ldap_read: want=23, got=23
0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36
.1.3.6.1.4.1.146
0010: 36 2e 32 30 30 33 37 6.20037
ber_get_next: tag 0x30 len 29 contents:
ber_dump: buf=0x83881e8 ptr=0x83881e8 end=0x8388205 len=29
0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34
...w...1.3.6.1.4
0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37
.1.1466.20037
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
conn=0 op=0 do_extended
ber_scanf fmt ({m) ber:
ber_dump: buf=0x83881e8 ptr=0x83881eb end=0x8388205 len=26
0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e
w...1.3.6.1.4.1.
0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush2: 14 bytes to sd 12
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00
0....x........
ldap_write: want=14, written=14
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00
0....x........
connection_get(12): got connid=0
connection_read(12): checking for input on id=0
TLS trace: SSL_accept:before/accept initialization
tls_read: want=11, got=11
0000: 80 7a 01 03 01 00 51 00 00 00 20 .z....Q...
tls_read: want=113, got=113
<... snip ...>
TLS trace: SSL_accept:SSLv3 read client hello A
TLS trace: SSL_accept:SSLv3 write server hello A
TLS trace: SSL_accept:SSLv3 write certificate A
TLS trace: SSL_accept:SSLv3 write server done A
tls_write: want=1105, written=1105
<... snip ...>
TLS trace: SSL_accept:SSLv3 flush data
tls_read: want=5, got=5
0000: 16 03 01 01 06 .....
tls_read: want=262, got=262
<... snip ...>
TLS trace: SSL_accept:SSLv3 read client key exchange A
tls_read: want=5, got=5
0000: 14 03 01 00 01 .....
tls_read: want=1, got=1
0000: 01 .
tls_read: want=5, got=5
0000: 16 03 01 00 30 ....0
tls_read: want=48, got=48
<... snip ...>
TLS trace: SSL_accept:SSLv3 read finished A
TLS trace: SSL_accept:SSLv3 write change cipher spec A
TLS trace: SSL_accept:SSLv3 write finished A
tls_write: want=59, written=59
<... snip ...>
TLS trace: SSL_accept:SSLv3 flush data
connection_read(12): unable to get TLS client DN, error=49 id=0
connection_get(12): got connid=0
connection_read(12): checking for input on id=0
ber_get_next
tls_read: want=5, got=0
ldap_read: want=8, got=0
ber_get_next on fd 12 failed errno=0 (Success)
connection_closing: readying conn=0 sd=12 for close
connection_close: conn=0 sd=12
---
-Eric Johanson
Principle Software Engineer
Newpoint Technologies, Inc.
14 years, 3 months
SASL pass-through autentication with a ldap-backend KDC
by Guillaume Rousse
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password
storage scheme, I understand autentication can be delegated to an
external mechanisme. Such as, for instance, a kerberos server. In this
case, it is advised to prevent changing passwords in the directory.
What happens if the autentication provider is an heimdal server, using
OpenLDAP as its backend, and smbkrb5 overlay to keep ldap, samba and
kerberos password synced ? Does pass-through still work ? And it is
recommended then to make the userPassword attribute read-ony, but still
use Exop PasswordChange to change samba and kerberos attributes ?
I didn't tested it yet, but it look very interesting if it works.
Particulary because heimdal password change through kpassword doesn't
use ExOp PasswordChange operation, but only update kerberos and samba
passwords.
I know smbkrb5 has a special {smbkrb5} password storage scheme for
redirecting autentication against kerberos password internally, not
relying on a external SASL process. But it's only usable if smbkrb5
overlay is available (some of our slaves servers are centos-based, and
don't have this overlay, but still need to autenticate users). And the
trick of setting password-hash directive in slapd.conf to {smbkrb5} to
prevent overwriting of userPassword attribute on PasswordChange
operation with a normal value has the drawback than even pure ldap
administrative accounts (syncrepl, for instance) get redirected to
kerberos password for autentication, whereas only our users have
principals currently.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
14 years, 3 months
Large database initial replication problem
by Łukasz Wąsikowski
Welcome!
I've got large test database (>20000 entries), set up replication using
syncrepl (refreshAndPersist). It work's fine when consumer is connected
to provider while importing all database. But when I add new consumer to
use existing database only first 500 records are replicated. I know
about sizelimit, but I don't want to raise it (because I don't know how
big my database will grow). The question is - why consumer won't get
rest of the entries in another queries? What am I doing wrong? I can't
import all database everytime I connect new consumer in a production
enviroment.
--
Best regards,
Lukasz Wasikowski
14 years, 3 months
adding syncprov module fails
by Dieter Kluenter
Hi,
I am trying to set up a cascading replication from scratch, adding
syncprov module fails with:
,----[ output of slapd -dsync ]
| @(#) $OpenLDAP: slapd 2.4.12 (Oct 17 2008 16:01:17) $
| dieter@rubin.l4b.de:/work/openldap-2.4.12/servers/slapd
| slap_queue_csn: queing 0xa583f0 20081021122834.783484Z#000000#001#000000
| slap_graduate_commit_csn: removing 0xa578b0 20081021122834.783484Z#000000#001#000000
| slapd starting
| slap_queue_csn: queing 0x40a70480 20081021122922.151442Z#000000#001#000000
| Control 1.3.6.1.4.1.4203.1.9.1.1 already registered.
| syncprov_init: Failed to register control -9
| slap_graduate_commit_csn: removing 0xa52ef0 20081021122922.151442Z#000000#001#000000
`----
this is my script to load the module
$LDAPMODIFY -x -D $ROOTDN -w $CPW -H $HOST <<EOF
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
EOF
My initial slapd.conf is just
,----[ slapd.conf ]
| include /opt/openldap-2.4/etc/openldap/schema/core.schema
| include /opt/openldap-2.4/etc/openldap/schema/cosine.schema
| include /opt/openldap-2.4/etc/openldap/schema/inetorgperson.schema
| include /opt/openldap-2.4/etc/openldap/schema/nis.schema
|
| pidfile /opt/openldap-2.4/var/run/slapd.pid
| argsfile /opt/openldap-2.4/var/run/slapd.args
|
| modulepath /opt/openldap-2.4/libexec/openldap
| moduleload syncprov.la
|
| database config
| rootdn "cn=config"
| rootpw "xxx"
`----
How come that the control is already registered?
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
14 years, 3 months
two issues with dyngroups
by Guillaume Rousse
Hello list.
I'm an happy users of dynlist overlay, in order to make my unix users
members of their unix primary group:
# admins, groups, msr-inria.inria.fr
dn: cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr
objectClass: groupOfURLs
objectClass: posixGroup
gidNumber: 5000
memberURL:
ldap:///ou=users,dc=msr-inria,dc=inria,dc=fr??sub?(gidNumber=5000)
cn: admins
With this configuration:
# dynamic groups
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
However, I'm facing two issues here.
The first is that dynlist overlay only accept a single configuration
directive for the whole base, preventing to map differently the request
URL depending on the context. In my previous example, I need to map the
URL as DN, because I'm dynamically building a group from users. If I
wanted to build a group from other group, my URL would have been
something as:
ldap:///ou=group,dc=msr-inria,dc=inria,dc=fr?member?sub?(cn=users)
and the configuration directive would have been instead
dynlist-attrset groupOfURLs memberURL
It would be nice to handle the overlay differently there.
The second directive is that ACLs seems to ignore this dynamic group:
# admins
access to dn.subtree="dc=msr-inria,dc=inria,dc=fr"
by group="cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr" write
by * break
This worked with a static group, it doesn't work anymore with a dynamic
one as I just presented.
I'm using OpenLDAP 2.4.11. Should I open ITS for those issues ?
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
14 years, 3 months
Newbie question ldap_sasl_interactive_bind_s: Invalid credentials (49)
by Uli Kleemann
Hello my fellow openldap friends,
I've installed openldap 2.4 on debian lenny usinf the Debian packages
slapd and ldap-utils.
For Authentification I would like to use sasl simple-bind but if I try e.g:
ldapsearch -D "cn=admin,dc=lug-saar,dc=spc" -W -d 255
respectively
ldapsearch -D "cn=Manager,dc=lug-saar,dc=de" -W -d 255
I got:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
As I couldn't find the Error using google yet, but getting as more confused as more HOWTOS I read here is
my ldap.conf:
---------------------------------------------------------------------------------------------------------------------------------
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=lug-saar,dc=de
#URI ldap://ldap.lug-saar.de
URI ldap://192.168.199.159
ldap_version 3
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
------------------------------------------------------------------------------------------------------------------------------------
my slapd.conf
-------------------------------------------------------------------------------------------------------------------------------------
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.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 none
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_hdb
# The maximum number of entries that is returned for a search operation
sizelimit 500
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend hdb
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database hdb
# The base of your directory in database #1
suffix "dc=lug-saar,dc=de"
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn "cn=root,dc=lug-saar,dc=de"
rootpw secret
rootpw {SSHA}Jh+[3]GpYm86f7E0ierBIQJhnN/gKmx
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# The dbconfig settings are used to generate a DB_CONFIG file the first
# time slapd starts. They do NOT override existing an existing DB_CONFIG
# file. You should therefore change these settings in DB_CONFIG directly
# or remove DB_CONFIG and restart slapd for changes to take effect.
# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0
# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057 for more
# information.
# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
# Indexing options for database #1
index objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod on
# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
checkpoint 512 30
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
by dn="cn=root,dc=lug-saar,dc=de" write
by anonymous auth
by self write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=root,dc=lug-saar,dc=de" write
by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=root,dc=lug-saar,dc=de" write
# by dnattr=owner write
#######################################################################
# Specific Directives for database #2, of type 'other' (can be hdb too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>
# The base of your directory for database #2
#suffix "dc=debian,dc=org"
---------------------------------------------------------------------------------------------------------------------------------
The schema and ldif files I put into /etc/ldap/schema
What did I do wrong? Thanks in advance.
--
Uli Kleemann <uli.kleemann(a)guug.de>
Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result.
14 years, 3 months
Recording the Last Successful Authorization
by Tim Gustafson
I was wondering if there is any way to configure OpenLDAP to record the last time an account was successfully authorized? We need to be able to prune accounts after a period of inactivity, but there's no way right now to know if they user has been active or not. We can't base it on the last time they connected to a shell because not everyone uses shells; some people just authenticate to POP their e-mail or log into a web page. If there was some way to maintain a time stamp of the last time that that a user successfully authenticated (by way of an LDAP bind to the LDAP server) that would solve this problem.
Thanks!
Tim Gustafson
SOE Webmaster
UC Santa Cruz
tjg(a)soe.ucsc.edu
831-459-5354
14 years, 3 months
userCertificate;binary in a 2.3.X ldif file
by Brett ＠Google
Can anyone shed any light on :
slapadd: could not parse entry (line=234)
str2entry: attributeType userCertificate #0: needs ';binary' transfer as per
syntax 1.3.6.1.4.1.1466.115.121.1.8
This is ocurring when running 2.4.x slapadd on a certificate containing a
binary attribute, which was a slapcat from a 2.3.X openldap server.
The attribute in question is already a binary attribute, there is a double
colon after the certificate name, so i gather it just wants
userCertificate;binary:: as the attribute name in the LDIF dump when loading
? Cant simply search and replace, because that will increase the line
length, which will stop it from parsing.
Alternatively, anybody know of any tool which can re-justify line lengths in
an ldif, if i search and replace the attribute name ?
It might be nice to have some sort of non-default legacy flag, for loading a
previous release's ldif (or at least be more forgiving than the present
parser)
Cheers
Brett
14 years, 3 months
mysterious segfault
by Jason Dusek
I've added two seemingly innocuous lines to my LDAP
configuration:
Index: conf-root/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif
===================================================================
--- etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif (revision 1444)
+++ etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif (working copy)
@@ -1,6 +1,9 @@
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
+objectClass: olcSyncProvConfig
+olcSpCheckpoint: 100 5
+olcSpSessionlog: 100
olcDatabase: {1}bdb
olcSuffix: dc=metascopic,dc=com
olcAccess: {0}to attrs=userPassword
However, they cause `slaptest` to segfault on Linux! I'm a
little perplexed by this.
:; slaptest -F etc/openldap/slapd.d/
Segmentation fault
Removing the lines restores `slaptest` to a state of sanity.
--
_jsn
14 years, 3 months
