Evaluation of Kerberos LDAP Schema against the information model
----------------------------------------------------------------

1) Principal
1.1) Principal: Attributes
1.1.1) principalName
Principal names are unique in a realm and the attribute in which the names are stored is "krbPrincpalName"

1.1.2) principalNotUsedBefore
Not present.

1.1.3) principalNotUsedAfter
The attribute "krbPrincipalExpiration" stores the date value after which the principal is not valid.

1.1.4) principalIsDisabled
This can be done by setting "DISALLOW_ALL_TIX" in "krbTicketFlags" attribute.

1.1.5) principalAliases
There is no attribute to store principal aliases.

1.2) Principal: Associations
A Principal can be associated with 
     i) one or more key sets
     ii) one or more policies (both ticket and password policies)

2) KeySet
Each key set is associated with one or more Keys.
In this schema, KeySet is not an object. It is a multi-valued attribute and is part of principal objects. 
Each value in this multi-valued attribute stores a set of keys for a particular version.
The reasons why KeySet is modeled to be an attribute rather than an object are,
     i) Creation and management of one or more objects (for each keyset)
     ii) Management of ACLs for these KeySet objects

3) Key
Keys are encrypted with the master key and stored.
3.1) Key: Attributes

3.1.1) keyEncryptionType
Stored

3.1.2) keyValue
Stored

3.1.3) keySaltValue
Stored

3.1.4) keyStringToKeyParameter
Not stored.

3.1.5) keyNotUsedAfter
Not stored. But it can be computed from "krbMaxPwdLife" and "Last Password Change Time"

3.1.6) keyNotUsedBefore
Not stored.

3.1.7)  keyIsDisabled
Not stored.

Note:
-----
The actual attributes that are stored in the key attribute are,
	Principal Name
	Key Version
	Master Key Version
	Last Password Change (Date)
	Number of Keys
	Key Type
	Salt Type
	Key Value
	Salt Value

3.2)  Key: Associations
None

4) Password Management Policy
There may be two configurations for Kerberos passwords.
     i) Kerberos password and the LDAP user password are the same. In this case, LDAP password policy can be used.
     ii) Kerberos password is different from LDAP user password. Here, Kerberos password policy can be used.

This schema defines only the password policy that is to be used when the Kerberos passwords are different from the LDAP passwords.
 
4.1) Password Management Policy: Attributes
4.1.1) Maximum Password Life
Maximum lifetime for the Kerberos passwords

4.1.2) Minimum Password Life
Minimum lifetime for the Kerberos passwords

4.1.3) Minimum Number of Character Classes
Minimum number of different character classes that a password must contain.

4.1.4) Minimum Password Length
Minimum length of the password

4.1.5) Password History Length
Number of old passwords kept


5)  Keying Policy
This is configurable at the realm level. Whenever principals are created, they can have keys of types that are present in the keying policy. If the keys are to be reset to different types, the administrator can do so by using "cpw" of kadmin.
When the users change their password using "kpasswd", the new keys will be of the same types as those of the old keys.

5.1)  Keying Policy: Attributes
5.1.1) Supported Encryption Types
All the encryption types that are supported by a realm.

5.1.2) Supported Salt Types
All the salt types that are supported by a realm.

5.1.3) Default Encryption Type
The default encryption type that is to be used for setting the principal keys.

5.1.4) Default Salt Type
The default salt type that is to be used for setting the principal keys.

6) Ticket Policy
6.1) Ticket Policy: Attributes
6.1.1) Maximum Ticket Life
The maximum lifetime of a ticket granted for a principal.

6.1.2) Maximum Renewable Lifetime
The maximum renewable lifetime of a ticket granted for a principal.

6.1.3) Ticket Flags
The flags that are allowed for a principal in it's ticket.