openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#5094) shutting down multiple ppolicy instances yields double-free
by mbackes＠symas.com 16 Aug '07

16 Aug '07

Full_Name: Matthew Backes Version: 2.3.x, head OS: all URL: Submission from: (NULL) (132.241.73.19) slapo-ppolicy's close method frees the static pwcons without checking to see if someone else is using or has freed it already. This issue appears at shutdown when trying to use slapo-ppolicy on multiple backends. Revisions 1.105 and 1.106 to ppolicy.c (in HEAD) fix this problem.

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no 16 Aug '07

16 Aug '07

ando(a)sys-net.it writes: > The "right" solution would be to protect the identity of the rootdn > with ACLs, so that regular users cannot add/modify it. Good idea, but that too depends on your policy. If you you have a cron job or whatever which updates entries, including that of the rootdn, you may not want it to have full rootdn access. If nothing else, it's a bit like logging in as root instead of as a regular user - if you screw up you have the opportunity to create much more havoc. I wonder if we need a rootpolicy config parameter to tune the details of all this. Then we can set a fairly paranoid default, and people who need it to work differently can override. (Another thing I remember someone asked about was to only accept rootdn login from some specific IP address. But now that I think of it, normal ACLs could ensure that if he had the password in an entry instead of in rootpw.) -- Hallvard

1 0

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com 16 Aug '07

16 Aug '07

randolf.werner(a)sap.com wrote: > Over the years i have > seen quite some Active Directories customers and many of them are very > afraid when you ask them you change some configuration or extending the > schema. Doesn't it seem odd to you that people would voluntarily use software that they are afraid of? Never mind, this discussion has gone far enough off-topic. -- -- Howard Chu Chief Architect, 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#5092) page size value of 1.2.840.113556.1.4.319 control
by randolf.werner＠sap.com 16 Aug '07

16 Aug '07

Hi, oh my god what have i started here. Please don't try to convince me that standards are important and slapd pricecly implents RFC 2696, i was already convinced of that before i started the discussion. Anyway i like to resond to Howard Chu because he mentioned something dangerous and wrong regarding Active Directory (somewhat of topic here) but i like to avaoid people following his suggestion: Howard Chu <hyc(a)symas.com> wrote: >> Here is why i believe others might run into the same issue. If you need >> to create a ldap client dealing with big search results for various LDAP >> directories you had to use 1.2.840.113556.1.4.319 even if you are only >> interested in collecting the entire result otherwise you would fail with >> Active Directory. > >Nonsense. You simply ask your AD administrator to raise the default sizelimit, >the same way you would ask an OpenLDAP administrator to do the same thing. Well about 6 years ago when i first noticed this problem, i asked Microsoft about that limit and yes you can use ntdsutil.exe to set MaxPageSize to a higher limit: http://support.microsoft.com/kb/315071/en-us But it is strongly recommend to not change it!!!! Over the years i have seen quite some Active Directories customers and many of them are very afraid when you ask them you change some configuration or extending the schema. In 2001 SAP's IT set MaxPageSize=10000 for a few weeks as a temporary workaround until i was able to provide a real solution. That was a long time ago and today SAP's and probably most other companies Active Directories are running with default values. 1.2.840.113556.1.4.319 and MaxPageSize had not been invented to make our life more difficult. A good article about it is e.g. http://searchwinit.techtarget.com/tip/0,289483,sid1_gci1265206,00.html. I like to close with Gary Olsen's conclusion "The best practice for setting MaxPageSize is to leave it alone." Best regards Randolf

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no 16 Aug '07

16 Aug '07

