Kerberosreference This chapter lists many of the files, commands, and daemons that are part of the Kerberos product. In addition, this chapter provides detailed information about how Kerberos authentication works.This is a list of the reference information in this chapter.Kerberos Files Kerberos Commands Kerberos Daemons Kerberos Terminology How the Kerberos Authentication System Works Gaining Access to a Service Using Kerberos Using Kerberos Encryption Types Using the gsscred Table Notable Differences Between Solaris Kerberos and MIT Kerberos Kerberosfiles filesKerberos File Name Description ~/.gkadmin .gkadmin filedescription~/.gkadmin filedescriptionDefault values for creating new principals in the SEAM Administration Tool ~/.k5login .k5login filedescription~/.k5login filedescriptionList of principals that grant access to a Kerberos account /etc/krb5/kadm5.acl kadm5.acl filedescription/etc/krb5/kadm5.acl filedescriptionKerberos access control list file, which includes principal names of KDC administrators and their Kerberos administration privileges /etc/krb5/kadm5.keytab kadm5.keytab filedescription/etc/krb5/kadm5.keytab filedescription /etc/krb5/kdc.conf kdc.conf filedescription/etc/krb5/kdc.conf filedescriptionKDC configuration file /etc/krb5/kpropd.acl kpropd.acl filedescription/etc/krb5/kpropd.acl filedescriptionKerberos database propagation configuration file /etc/krb5/krb5.conf krb5.conf filedescription/etc/krb5/krb5.conf filedescriptionKerberos realm configuration file /etc/krb5/krb5.keytab krb5.keytab filedescription/etc/krb5/krb5.keytab filedescriptionKeytab file for network application servers /etc/krb5/warn.conf warn.conf filedescription/etc/krb5/warn.conf filedescriptionKerberos ticket expiration warning and automatic renewal configuration file /etc/pam.conf pam.conf fileKerberos and/etc/pam.conf fileKerberos andPAM configuration file /tmp/krb5cc_uid krb5cc_uid filedescription/tmp/krb5cc_uid filedescriptionDefault credentials cache, where uid is the decimal UID of the user /tmp/ovsec_adm.xxxxxx ovsec_adm.xxxxx filedescription/tmp/ovsec_adm.xxxxx filedescriptionTemporary credentials cache for the lifetime of the password changing operation, where xxxxxx is a random string /var/krb5/.k5.REALM .k5.REALM filedescription/var/krb5/.k5.REALM filedescriptionKDC stash file, which contains a copy of the KDC master key /var/krb5/kadmin.log kadmin.log filedescription/var/krb5/kadmin.log filedescriptionLog file for kadmind /var/krb5/kdc.log kdc.log filedescription/var/krb5/kdc.log filedescriptionLog file for the KDC /var/krb5/principal principal filedescription/var/krb5/principal filedescriptionKerberos principal database /var/krb5/principal.kadm5 principal.kadm5 filedescription/var/krb5/principal.kadm5 filedescriptionKerberos administrative database, which contains policy information /var/krb5/principal.kadm5.lock principal.kadm5.lock filedescription/var/krb5/principal.kadm5.lock filedescriptionKerberos administrative database lock file /var/krb5/principal.ok principal.ok filedescription/var/krb5/principal.ok filedescriptionKerberos principal database initialization file that is created when the Kerberos database is initialized successfully /var/krb5/principal.ulog principal.ulog filedescription/var/krb5/principal.ulog filedescriptionKerberos update log, which contains updates for incremental propagation /var/krb5/slave_datatrans slave_datatrans filedescription/var/krb5/slave_datatrans filedescriptionBackup file of the KDC that the kprop_script script uses for propagation /var/krb5/slave_datatrans_slave slave_datatrans_slave filedescription/var/krb5/slave_datatrans_slave filedescriptionTemporary dump file that is created when full updates are made to the specified slave Kerberoscommands commandsKerberos This section lists some commands that are included in the Kerberos product.Command Description /usr/bin/ftp ftp commandKerberos and/usr/bin/ftp commandKerberos and File Transfer Protocol program /usr/bin/kdestroy kdestroy commandKerberos and/usr/bin/kdestroy commandKerberos andDestroys Kerberos tickets /usr/bin/kinit kinit commandKerberos and/usr/bin/kinit commandKerberos and Obtains and caches Kerberos ticket-granting tickets /usr/bin/klist klist commandKerberos and/usr/bin/klist commandKerberos and Displays current Kerberos tickets /usr/bin/kpasswd kpasswd commandKerberos and/usr/bin/kpasswd commandKerberos and Changes a Kerberos password /usr/bin/ktutil ktutil commandKerberos and/usr/bin/ktutil commandKerberos and Manages Kerberos keytab files /usr/bin/rcp rcp commandKerberos and/usr/bin/rcp commandKerberos andRemote file copy program /usr/bin/rdist rdist commandKerberos and/usr/bin/rdist commandKerberos andRemote file distribution program /usr/bin/rlogin rlogin commandKerberos and/usr/bin/rlogin commandKerberos andRemote login program /usr/bin/rsh rsh commandKerberos and/usr/bin/rsh commandKerberos andRemote shell program /usr/bin/telnet telnet commandKerberos and/usr/bin/telnet commandKerberos andKerberized telnet program /usr/lib/krb5/kprop kprop commanddescription/usr/lib/kprop commanddescriptionKerberos database propagation program /usr/sbin/gkadmin gkadmin commanddescription/usr/sbin/gkadmin commanddescriptionKerberos database administration GUI program, which is used to manage principals and policies /usr/sbin/gsscred gsscred commanddescription/usr/sbin/gsscred commanddescriptionManage gsscred table entries /usr/sbin/kadmin kadmin commanddescription/usr/sbin/kadmin commanddescriptionRemote Kerberos database administration program (run with Kerberos authentication), which is used to manage principals, policies, and keytab files /usr/sbin/kadmin.local kadmin.local commanddescription/usr/sbin/kadmin.local commanddescriptionLocal Kerberos database administration program (run without Kerberos authentication and must be run on master KDC), which is used to manage principals, policies, and keytab files /usr/sbin/kclient kclient commanddescription/usr/sbin/kclient commanddescriptionKerberos client installation script which is used with or without a installation profile /usr/sbin/kdb5_ldap_util /usr/sbin/kdb5_ldap_util commanddescriptionkdb5_ldap_util commanddescriptionCreates LDAP containers for Kerberos databases /usr/sbin/kdb5_util /usr/sbin/kdb5_util commanddescriptionkdb5_util commanddescriptionCreates Kerberos databases and stash files /usr/sbin/kgcmgr /usr/sbin/kgcmgr commanddescriptionkgcmgr commanddescriptionConfigures Kerberos master and slave KDCs /usr/sbin/kproplog /usr/sbin/kproplog commanddescriptionkproplog commanddescriptionLists a summary of update entries in the update log Kerberosdaemons daemonstable of Kerberos gssd daemonKerberos and The following table lists the daemons that the Kerberos product uses.Daemon Description /usr/sbin/in.ftpd ftpd daemonKerberos andin.ftpd daemonKerberos and/usr/sbin/in.ftpd daemonKerberos andFile Transfer Protocol daemon /usr/lib/krb5/kadmind kadmind daemonKerberos and/usr/lib/krb5/kadmind daemonKerberos andKerberos database administration daemon /usr/lib/krb5/kpropd kpropd daemonKerberos and/usr/lib/krb5/kpropd daemonKerberos andKerberos database propagation daemon /usr/lib/krb5/krb5kdc krb5kdc daemonKerberos and/usr/lib/krb5/krb5kdc daemonKerberos andKerberos ticket processing daemon /usr/lib/krb5/ktkt_warnd ktkt_warnd daemonKerberos and/usr/lib/krb5/ktkt_warnd daemonKerberos andKerberos ticket expiration warning and automatic renewal daemon /usr/sbin/in.rlogind rlogind daemonKerberos andin.rlogind daemonKerberos and/usr/sbin/in.rlogind daemonKerberos andRemote login daemon /usr/sbin/in.rshd rshd daemonKerberos andin.rshd daemonKerberos and/usr/sbin/in.rshd daemonKerberos andRemote shell daemon /usr/sbin/in.telnetd telnetd daemonKerberos andin.telnetd daemonKerberos and/usr/sbin/in.telnetd daemonKerberos andtelnet daemon terminologyKerberos Kerberosterminology The following section presents Kerberos terms and their definitions. These terms are used throughout the Kerberos documentation. To grasp Kerberos concepts, an understanding of these terms is essential.terminologyKerberos-specific Kerberosterminology You need to understand the terms in this section in order to administer KDCs.KDCmasterdefinitionKDCslavedefinitionmaster KDCdefinitionslave KDCsdefinitionThe Key Distribution Center or KDC is the component of Kerberos that is responsible for issuing credentials. These credentials are created by using information that is stored in the KDC database. Each realm needs at least two KDCs, a master and at least one slave. All KDCs generate credentials, but only the master KDC handles any changes to the KDC database.stash filedefinitionkadmind daemonmaster KDC andkrb5kdc daemonmaster KDC andA stash file contains the master key for the KDC. This key is used when a server is rebooted to automatically authenticate the KDC before starting the kadmind and krb5kdc commands. Because this file includes the master key, the file and any backups of the file should be kept secure. The file is created with read-only permissions for root. To keep the file secure, do not change the permissions. If the file is compromised, then the key could be used to access or modify the KDC database. authenticationterminology terminologyauthentication-specific You need to know the terms in this section to understand the authentication process. Programmers and system administrators should be familiar with these terms.clientsdefinition in KerberosA client is the software that runs on a user's workstation. The Kerberos software that runs on the client makes many requests during this process. So, differentiating the actions of this software from the user is important.servicedefinition in Kerberosserversdefinition in KerberosThe terms server and service are often used interchangeably. To clarify, the term server is used to define the physical system that Kerberos software is running on. The term service corresponds to a particular function that is being supported on a server (for example, ftp or nfs). Documentation often mentions servers as part of a service, but this definition clouds the meaning of the terms. Therefore, the term server refers to the physical system. The term service refers to the software.keysdefinition in Kerberosprivate keysdefinition in Kerberosservice keysdefinition in Kerberossession keysdefinition in KerberosThe Kerberos product uses two types of keys. One type of key is a password derived key. The password derived key is given to each user principal and is known only to the user and to the KDC. The other type of key used by the Kerberos product is a random key that is not associated with a password and so is not suitable for use by user principals. Random keys are typically used for service principals that have entries in a keytab and session keys generated by the KDC. Service principals can use random keys since the service can access the key in the keytab which allows it to run non-interactively. Session keys are generated by the KDC (and shared between the client and service) to provide secure transactions between a client and a service.ticketsdefinition in KerberosA ticket is an information packet that is used to securely pass the identity of a user to a server or service. A ticket is valid for only a single client and a particular service on a specific server. A ticket contains:Principal name of the service Principal name of the user IP address of the user's host Timestamp Value which defines the lifetime of the ticket Copy of the session key All of this data is encrypted in the server's service key. Note, the KDC issues the ticket embedded in a credential described below. After a ticket has been issued, it can be reused until the ticket expires.credentialdescriptionA credential is a packet of information that includes a ticket and a matching session key. The credential is encrypted with the requesting principal's key. Typically, the KDC generates a credential in response to a ticket request from a client.authenticatorin KerberosAn authenticator is information used by the server to authenticate the client user principal. An authenticator includes the principal name of the user, a timestamp, and other data. Unlike a ticket, an authenticator can be used once only, usually when access to a service is requested. An authenticator is encrypted by using the session key shared by the client and server. Typically, the client creates the authenticator and sends it with the server's or service's ticket in order to authenticate to the server or service. ticketstypes of types of tickets Tickets have properties that govern how they can be used. These properties are assigned to the ticket when it is created, although you can modify a ticket's properties later. For example, a ticket can change from being forwardable to being forwarded. You can view ticket properties with the klist command. See Viewing Kerberos Tickets.Tickets can be described by one or more of the following terms:Forwardable/forwardedforwardable ticketsdefinitionticketsforwardableA forwardable ticket can be sent from one host to another host, obviating the need for a client to reauthenticate itself. For example, if the user david obtains a forwardable ticket while on user jennifer's machine, he can log in to his own machine without having to get a new ticket (and thus authenticate himself again). See Example 26–1 for an example of a forwardable ticket. Initialinitial ticketdefinitionticketsinitialAn initial ticket is a ticket that is issued directly, not based on a ticket-granting ticket. Some services, such as applications that change passwords, can require tickets to be marked initial in order to assure themselves that the client can demonstrate a knowledge of its secret key. An initial ticket indicates that the client has recently authenticated itself, instead of relying on a ticket-granting ticket, which might have been around for a long time. Invalidinvalid ticketdefinitionticketsinvalidAn invalid ticket is a postdated ticket that has not yet become usable. An invalid ticket will be rejected by an application server until it becomes validated. To be validated, a ticket must be presented to the KDC by the client in a ticket–granting service request, with the VALIDATE flag set, after its start time has passed. Postdatable/postdatedpostdated ticketdefinitionticketspostdatableA postdated ticket is a ticket that does not become valid until some specified time after its creation. Such a ticket is useful, for example, for batch jobs that are intended to be run late at night, because the ticket, if stolen, cannot be used until the batch job is to be run. When a postdated ticket is issued, it is issued as invalid and remains that way until its start time has passed, and the client requests validation by the KDC. A postdated ticket is normally valid until the expiration time of the ticket-granting ticket. However, if the ticket is marked renewable, its lifetime is normally set to be equal to the duration of the full life of the ticket-granting ticket. Proxiable/proxyAt times, it is necessary for a principal to allow a service to perform an operation on its behalf. The principal name of the proxy must be specified when the ticket is created. The Solaris release does not support proxiable or proxy tickets.proxiable ticketdefinitionticketsproxiableproxy ticketdefinitionticketsproxyA proxiable ticket is similar to a forwardable ticket, except that it is valid only for a single service, whereas a forwardable ticket grants the service the complete use of the client's identity. A forwardable ticket can therefore be thought of as a sort of super-proxy. Renewablerenewable ticketdefinitionticketsrenewableBecause it is a security risk to have tickets with very long lives, tickets can be designated as renewable. A renewable ticket has two expiration times: the time at which the current instance of the ticket expires, and the maximum lifetime for any ticket, which is one week. If a client wants to continue to use a ticket, the client renews it before the first expiration occurs. For example, a ticket can be valid for one hour, with all tickets having a maximum lifetime of 10 hours. If the client that is holding the ticket wants to keep it for more than an hour, the client must renew it within that hour. When a ticket reaches the maximum ticket lifetime (10 hours), it automatically expires and cannot be renewed. For information on how to view the attributes of tickets, see Viewing Kerberos Tickets.ticketslifetime lifetime of ticketin Kerberos Any time a principal obtains a ticket, including a ticket–granting ticket (TGT), the ticket's lifetime is set as the smallest of the following lifetime values:kinit commandticket lifetimeThe lifetime value that is specified by the l option of kinit, if kinit is used to get the ticket. By default, kinit used the maximum lifetime value. max_life valuedescriptionkdc.conf fileticket lifetime andfileskdc.confThe maximum lifetime value (max_life) that is specified in the kdc.conf file. The maximum lifetime value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm. The maximum lifetime value that is specified in the Kerberos database for the user principal that requests the ticket. Figure 27–1 shows how a TGT's lifetime is determined and where the four lifetime values come from. Even though this figure shows how a TGT's lifetime is determined, basically the same thing happens when any principal obtains a ticket. The only differences are that kinit doesn't provide a lifetime value, and the service principal that provides the ticket provides a maximum lifetime value (instead of the krbtgt/realm principal).

