- The long term PLAN: 


The idea is to create an ldap front end for administrating the 
KDC. The data in the KDC will remain in the KDC database, however
the acl's and other data will remain in a db-based backend (or
should they be added to the KDC ?). 

- The Short term PLAN: 

Use the shell backend and a hacked up version of kadmin-local
to explore the possiblities. Try and get search working first. 


- Goals : 

1. Duplicate all the functionality of kadmind. ( Changepasswd ?) 

2. Dynamic update of acls. 

3. Acls based on ldap attributes. 

- Implementation: 

Write a schema for the elements of the KDC. 


- Here's what the database knows : 
Principals

Principal: bbense@stanford.edu
Expiration date: [never]
Last password change: Fri Aug 06 09:53:42 PDT 1999
Password expiration date: [none]
Maximum ticket life: 1 day 01:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Aug 26 11:49:49 PDT 1999 (bbense/admin@stanford.edu)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes: REQUIRES_PRE_AUTH
Policy: [none]



Policies

Policy: default
Maximum password life: 0
Minimum password life: 0
Minimum password length: 8
Minimum number of password character classes: 1
Number of old keys kept: 1
Reference count: 13

ACL's are read into a set of structs on startup. 

- How to deal with ACL's ? 

Static and Dynamic ? or treat Static as a special case of Dynamic? 

Store separately or with object ? 

Store as an ldap referral? 

Need to look up relevant RFC's? Are ldapACI's sufficient? 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The SCHEMA: 

	The root of the server is the ADMIN Server listed in krb5.conf
	for the realm in dc format.  

	dc=krb5-admin,dc=stanford,dc=edu

Since one kdc can "potentially" have multiple realms. Each realm is 
an node off the root : 

krb5Realm=stanford.edu

We need to define 3 object classes : 

krb5Principal - Subclass of ????

cn=principal/inst@realm 
krbname=
expirationDate=
lastPasswdChange=
passwordExpireDate=
maximumTicketLife=
maximumRenewableLife=

Multivalued : ticketAttribute=

( Are keys a sub-entry of the principal? What does this do to the 
add procedure ? The other choice is to tag the attribute key1*,key2* )
Need to look at the internal data structure of keys... 

krb5Policy - Subclass of ??? 

krb5ACL - Subclass of ??? 

( How about putting the krb5.conf realm entry in the directory ?) 
( Define krb5realm object )
( Do we need ou's ? How about ou=kdc and ou=acl_file ? )