Lists of LDAP requirements
William.Fiveash at sun.com
Tue Jul 18 15:23:15 EDT 2006
On Mon, Jul 17, 2006 at 05:37:07PM -0400, Sam Hartman wrote:
> HI. Hi. Two weeks ago I asked people interested in working on the
> LDAP plugin to send in the list of issues they want to see fixed for
> I have only seen MIT's list.
> I was sort of expecting something from at least Sun and Novell.
I've attached the current set of Sun requested LDAP plugin issues.
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
-------------- next part --------------
Sun Kerberos LDAP Plugin Requirements
- I Schema
- 1 krb principal attributes missing
There are attributes missing that are needed to satisfy
customer requirements. Should a krbLog structural object class
similar to the IBM Skibbie schema be used for this?
- 2 No schema versioning support
Novell has shipped the current schema so any change to current
schema will need a new version #.
- 3 krbsecretkey attribute improvements
Nico listed several issues:
- Size of kvno should be 4 bytes not 2.
- Major and minor format version numbers for krbsecretkey format.
- Other layout issues (see Message-id:
20060531193513.GM11607 at binky.Central.Sun.COM
<mailto:20060531193513.GM11607 at binky.Central.Sun.COM> in
kdc-schema at mit.edu)
- 4 krbsubtree attribute should be multivalue
Allow the admin to specify more than one subtree to search.
Note that the current ldap plugin code always searches the
krbrealmcontainer first then the specified subtree. Should the
admin have more control over the search base order?
- 5 Record extensibility
Currently the schema and the plug-in code does not allow new
- II Migrating existing db2 KDB to LDAP directory
- 1 Migrate all db2 KDB records as discreet object entries under the
krbrealmcontainer object entries
There would be a 1-1 mapping of db2 KDB record to krb
structural class object entry.
- 2 Migrate db2 KDC records with some principals associated with
existing dir. object entries
Some principals would be stored as auxillary class attributes
mixed in to non-krbprincipal structural class objects. There
needs to be a way to auto-map the principal records to existing
- III Admin interface consistency
Generally, it would be good if one could migrate a db2 KDB to an
LDAP Directory (assuming the simple migration case), modify the
krb5.conf file on the KDC to use the LDAP plugin and everything
would function as it did when the db2 KDB was in use.
- 1 kdb5_util should work more transparently
All kdb5_util commands should work like create, dump, load,
etc... Currently kdb5_util create does nothing when the KDB
backend is LDAP.
- 2 Is kdb5_ldap_util really necessary?
We would like to avoid unnecessary introduction of new
interfaces esp. those that are plugin specific.
- kdb5_ldap_util stashsrvpw command needed to create LDAP simple
bind password file
Can this be done in a better way?
- IV DIT (Directory Information Tree)
- 1 LDAP plugin should support more than 1 principal associated with a
For example, I want to associate the distinct krb principals
will at MYREALM and will/admin at MYREALM to the user object for
Will. This also goes for princs in different realms associated
with a non-krbprinc object.
- V Flexible LDAP bind specification
Should be able to provide a URI and specify the SASL mech.
Currently only ldaps:// (LDAP over SSL) is supported with a simple
bind. More SASL security mechs should be supported.
- VI Multi-Master KDC Support
While this is a side issue, support for the KDB on a directory
does allow provide some multi-master support. Are there
additional features needed to provide true multi-master support?
- 1 Need support for more than 1 admin_server.
- VII k*.conf parameters and the krbrealmcontainer object
- 1 k*.conf parameters must take precedence over krbrealmcontainer
object attributes (or any other dir. object).
- 2 There should not be any default k*.conf parameters values for
krbrealmcontainer object, only values specified by admin.
Currently the LDAP code is creating krbrealmcontainer entries
with supported_enctypes filled in. This is not good.
- 3 krbrealmcontainer parameters should also be supported by k*.conf
For example the krbsubtree attribute in the krbrealmcontainer
should have an analogous kdc.conf parameter in the realms
section. Creation of a krbrealmcontainer should be optional.
- VIII db_module_dir supports > 1 path
To make it easier for people to provide their own DB backends
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 230 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20060718/9812cd50/attachment.bin
More information about the krbdev