- openldap-bugs - openldap.org

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by quanah＠zimbra.com 22 Mar '10

22 Mar '10

--On Monday, March 22, 2010 12:41 PM +0000 kean.johnston(a)gmail.com wrote: >> Authorization is the job of the ACL engine. Putting ad-hoc rules into >> user entries is, in a word, stupid. It's also unscaleable and will >> become an administration nightmare. > Well OK then. Using a configuration mechanism like ACL's that cannot be > distributed to multiple users (like editing a directory can) is, in a > word, stupid. It is also unscaleable and will become an administration > nightmare. And authorisation is not (or SHOULD not be) the job of ACL's > its the job of authorisation modules, which nssov is. > > Being forced to give admins who simply want to be able to change access > to a random host in a centralised server root access to what may be a > critical server with other sensitive data on it is simply wrong. As already noted, there is no need to give root access to admins. My guess is you really do not understand how ACLs work. I would advise carefully reading the slapd-access(5) man page. Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6481) Asssert with acl-sets and referals
by masarati＠aero.polimi.it 22 Mar '10

22 Mar '10

Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6490) dds and pcache overlays not checking NULL value
by masarati＠aero.polimi.it 22 Mar '10

22 Mar '10

Fixed (slighlty differently) in HEAD. Please test. Thanks, p.

1 0

(ITS#6497) Infinite loop in translucent.c
by ondrej.kuznik＠acision.com 22 Mar '10

22 Mar '10

Full_Name: Ondrej Kuznik Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Hi, there is a bug in translucent.c:208 in translucent_cf_gen such that modification of olcTranslucentRemote or olcTranslucentLocal can trigger an infinite loop, making the server unresponsive. Please see the attached patch that fixes the issue and consider including it in your codebase: --- servers/slapd/overlays/translucent.c 2009-11-30 12:59:06.000000000 +0100 +++ servers/slapd/overlays/fixed.c 2010-03-22 16:23:39.000000000 +0100 @@ -205,7 +205,7 @@ i = c->valx; ch_free( (*an)[i].an_name.bv_val ); do { - (*an)[i] = (*an)[i+1]; + (*an)[i] = (*an)[++i]; } while ( !BER_BVISNULL( &(*an)[i].an_name )); } return 0;

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> So let them edit the host permissions. Delegate the privileges to > groups, and give them write access to their respective groups. ... > Irrelevant. Using slapd.conf doesn't preclude delegation of privileges > or dynamic updates to privilege memberships. I have read the admin guide from cover to cover, several times. I am not an LDAP expert (yet) so perhaps some things you take for granted are not obvious to the newcomer. Everything I have read just makes me confused about how the above can work. If you can point me at a relevant place in teh the man pages, or the admin guide, or an example of how this is possible, I will both be very grateful and have a deeper understanding of why this patch isn't necessary. The documentation says: Authorization is checked by performing an LDAP Compare operation looking for the PAM service name in the authorizedService attribute. slapd ACLs should be set to grant or deny Compare privilege to the appropriate users or groups as desired. As the OpenLDAP architect and someone who has been using LDAP for decades, that may seem obvious to you. It is not to others. As I understand that to mean, I would have to have something like: access to dn.exact="cn=host1,ou=hosts,dc=example,dc=com" attrs=authroizedService by dn="uid=user1,ou=people,dc=example,dc=com" compare by dn=uid=user2,ou=people,dc=example,dc=com" compare by group.exact="cn=somegroup,ou=groups,dc=example,dc=com" compare by * none which is how I would give access to a group of people as well as individuals. Now I want to grant special access to user3, who isn't part of any particular group, just a random user who needs access to the host. Now I have to change the above ACL. That ACL is in slapd.conf. How to I delegate being able to give a non-root user permissions to add user3 to that host. How do I delegate a non-root user to set permissions for host2 and host 3 etc. I realise this may be incorrect but thats how I understand the docs. I am not particularly dumb so if thats what I took away from the docs, chances are others did too, and at best, the documentation needs beefing up. > On the contrary - for security management, it's the BEST thing. Keeping > your authorization rules scattered across the data space not only makes > it harder to administer, it also makes it easier to subvert. Keeping it > all isolated in a single administrative space negates both of those > problems. Clearly you have never worked in an organisation with several tens or even hundreds of thousands of users. I don't see how putting everything in the one place helps at all. In fact it makes it a bottleneck of the worst kind. But being able to partition things and giving team A responsibility over access to this group of hosts and team B responsibility over that group of hosts and having the host access and authorization information actually be in the host entry just makes more sense, and it scales better.

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by hyc＠symas.com 22 Mar '10

