Adding OU with PSQL backend
by Marcel Berteler
For a project that requires a large user authentication database, we are
currently using OpenLDAP with a BDB backend. We have about 150K users in
the tree and all works well. Authentication and new user creation is
fast and we are happy.
But, when we try and get statistical data from the tree, we run into the
limitations of LDAP: trying to find all user that have registered last
month, using a filter with 2 dates, is just too slow. It takes minutes
to come back with a result.
To get around this limitation, we want to experiment with a PSQL backend
so we can do some comparative testing.
(If any of you have a way of allowing us to interrogate our BDB backend
with SQL like queries that are relatively fast, than please let me know.)
Our test environment:
openldap 2.4.16 with Postgres backend
I have loaded CORE in slapd.conf as well as our custom schema for our users
The only ACL in the conf is ACCESS TO * BY * WRITE
Our tree looks like this and I have loaded the data tables and meta-data
tables:
dc=example,dc=come
ou=people,dc=example,dc=com
cn=user1,dc=example,dc=com
The setup is working about 60%.
with openLdapAdmin, I can see the tree and I can add users.
What I can not do, is add an OU. It gives me:
LDAP said: Server is unwilling to perform
Error number: 0x35 (LDAP_UNWILLING_TO_PERFORM)
Description: The LDAP server refused to perform the operation.
If I get this on our custom schema, I can explain this by not having the
right meta-data and procedures loaded. But as this is part of the CORE
schema, am I right in only adding the meta-data for OU in
ldap_attr_mappings without add or delete procedures?
I have looked at the log files and outputs but I can not figure out what
is going wrong and why it is not accepting any new OU
Any help is appreciated.
--
Regards,
Marcel Berteler
*Chief Information Officer
*/"May the source be with you"/
Website: http://www.bdsolutions.co.za
Email Legal Notice: http://www.bdsolutions.co.za/legal/
12 years, 7 months
just curious
by Piotr Wadas
Hello, I've been trying past weeks upgrading my production openldap
software. I started from 2.4.11 when it was available, through all
available versions, up to 2.4.16. I tried package builds, and my own
builds. Each version except 2.4.10 was likely to hang, as it's production,
and load is quite high, I haven't too much patience to debug and
researching what's actually going on, but I tried disabling syncrepl (no
effect), some different settings for bdb backend and slapd thread,
concurrency etc ( starting from settings which caused no problems with
2.4.10 ), and finally, got back to 2.4.10 which works fine. Between
version change I noticed that 2.4.11+ is build with newer libdb versions
(package depends), starting from libdb4.2 (2.4.10), up to libdb4.7 (newer
openldap version). I didn't try to build 2.4.15+ with some old (4.2)
libdb.
Is it some major significant jump between 2.4.10 and all later versions?
some general rewrite of some feature ? It's not syncrepl related, as
daemon hang no matter whether configured as slave or standalone.
The symptoms was, it was (in general) producing BIGGER server load
than 2.4.10, and, although daemon process did not segfaults, server
stopped responding for requests (?). With higher load I wasn't able
to try logging and use of debug symbols.
I expected it will work without any slapd.conf, anyway nor leaving it
untouched, nor some minor reasonable changes had no effect.
So, what's going on? :) Is it possibly related to libdb ? or what?
What else could it be ? Except libdb ( 5 different versions available
in my system with one default, usually newest ), there was no other
software change, just upgrading openldap/libldap.
Any clues you may have? I'm sorry I cannot provide more information,
anyway config is rather standard and simple, some custom schemas
added with indexing, that's all. 2.4.10 has no problems at all,
and significantly lower general machine load. ( if 2.4.10 = 100%, 2.4.11+
makes 300-400% )
Actually I'm not expecting some miracle explanation, anyway it's
interesting what could it be.. I have about 25 000 entries total in
my directory tree, it's used as NSS source, and other information
for various applications.
regards :)
P.
12 years, 7 months
Porting mozldap to openldap
by Nguyen, Quang
Hi everybody,
I have spend sometime to understand mozldap and openldap. I have
searched the archives using these keyword "mozldap to openldap" or just
"mozldap" but found nothing.
I have to port an application currently using mozldap to openldap.
Has anyone done this before, I would like to ask some questions such as:
1. I see that the application called ldapssl_advclientauth_init(),
ldapssl_init() if using certificate and call prldap_init() if using
simple authentication. The function ldapssl_advclientauth_init() is very
big after I traced it down. Is there an equivalent call in openldap?
2. Is there any example posted somewhere that my search on google missed
(I could not find any).
3. Is there anything I should be watching for?
4. What is the best approach to do this?
I thank you very much for any help, suggestion I can get.
Best regards
12 years, 7 months
Setting up LDAP server
by Santosh Balan
Hi Friends,
Can anyone help me on implementing and configuring LDAP server to
authenticate users with system policies and auto mount a user's partition
provided to him. Also, I want it to authenticate qmail users using LDAP.
Your assistance is highly appreciable. Thanking you in advance.
Thanks and Regards
Santosh Balan
9819419509
--
It's News. It's Reviews. It's Interviews. It's Free. What Are You Waiting For?
www.movieline.com
12 years, 7 months
ldap SQL backend and syncrepl
by Frederic Bouy
Hello,
For performance issues (millions or records) I have two ldap servers:
- one master with an sql backend (postgres) to allow easy data manipulation
- one slave to anwer ldap queries and provide good response time
When lauching the slave ("./slapd -f
/usr/local/openldap/etc/openldap/slapd-front.conf -h "ldap://localhost:3890"
-d 1") I got a first non blocking error I don't really understand:
" => bdb_dn2id("dc=lnp")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30988)"
According to the fact that the following command is successfull:
"ldapwhoami -H "ldap://localhost:389" -D "cn=manager,dc=lnp" -w secret"
and then the synchronization fails with this error:
"read1msg: ld 0x9ca73e8 msgid 2 message type search-entry
ber_scanf fmt ({xx) ber:
ber_scanf fmt ({a) ber:
ber_scanf fmt (o) ber:
ber_scanf fmt ({em) ber:
do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD
ldap_msgfree
connection_get(11): got connid=0
ldap_free_request (origid 2, msgid 2)
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 11
ldap_free_connection: actually freed
do_syncrepl: rid=001 quitting"
Do you know whether suncrepl is support for ldap with sql backend?
Do you know where can I find some documentation on this?
Do you have any clue on how I could solve my issues?
Thanks in advance.
Please find below the .conf of those two ldap servers:
# === MASTER =====
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/lnp.schema
pidfile /usr/local/openldap/var/slapd-lnp.pid
argsfile /usr/local/openldap/var/slapd-lnp.args
backend sql
#######################################################################
# sql database definitions
#######################################################################
database sql
suffix "dc=lnp"
rootdn "cn=Manager,dc=lnp"
rootpw secret
dbname lnp
dbuser lnp
dbpasswd lnp
strcast_func "text"
#subtree_cond "ldap.entries.dn like '%'||?"
concat_pattern "?||?"
has_ldapinfo_dn_ru no
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
lastmod on
# === MASTER =====
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/lnp.schema
pidfile /usr/local/openldap/var/run/slapd-front.pid
argsfile /usr/local/openldap/var/run/slapd-front.args
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=lnp"
rootdn "cn=Manager,dc=lnp"
rootpw secret
directory /usr/local/openldap/var/openldap-data
# index entryCSN,entryUUID eq
index entryUUID eq
# filter="(objectClass=*)"
syncrepl rid=001
provider=ldap://localhost:389
bindmethod=simple
type=refreshAndPersist
searchbase="ou=31,dc=lnp"
schemachecking=off
binddn="cn=manager,dc=lnp"
credentials=secret
filter="(objectClass=*)"
mirrormode on
serverID 1
12 years, 7 months
Re: Directory migration
by Michael Ströder
Ian wrote:
> On Tue, 21 Apr 2009 23:07:11 Michael Ströder wrote:
>> Hmm, which password scheme is used? Are the userPassword values prefixed
>> with {MD5} or with {CRYPT}? In the latter case libcrypt on both systems
>> could be incompatible. So this could be another issue. The general
>> advice is not to use {CRYPT}. Recommended is to use salted SHA-1
>> (password scheme {SSHA}).
>
> Well FreeBSD is using MD5 for it's encryption and so is the linux workstation.
This does not say much since there are also MD5-based password hashes in
Unix crypt.
> Is the LDAP server encrypting the hashes as well?
No, the clear-text password is hashed depending on the password scheme
together with a random salt.
> They don't look like the
> hashes in master.password
What is master.password?
> at all, so I guess it is? And that's one reason why
> you need to use the PADL scripts when you import /etc/passwd into your LDAP
> directory?
If you import /etc/shadow or whereever your salted Unix password hashes
are stored you would use the platform-specific password scheme {CRYPT}.
> The password entry looks like this:
> userPassword:: e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0=
^^
The double-colon indicates that the value is base64-encoded in the LDIF
representation.
$ python -c "print
'e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0='.decode('base64')"
{md5}547qEjL5yQnfIp7aDAXd8w==
So this is a plain MD5-hashed password. This password scheme is *not*
platform-specific. Is this from your original data? Do all entries have
password values like this? Check that. If yes, then you should not have
a problem to migrate this data.
> So I don't know what encoding it's using - is there a setting that controls
> this? (nothing in slapd.conf that I can see).
There are various relevant settings. But I wonder which component is
used for setting the password and which mechanism it uses.
You should also consult the fine articles in the FAQ-O-MATIC:
http://www.openldap.org/faq/data/cache/419.html
Ciao, Michael.
12 years, 7 months
Re: Directory migration
by Michael Ströder
Ian wrote:
> On Wed, 22 Apr 2009 00:04:47 Andrew Findlay wrote:
>> On Tue, Apr 21, 2009 at 03:37:11PM +0200, Michael Ströder wrote:
>>> Hmm, which password scheme is used? Are the userPassword values prefixed
>>> with {MD5} or with {CRYPT}? In the latter case libcrypt on both systems
>>> could be incompatible. So this could be another issue. The general
>>> advice is not to use {CRYPT}. Recommended is to use salted SHA-1
>>> (password scheme {SSHA}).
>> You also need to make sure that the new server was built with support
>> for your chosen hash scheme. If using crypt passwords, this means
>> adding the --enable-crypt flag to the initial 'configure' command.
>
> Maybe that's where the problem lies. From what Michael said in his reply, the
> passwords are plain MD5 hashes. Perhaps I've build the new one with crypt
> support and it's trying to use that instead of straight MD5?
The password scheme {MD5} does not need --enable-crypt!
>> As Michael says, it would make sense to use 2.4.16 for your
>> new installation.
>
> And I shall, but maybe now it's best to get 2.3.x working first, then go to
> the new version.
You might have to migrate your database. So there's really no reason to
not directly use 2.4.16.
Ciao, Michael.
12 years, 7 months
Re: Directory migration
by Ian Moore
On Wed, 22 Apr 2009 00:13:51 Michael Ströder wrote:
> Ian wrote:
> > On Tue, 21 Apr 2009 23:07:11 Michael Ströder wrote:
> >> Hmm, which password scheme is used? Are the userPassword values prefixed
> >> with {MD5} or with {CRYPT}? In the latter case libcrypt on both systems
> >> could be incompatible. So this could be another issue. The general
> >> advice is not to use {CRYPT}. Recommended is to use salted SHA-1
> >> (password scheme {SSHA}).
> >
> > Well FreeBSD is using MD5 for it's encryption and so is the linux
> > workstation.
>
> This does not say much since there are also MD5-based password hashes in
> Unix crypt.
>
> > Is the LDAP server encrypting the hashes as well?
>
> No, the clear-text password is hashed depending on the password scheme
> together with a random salt.
>
> > They don't look like the
> > hashes in master.password
>
> What is master.password?
:-) FBSD equivalent of /etc/shadow
> > at all, so I guess it is? And that's one reason why
> > you need to use the PADL scripts when you import /etc/passwd into your
> > LDAP directory?
>
> If you import /etc/shadow or whereever your salted Unix password hashes
> are stored you would use the platform-specific password scheme {CRYPT}.
>
> > The password entry looks like this:
> > userPassword:: e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0=
>
> ^^
> The double-colon indicates that the value is base64-encoded in the LDIF
> representation.
>
> $ python -c "print
> 'e21kNX01NDdxRWpMNXlRbmZJcDdhREFYZDh3PT0='.decode('base64')"
> {md5}547qEjL5yQnfIp7aDAXd8w==
>
> So this is a plain MD5-hashed password. This password scheme is *not*
> platform-specific.
So I guess that's why it works logging in from a linux workstation, even
though the passwords originally were imported from the FBSD master.passwd
file and also works with squid running on the FBSD server.
> Is this from your original data?
Yes, taken from the original server's LDAP database.
> Do all entries have password values like this? Check that.
Yes, they do!
> If yes, then you should not have a problem to migrate this data.
Yet sadly I do have a problem :-/
I have used ldapsearch to confirm that the password hashes are the same on the
old & new servers when I use ldapsearch or slapcat to view them. Yet I can't
login on the new server. And since the hashes are salted, I can't tell if the
actual password is really different.
>
> > So I don't know what encoding it's using - is there a setting that
> > controls this? (nothing in slapd.conf that I can see).
>
> There are various relevant settings. But I wonder which component is
> used for setting the password and which mechanism it uses.
>
> You should also consult the fine articles in the FAQ-O-MATIC:
>
> http://www.openldap.org/faq/data/cache/419.html
I'll give that a read tonight and do some more testing.
Cheers,
--
Ian
gpg key: http://home.swiftdsl.com.au/~imoore/no-spam.asc
12 years, 7 months
Re: Master server error
by Gavin Henry
----- "Ivan Ordonez" <iordonez(a)nature.berkeley.edu> wrote:
> Hi,
>
> Just wondering why the master server is trying to contact the slave
> when
> I use any of the smbldap tools? I would get the message below.
>
> erreur LDAP: Can't contact slave ldap server (IO::Socket::INET:
> connect:
> timeout)
> =>trying to contact the master server
>
> It would then contact the master server and give me the result.
> Instead
> of pulling the information faster, it will take a few minutes. It is
>
> not a big deal, as things are working fine but I just want to know if
>
> there's a way to get rid of the error. Please advise.
>
This is actually to do with the smbldap tools, not OpenLDAP. Check the config
file for the master/slave settings and the Perl code too. The master isn't
trying to contact the slave at ;-)
Thanks.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
12 years, 7 months
Master server error
by Ivan Ordonez
Hi,
Just wondering why the master server is trying to contact the slave when
I use any of the smbldap tools? I would get the message below.
erreur LDAP: Can't contact slave ldap server (IO::Socket::INET: connect:
timeout)
=>trying to contact the master server
It would then contact the master server and give me the result. Instead
of pulling the information faster, it will take a few minutes. It is
not a big deal, as things are working fine but I just want to know if
there's a way to get rid of the error. Please advise.
Thanks,
-Ivan
12 years, 7 months
