openldap-software

openldap-software@openldap.org

2719 discussions

slapo-chain and propagation delay
by manu＠netbsd.org 04 Aug '08

04 Aug '08

Hello I have a minor problem with slapo-chain: when a user makes a modification on a replica, the modification is sent to the master, and then pulled from the master through syncrepl. It takes a short time to syncrepl for pulling the updated data from the master, but that time is long enough for a web form to reload the previous data, therefore giving the feeling that the modification has been ignored. Is ther any solution for that problem? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

3 2

PGP Keys
by Jorge Medina 03 Aug '08

03 Aug '08

Do anybody knows where I could get the PGP keys to verify the integrity of the source code I downloaded from a mirror? Thanks -Jorge

4 3

Re: Reset LDAP Password for root
by Michael Ströder 03 Aug '08

03 Aug '08

Uli Kleemann wrote: > > Installing openldap I made the mistake to follow an old HOWTO and put > the root passwort in slapd.conf encrypted as recommend in that HOWTO. > So far so good. According to murphyś law I didn`t note the plain > password so that I know have to reset it. As I couldn`t find a > usefull description to do that yet, I would like to ask you for help. Put the output of slappasswd after directive 'rootdn' and restart the server. Ciao, Michael.

1 1

back-sql using varchar keyvals and ids
by Potkanski, Jason 02 Aug '08

02 Aug '08

I have an interest in using openldap as an external authenticator for our membership to connect to external services. Our main table has a primary key of a varchar (10) and nothing unique in the table that is an int. I would love to replace ldap_entries with a view, however, returning the entries failed when I attempted it. I did a bit of experimentation with the dc=example,dc=com on a search: ldapsearch -x -b dc=example,dc=com sn=Puzdoy The ldap_entries keyval was changed from int to varchar 10 and persons table id was changed to varchar 10. Below is a table on some experiments ldap_entries.keyval and persons.id MySQL SQL SERVER 2000 2 Ok Ok 02 Ok Fail ABC Fail Fail abc Fail Fail Log: Jul 31 10:15:41 jpotkanski-lx slapd[30011]: Constructed query: SELECT DISTINCT ldap_entries.id,persons.id,'inetOrgPerson' AS objectClass... Jul 31 10:15:41 jpotkanski-lx slapd[30011]: id: '1' Jul 31 10:15:41 jpotkanski-lx slapd[30011]: >>> dnPrettyNormal: <cn=Torvlobnor Puzdoy,dc=example,dc=com> Jul 31 10:15:41 jpotkanski-lx slapd[30011]: <<< dnPrettyNormal: <cn=Torvlobnor Puzdoy,dc=example,dc=com>, <cn=torvlobnor puzdoy,dc=examp ... Jul 31 10:15:41 jpotkanski-lx slapd[30011]: backsql_oc_get_candidates(): added entry id=3, keyval=2 dn="cn=Torvlobnor Puzdoy,dc=example, ... Jul 31 10:15:41 jpotkanski-lx slapd[30011]: <==backsql_oc_get_candidates(): 1 Jul 31 10:15:41 jpotkanski-lx slapd[30011]: backsql_search(): loading data for entry id=0, oc_id=0, keyval=0 Jul 31 10:15:41 jpotkanski-lx slapd[30011]: backsql_search(): loading data for entry id=5, oc_id=2, keyval=1 On a failed one, backsql_oc_get_candidates(): 0 openldap 2.3.39, 4.fc8 , unixodbc 2.2.12, freetds .84, mysql-odbc latest. Before opening anything in ITS, I wondered if this is a bug, feature request or maybe solved in 2.4? Jason Potkanski Information Technology Developer CCIM Institute 430 N. Michigan Ave, Suite 800 Chicago, IL 60611-4092 jpotkanski(a)ccim.com www.ccim.com tel: 312.321.8559

3 5

slapd does not start, where do I find the error?
by Jorge Medina 01 Aug '08

01 Aug '08

I got the sources (2.2.8), compiled and installed OpenLDAP in RedHat Enterprise Linux 5 ( 64-bit.) (I also got the sources and compiled BerkeleyDB 4.6) Now, I am trying to start the server. I don't get any error message in the console. In Ubuntu, the errors would show up in /var/log/syslog Where could I find what is wrong when I invoke slapd? Where do the errors get logged ?

4 5

Determine current access level
by Simon Victor 01 Aug '08

01 Aug '08

Hi all, I'm stuck on a specific issue with acls: I wan't to get the "current access level" for an entry (not at attribute level). My problem is, that i want to check if the acls allows me to delete or modify an entry before i really do it. Is there a way go read out the acls? Is this possible with aci's? The inheritance of aci could be tricky... Best regards, Simon

2 1

Re: Meta Idassert-bind
by Andrew Graham 01 Aug '08

01 Aug '08

Thankyou, I shall raise a bug report for you. Drew Andrew Graham ICT AgustaWestland UK Tel No: +44 (0) 1935 70 4421 andrew.graham(a)agustawestland.com >>> Pierangelo Masarati <ando(a)sys-net.it> 31/07/2008 19:42:07 >>> ----- "Andrew Graham" <andrew.graham(a)agustawestland.com> wrote: > *** Before acting on this email or opening any attachment you are > advised to read the disclaimer at the end of this email *** > > I've re-read my original message and it didn't make alot of sense. So > here's take two! > > I'm using back-meta to attempt to amalgamate several ldap servers > into > one single tree. This should cater for users that exist only in a > local > BDB database, and also for users with accounts in one of the target > ldap > servers. If I say 'local' or 'remote' user at any point, I'm > referring > to users stored in the local bdb database or a remote ldap server > respectively. I shall refer to the local openldap server as the proxy > server. > > The meta database is subordinate to the local database. This allows > me > to have a base record for the entire directory. > > Everything works perfectly for targets that don't require a bind > before > searching. For targets that do require a successful bind, I've been > trying to use the 'idassert-bind' feature with mixed results. The > following is a description of the behaviour I am trying to achieve: > > If a local user binds to the proxy server, and performs a query with > one or more targets in scope, then the proxy server should use > predefined credentials to bind to and search only the targets in > scope > on behalf of the local user. > > If a remote user binds to the proxy server, and performs a query > affecting only the target where that user is stored, then the proxy > server should bind to that target using the credentials supplied by > the > remote user. If there are any other targets in the scope of the > query, > openldap should not attempt to use the predefined credentials to bind > to > and search on that target. > > To try to achieve this, I have placed all local users in their own > branch of the tree, and set the 'idassert-authzFrom' for each target > to > match this branch only, thus preventing remote users from using the > idassert feauture and barring them from querying other targets than > their own. > > Here is the first of two 'interesting' results. If I bind to the > proxy > server as a remote user with multiple targets in scope, the bind is > proxied to the remote user's target correctly. The proxy then > proceeds > to attempt to bind to the other targets in scope using seemingly > random > names. Some examples (captured with wireshark) are '\270+1\b', > '\250\202/\b\005', '\220\241\322\267\220\241\322\267\020' and > 'x\267.\b'. The name changes every time, but each time no password is > provided. The proxy will not attempt to search any of the targets > after > binding, even the target to which the user belongs. > > I'm not sure I understand the purpose of the 'non-prescriptive' flag, > but if I set it on each target (as Pierangelo suggested previously), > the > unusual behaviour changes. When binding with a remote user, the proxy > will correctly bind to the target to which the remote user belongs > using > the remote users credentials. If another target is in scope, the > proxy > will attempt to bind to it without name or password. The proxy will > proceed to search the targets. This is fine for my situation, but I > would like to understand why this happens? > > The second problem I'm having is with the local users. If the > 'network-timeout' statement is used in the meta database definition, > whenever a local user binds to the proxy and queries one or more of > the > target servers, the proxy will attempt to bind to the targets with > the > predefined name but with no password. If network-timeout is not > specified, the proxy binds with both the predefined name and password > to > every target in scope. Is this behaviour intended or a bug? I think your explanation is clear enough, provided some of the behaviours you describe are quite unexpected. There seems to be quite a few bugs in this feature. Unfortunately, I won't be able to work at it in the next few days, you'll need to wait at least until the end of next week. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it ----------------------------------- *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

1 0

Re: Meta Idassert-bind
by Andrew Graham 31 Jul '08