22 Mar '10

Kean Johnston wrote: >> This patch was rejected. The functionality it offered was already >> provided by the slapd ACL engine. > Could I ask you to reconsider your position on using ACL's? Using ACL's for > this kind of thing is a little bit like asking the security guard that > makes your entry badge also be in charge of all of your HR data and > documents. I understand the ACL engine may be quick but it completely > defeats the purpose of having a centralised directory. No, doing anything else defeats that purpose. > What if I want > directory administrators to be able to edit host permissions but I don't > want them to have root so they can edit slapd.conf or change the SLAPD > configuration? So let them edit the host permissions. Delegate the privileges to groups, and give them write access to their respective groups. > what if I cant even use the modern configuration because > overlays I want to use don't support it and I am forced to use slapd.conf? Irrelevant. Using slapd.conf doesn't preclude delegation of privileges or dynamic updates to privilege memberships. > It also moves away from the model of having data about the host in one dn: > cn=host,dc=example,dc=com entry to now having pretty vital information > about the host moved completely out of the directory itself and into the > directory server's configuration. That surely can't be a good thing. On the contrary - for security management, it's the BEST thing. Keeping your authorization rules scattered across the data space not only makes it harder to administer, it also makes it easier to subvert. Keeping it all isolated in a single administrative space negates both of those problems. The key to scalable security is centralized control with distributed access, not distributed control. The more widely you distribute the actual points of control, the more likely you are to make a mistake and open a hole between the points. > What if I want to move from OpenLDAP to some other server? Then you probably should be using nss-pam-ldapd, and not nssov. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by hyc＠symas.com 22 Mar '10

22 Mar '10