hyc(a)symas.com writes: >> The back-bdb behavior sounds right: It should remain possible to have >> the rootdn's password in an entry instead of in slapd.conf. Among other >> things, if the site has routines for regular password changes and "your >> password is getting old" warnings, those will then cover rootdn as well. > > (But aging out the administrator's password is a good way to lock > yourself out of your system. Sure, so it depends on just how central that password is. But if I've ignored a "your password is getting too old" warning for an admin user and it gets disabled I've screwed up anyway, I prefer to set things up to err on the side of caution. Though if it's even hard to log in to the server machine and fix things there, I'd be in trouble. > Note that ppolicy always lets the rootdn > past all policy checks for this reason.) Actually I've never used ppolicy, so I was thinking of our site's automatic emails when we need to change our passwords. >> OTOH if such an entry and rootpw both exist, I think it's a bug to >> accept both passwords. I think an existing rootpw should override the >> entry's password, that's safest and least surprising (if the admin sets >> rootpw and someone else manages to create an entry with dn: <rootdn>). > > I disagree; this behavior has existed for a long time and there are probably > people out there relying on it. Good point. I would still like to get rid of it though. Even if it takes an extra slapd.conf keyword. > This isn't much different from the fact that > userPassword itself is multivalued. I seem to recall this behavior being > documented somewhere, can't find the reference at the moment. I disagree - the difference is that rootpw vs. userPassword are stored in different places and different people can modify or create them. The rootpw doc in slapd.conf(5) looks misleading to me - at least it's easy to read it differently from how it works. I'm getting a deja vu feeling here, but I'm not sure from which discussion... >> A few icky issues: >> >> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside >> the database's DIT, it would be possible to create such an entry with >> a password. We could advise people to use a DN outside the database >> suffix in this case, and/or accept 'rootpw' with no parameter as >> explicitly refusing Simple Bind with the rootdn. > > I don't think these cases merit any special consideration. OK. Well, I might do something more general to the doc which touches on it anyway if I think of a better way to write it. >> - back-null's "bind on" (accept Simple Bind with any password). >> Maybe in this case it's best to treat rootdn without rootpw as >> "reject simple bind as rootdn", like your patch does. > > If "bind on" means "accept Simple Bind with any password" then rootpw > should be irrelevant here. Of course, for back-null the rootdn itself is > pretty meaningless. I looked cross-eyed at that code. I meant bind off. Nevermind. -- Hallvard

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it 16 Aug '07

16 Aug '07

>> The back-bdb behavior sounds right: It should remain possible to have >> the rootdn's password in an entry instead of in slapd.conf. Among other >> things, if the site has routines for regular password changes and "your >> password is getting old" warnings, those will then cover rootdn as well. > > (But aging out the administrator's password is a good way to lock yourself > out > of your system. Note that ppolicy always lets the rootdn past all policy > checks > for this reason.) > >> OTOH if such an entry and rootpw both exist, I think it's a bug to >> accept both passwords. I think an existing rootpw should override the >> entry's password, that's safest and least surprising (if the admin sets >> rootpw and someone else manages to create an entry with dn: <rootdn>). > > I disagree; this behavior has existed for a long time and there are > probably > people out there relying on it. This isn't much different from the fact > that > userPassword itself is multivalued. I seem to recall this behavior being > documented somewhere, can't find the reference at the moment. In any case, I see this as a bug rather than a feature. The rootdn should be a special identity, which in many cases is only used for internal purposes. If the rootdn is outside the scope of the database, then it's not going to impact that database's be_bind(); if it's inside and it doesn't have a rootpw, then it might make sense that an entry with that DN exists, so that setting the rootpw could represent a means to workaround forgetting the entry's password or database corruptions. But checking both really sounds a bit too cumbersome. The we should allow multiple rootpw values... It's another question whether we should preserve or not this behavior for backward compatibility; in that case, all we need to do is handle the non-success, non-continue case in the switch and let it pass thru. But I'd require this at least to be explicitly enabled. >> A few icky issues: >> >> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside >> the database's DIT, it would be possible to create such an entry with >> a password. We could advise people to use a DN outside the database >> suffix in this case, and/or accept 'rootpw' with no parameter as >> explicitly refusing Simple Bind with the rootdn. > > I don't think these cases merit any special consideration. I disagree. They sound academic, but they could pose a threat. I don't mean the code should obnoxiously check for this, but the possibility should be documented. The "right" solution would be to protect the identity of the rootdn with ACLs, so that regular users cannot add/modify it. >> - back-null's "bind on" (accept Simple Bind with any password). >> Maybe in this case it's best to treat rootdn without rootpw as >> "reject simple bind as rootdn", like your patch does. > > If "bind on" means "accept Simple Bind with any password" then rootpw > should be > irrelevant here. Of course, for back-null the rootdn itself is pretty > meaningless. Yes. The idea is to provide a simple means to allow binding with some identity without the need to configure anything special - that's the role of back-null, basically. What I essentially did was to take all backends that implement BI_op_bind and add the possibility to exploit the rootdn, which is allowed by the configuration anyway. I think this is better than letting people define rootdn/rootpw in the configuration and not using it. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by quanah＠zimbra.com 16 Aug '07

