I can't login in my system using OpenLDAP
by Eric KOM
Hi Dear!
Since 3 days I try to setting a LDAP Server with OpenLDAP on Debian Lenny.
I'm using Mandriva Management Console (mmc) like web based admin.
I already create some users with mmc, but I can't login?
Please, everybody can help me or provide me a good tuto?
--
Yours truly,
Eric KOM
110 LAWN STREET ROSETTENVILLE
2190
JOHANNESBURG
SOUTH AFRICA
Phone: +27 (0) 788 791 334
Fax: +27 (0) 865 563 009
E-mail: erickom(a)namekom.co.za
Websites: www.erickom.co.za | www.namekom.co.za/erickom | www.namekom.co.za
11 years, 8 months
troubles with back-ldap based replication
by DT Piotr Wadas
Hello.
I have some troubles setting syncrepl + back-ldap push based
replication, as described on
http://www.openldap.org/doc/admin24/replication.html#LDAP Sync Replication
I'm using current stable openldap - the problem is, when I set up daemons
(using the same slapcat output file) and modify e.g. "description"
attribute on master side, back-ldap pushes out system attributes like
entryCSN, creatorsName, etc, which causes modify operation to fail on
final consumer side.
conn=1000 op=33 MOD attr=creatorsName createTimestamp description entryCSN
conn=1000 op=33 RESULT tag=103 err=19 text=creatorsName: no user modification allowed
Is it some ACL-related matter, should I create some ACL, which
denies to read of system attributes on master-side, to avoid replicating
it with syncrepl to local back-ldap ?
In such push-based scenario ( in opposite to classic provider-consumer
syncrepl), final consumer does not know actually that it is a replica,
it's just receiving modify operation, how do I prevent read-only system
attributes from being pushed from back-ldap to final replica?
Regards,
DT
11 years, 8 months
Re: invalid syntax on pwdPolicy object add
by Julien Vehent
On Tue, 14 Sep 2010 10:51:01 +0200, Emmanuel Lecharny <elecharny(a)gmail.com> wrote:
> On 9/14/10 8:40 AM, mailing lists wrote:
>> Hello,
>>
>> I think that the pwdAttribute needs an OID value (specified by the syntax)
>> so you would must use the OID of the userPassword attribute which is
>> 2.5.4.35
>>
>>
>>
>>
>>
> I thought that would be a possibility for the failure Kiran and Julien are facing, (please guys, can you give it a try ?), but IMO, there is no reason why we would not be allowed to use 'userPassword' in this context.
>
> Using the OID instead of the alias name does not carry any extra information, as soon as the alias is valid accordingly to the schema (whatever it represents, be it an AT, OC, MR, or any of the other kind of schema objects). The syntax should just check that the alias is syntaxically correct. It's up to the ppolicy overlay to check that the value is a valid AT.
>
> Plus the error message is really misleading if this is the cause for the error.
I tried with the OID... same thing.
How can I check that the module is properly loaded and functional ?
Julien
11 years, 8 months
objectClass index from slapd.conf is not working
by tim stone
Hello,
I've a strange behavior while using index objectClass for searching.
In my slapd.conf I have defined the index in the database section:
index objectClass eq
Other indexes follows in the config. All of them working fine.
If I search via ldapsearch like:
ldapsearch -x -h localhost -w password -D"cn=admin,ou=root"
-b"ou=root" "(objectclass=Guest)"
I can find following Message in the syslog (loglevel -1):
Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY
Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass)
Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read: failed (-30989)
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=0,
first=0, last=0
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=0
first=0 last=0
Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_filter_candidates
Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY
Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass)
Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates:
id=-1, first=228, last=355772
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1
first=228 last=355772
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1
first=228 last=355772
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1
first=228 last=355772
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1
first=112277 last=355755
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1
first=112277 last=355755
Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1
first=112277 last=355755
Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter
Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY
Sep 1 14:02:52 LDAP01 slapd[17856]: <= test_filter 5
Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter
Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: "cn=Aaa,cn=Bbb,...
Sep 1 14:02:52 LDAP01 slapd[17856]: <= entry_decode(cn=Aaa,cn=Bbb,...
Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_dn2id("cn=aaa,cn=bbb,...
Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_dn2id: got id=0x1b696
Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter
Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY
Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following...
As result, the entires are found, but not in the index and the search
takes a very long time.
After this, I have rebuild the complete database via slapcat/slapadd,
rebuild the index via slapindex for objetClass, but nothing helped.
In tried the test above on:
* OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5)
* OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5)
* Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2)
with different databases and a search against a objectClass.
If I try another index (not objectClass) from the slapd.conf the index
works, example:
ldapsearch -x -h localhost -w password -D"cn=admin,ou=root"
-b"ou=root" "(mypk=1234-234)"
Sep 1 14:03:44 LDAP01 slapd[17856]: => bdb_equality_candidates (mypk)
Sep 1 14:03:44 LDAP01 slapd[17856]: => key_read
Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_index_read 1 candidates
Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=1,
first=112838, last=112838
Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1
first=112838 last=112838
Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1
first=112838 last=112838
Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1
first=112838 last=112838
Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1
first=112838 last=112838
Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1
first=112838 last=112838
Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1
first=112838 last=112838
Sep 1 14:03:44 LDAP01 slapd[17856]: => test_filter
Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY
Sep 1 14:03:44 LDAP01 slapd[17856]: <= test_filter 6
Sep 1 14:03:44 LDAP01 slapd[17856]: => send_search_entry: conn 1002
dn="cn=Fff,cn=Eee,...
Sep 1 14:03:44 LDAP01 slapd[17856]: <= send_search_entry: conn 1002 exit.
Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3
Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0
Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002
Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for
input on id=1002
Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624
Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind
Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12
Why does only the objectClass index not work?
The only difference I can see, is that all other indexes are based on
"normal" attributes. I don't know, if it is necessary, but for
objectClass I can't find a attribute definition in the schema. In the
core.schema is the attribute definition for objectClass deactivated
(aka #)...
Here is the Config from the LDAP-Server:
# Schema and objectClass definitions
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/my_ldap_attribute.schema
include /etc/openldap/schema/my_ldap.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit -1
timelimit 300
disallow bind_anon
gentlehup on
tool-threads 1
#######################################################################
# bdb database definitions
#######################################################################
database bdb
suffix "ou=root"
rootdn "cn=root,ou=root"
checkpoint 4096 15
rootpw password
directory /var/lib/ldap
dbnosync
# Indices to maintain
index objectClass,entryUUID,entryCSN eq
index mypk,myusername pres,eq
index myproperty,mylanguage eq
index cn eq,sub
Kindly regards Tim Stone
11 years, 8 months
Re: invalid syntax on pwdPolicy object add
by mailing lists
Hello,
I think that the pwdAttribute needs an OID value (specified by the syntax)
so you would must use the OID of the userPassword attribute which is
2.5.4.35
11 years, 8 months
Keep alive functionality when the remote closes the conenction due idle
by alin vasile
Hi guys,
I have a question related to the open ldap client keep alive functionality. Our OS is SLES 11.
In our client code we are reusing the ldap connections between requests uning a connection pool. For each conenction we are setting the keep-alive options (LDAP_OPT_X_KEEPALIVE_IDLE, LDAP_OPT_X_KEEPALIVE_PROBES and LDAP_OPT_X_KEEPALIVE_INTERVAL) and this works fine.
My question is how the openl ldap library (libldap and libldap_r) handles the situation when the number of kee-alive probes for a connection is exceeded and the connection is closed at the server side.
Did you dealt with this situation?
Thanks,
Alin
11 years, 8 months
syncrepl incomplete database problem
by Islam Amer
Hello everyone,
I have a problem with a simple master/slave syncrepl replication
setup. Everytime I restart the slave it goes back to an empty state
and then syncs about only 200 entries from thousands in the master.
>From then on it gets the update events from the master fine.
I have tried some of the things suggested in this mailing list but
none have worked so far. For example I tried initializing the slave
with a full slapcat of the master after deleting all files from
/var/lib/ldap/ , but when I start the slave it deletes ALL entries and
starts over.
The master is debian etch with 2.3.30-5+etch2 ( critical, not easy to update )
The slave is 2.3.43 RHEL
The slave config is :
syncrepl rid=100 provider=ldaps://xxxxxxxxxxxxxx:636 type=refreshOnly
tls_cert=/var/lib/ldap/ssl/clientcert.pem
tls_key=/var/lib/ldap/ssl/clientkey.pem
tls_cacert=/var/lib/ldap/ssl/cacert.pem interval=00:00:01:00 retry="5
60" searchbase="dc=xxxx" filter="(objectClass=*)" scope=sub
schemachecking=off bindmethod=simple binddn="cn=xxxxx,dc=xxxx"
credentials=xxxxxx
slapd is started with options "-c rid=100,csn=0"
( the real values are obscured for security, sorry )
I switched to refreshOnly because the connection passes through a
strict firewall, and I read that the persistent connection of
refreshAndPersist has problems with that.
Any help is appreciated.
Thanks.
11 years, 8 months
Re: invalid syntax on pwdPolicy object add
by Julien Vehent
On Mon, 13 Sep 2010 19:29:12 +0530, Kiran Ayyagari <kayyagari(a)apache.org> wrote:
> On Mon, Sep 13, 2010 at 5:07 PM, Julien Vehent <julien(a)linuxwall.info> wrote:
>>
>>
>>
>> # slapd -V
>> @(#) $OpenLDAP: slapd 2.4.23 (Aug 26 2010 18:33:04) $
>> root@monster:/tmp/buildd/openldap-2.4.23/debian/build/servers/slapd
>>
>>
>> It's not a space/tab problem, and I've tried to put the request in an ldif file and insert it, with the same result.
>> It's definitely a constraint that's not satisfied... but which one ??
>
> think it is reproducible cause I have got the same error when I
> followed the above steps
> 'error code 21 - pwdAttribute: value #0 invalid per syntax'
>
> I have built OpenLDAP version 2.4.23 on Ubuntu 9.04 with berkeley db
> version 4.7.25
>
> Kiran Ayyagari
>
Alright, so it's either my steps that are wrong, or a problem with slapd.
I'll be humble and suppose that my configuration is wrong first. Any hint on what I could have missed ?
described here: http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:openldap:openl...
Julien
11 years, 8 months
Logging practices of OpenLDAP
by Mark John Rank
List:
UW-Milwaukee is in the process of reviewing IAM infrastructure
and looking to harmonize logging, audit and data retention configuration
for many of our IAM related services. Our OpenLDAP service is
in scope for this review.
To help frame the review, I am looking for guidance or best practices
for configuring logging for OpenLDAP, especially for the HigherEd
community. Of particular interest is the decision process around
balancing log level, performance overhead and data retention.
A search of the archives didn't result in much so I though I would
just ask the question of the list. If individuals are interested in
sharing, they can reply to the list or they can contact me directly
at the address below.
Regards,
Mark
------------------------------------------
Mark Rank, Middleware Architect
University Information Technology Services
UW-Milwaukee
Email: rankm(a)uwm.edu
Phn: 414-229-3706
------------------------------------------
11 years, 8 months
Confused about password authentication formats
by 1.41421＠gmail.com
I have an OpenLDAP 2.4.23 server up and running in a Linux box L against
which I can carry out password authentication on behalf of users logging
into an embedded system E. To accomplish this, in LI have an LDIF file with
entries along the following lines:
dn: uid=xxx,ou=yyy,dc=zzz,dc=com
uid: xxx
cn: xxx
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: ThisIsthePassword
shadowLastChange: 14014
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1003
gidNumber: 1003
homeDirectory: /home/xxx
gecos: ,,,
I would like to change this so that, when sending password information from
my LDAP client in E to the LDAP server in L, the password itself is never
sent in the clear. So I thought to change the value of the userPassword
attribute to read
{SHA}3DRF4FXpG8r+Ki8i8azuZh7KwO8=
instead, where the string above was obtained by means of
slappasswd -v -s ThisIsthePassword -h "{SHA}"
in L.
After restarting the LDAP server in L, when user xxx logs into E with
password "ThisIsthePassword" I can verify in the traces of the LDAP server
(I am running it as slapd -d 255) that the client in E is sending
the "3DRF4FXpG8r+Ki8i8azuZh7KwO8=" string, exactly as specified in the
value of the userPassword attribute. However, the authentication is failing.
What is it exactly that the LDAP client in L is supposed to be sending to
the LDAP server in this case? I noticed that if the client sends the
actual "ThisIsthePassword" string instead the authentication also fails. I
am obviously missing something here but, what is it?
11 years, 8 months