31 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I've re-read my original message and it didn't make alot of sense. So here's take two! I'm using back-meta to attempt to amalgamate several ldap servers into one single tree. This should cater for users that exist only in a local BDB database, and also for users with accounts in one of the target ldap servers. If I say 'local' or 'remote' user at any point, I'm referring to users stored in the local bdb database or a remote ldap server respectively. I shall refer to the local openldap server as the proxy server. The meta database is subordinate to the local database. This allows me to have a base record for the entire directory. Everything works perfectly for targets that don't require a bind before searching. For targets that do require a successful bind, I've been trying to use the 'idassert-bind' feature with mixed results. The following is a description of the behaviour I am trying to achieve: If a local user binds to the proxy server, and performs a query with one or more targets in scope, then the proxy server should use predefined credentials to bind to and search only the targets in scope on behalf of the local user. If a remote user binds to the proxy server, and performs a query affecting only the target where that user is stored, then the proxy server should bind to that target using the credentials supplied by the remote user. If there are any other targets in the scope of the query, openldap should not attempt to use the predefined credentials to bind to and search on that target. To try to achieve this, I have placed all local users in their own branch of the tree, and set the 'idassert-authzFrom' for each target to match this branch only, thus preventing remote users from using the idassert feauture and barring them from querying other targets than their own. Here is the first of two 'interesting' results. If I bind to the proxy server as a remote user with multiple targets in scope, the bind is proxied to the remote user's target correctly. The proxy then proceeds to attempt to bind to the other targets in scope using seemingly random names. Some examples (captured with wireshark) are '\270+1\b', '\250\202/\b\005', '\220\241\322\267\220\241\322\267\020' and 'x\267.\b'. The name changes every time, but each time no password is provided. The proxy will not attempt to search any of the targets after binding, even the target to which the user belongs. I'm not sure I understand the purpose of the 'non-prescriptive' flag, but if I set it on each target (as Pierangelo suggested previously), the unusual behaviour changes. When binding with a remote user, the proxy will correctly bind to the target to which the remote user belongs using the remote users credentials. If another target is in scope, the proxy will attempt to bind to it without name or password. The proxy will proceed to search the targets. This is fine for my situation, but I would like to understand why this happens? The second problem I'm having is with the local users. If the 'network-timeout' statement is used in the meta database definition, whenever a local user binds to the proxy and queries one or more of the target servers, the proxy will attempt to bind to the targets with the predefined name but with no password. If network-timeout is not specified, the proxy binds with both the predefined name and password to every target in scope. Is this behaviour intended or a bug? My current configuration is... require authc access to * by * write # # Meta # database meta suffix "dc=meta,dc=example,dc=com" subordinate rootdn "cn=manager,dc=example,dc=com" network-timeout 10 #Target 1 uri "ldap://ldap.acme.org/dc=target1,dc=meta,dc=example,dc=com" idassert-bind bindmethod=simple binddn="cn=searchuser,dc=acme,dc=org" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.regex:dc=users,dc=example,dc=com" rewriteEngine on suffixmassage "dc=target1,dc=meta,dc=example,dc=com" "dc=acme,dc=org" #Target 2 uri "ldap://ldap.another.com/dc=target2,dc=meta,dc=example,dc=com" idassert-bind bindmethod=simple binddn="cn=searchuser,dc=another,dc=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.regex:dc=users,dc=example,dc=com" rewriteEngine on suffixmassage "dc=target2,dc=meta,dc=example,dc=com" "dc=another,dc=com" # #Local # database bdb suffix "dc=example,dc=com" directory /usr/local/var/openldap-data/base/ rootdn "cn=manager,dc=example,dc=com" rootpw "secret" index objectclass eq index cn,sn eq,sub The ldif file I use to populate the local database... dn: dc=example,dc=com dc: example description: Container for metadirectory objectClass: dcObject objectClass: organization o: example dn: cn=Search user,dc=users,dc=example,dc=com cn: search user sn:search user objectclass: top objectclass: person objectclass: organizationalPerson userpassword: secret Thanks for your help! Drew Andrew Graham ICT AgustaWestland UK Tel No: +44 (0) 1935 70 4421 andrew.graham(a)agustawestland.com *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

2 1

slapd_db_hotbackup
by Alvin Chang 31 Jul '08

31 Jul '08

Hello everyone: If anyone used slapd_db_hotbackup in the past, please kindly point me at man pages or examples. It will be much appreciated. I did try google, but only RPM packages came up and if I add -rpm to the search, then only two irrelevant results came.. Thanks in advance, -- Alvin Chang Linux Systems Administrator OpenX Limited Skype: alvin.chang_at_openx.org IRC: #openx on freenode.net

3 2

BDB 4.3 instability
by Craig Worgan 31 Jul '08

31 Jul '08

Hi, Does anyone know the specifics of the instability of BDB 4.3 (see http://www.openldap.org/faq/data/cache/44.html)? I run OpenLDAP on a RedHat platform that ships with BDB 4.3 and I need to convince other applications on the system that an upgrade is important. At this point they are asking for more specific details than 'OpenLDAP doesn't recommend BDB 4.3'. Thanks, Craig Worgan

4 12

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software