openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by h.b.furuseth＠usit.uio.no 16 Aug '07

16 Aug '07

randolf.werner(a)sap.com writes: > Active Directory. You look at the ldap_create_page_control API spec > (developers oftern use API specs and not protocol RFCs) and notice page > size to be an usinged integer. Since you are not really interested in > pages you specify the largest possible value 2**32-1. So that API spec is bogus, it should have specified the range. Which data type is being used is not relevant to what the protocol accepts, in particular since the width of data types sometimes change. E.g. if you move from a 32-bit to a 64-bit host. > 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. Notice however that your first problem happened because AD breaks the standard, and your second problem because you rewrote it by bogus Microsoft documentation and it worked because of another way AD breaks the standard. (Though less seriously in the second case, it follows the "be liberal in what you accept" way.) If OpenLDAP is changed to accept wider limits, it might also encourage more people to write bogus code like you did. OpenLDAP has been going in the other direction over the years, doing ever more strict error checking. 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. > Therefore i am almost 100% sure Active Directory will not break > existing clients by using signed instead of unsigned integer page size > just to be more RFC 2696 compliant. In addition to fixing the doc, they they could fix that in API by reducing a passed value >= 2**31 to the max valid value. Not that they seem to care much about standards anyway. One note - I'm curious why you did not use page size 0, which the Microsoft API pages you posted say overrides such page sizes. Though maybe I misunderstood and that doesn't actually help. -- Regards, Hallvard

1 0

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

16 Aug '07

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. Also it matches better the behavior if you Bind with a DN in one database, which is the rootdn of another database. The Bind operation will work like a normal Bind since won't know that the DN is the rootdn of the second database. rootpw is a separate feature which can be convenient and which we in any case need so it is possible to bind as rootdn even with an empty database, or in backends which do not hold local entries. (Briefly: rootdn for authorization, rootpw+rootdn for authentication.) Anyway, that's why I suggested a be_rootpw_bind() rather than be_rootdn_bind() function, it reflects this better. (BTW, why a switch() statement to check its return value instead of just an if()?) 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>). 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. - 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. I don't know if there are overlays which can also make it sensible to do that, or if we need to anticipate such overlays. retcode, maybe? -- Regards, Hallvard

1 0

(ITS#5093) slap_mods_opattrs() doesn't work with modrdn
by ando＠sys-net.it 16 Aug '07

16 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando I've noticed that in HEAD modifyTimestamp and entryCSN do not change over modrdn. The reason is subtle, because slap_mods_opattrs() expects to be called with Operation's o_request data for a modify and not for modrdn, which misses the rs_no_opattrs member. I've reworked things to better preserve modification consistency in the future. p.

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