Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it
>> 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
---------------------------------------
15 years, 5 months
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by quanah＠zimbra.com
--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
15 years, 5 months
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by hyc＠symas.com
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/
15 years, 5 months
Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com
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/
15 years, 5 months
Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com
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/
15 years, 5 months
Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by h.b.furuseth＠usit.uio.no
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
15 years, 5 months
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no
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
15 years, 5 months
(ITS#5093) slap_mods_opattrs() doesn't work with modrdn
by ando＠sys-net.it
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.
15 years, 5 months
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it
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.
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
---------------------------------------
15 years, 5 months
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it
ghenry(a)suretecsystems.com wrote:
> Don't you do this in test043:
>
> "# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply"
exactly. 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
---------------------------------------
15 years, 5 months