Diagram shows that a ticket lifetime is the smallest value allowed by the kinit command, the user principal, the site default, and the ticket granter.

The renewable ticket lifetime is also determined from the minimum of four values, but renewable lifetime values are used instead, as follows:The renewable lifetime value that is specified by the r option of kinit, if kinit is used to obtain or renew the ticket. max_renewable_life valuedescriptionticketsmaximum renewable lifetimeThe maximum renewable lifetime value (max_renewable_life) that is specified in the kdc.conf file. The maximum lifetime renewable value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm. The maximum lifetime renewable value that is specified in the Kerberos database for the user principal that requests the ticket. Each ticket is identified by a principal name. The principal name can identify a user or a service. Here are examples of several principal names.Principal Name Description changepw/kdc1.example.com@EXAMPLE.COM A principal for the master KDC server that allows access to the KDC when you are changing passwords. clntconfig/admin@EXAMPLE.COM A principal that is used by the kclient installation utility. ftp/boston.example.com@EXAMPLE.COM A principal used by the ftp service. This principal can be used instead of a host principal. host/boston.example.com@EXAMPLE.COM A principal that is used by the Kerberized applications (klist and kprop, for example) and services (such as ftp and telnet). This principal is called a host or service principal. The principal is used to authenticate NFS mounts. K/M@EXAMPLE.COM The master key name principal. One master key name principal is associated with each master KDC. kadmin/history@EXAMPLE.COM A principal that includes a key used to keep password histories for other principals. Each master KDC has one of these principals. kadmin/kdc1.example.com@EXAMPLE.COM A principal for the master KDC server that allows access to the KDC by using kadmind. kadmin/changepw.example.com@EXAMPLE.COM A principal that is used to accept password change requests from clients that are not running a Solaris release. krbtgt/EXAMPLE.COM@EXAMPLE.COM This principal is used when you generate a ticket-granting ticket. krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM This principal is an example of a cross-realm ticket-granting ticket. nfs/boston.example.com@EXAMPLE.COM A principal that is used by the NFS service. This principal can be used instead of a host principal. root/boston.example.com@EXAMPLE.COM A principal that is associated with the root account on a client. This principal is called a root principal and provides root access to NFS mounted file systems.. username@EXAMPLE.COM A principal for a user. username/admin@EXAMPLE.COM An admin principal that can be used to administer the KDC database. authenticationoverview of Kerberos Kerberosoverview authentication system session keysKerberos authentication and keyssession keysKerberos authentication and Applications allow you to log in to a remote system if you can provide a ticket that proves your identity, and a matching session key. The session key contains information that is specific to the user and the service that is being accessed. A ticket and session key are created by the KDC for all users when they first log in. The ticket and the matching session key form a credential. While using multiple networking services, a user can gather many credentials. The user needs to have a credential for each service that runs on a particular server. For example, access to the ftp service on a server named boston requires one credential. Access to the ftp service on another server requires its own credential. ticket filecredential cachecredentialcachecachecredentialticketsfilecredential cacheThe process of creating and storing the credentials is transparent. Credentials are created by the KDC that sends the credential to the requester. When received, the credential is stored in a credential cache. serversgaining access with Kerberos Kerberosgaining access to server accessgetting to serverwith Kerberos To access a specific service on a specific server, the user must obtain two credentials. The first credential is for the ticket-granting ticket (known as the TGT). Once the ticket-granting service has decrypted this credential, the service creates a second credential for the server that the user is requesting access to. This second credential can then be used to request access to the service on the server. After the server has successfully decrypted the second credential, then the user is given access. The following sections describe this process in more detail.credentialobtaining for a TGS obtainingcredential for a TGS gettingcredential for a TGS ticket-granting serviceTGS TGSgetting credential for To start the authentication process, the client sends a request to the authentication server for a specific user principal. This request is sent without encryption. No secure information is included in the request, so it is not necessary to use encryption. When the request is received by the authentication service, the principal name of the user is looked up in the KDC database. If a principal matches the entry in the database, the authentication service obtains the private key for that principal. The authentication service then generates a session key to be used by the client and the ticket-granting service (call it Session key 1) and a ticket for the ticket-granting service (Ticket 1). This ticket is also known as the ticket-granting ticket (TGT). Both the session key and the ticket are encrypted by using the user's private key, and the information is sent back to the client. The client uses this information to decrypt Session Key 1 and Ticket 1, by using the private key for the user principal. Because the private key should only be known by the user and the KDC database, the information in the packet should be safe. The client stores the information in the credentials cache. During this process, a user is normally prompted for a password. If the password the user specifies is the same as the password that was used to build the private key stored in the KDC database, then the client can successfully decrypt the information that is sent by the authentication service. Now the client has a credential to be used with the ticket-granting service. The client is ready to request a credential for a server.