Kean Johnston wrote: >> Authorization is the job of the ACL engine. Putting ad-hoc rules into >> user entries is, in a word, stupid. It's also unscaleable and will >> become an administration nightmare. > Well OK then. Using a configuration mechanism like ACL's that cannot be > distributed to multiple users (like editing a directory can) is, in a word, > stupid. It is also unscaleable and will become an administration nightmare. > And authorisation is not (or SHOULD not be) the job of ACL's its the job of > authorisation modules, which nssov is. > > Being forced to give admins who simply want to be able to change access to > a random host in a centralised server root access to what may be a critical > server with other sensitive data on it is simply wrong. You seem to be laboring under the false premise that root privileges are required to administer authorization in slapd. Since that is false, the rest of your statements are moot. >> The user host attribute functionality is deprecated. I have no desire to >> make it even vaguely appear to be useful. > Then don't sell it as one. You claim pam_ldap compatibility but that is > false. The user docs also aren't nearly as strongly worded, saying that the > hostserver and ACL's is preferable, not that userhost is deprecated. > A flexible solution gives administrators the opportunity to use the tool in > ways you haven't conceived of because it works for them and their > environment. A ridgid and dictatorial tool forces people to do things one > way and one way only. I have worked for one of the larger software > companies and can tell you that the ACL mechanism would scale orders of > magnitude worse, and they did, in fact have authorisation info stored in > user and host attributes because that was the only way to delegate > responsibility to multiple groups. That may have been true of that other software package. That is not true here. > PS, you may wanna consider dropping the Ulrich Drepper attitude. When a > contributor, especially a first time one, who has gone to considerable > lengths to follow all the guidelines and do things just your way has, as > his first experience someone calling things "stupid" ... well, that will > thin the development herd considerably. No, I should rather step it up a notch. I don't want contributions from J. Random Developer. I want contributions from people who participate in the community. That means reading up on how things are done, following the established practices, and demonstrating a familiarity with the way things are done and establishing a familiarity with the other community members. That means showing that you'll take the time to stick around and continue to maintain/support your code if we pull it in. If a developer won't put that time in up front, then I don't care how good their code is; I don't want to be saddled with it when they inevitably disappear. The established practice for contributing new code is to discuss it on the openldap-devel mailing list first, before spending any time on actual coding. After the developer community gets a chance to think about it and weigh in on whether it's a good idea or not, then you start (or don't start) writing the code and submitting to the ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> Authorization is the job of the ACL engine. Putting ad-hoc rules into > user entries is, in a word, stupid. It's also unscaleable and will > become an administration nightmare. Well OK then. Using a configuration mechanism like ACL's that cannot be distributed to multiple users (like editing a directory can) is, in a word, stupid. It is also unscaleable and will become an administration nightmare. And authorisation is not (or SHOULD not be) the job of ACL's its the job of authorisation modules, which nssov is. Being forced to give admins who simply want to be able to change access to a random host in a centralised server root access to what may be a critical server with other sensitive data on it is simply wrong. > The user host attribute functionality is deprecated. I have no desire to > make it even vaguely appear to be useful. Then don't sell it as one. You claim pam_ldap compatibility but that is false. The user docs also aren't nearly as strongly worded, saying that the hostserver and ACL's is preferable, not that userhost is deprecated. A flexible solution gives administrators the opportunity to use the tool in ways you haven't conceived of because it works for them and their environment. A ridgid and dictatorial tool forces people to do things one way and one way only. I have worked for one of the larger software companies and can tell you that the ACL mechanism would scale orders of magnitude worse, and they did, in fact have authorisation info stored in user and host attributes because that was the only way to delegate responsibility to multiple groups. PS, you may wanna consider dropping the Ulrich Drepper attitude. When a contributor, especially a first time one, who has gone to considerable lengths to follow all the guidelines and do things just your way has, as his first experience someone calling things "stupid" ... well, that will thin the development herd considerably.

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> This patch was rejected. The functionality it offered was already > provided by the slapd ACL engine. Could I ask you to reconsider your position on using ACL's? Using ACL's for this kind of thing is a little bit like asking the security guard that makes your entry badge also be in charge of all of your HR data and documents. I understand the ACL engine may be quick but it completely defeats the purpose of having a centralised directory. What if I want directory administrators to be able to edit host permissions but I don't want them to have root so they can edit slapd.conf or change the SLAPD configuration? what if I cant even use the modern configuration because overlays I want to use don't support it and I am forced to use slapd.conf? It also moves away from the model of having data about the host in one dn: cn=host,dc=example,dc=com entry to now having pretty vital information about the host moved completely out of the directory itself and into the directory server's configuration. That surely can't be a good thing. What if I want to move from OpenLDAP to some other server? Kean

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by hyc＠symas.com 21 Mar '10

21 Mar '10

kean.johnston(a)gmail.com wrote: > Full_Name: Kean Johnston > Version: HEAD > OS: Linux (CentOS 5.3) > URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch > Submission from: (NULL) (196.210.34.161) > > > The nssov manual page states that some of it's options "duplicates the original > pam_ldap authorization behavior". However, they don't quite. pam_ldap has the > ability for you to use "wildcards" in a user's host: attribute. I say > "wildcards" in quotes because the pam_ldap implementation does not actually use > regex matching, but rather check for two special strings, "*" and "!". > > The ability to use actual wildcards, especially ones you can negate, on a per > user basis is extremely useful to an administrator of large networks. For > example you may want all developers to have access to the machines in > developers.mydomain.com but you want to disallow access to some of those > machines to contractors or interns. > > This patch allows such behaviour, so it serves the dual purpose of actually > implementing existing pam_ldap behaviour in case people already depend on that, > as well as extends it to be a more generally usable feature by using actual > regular expressions. The code is simple, and the man page change describes it > well enough. Please consider adding this code to nssov. Thank you. > Authorization is the job of the ACL engine. Putting ad-hoc rules into user entries is, in a word, stupid. It's also unscaleable and will become an administration nightmare. The user host attribute functionality is deprecated. I have no desire to make it even vaguely appear to be useful. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by hyc＠symas.com 21 Mar '10

