Understanding Kerberos Integration with eDirectory
In a Kerberos system, the entities in a network are called principals and a logical grouping of principals is called a realm.
In Novell Kerberos KDC, the realms and principals of Kerberos are mapped to eDirectory as shown in the following table:
Table 2. Kerberos Mapping With eDirectory
Realm |
Can be mapped to: - a sub-tree or a container.
- an entire eDirectory tree. It can be the [Root] too.
For example, if eDirectory has a container, HR, you can create a realm, HRREALM that references to the HR container. All the users in the container HR belong to the realm, HRREALM. |
Principal |
Can be mapped to a user object or to a service object; called user principal and service principal respectively. For example, if an eDirectory tree has FTP as a service object and John as an user object, you can add - a user principal, John.
- a service principal, FTP.
Kerberos specific object class krbPrincipalAux get added to the objects. |
You can create realms in eDirectory and add principals to these realms.You can associate these realms and principals to one or more eDirectory users. For information on creating realms, adding principals and managing them, refer to Managing Novell Kerberos KDC.
You need to create the realms under the Kerberos container that can be located anywhere in the eDirectory tree. This helps you to administer the Kerberos objects easily.
Figure 2 Kerberos Integration with eDirectory
The following diagram illustrates how the Kerberos data is mapped in eDirectory:
Figure 3 eDirectory and Kerberos Mapping
This section provides information on:
Kerberos Container
Kerberos container contains only the realm objects. All the realm objects in the tree are placed in this container. This makes the Kerberos administration easier. The Kerberos container can be located anywhere in the tree but the location of the container is stored in the security container.
The Kerberos container can be
Kerberos Container Reference Attributes
The following table describes the Kerberos container attribute:
Table 3. Kerberos Container Attributes
Container name |
Name of the container object. |
Security Container Reference Attributes
Security Container contains an attribute that gives the location of the Kerberos container.
Table 4. Security Container Attributes
Container reference |
DN of the Kerberos container. |
Realm Container
The realm container stores the realm name and related realm information for Kerberos authentication and administration, password management servers to process requests. This object contains krbtgt, kadmin/admin, kadmin/changepw, kadmin/history, internal principals, and any other service principal.
Realm Container Attributes
The following table describes the realm container attributes:
Table 5. Description of the Realm Container Attributes
Realm name |
Name of the realm. This is unique within an eDirectory tree. |
Supported encryption types |
List of all the encryption types supported by the realm. |
Supported salt types |
List of all the salt types supported by the realm. |
Default encryption type |
The default encryption type supported by the realm. |
Default salt type |
The default salt type supported by the realm. |
Master key |
Realm specific master key. |
Search scope |
Scope for searching the principals under the specified subtree. |
UP enabled |
Specifies whether to use the universal password of the user as the Kerberos password or not. |
Realm Container Associations
The following table describes the objects and servers you can associate the realm container to:
Table 6. Realm Container Associations
Policy reference |
Reference to a policy object. All the principals belonging to the realm container. |
Subtree |
Reference to an entry that starts a sub-tree under which the principals of the realm are placed. |
KDC servers |
List of references to the KDC service objects that can service the realm. |
Administration servers |
List of references to the administration service objects that can service the realm. |
Password servers |
List of references to the password service objects that can service the realm. |
Principal Objects
A Principal is a fundamental entity in Kerberos. All the services, clients, and users are represented as principals in Kerberos. Principals are associated with keys.
Principal Attributes
The following table describes the principal attributes:
Table 7. Principal Attributes
Principal name |
Name of the principal. This is used to uniquely identify a principal within a realm. |
Principal expiration |
This is the time at which the principal expires. |
Principal (secret) key |
This is a set of all the secret keys that are associated with a principal. The version, type and other information about the keys are stored in this attribute. |
UP enabled |
This attribute specifies whether to use the universal password of the user as the Kerberos password or not. |
Principal Associations
The following table describes the object you can associate a principal to:
Table 8. Principal Associations
Ticket policy |
Reference to a ticket policy object that is applicable to a particular principal. |
Password policy |
Reference to a Kerberos password policy object that is applicable to a particular principal. |
Kerberos Service Objects
This represents the Kerberos services namely KDC, Administration, and Password services.
Each service of Novell Kerberos KDC (KDC server, Administration server, and Password server) uses a representative object in eDirectory. This has two purposes:
- To treat the service as a client of eDirectory and provide necessary authorization
- To store any configuration related to the service
When each service comes up, it makes an LDAP bind to eDirectory as the corresponding service object, using the stashed password or stored certificate on the local system. All subsequent operations happen based on the rights provided to that object.
Kerberos Service Attributes
The following table describes the Kerberos service attributes:
Table 9. Kerberos Service Attributes
Host server |
This attribute holds the host name, transport protocol and port for a Kerberos service. |
Kerberos Service Associations
The following table describes the object you can associate a Kerberos service to:
Table 10. Kerberos Service Associations
Realm references |
List of references to the realm objects. |
Ticket Policy Object
This is a Kerberos ticket policy object. This object can be located anywhere in the eDirectory tree.
Ticket Policy Attributes
The following table describes the policy attributes:
Table 11. Policy Attributes
Ticket flags |
Various ticket flags that can be allowed for a principal. |
Maximum ticket lifetime |
Maximum lifetime of a ticket for a principal in seconds. |
Maximum ticket renewable lifetime |
Maximum lifetime for a principal's ticket in seconds. |
Password Policy Object
This is a Kerberos password policy object. This object can be located anywhere in the eDirectory tree.
Password Policy Attributes
The following table describes the password policy attributes:
Table 12. Password Policy Attributes
Maximum password life |
Maximum lifetime of a principal's password. |
Minimum password life |
Minimum lifetime of a principal's password. |
Password mininimum characters |
Minimum number of character classes allowed in a password. |
Password minimum length |
Minimum length of the password. |
Password history length |
Number of previous versions of passwords that are stored. |
Password policy count |
Number of principals that refer to this policy. |
Administrative Considerations While Integrating Kerberos with eDirectory
Administrators are advised to consider the following points while deploying Novell Kerberos KDC, as it involves an integration between Kerberos and eDirectory paradigms:
- Multiple realms can be configured in a single tree.
- Multiple Kerberos identities can be associated with a single user identity. This follows the preferred way of managing eDirectory data, that of storing all data pertaining to the user object on itself.
- Overall, the need for more than one administrator is avoided. The benefits of having such a single point of management are ease of administration and reduced administrative costs.
- In case separate eDirectory container administrators being present, each will have an additional responsibility of administrating the Kerberos data.