Flow diagram shows a client requesting a credential for server access from the KDC, and using a password to decrypt the returned credential.

serversobtaining credential for obtainingcredential for a server gettingcredential for a server credentialobtaining for a server To request access to a specific server, a client must first have obtained a credential for that server from the authentication service. See Obtaining a Credential for the Ticket-Granting Service. The client then sends a request to the ticket-granting service, which includes the service principal name, Ticket 1, and an authenticator that was encrypted with Session Key 1. Ticket 1 was originally encrypted by the authentication service by using the service key of the ticket-granting service. authenticatorin KerberosBecause the service key of the ticket-granting service is known to the ticket-granting service, Ticket 1 can be decrypted. The information in Ticket 1 includes Session Key 1, so the ticket-granting service can decrypt the authenticator. At this point, the user principal is authenticated with the ticket-granting service. Once the authentication is successful, the ticket-granting service generates a session key for the user principal and the server (Session Key 2), and a ticket for the server (Ticket 2). Session Key 2 and Ticket 2 are then encrypted by using Session Key 1. Because Session Key 1 is known only to the client and the ticket-granting service, this information is secure and can be safely sent over the network. When the client receives this information packet, the client decrypts the information by using Session Key 1, which it had stored in the credential cache. The client has obtained a credential to be used with the server. Now the client is ready to request access to a particular service on that server.