21 Mar '10

kean.johnston(a)gmail.com wrote: > I like what this offers administrators but I have a comment about how you > handle "wildcards". They aren't wild at all, but "magic strings" with only > one possible meaning: all users/services with the single magic character > "*". If you have a defined user naming convention like i_whatever for > interns and c_whatever for contractors, it would be useful to be able to > either include or exclude such users from using certain services. > > My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for > userhost and userservices attributes, and includes negation. Would you be > interested in working with me to expand this to support real wildcards? > Also I suggest you make this two patches, as the patch submission > guidelines clearly state that one patch for 1 feature, and the meaty parts > of this are obfuscated by increasing the buffer sizes which should probably > be in a separate patch. > > Regards, Kean This patch was rejected. The functionality it offered was already provided by the slapd ACL engine. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

I like what this offers administrators but I have a comment about how you handle "wildcards". They aren't wild at all, but "magic strings" with only one possible meaning: all users/services with the single magic character "*". If you have a defined user naming convention like i_whatever for interns and c_whatever for contractors, it would be useful to be able to either include or exclude such users from using certain services. My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for userhost and userservices attributes, and includes negation. Would you be interested in working with me to expand this to support real wildcards? Also I suggest you make this two patches, as the patch submission guidelines clearly state that one patch for 1 feature, and the meaty parts of this are obfuscated by increasing the buffer sizes which should probably be in a separate patch. Regards, Kean

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

ftp.openldap.org reports no space on the device, so the URL for the patch is at: http://64.34.163.232/openldap/kean-johnston-100321.patch

1 0

