Principal attributes and policy in LDAP Realm

[Klaus Heinrich Kiwi]

On Mon, 2008-06-16 at 23:38 -0400, Ken Raeburn wrote:
> I suspect there are several LDAP schemas we could do a better job of  
> supporting and integrating with...

And what, in your opinion, would be the better approach to accomplish
this task?

The IBM Schema has a lot of commonality with the Novell Schema (the IBM
Schema itself seems to be a mash-up between Netscape/IBM Tivoli Schema
and the Microsoft Schema), but there are fundamental differences as
well:
 * No Kerberos container concept, although I'm planning on using this
configuration parameter to specify the DN of the object immediately
above the Realms
 * Password Policy can object can be embedded within the Realm or the
Principal objects themselves, in addition of being a separate object
referenced by an attribute within the Realm or Principal
 * A lot of attributes (that I must admit I don't completely understand)
like krbTrustedAdmObject, krbDisableTimeInterval, krbMultKeyVersionsOK,
krbAdmAclDB, krbEncTypeSupport, krbKeyType, passwordDictFiles etc.
 * Principals have a krbSecretKeyCfg attribute that defines how
authentication should be done, including a method that relies on the
password stored by a 'userPassword' attribute of the entry representing
the principal (I wonder if the KDB Abstraction Layer can support such
operation)

What I am doing right now is using the existing KDB LDAP plugin as a
base for a new plugin (I wonder if I should worry about namespace
collisions later), but of course ideally we should stick with a single
code base and have the differences handled by runtime configuration. I'm
just not sure if that is feasible or not.

 -Klaus
-- 
Klaus Heinrich Kiwi <klausk at linux.vnet.ibm.com>
Linux Security Development, IBM Linux Technology Center