openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by ghenry＠suretecsystems.com 08 Feb '07

08 Feb '07

<quote who="rklein(a)deep-field.com"> > We want to migrate from using SunLDAP to using OpenLDAP. This involves > migrating > the existing user data from SunLDAP to OpenLDAP. We were able to do this > successfully, however, we found an incompatibility in password encryption. > Specifically: > > "The passwords from SunONE are stored in SSHA format. This means that > for each password a salt has been generated. The password + salt is > encoded > using > SHA1 algorithm. That encoded string + salt is stored in the password > field. > > Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE > uses an 8 byte salt and OpenLDAP uses a 4 byte salt. > > So, when OpenLDAP looks at the password strings, it gets the wrong salt, > and will fail to decode the password." > > We're therefore requesting that OpenLDAP provide an option for an 8 byte > salt > for the SSHA encryption that is compatible with the SunONE encryption. > This will > allow us to convert to OpenLDAP without requiring all of our users to > reset > their passwords. Thanks. > Hi, Sorry, I don't mean to point out the obvious, but OpenLDAP is an Open Source project which means the source code is available for you to patch. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#4837) SunLDAP to OpenLDAP migration problem
by rklein＠deep-field.com 08 Feb '07

08 Feb '07

Full_Name: Ruth Klein Version: 2.3.24 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.247.247.122) We want to migrate from using SunLDAP to using OpenLDAP. This involves migrating the existing user data from SunLDAP to OpenLDAP. We were able to do this successfully, however, we found an incompatibility in password encryption. Specifically: "The passwords from SunONE are stored in SSHA format. This means that for each password a salt has been generated. The password + salt is encoded using SHA1 algorithm. That encoded string + salt is stored in the password field. Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE uses an 8 byte salt and OpenLDAP uses a 4 byte salt. So, when OpenLDAP looks at the password strings, it gets the wrong salt, and will fail to decode the password." We're therefore requesting that OpenLDAP provide an option for an 8 byte salt for the SSHA encryption that is compatible with the SunONE encryption. This will allow us to convert to OpenLDAP without requiring all of our users to reset their passwords. Thanks.

1 0