(ITS#6496) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

Full_Name: Kean Johnston Version: HEAD OS: Linux (CentOS 5.3) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch Submission from: (NULL) (196.210.34.161) The nssov manual page states that some of it's options "duplicates the original pam_ldap authorization behavior". However, they don't quite. pam_ldap has the ability for you to use "wildcards" in a user's host: attribute. I say "wildcards" in quotes because the pam_ldap implementation does not actually use regex matching, but rather check for two special strings, "*" and "!". The ability to use actual wildcards, especially ones you can negate, on a per user basis is extremely useful to an administrator of large networks. For example you may want all developers to have access to the machines in developers.mydomain.com but you want to disallow access to some of those machines to contractors or interns. This patch allows such behaviour, so it serves the dual purpose of actually implementing existing pam_ldap behaviour in case people already depend on that, as well as extends it to be a more generally usable feature by using actual regular expressions. The code is simple, and the man page change describes it well enough. Please consider adding this code to nssov. Thank you.

1 0

(ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

Full_Name: Kean Johnston Version: HEAD OS: Linux (CentOS 5.3) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch Submission from: (NULL) (196.210.34.161) The nssov manual page states that some of it's options "duplicates the original pam_ldap authorization behavior". However, they don't quite. pam_ldap has the ability for you to use "wildcards" in a user's host: attribute. I say "wildcards" in quotes because the pam_ldap implementation does not actually use regex matching, but rather check for two special strings, "*" and "!". The ability to use actual wildcards, especially ones you can negate, on a per user basis is extremely useful to an administrator of large networks. For example you may want all developers to have access to the machines in developers.mydomain.com but you want to disallow access to some of those machines to contractors or interns. This patch allows such behaviour, so it serves the dual purpose of actually implementing existing pam_ldap behaviour in case people already depend on that, as well as extends it to be a more generally usable feature by using actual regular expressions. The code is simple, and the man page change describes it well enough. Please consider adding this code to nssov. Thank you.

1 0

(ITS#6494) replication doesn't works if directory contains more than one tree
by Ikonta＠yandex.ru 19 Mar '10

19 Mar '10

Full_Name: Sergey A. Starikov Version: 2.4.21 OS: FreeBSD 7.2-RELEASE-p4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.229.208.12) Also (currently the main OS) is FreeBSD 6.4-RELEASE-p9. Configuration stored in slapd.conf. Two servers in mirror mode. The slapd.conf is: <includes> serverID pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb <ACLs set (replicator user can read everything in replicated tree)> sizelimit 1024 # ####################################################################### # BDB database definitions ####################################################################### # db #1 (caotus userbase, main database) database bdb suffix "dc=mydomain,dc=ru" rootdn "uid=admin,dc=mydomain,dc=ru" rootpw {SSHA}<some hash> overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/db/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub <and some other indexes> # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=002 provider=ldap://ldapN.mydomain.ru:389 type=refreshOnly interval=00:00:12:00 retry="64 16 256 4" searchbase="dc=mydomain,dc=ru" scope=sub sizelimit=unlimited timelimit=512 schemachecking=on bindmethod=simple binddn="uid=Replicator,ou=People,dc=mydomain,dc=ru" credentials=secret mirrormode on # db #2 (ESPP certs database accesslog) database bdb suffix "cn=accesslog" # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/log/openldap-accesslog # Indices to maintain index reqStart eq In described case accesslog overlay works normally. But overlay syncprov is _particularly_ inoperate (transferred only one of about 28 changes in source database). Both in refreshAndPersist and refreshOnly replication modes. If I remove the accesslog overlay from slapd.conf --- replication works as it should. Also, if I try to add instead the accesslog another tree, for example: slapd.conf: ... # db #2 database bdb suffix "dc=public,dc=org" directory /var/db/openldap-db2 # Indices to maintain index objectClass eq <other indexes> ... replication also doesn't works.

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 18 Mar '10

18 Mar '10

On 3/17/2010 9:25 PM, Quanah Gibson-Mount wrote: > --On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > >> tjoen wrote: >>> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >>>> After some chatter on the mailing list, the problem is now >>>> understood: >>>> - TLS error messages are indeed reported by OpenLDAP: >>>> TLS: could not use key file >>>> `/usr/local/etc/openldap/certs/ldap.key.pem'. >>> ... >>>> - The only way to see these error messages is to start the daemon >>>> with >>>> '-d stats' >>> ... >>>> My suggestions: print the TLS error messages out to syslog, or if >>>> that's not possible, print them to stdout regardless of whether the >>>> daemon is running in the foreground or not. >>> >>> Isn't it in local4.* ? >>> >> >> No, they do not get sent to local4.* - the only TLS message which makes >> it there in this scenario is: slapd[72041]: main: TLS init def ctx >> failed: -1 >> >> Like I said, the ONLY way to get the actual TLS error messages is to run >> the daemon by hand in the foreground with loglevel stats by way of >> 'slapd >> -d stats'. Per the manpage this also prevents slapd from forking: >> -d debug-level >> Turn on debugging as defined by debug-level. If this >> option is specified, even with a zero argument, slapd >> will not fork or disassociate from the invoking >> terminal. >> >> >> Let me know if I'm still not being clear. > > If you are trying to debug an issue, you most certainly should be > running slapd -d <level>... that's why it exists. > > --Quanah > That's a valid point. However, it does not explain why the TLS errors aren't (or "shouldn't be") logged via syslog.

1 0

Re: (ITS#6493) Broken link in online openldap administrator's guide
by ghenry＠OpenLDAP.org 18 Mar '10

18 Mar '10

----- "felix wolfsteller" <felix.wolfsteller(a)intevation.de> wrote: > Full_Name: Felix Wolfsteller > Version: n/a > OS: na/a > URL: http://www.openldap.org/doc/admin24/schema.html > Submission from: (NULL) (212.95.107.190) > > > In the online openldap administrator's guide, section 13.2.1 > ( http://www.openldap.org/doc/admin24/schema.html ) > , > > " http://www.alvestrand.no/harald/objectid/ " > > is referenced, where it should be > > " http://www.alvestrand.no/objectid/ " , i guess. Thanks, will fix. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6493) Broken link in online openldap administrator's guide
by felix.wolfsteller＠intevation.de 18 Mar '10

18 Mar '10

Full_Name: Felix Wolfsteller Version: n/a OS: na/a URL: http://www.openldap.org/doc/admin24/schema.html Submission from: (NULL) (212.95.107.190) In the online openldap administrator's guide, section 13.2.1 ( http://www.openldap.org/doc/admin24/schema.html ) , " http://www.alvestrand.no/harald/objectid/ " is referenced, where it should be " http://www.alvestrand.no/objectid/ " , i guess.

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by quanah＠zimbra.com 17 Mar '10

17 Mar '10

--On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > tjoen wrote: >> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >>> After some chatter on the mailing list, the problem is now understood: >>> - TLS error messages are indeed reported by OpenLDAP: >>> TLS: could not use key file >>> `/usr/local/etc/openldap/certs/ldap.key.pem'. >> ... >>> - The only way to see these error messages is to start the daemon with >>> '-d stats' >> ... >>> My suggestions: print the TLS error messages out to syslog, or if >>> that's not possible, print them to stdout regardless of whether the >>> daemon is running in the foreground or not. >> >> Isn't it in local4.* ? >> > > No, they do not get sent to local4.* - the only TLS message which makes > it there in this scenario is: slapd[72041]: main: TLS init def ctx > failed: -1 > > Like I said, the ONLY way to get the actual TLS error messages is to run > the daemon by hand in the foreground with loglevel stats by way of 'slapd > -d stats'. Per the manpage this also prevents slapd from forking: > -d debug-level > Turn on debugging as defined by debug-level. If this > option is specified, even with a zero argument, slapd > will not fork or disassociate from the invoking > terminal. > > > Let me know if I'm still not being clear. If you are trying to debug an issue, you most certainly should be running slapd -d <level>... that's why it exists. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by quanah＠zimbra.com 17 Mar '10

17 Mar '10

--On Tuesday, March 16, 2010 8:31 PM +0000 robert.hanson(a)calabrio.com wrote: > Full_Name: Robert Hanson > Version: 2.4.21 > OS: RedHat 4.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.203.208.250) > > > 1) start with an empty database; use slapadd to add a large (3 MB) > database. 2) Use ldapbrowser to delete nearly all the nodes. After this > process, I get to a point where a subnode can't be deleted; I see the > message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center > 1, ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed] > 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, > ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser > window. > > Steps to reproduce: (on redhat linux; I think any linux will do) > 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the > distro. 2) copy built slapd to an appropriate place. link it to slapadd. > 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is > scheduled to close 3/23/2010; let me know if you need the file uploaded > again). unzip the file, it contains the slapcat.out; a blank database > (in a subfolder), and a slapd.conf file. > 4) Edit the slapd.conf file as needed to point to the directory where you > put the database. > > That was the setup, now here are the steps to reproduce the problem: > > 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. > 6) start slapd (using slapd -d 1 -f slapd.conf) > 7) use ldapbrowser to delete the "lcc=call center 1" node. > > It takes a long time, but eventually you'll see it fail while trying to > delete the "agents" node. > Do you see this problem using BDB 4.7.25+patches instead of BDB 4.8? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 17 Mar '10