Flow diagram shows a client sending a request encrypted with Session Key 1 to the KDC, and then decrypting the returned credential with the same key.

accessobtaining for a specific service serviceobtaining access for specific service obtainingaccess to a specific service gettingaccess to a specific service To request access to a specific service, the client must first have obtained a credential for the ticket-granting service from the authentication server, and a server credential from the ticket-granting service. See Obtaining a Credential for the Ticket-Granting Service and Obtaining a Credential for a Server. The client can then send a request to the server including Ticket 2 and another authenticator. The authenticator is encrypted by using Session Key 2. Ticket 2 was encrypted by the ticket-granting service with the service key for the service. Because the service key is known by the service principal, the service can decrypt Ticket 2 and get Session Key 2. Session Key 2 can then be used to decrypt the authenticator. If the authenticator is successfully decrypted, the client is given access to the service.

Flow diagram shows a client using Ticket 2 and an authenticator encrypted with Session Key 2 to obtain access permission to the server.

Kerberosencryption typesusing encryption typesKerberos and Encryption types identify which cryptographic algorithms and mode to use when cryptographic operations are performed. The aes, des3-cbc-sha1 and rc4–hmac encryption types enable the creation of keys that can be used for higher strength cryptographic operations. These higher strength operations enhance the overall security of the Kerberos service.In releases prior to Solaris 10 8/07 release, the aes256-cts-hmac-sha1-96 encryption type can be used with the Kerberos service if the unbundled Strong Cryptographic packages are installed. When a client requests a ticket from the KDC, the KDC must use keys whose encryption type is compatible with both the client and the server. While the Kerberos protocol allows the client to request that the KDC use particular encryption types for the client's part of the ticket reply, the protocol does not allow the server to specify encryption types to the KDC.If you have a master KDC installed that is not running the Solaris 10 release, the slave KDCs must be upgraded to the Solaris 10 release before you upgrade the master KDC. A Solaris 10 master KDC will use the new encryption types, which an older slave will not be able to handle. The following lists some of the issues that must be considered before you change the encryption types.The KDC assumes that the first key/enctype associated with the server principal entry in the principal database is supported by the server. On the KDC, you should make sure that the keys generated for the principal are compatible with the systems on which the principal will be authenticated. By default, the kadmin command creates keys for all supported encryption types. If the systems that the principal is used on do not support this default set of encryption types, then you should restrict the encryption types when creating a principal. You can restrict the encryption types through use of the e flag in kadmin addprinc or by setting the supported_enctypes parameter in the kdc.conf file to this subset. The supported_enctypes parameter should be used when most of the systems in a Kerberos realm support a subset of the default set of encryption types. Setting supported_enctypes specifies the default set of encryption types kadmin addprinc uses when it creates a principal for a particular realm. As a general rule, it is best to control the encryption types used by Kerberos using one of these two methods. When determining the encryption types a system supports, consider both the version of Kerberos running on the system as well as the cryptographic algorithms supported by the server application for which a server principal is being created. For example, when creating an nfs/hostname service principal, you should restrict the encryption types to the types supported by the NFS server on that host. Note that in the Solaris 10 release, all supported Kerberos encryption types are also supported by the NFS server. The master_key_enctype parameter in the kdc.conf file can be used to control the encryption type of the master key that encrypts the entries in the principal database. Do not use this parameter if the KDC principal database has already been created. The master_key_enctype parameter can be used at database creation time to change the default master key encryption type from des-cbc-crc to a stronger encryption type. Make sure that all slave KDCs support the chosen encryption type and that they have an identical master_key_enctype entry in their kdc.conf when configuring the slave KDCs. Also, make sure that the master_key_enctype is set to one of the encryption types in supported_enctypes, if supported_enctypes is set in kdc.conf. If either of these issues are not handled properly, then the master KDC might not be able to work with the slave KDCs. On the client, you can control which encryption types the client requests when getting tickets from the KDC through a couple of parameters in krb5.conf. The default_tkt_enctypes parameter specifies the encryption types the client is willing to use when the client requests a ticket-granting ticket (TGT) from the KDC. The TGT is used by the client to acquire other server tickets in a more efficient manner. The effect of setting default_tkt_enctypes is to give the client some control over the encryption types used to protect the communication between the client and KDC when the client requests a server ticket using the TGT (this is called a TGS request). Note, that the encryption types specified in default_tkt_enctypes must match at least one of the principal key encryption types in the principal database stored on the KDC. Otherwise, the TGT request will fail. In most situations, it is best not to set default_tkt_enctypes because this parameter can be a source of interoperability problems. By default, the client code requests that all supported encryption types and the KDC choose the encryption types based on the keys the KDC finds in the principal database. The default_tgs_enctypes parameter restricts the encryption types the client requests in its TGS requests, which are used to acquire server tickets. This parameter also restricts the encryption types the KDC uses when creating the session key that the client and server share. For example, if a client wants to only use 3DES encryption when doing secure NFS, you should set default_tgs_enctypes = des3-cbc-sha1. Make sure that the client and server principals have a des-3-cbc-sha1 key in the principal database. As with default_tkt_enctype, it is probably best in most cases not to set this because it can cause interoperability problems if the credentials are not setup properly both on the KDC and the server. On the server, you can control the encryption types accepted by the server with the permitted_enctypes in kdc.conf. In addition, you can specify the encryption types used when creating keytab entries. Again, it is generally best not to use either of these methods to control encryption types and instead let the KDC determine the encryption types to use because the KDC does not communicate with the server application to determine which key or encryption type to use. gsscred tableusing tablesgsscred mappingUIDs to Kerberos principals IDsmapping UNIX to Kerberos principals The gsscred table is used by an NFS server when the server is trying to identify a Kerberos user, if the default mappings are not sufficient. The NFS service uses UNIX IDs to identify users. These IDs are not part of a user principal or a credential. The gsscred table provides additional mapping from GSS credentials to UNIX UIDs (from the password file). The table must be created and administered after the KDC database is populated. See Mapping GSS Credentials to UNIX Credentials for more information.When a client request comes in, the NFS service tries to map the credential name to a UNIX ID. If the mapping fails, the gsscred table is checked. The Solaris 10 version of the Kerberos service is based on MIT Kerberos version 1.2.1. The following lists the enhancements included in the Solaris 10 release that are not included in the MIT 1.2.1 version:Kerberos support of Solaris remote applications Incremental propagation for the KDC database Client configuration script Localized error messages BSM audit record support Thread safe use of Kerberos using GSS-API Use of the Encryption Framework for cryptography This version also includes some post MIT 1.2.1 bug fixes. In particular, 1.2.5 btree bug fixes and 1.3 TCP support have been added.