Re: (ITS#4834) DN matching rules should be indexed
by h.b.furuseth＠usit.uio.no 08 Feb '07

08 Feb '07

Howard Chu writes: > That's a good idea but would require more work to define indexer > functions for each matching rule before we could do anything further. I was thinking to only support it for existing indexer functions. Would 'index cn :caseExactMatch' require a new indexer function? > My reason for posting this ITS is that we already have the index > available for the DN relativeMatch rules, so we should be taking > advantage of them. Fair enough. -- Regards, Hallvard

1 0

Re: (ITS#4836) dynamic configuration support for ppolicy
by hyc＠symas.com 08 Feb '07

08 Feb '07

bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: OPENLDAP_REL_ENG_2_3 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.25.211.20) > > > Dynamic configuration would remove the need for restarting slapd in many > situations (add a schema, add an index), however sites requiring ppolicy on any > database in running in the same slapd cannot use dynamic configuration since > ppolicy in REL_ENG_2_3 does not have dynamic configuration support. > > ppolicy in HEAD does have such support, but the version from head does not > compile on REL_ENG_2_3, and various bugfixes since it was originally added > depend on features in HEAD. > It would be useful to have dynamic configuration support for ppolicy in > REL_ENG_2_3. "Would be useful" doesn't sound like a bug report to me, and RE23 really shouldn't be receiving enhancements at this stage of its cycle. I've added the necessary patches to RE23, but understand that requests of this sort are much less likely to be honored going forward. New code will be in RE24. -- -- 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

(ITS#4836) dynamic configuration support for ppolicy
by bgmilne＠staff.telkomsa.net 08 Feb '07

08 Feb '07

Full_Name: Buchan Milne Version: OPENLDAP_REL_ENG_2_3 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.211.20) Dynamic configuration would remove the need for restarting slapd in many situations (add a schema, add an index), however sites requiring ppolicy on any database in running in the same slapd cannot use dynamic configuration since ppolicy in REL_ENG_2_3 does not have dynamic configuration support. ppolicy in HEAD does have such support, but the version from head does not compile on REL_ENG_2_3, and various bugfixes since it was originally added depend on features in HEAD. It would be useful to have dynamic configuration support for ppolicy in REL_ENG_2_3.

1 0

Re: (ITS#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

kurt(a)OpenLDAP.org wrote: > On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > >> h.b.furuseth(a)usit.uio.no wrote: >>> Suggestion: Generalize a bit and support the slapd.conf statement >>> >>> index attr :matchingRule >>> >>> Can be used with the extended filter (attr:matchingRule:=foo), >>> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >>> >> That's a good idea but would require more work to define indexer >> functions >> for each matching rule before we could do anything further. My >> reason for >> posting this ITS is that we already have the index available for >> the DN >> relativeMatch rules, so we should be taking advantage of them. > > I note that dn2id is only useful for entryDN matching. For > matching of arbitrary DN attributes, additional indexing would > be needed. True. For the examples I've seen, this is good enough, and it's trivial to support it. > It may be possible/reasonable to integrate indexing > for this with component matching indexing... which, of course, > needs work. Yes, and time... -- -- 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#4834) DN matching rules should be indexed
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Suggestion: Generalize a bit and support the slapd.conf statement >> >> index attr :matchingRule >> >> Can be used with the extended filter (attr:matchingRule:=foo), >> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >> > That's a good idea but would require more work to define indexer > functions > for each matching rule before we could do anything further. My > reason for > posting this ITS is that we already have the index available for > the DN > relativeMatch rules, so we should be taking advantage of them. I note that dn2id is only useful for entryDN matching. For matching of arbitrary DN attributes, additional indexing would be needed. It may be possible/reasonable to integrate indexing for this with component matching indexing... which, of course, needs work. -- Kurt > > -- > -- 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#4556 ditStructureRules
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 7, 2007, at 11:22 PM, hyc(a)symas.com wrote: > I've often thought about adding support here, but it looks like an > all-or-nothing proposition. I.e., when you have a server that uses > ditStructureRules, you must actually define a full set of rules > otherwise you > cannot add any user entries to the directory at all. This would be > a pretty > drastic change for people accustomed to the current behavior, where > you can > put any entry you like anywhere you like. Beginners have a hard > enough time > just getting their first two entries into the directory; requiring > the use of > ditStructureRules would seem to just make a bad situation worse. It may be possible to do something similar to what was done for ditContentRules, which are also all or none in X.500 (no rules defined means no use of aux objectcleasses in X.500). In OpenLDAP, no rules means any use of auxiliary classes is okay. But if you add a rule, any rule, then these defined rules must be followed. -- Kurt > > Possibly we could make it a configurable option - enable them with a > per-database setting, defaulting to off to preserve the current > behavior. > Fully aligning with X.500 practices would have to wait for a new > generation > of server. E.g., we currently support the use of subdatabases using > subordinate/glue. These provide some of the notion of X.500 > Administrative > Areas, except their definitions reside in the cn=config tree, not as > subentries of the main DIT. Providing full subentry-based > administration > would be a major change in how the server is operated and how the > DIT is > administered. Something for OpenLDAP 3.0. > -- > -- 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#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

h.b.furuseth(a)usit.uio.no wrote: > Suggestion: Generalize a bit and support the slapd.conf statement > > index attr :matchingRule > > Can be used with the extended filter (attr:matchingRule:=foo), > or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. > That's a good idea but would require more work to define indexer functions for each matching rule before we could do anything further. My reason for posting this ITS is that we already have the index available for the DN relativeMatch rules, so we should be taking advantage of them. -- -- 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

(ITS#4835) dyngroup.schema needs clarification
by hyc＠OpenLDAP.org 07 Feb '07

07 Feb '07

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Our current schema definition defines groupOfURLs as a structural objectclass. This matches the definition used by Netscape, where this schema originates. However, the published documentation describes it as an auxiliary objectclass, and indeed the Netscape/iPlanet/Sun/FDS/RHDS servers use it as if it were an auxiliary. http://www.redhat.com/docs/manuals/dir-server/schema/6.1/oc_dir.htm#1316814 This ambiguity arises because Netscape/iPlanet/Sun/FDS/RHDS don't actually implement the LDAP/X.500 data model correctly. There are many areas where they fail to implement the model, but in this specific case they simply don't enforce schema definitions. http://forum.java.sun.com/thread.jspa?threadID=5016864&messageID=9034636 And it appears that their developers didn't consider this a problem worthy of attention. But it's creating confusion for other users. http://www.openldap.org/lists/openldap-software/200609/msg00121.html I think the right thing to do here is change our definition to AUXILIARY since that matches its actual usage. It won't match the published definitions, but those definitions are demonstrably wrong.

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