17 Mar '10

tjoen wrote: >On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >> After some chatter on the mailing list, the problem is now understood: >> - TLS error messages are indeed reported by OpenLDAP: >> TLS: could not use key file `/usr/local/etc/openldap/certs/ldap.key.pem'. >... >> - The only way to see these error messages is to start the daemon with >> '-d stats' >... >> My suggestions: print the TLS error messages out to syslog, or if that's >> not possible, print them to stdout regardless of whether the daemon is >> running in the foreground or not. > >Isn't it in local4.* ? > No, they do not get sent to local4.* - the only TLS message which makes it there in this scenario is: slapd[72041]: main: TLS init def ctx failed: -1 Like I said, the ONLY way to get the actual TLS error messages is to run the daemon by hand in the foreground with loglevel stats by way of 'slapd -d stats'. Per the manpage this also prevents slapd from forking: -d debug-level Turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slapd will not fork or disassociate from the invoking terminal. Let me know if I'm still not being clear.

1 0

(ITS#6492) sendmail+openldap
by exclusivedesign＠yandex.ru 17 Mar '10

17 Mar '10

Full_Name: Leo Version: openldap-sasl-client-2.4.21 OS: freebsd 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.247.195.163) Hello. I use ldap_routing feature in the sendmail (8.14.4). When I upgrade openldap from 2.4.19 to 2.4.21, ldap routing stopped working. SYSERR(root): Error getting LDAP results in map ldapmra: Partial results and referral received downgrade to old version - not helped. Help me please.

1 0

(ITS#6491) LDAP Error code 80 - Dn index delete failed
by robert.hanson＠calabrio.com 16 Mar '10

16 Mar '10

Full_Name: Robert Hanson Version: 2.4.21 OS: RedHat 4.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.203.208.250) 1) start with an empty database; use slapadd to add a large (3 MB) database. 2) Use ldapbrowser to delete nearly all the nodes. After this process, I get to a point where a subnode can't be deleted; I see the message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed] 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser window. Steps to reproduce: (on redhat linux; I think any linux will do) 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the distro. 2) copy built slapd to an appropriate place. link it to slapadd. 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is scheduled to close 3/23/2010; let me know if you need the file uploaded again). unzip the file, it contains the slapcat.out; a blank database (in a subfolder), and a slapd.conf file. 4) Edit the slapd.conf file as needed to point to the directory where you put the database. That was the setup, now here are the steps to reproduce the problem: 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. 6) start slapd (using slapd -d 1 -f slapd.conf) 7) use ldapbrowser to delete the "lcc=call center 1" node. It takes a long time, but eventually you'll see it fail while trying to delete the "agents" node.

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 14 Mar '10

14 Mar '10

> <masarati(a)aero.polimi.it> wrote: > >> > access to * attrs=cmusaslsecretOTP >> > by dn.regex="cn=replica,o=test" write stop >> > by * break >> >> This is orthogonal to the sasl auxprops discussion. It's a matter of >> well-configuring the authorizing identity in slapo-chain(5). > > I pointed it here for future reference because this is an unusual case. > I suspect everyone configure replicas with universal read-only access. > For this to work, replica must also have write access to > cmusaslsecretOTP. Well, if a shadow uses slapo-chain(5), the producer must be configured in order to allow writes coming from the shadow. >> > Another point: bind on the replica is impossible when the master is >> > down. I understand this is to prevent replaying the same OTP on >> multiple >> > replicas, but that defeats the purpose of setting up replicas for fail >> > over. >> >> This was clearly pointed out at the beginning of the discussion. You >> can't have both, it should be clear. > > Yes, I understand that. > >> Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is >> used, OTP breaks. If it is acceptable to have it broken, we can remove >> the hardcoding, and let admins decide whether they prefer fail-over over >> consistency. I'd have no doubt, and favor consistency. > > When you tell about using the shadow copy, the modification will still > be sent to the master, right? Not in the original code. In that case, the modification was bypassing replication, thus it was being applied to the shadow without generating a referral. The alternative, inconsistent solution you seem to indicate would require to replay the modification as internal in case the modification to the producer failed because the service was not available. > Such a behavior allows replays attacks > within the modification propagation time frame, but it ensures that bind > are still possible when then master is down. I think it could be > interesting to have a configuration setting for that. We should bring this to -devel, to see whether it makes sense and whether it would be acceptable. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs