[29977] in Kerberos
Re: Principal attributes and policy in LDAP Realm
daemon@ATHENA.MIT.EDU (Klaus Heinrich Kiwi)
Tue Jun 17 07:58:37 2008
From: Klaus Heinrich Kiwi <klausk@linux.vnet.ibm.com>
To: Ken Raeburn <raeburn@mit.edu>
In-Reply-To: <5312EC7E-A3E1-4291-AEA5-6A066157380E@MIT.EDU>
Date: Tue, 17 Jun 2008 08:57:01 -0300
Message-Id: <1213703822.17827.61.camel@klausk.br.ibm.com>
Mime-Version: 1.0
Cc: Kerberos mailing list list <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@linux.vnet.ibm.com>
Linux Security Development, IBM Linux Technology Center
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