16 Aug '07

--On Thursday, August 16, 2007 12:37 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > A few icky issues: > > - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside > the database's DIT, it would be possible to create such an entry with > a password. We could advise people to use a DN outside the database > suffix in this case, and/or accept 'rootpw' with no parameter as > explicitly refusing Simple Bind with the rootdn. Or in the case of SASL/GSSAPI, there can be a straight SASL rewrite to an internal DN for the rootdn as well. There is no requirement for the rootdn to have to have a rootpw associated with it, and there needn't be. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by hyc＠symas.com 16 Aug '07

16 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> Fixed in HEAD. Now all backends honor rootdn bind (with slight >> variations; see back-null) through a common interface; in some cases, >> it's a blind fix (shell, perl, passwd). I think I also fixed an >> inconsistency in back-bdb: as far as I understand, a bind with rootdn >> and incorrect rootdn password, or in case rootpw was null, originally >> passed through, probably either by mistake or to check if an analogous >> identity were defined in the database. I consider this an >> inconsistency, but please review. > > The back-bdb behavior sounds right: It should remain possible to have > the rootdn's password in an entry instead of in slapd.conf. Among other > things, if the site has routines for regular password changes and "your > password is getting old" warnings, those will then cover rootdn as well. (But aging out the administrator's password is a good way to lock yourself out of your system. Note that ppolicy always lets the rootdn past all policy checks for this reason.) > OTOH if such an entry and rootpw both exist, I think it's a bug to > accept both passwords. I think an existing rootpw should override the > entry's password, that's safest and least surprising (if the admin sets > rootpw and someone else manages to create an entry with dn: <rootdn>). I disagree; this behavior has existed for a long time and there are probably people out there relying on it. This isn't much different from the fact that userPassword itself is multivalued. I seem to recall this behavior being documented somewhere, can't find the reference at the moment. > A few icky issues: > > - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside > the database's DIT, it would be possible to create such an entry with > a password. We could advise people to use a DN outside the database > suffix in this case, and/or accept 'rootpw' with no parameter as > explicitly refusing Simple Bind with the rootdn. I don't think these cases merit any special consideration. > - back-null's "bind on" (accept Simple Bind with any password). > Maybe in this case it's best to treat rootdn without rootpw as > "reject simple bind as rootdn", like your patch does. If "bind on" means "accept Simple Bind with any password" then rootpw should be irrelevant here. Of course, for back-null the rootdn itself is pretty meaningless. -- -- Howard Chu Chief Architect, 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#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com 16 Aug '07

16 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > That said, pretending that Microsoft does not exist isn't always a > winning strategy, so it might make sense to implement a "relaxed" mode > which accepts common ways to break the standard. But I don't think it > should be turned on by default. We don't pretend Microsoft doesn't exist. But we *do* expect them to mean what they say; since 3 Microsoft employees worked on RFC2696 you would sort of expect them to get it right. -- -- Howard Chu Chief Architect, 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#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com 16 Aug '07

16 Aug '07

randolf.werner(a)sap.com wrote: > Hi, > =20 > thanks for your replies. Anyway i did not opened this message to discuss > who implented RFC 2696 correctly and who not. The point is something > else: The point is that there is a specific definition of the protocol. When vendors implement the protocol incorrectly, interoperability suffers. The fix for those interoperability problems is to take steps to ensure that vendors don't deviate from the published specifications. Likewise, application developers must pay attention to the published specs and write compliant code. Otherwise the entire concept of published standards is meaningless. > Here is why i believe others might run into the same issue. If you need > to create a ldap client dealing with big search results for various LDAP > directories you had to use 1.2.840.113556.1.4.319 even if you are only > interested in collecting the entire result otherwise you would fail with > Active Directory. Nonsense. You simply ask your AD administrator to raise the default sizelimit, the same way you would ask an OpenLDAP administrator to do the same thing. > I am not interested in discussing who is right and who is wrong, i am > just interested in making as much as possible working together in the > real world with as little as possible customer pain. In the real world, if you ignore the specs, your programs break. If you adhere to the specs, your programs keep working. What you're asking for is the equivalent of this: "My Microsoft building has a nail sticking out on the floor and I keep tripping over it when I walk by. Your OpenLDAP building is missing this nail; please pull a nail out so I can trip over it the same way." -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs