Principal attributes and policy in LDAP Realm

[Simo Sorce]

On Mon, 2008-06-16 at 19:25 -0400, Ken Raeburn wrote:
> On Jun 16, 2008, at 19:00, Klaus Heinrich Kiwi wrote:
> > Is there a better description of what's in the tl_data structure? I  
> > saw
> > some #defines in the kdb_ldap.h header file but couldn't correlate to
> > anything just by looking at their names. Also, looks like this tl_data
> > structure has a function outside the kdb abstraction layer domain  
> > (ie.:
> > it's used within the KDC itself). Could you give me any insight of how
> > it's being used and where? The description in the Schema file ("holds
> > the application specific data") is a little confusing (application  
> > here
> > refers to the Kerberos protocol? MIT KDC implementation? the LDAP KDB
> > plugin itself?)
> 
> The "application" data in question is indeed the MIT KDC  
> implementation; all this stuff is internal to the MIT implementation.   
> In src/include/kdb.h you'll find definitions of some macros KRB5_TL_*  
> vaguely describing in their names what they're used for; for the  
> actual definitions of the layouts, you'll have to dig around in the  
> sources.  At the moment, it's sort of a catch-all slot for holding  
> anything new we want to stick in there without having to redefine the  
> XDR types we use for database records (since the old DBM-style APIs  
> only give you "key" and "data" slots), stuff like that.

Ken,
this krbExtraData blob is indeed quite problematic, in ldap we can add
as much attributes as needed into the schema, and it is preferable to
have clear separated attributes that can be manipulated by manually
editing an ldif file.
Is there a specific reason why the database layer has not been
abstracted appropriately ? Any chance we can work to fix these problems
and come up with a better schema ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York