Lists of LDAP requirements

[Will Fiveash]

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
> 1.6.
> 
> 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.

-- 
Will Fiveash
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?
      - last_success
      - last_failed
      - failed_auth_count
   - 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
        TL_DATA types.
- 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
        object entries.
- 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
     non-krbprincipal object
        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
     files
        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
     eventually.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20060718/9812cd50/attachment.bin