Re: multiples syncrepl from same host and DB
by Abdelhamid MEDDEB
Hi,
I don't think so.
Try instead:
olcSyncrepl: {0}rid=201 provider=ldap://master searchbase="suffixDB" filter="(<a filter who return data in both branch1 and 2>)" ...
Reset the data in slave before trying again
Maybe it would be better
Cheers
Le 15/04/2015 14:00, openldap-technical-request(a)openldap.org a écrit :
hello,
I wanted to synchronize 2 branches of a master DB (slapd-2.4.38). So I
created 2 olcSyncrepl on the slave :
olcSyncrepl: {0}rid=201 provider=ldap://master searchbase="cn=branch1,suffixDB" scope=sub
olcSyncrepl: {1}rid=202 provider=ldap://master searchbase="cn=branch2,suffixDB" scope=sub
Unfortunatly, it doesn't work. A change on branch2 on the master
produces often a "CSN too old" on the slave.
After investigating, it seems that the pb comes from the fact there is
one contextCSN by DB. So if the sync task on branch1 is the first to
process, it updates the contextCSN and therefore the sync task on
branch2 thinks that change is not newer. Am I right ?
So is there a proper way to achieve what I want ?
--
*Abdelhamid MEDDEB*
http://www.meddeb.net
7 years, 11 months
Re: Help: LDAP using alias to reference value of another attribute
by Quanah Gibson-Mount
--On Tuesday, April 14, 2015 5:52 PM +0400 Poul Etto <zepouletto(a)gmail.com>
wrote:
> There are "u" user accounts on the ldap server
> We have a number of "s" services that use LDAP to manage user account.
> Each service has particular attributes
> Each service must be able to access only it's information
> Basic services use only the information contained in the standard LDAP
> useraccount
> Advanced services have dedicated OUs with special attributes
>
> It is important that each service can accees in RO (no modification) to
> only it's information.
> That's why we made our LDAP as it is in the attached picture.
This is what custom objectClasses and ACLs are for.
Here's an example of a directory set up correctly:
<https://itservices.stanford.edu/service/directory/datadefs/accounts>
Where services are tied to the user object, with their own specific
attributes. ACLs can be used to restrict what data a given service can
retrieve.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 11 months
can't chang ldap user passwd by self
by rockwang
hi,guys
I just setup a openldap server via compile command as following.
./configure --prefix=/opt/openldap
--enable-overlays=mod
--enalbe-dynamic=yes
--enable-modules=yes
--enable-ppolicy=yes
slapd.conf as below
include /opt/openldap/etc/openldap/schema/core.schema
include /opt/openldap/etc/openldap/schema/cosine.schema
include /opt/openldap/etc/openldap/schema/inetorgperson.schema
include /opt/openldap/etc/openldap/schema/nis.schema
include /opt/openldap/etc/openldap/schema/openldap.schema
include /opt/openldap/etc/openldap/schema/ppolicy.schema
pidfile /opt/openldap/var/run/slapd.pid
argsfile /opt/openldap/var/run/slapd.args
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=abc,dc=com"
by * none
access to *
by self write
by dn.base="cn=Manager,dc=abc,dc=com"
by * read
by * none
database bdb
suffix "dc=abc,dc=com"
rootdn "cn=Manager,dc=abc,dc=com"
rootpw 12345678
directory /opt/openldap/var/openldap-data
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
loglevel -1
my question is user can't change his own password. I use following command
so I have different result.
when not add -x
is there error in my config file about acl. I have set pwdRest is true.
I need help. thks
7 years, 11 months
ldap_sasl_interactive_bind_s works while ldap_sasl_bind_s does not (GSSAPI bind)
by Osipov, Michael
Hi folks,
I am trying to perform a SASL bind against Active Directory with GSSAPI mech. I wrote a very simple C client which should serve as a proof of concept.
I read the man page about both methods [1] and decided to try ldap_sasl_bind_s first.
I saw that ldap_sasl_bind_s never sends a Kerberos token to the server (Wireshark capture). Then I tried ldap_sasl_interactive_bind_s as in ldapsearch after fiddler with interact and defaults, which is by the way not very helpful described in the man page, though [2] helped a lot. This one works flawlessly.
The difference between both is not really clear to me because we aren't going to use any interactive code. Our goal is to write attribute retrieval for headless libs.
A day after, I have downloaded the source tarball and saw that ldap_sasl_bind_s never calls sasl_client_start where ldap_sasl_interactive_bind_s actually does. Additionally, I have found gssapi.c with ldap_int_gss_spnego_bind_s and ldap_gssapi_bind_s where both init the GSS context and loop over the tokens with ldap_sasl_bind_s.
Does that ultimately mean that one should avoid ldap_sasl_bind_s altogether and work with ldap_sasl_interactive_bind_s regardless of the mech(s) used?
[1] http://www.openldap.org/software/man.cgi?query=ldap_sasl_bind_s&sektion=3...
[2] http://adam.younglogic.com/2012/02/exteranl-sasl/
Regards,
Michael
7 years, 11 months
can't chang password via simple authentication
by rockwang
hi,guys
I can't chang user password via simple authentication at ldap
client.
I have set acl rule in slapd.conf.
access to attr=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=abc,dc=com" write
by * none
access to *
by self write
by dn.base"cn=Manager,dc=abc,dc=com" write
by * read
ldappasswd -x -D "uid=bobliu,ou=it,dc=abc,dc=com" -W -S
New password:
Re-enter new password:
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
but can use ldapsearch via simple authentication.
what about problem. thks
7 years, 11 months
Re: Very slow ldapserach
by Saša-Stjepan Bakša
On 9 April 2015 at 17:57, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Thursday, April 09, 2015 10:21 AM +0200 Saša-Stjepan Bakša <
> ssbaksa(a)gmail.com> wrote:
>
>> And search for all still crashes openldap server
>>
>> ldapsearch -h 10.14.252.103 -p 389 -D cn=admin,dc=spr -w siemens -s sub
>> -a always -b dc=SPR objectClass=*
>>
>>
>> I must wait for 2.4.41 release then. In the mean time I will use LTB
>> project build with HDB to see can I have that version in working state
>> for my colleagues test suite.
>>
>
> Hi Sasa,
>
> Thanks for checking. Looks like there is some more work to do in this
> area before 2.4.41 releases. I wil be asking you to do further testing in
> the near future. If it were possible for you to provide me an example DB
> and your slapd configuration that replicates this behavior, it would help
> with a resolution.
>
> --Quanah
Hi Quanah,
I will be more than happy to provide help with testing. I am at home now
but tomorrow morning (8:00 CET) I will provide as much data as I can to
you. As some of data can be of sensitive nature, may be I will be obliged
to send it directly to you. Is that Ok with you?
Best regards,
Sasa
7 years, 11 months
Re: Very slow ldapserach
by Saša-Stjepan Bakša
On 9 April 2015 at 17:57, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Thursday, April 09, 2015 10:21 AM +0200 Saša-Stjepan Bakša <
> ssbaksa(a)gmail.com> wrote:
>
>> And search for all still crashes openldap server
>>
>>
>>
>> I must wait for 2.4.41 release then. In the mean time I will use LTB
>> project build with HDB to see can I have that version in working state
>> for my colleagues test suite.
>>
>
> Hi Sasa,
>
> Thanks for checking. Looks like there is some more work to do in this
> area before 2.4.41 releases. I wil be asking you to do further testing in
> the near future. If it were possible for you to provide me an example DB
> and your slapd configuration that replicates this behavior, it would help
> with a resolution.
>
> --Quanah
>
>
And again I did stupid thing to send withoth checking recipient. I hate
this Gmail web interface. Sorry.
7 years, 11 months
Bug with MDB backend and onelevel scope
by Côme BERNIGAUD
Hello, I got this weird behavior: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782212
Summary:
# LDAPv3
# base <ou=wheezy,ou=debian,ou=fai,ou=configs,ou=systems,dc=mcmic,dc=test> with scope oneLevel
# filter: objectClass=FAIbranch
# requesting: ALL
#
# wheezy, debian, fai, configs, systems, mcmic.test
dn: ou=wheezy,ou=debian,ou=fai,ou=configs,ou=systems,dc=mcmic,dc=test
This dn should not be in the results as it’s the base and the scope is oneLevel.
As I managed to build slapd from http://www.openldap.org/software/download/ and reproduce the problem I thought I should ask here if anyone already encountered this kind of problems.
It only happens with MDB, with this particular base and filter (filter "ou=wheezy" for instance works correctly).
Any idea what the root of this problem could be?
7 years, 11 months
Re: Very slow ldapserach
by Saša-Stjepan Bakša
On 9 April 2015 at 02:37, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Wednesday, April 08, 2015 8:51 PM +0200 Saša-Stjepan Bakša <
> ssbaksa(a)gmail.com> wrote:
>
> I am sorry for this mistake with answering to you and not to the group.
>> It was unintentional mistake.
>>
>>
>> Ok, I will check ITS#7657.
>>
>
> Please try current RE24 code. It is believed the fixes for ITS#8011 which
> are scheduled to be part of the 2.4.41 relase should resolve the issue.
>
> Thanks,
>
> Quanah
>
>
At 8:00 local time:
git checkout OPENLDAP_REL_ENG_2_4
git pull
Build + test
root@test:~# date; ldapsearch -h 10.14.252.103 -p 389 -D cn=admin,dc=spr -w
siemens -s sub -a always -b msisdn=385212000009,dc=MSISDN,dc=SPR
objectClass=*; date
*Thu Apr 9 08:22:46 CEST 2015*
# extended LDIF
#
# LDAPv3
# base <msisdn=385212000009,dc=MSISDN,dc=SPR> with scope subtree
# filter: objectClass=*
# requesting: ALL
#
----- cut------
# search result
search: 2
result: 0 Success
# numResponses: 9
# numEntries: 8
*Thu Apr 9 08:23:38 CEST 2015*
Nothing changed yet - 52 seconds
And search for all still crashes openldap server
ldapsearch -h 10.14.252.103 -p 389 -D cn=admin,dc=spr -w siemens -s sub -a
always -b dc=SPR objectClass=*
552641e7 >>> dnPrettyNormal: <dc=SPR>
552641e7 <<< dnPrettyNormal: <dc=SPR>, <dc=spr>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
552641e7 => mdb_search
552641e7 mdb_dn2entry("dc=spr")
552641e7 => mdb_dn2id("dc=spr")
552641e7 <= mdb_dn2id: got id=0x1
552641e7 => mdb_entry_decode:
552641e7 <= mdb_entry_decode
552641e7 search_candidates: base="dc=spr" (0x00000001) scope=2
552641e7 => mdb_equality_candidates (objectClass)
552641e7 => key_read
552641e7 <= mdb_index_read 10000000 candidates
552641e7 <= mdb_equality_candidates: id=-1, first=16, last=10000015
Segmentation fault
I must wait for 2.4.41 release then. In the mean time I will use LTB
project build with HDB to see can I have that version in working state for
my colleagues test suite.
Br
Sasa
7 years, 11 months
