JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Administration: Security Services     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Verifying File Integrity by Using BART (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Using Pluggable Authentication Modules

15.  Using Secure Shell

16.  Secure Shell (Reference)

17.  Using Simple Authentication and Security Layer

18.  Network Services Authentication (Tasks)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

Configuring the Kerberos Service (Task Map)

Configuring Additional Kerberos Services (Task Map)

Configuring KDC Servers

How to Automatically Configure a Master KDC

How to Interactively Configure a Master KDC

How to Manually Configure a Master KDC

How to Configure a KDC to Use an LDAP Data Server

How to Automatically Configure a Slave KDC

How to Interactively Configure a Slave KDC

How to Manually Configure a Slave KDC

How to Refresh the Ticket-Granting Service Keys on a Master Server

Configuring Cross-Realm Authentication

How to Establish Hierarchical Cross-Realm Authentication

How to Establish Direct Cross-Realm Authentication

Configuring Kerberos Network Application Servers

How to Configure a Kerberos Network Application Server

How to Use the Generic Security Service With Kerberos When Running FTP

Configuring Kerberos NFS Servers

How to Configure Kerberos NFS Servers

How to Create a Credential Table

How to Add a Single Entry to the Credential Table

How to Provide Credential Mapping Between Realms

How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

Configuring Kerberos Clients

Configuring Kerberos Clients (Task Map)

How to Create a Kerberos Client Installation Profile

How to Automatically Configure a Kerberos Client

How to Interactively Configure a Kerberos Client

How to Configure a Kerberos Client for an Active Directory Server

How to Manually Configure a Kerberos Client

How to Disable Verification of the Ticket-Granting Ticket

How to Access a Kerberos Protected NFS File System as the root User

How to Configure Automatic Migration of Users in a Kerberos Realm

How to Configure Account Lockout

How to Automatically Renew All Ticket-Granting Tickets (TGTs)

Synchronizing Clocks Between KDCs and Kerberos Clients

Swapping a Master KDC and a Slave KDC

How to Configure a Swappable Slave KDC

How to Swap a Master KDC and a Slave KDC

Administering the Kerberos Database

Backing Up and Propagating the Kerberos Database

The kpropd.acl File

The kprop_script Command

How to Back Up the Kerberos Database

How to Restore the Kerberos Database

How to Convert a Kerberos Database After a Server Upgrade

How to Reconfigure a Master KDC to Use Incremental Propagation

How to Reconfigure a Slave KDC to Use Incremental Propagation

How to Configure a Slave KDC to Use Full Propagation

How to Verify That the KDC Servers Are Synchronized

How to Manually Propagate the Kerberos Database to the Slave KDCs

Setting Up Parallel Propagation

Configuration Steps for Setting Up Parallel Propagation

Administering the Stash File

How to Remove a Stash File

How to Employ a New Master Key

Managing a KDC on an LDAP Directory Server

How to Mix Kerberos Principal Attributes in a Non-Kerberos Object Class Type

How to Destroy a Realm on an LDAP Directory Server

Increasing Security on Kerberos Servers

How to Restrict Access to KDC Servers

How to Use a Dictionary File to Increase Password Security

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)

Glossary

Index

Configuring Kerberos Clients

Kerberos clients include any host, that is not a KDC server, on the network that needs to use Kerberos services. This section provides procedures for installing a Kerberos client, as well as specific information about using root authentication to mount NFS file systems.

Configuring Kerberos Clients (Task Map)

The following task map includes all of the procedures associated with setting up Kerberos clients. Each row includes a task identifier, a description of why you would want to do that task, followed by a link to the task.

Task
Description
For Instructions
Establish a Kerberos client installation profile.
Generates a client installation profile that can be used to automatically install a Kerberos client.
Configure a Kerberos client.
Manually installs a Kerberos client. Use this procedure if each client installation requires unique installation parameters.
Automatically installs a Kerberos client. Use this procedure if the installation parameters for each client are the same.
Interactively installs a Kerberos client. Use this procedure if only a few of the installation parameters need to change.
Automatically installs a Kerberos client of an Active Directory server.
Allow a client to access a NFS file system as the root user
Creates a root principal on the client, so that the client can mount a NFS file system shared with root access. Also, allows for the client to set up non-interactive root access to the NFS file system, so that cron jobs can run.
Disable verification of the KDC that issued a client Ticket Granting Ticket (TGT).
Allows clients that do not have a host principal stored in the local keytab file to skip the security check that verifies that the KDC that issued the TGT is the same server that issued the host principal.

How to Create a Kerberos Client Installation Profile

This procedure creates a kclient profile that can be used when you install a Kerberos client. By using the kclient profile, you reduce the likelihood of typing errors. Also, using the profile reduces user intervention as compared to the interactive process.

  1. Become superuser.
  2. Create a kclient installation profile.

    A sample kclient profile could look similar to the following:

    client# cat /net/denver.example.com/export/install/profile
    REALM EXAMPLE.COM
    KDC kdc1.example.com
    ADMIN clntconfig
    FILEPATH /net/denver.example.com/export/install/krb5.conf
    NFS 1
    DNSLOOKUP none

How to Automatically Configure a Kerberos Client

Before You Begin

This procedure uses an installation profile. See How to Create a Kerberos Client Installation Profile.

To complete this task, you must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

Example 21-8 Automatically Configuring a Kerberos Client With Command-Line Overrides

The following example overrides the DNSARG and the KDC parameters that are set in the installation profile.

# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile\
-d dns_fallback -k kdc2.example.com

Starting client setup
---------------------------------------------------

kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>

nfs/client.example.com entry ADDED to KDC database.
nfs/client.example.com entry ADDED to keytab.

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE.

client#

How to Interactively Configure a Kerberos Client

This procedure uses the kclient installation utility without a installation profile. In the Oracle Solaris 11 release, the kclient utility improved ease of use and the ability to work with Active Directory servers. See How to Configure a Kerberos Client for an Active Directory Server for more information. See Example 21-10 for an example of running kclient on a previous release.

Before You Begin

To complete this task, you must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

Example 21-9 Running the kclient Installation Utility

client# /usr/sbin/kclient

Starting client setup
---------------------------------------------------

Is this a client of a non-Solaris KDC ? [y/n]: n
        No action performed.
Do you want to use DNS for kerberos lookups ? [y/n]: n
        No action performed.
Enter the Kerberos realm: EXAMPLE.COM
Specify the KDC hostname for the above realm: kdc1.example.com

Note, this system and the KDC's time must be within 5 minutes of each other for
Kerberos to function. Both systems should run some form of time synchronization
system like Network Time Protocol (NTP).
Do you have any slave KDC(s) ? [y/n]: y
Enter a comma-separated list of slave KDC host names: kdc2.example.com

Will this client need service keys ? [y/n]: n
        No action performed.
Is this client a member of a cluster that uses a logical host name ? [y/n]: n
        No action performed.
Do you have multiple domains/hosts to map to realm ? [y/n]: y
Enter a comma-separated list of domain/hosts to map to the default realm: engineering.example.com, \
        example.com

Setting up /etc/krb5/krb5.conf.

Do you plan on doing Kerberized nfs ? [y/n]: y
Do you want to update /etc/pam.conf ? [y/n]: y
Enter a comma-separated list of PAM service names in the following format:
service:{first|only|optional}: xscreensaver:first
Configuring /etc/pam.conf.

Do you want to copy over the master krb5.conf file ? [y/n]: n
        No action performed.

---------------------------------------------------
Setup COMPLETE.

Example 21-10 Running the kclient Installation Utility in the Oracle Solaris 10 Release

The following output shows the results of running the kclient command.

client# /usr/sbin/kclient

Starting client setup
---------------------------------------------------

Do you want to use DNS for kerberos lookups ? [y/n]: n
        No action performed.
Enter the Kerberos realm: EXAMPLE.COM
Specify the KDC hostname for the above realm: kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Enter the krb5 administrative principal to be used: clntconfig/admin
Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>
Do you plan on doing Kerberized nfs ? [y/n]: n

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Do you want to copy over the master krb5.conf file ? [y/n]: y
Enter the pathname of the file to be copied: \
/net/denver.example.com/export/install/krb5.conf

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE !
#

How to Configure a Kerberos Client for an Active Directory Server

This procedure uses the kclient installation utility without a installation profile.

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

  1. (Optional) Enable DNS resource record creation for the client.
    client# sharectl set -p ddns_enable=true smb
  2. Run the kclient utility.

    The -T option selects a KDC server type. In this case an Active Directory server is selected.

    client# kclient -T ms_ad

    By default, you will need to provide the password for the Administrator principal.

Example 21-11 Configuring a Kerberos Client for an Active Directory Server Using kclient

The following output shows the results of running the kclient command using the ms_ad (Microsoft Active Directory) server type argument. The client will be joined to the Active Directory domain called EXAMPLE.COM.

client# /usr/sbin/kclient -T ms_ad

Starting client setup
---------------------------------------------------

Attempting to join 'CLIENT' to the 'EXAMPLE.COM' domain.
Password for Administrator@EXAMPLE.COM: <Type the password>
Forest name found: example.com
Looking for local KDCs, DCs and global catalog servers (SVR RRs).

Setting up /etc/krb5/krb5.conf

Creating the machine account in AD via LDAP.
---------------------------------------------------
Setup COMPLETE.
#

How to Manually Configure a Kerberos Client

In this procedure, the following configuration parameters are used:

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

  1. Edit the Kerberos configuration file (krb5.conf).

    To change the file from the Kerberos default version, you need to change the realm names and the server names. You also need to identify the path to the help files for gkadmin.

    kdc1 # cat /etc/krb5/krb5.conf
    [libdefaults]
            default_realm = EXAMPLE.COM
    
    [realms]
            EXAMPLE.COM = {
            kdc = kdc1.example.com
            kdc = kdc2.example.com
            admin_server = kdc1.example.com
            }
    
    [domain_realm]
            .example.com = EXAMPLE.COM
    #
    # if the domain name and realm name are equivalent, 
    # this entry is not needed
    #
    [logging]
            default = FILE:/var/krb5/kdc.log
            kdc = FILE:/var/krb5/kdc.log
    
    [appdefaults]
        gkadmin = {
            help_url = http://docs.oracle.com/cd/E23824_01/html/821-1456/aadmin-23.html

    Note - If you want to restrict the encryption types, you can set the default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.


  2. (Optional) Change the process that is used to locate the KDCs.

    By default, the Kerberos realm to KDC mapping is determined in the following order:

    • The definition in the realms section in krb5.conf

    • By looking up SRV records in DNS.

    You can change this behavior by adding dns_lookup_kdc or dns_fallback to the libdefaults section of the krb5.conf file. See the krb5.conf(4) man page for more information. Note that referrals are always tried first.

  3. (Optional) Change the process used to determine the realm for a host.

    By default the host to realm mapping is determined in the following order:

    • If the KDC supports referrals, then the KDC may inform the client which realm the host belongs to.

    • By the definition of domain_realm in the krb5.conf file.

    • The DNS domainname of the host.

    • The default realm.

    You can change this behavior by adding dns_lookup_kdc or dns_fallback to the libdefaults section of the krb5.conffile. See the krb5.conf(4) man page for more information. Note that referrals will always be tried first.

  4. (Optional) Synchronize the client's clock with the master KDC's clock by using NTP or another clock synchronization mechanism.

    Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be synchronized with the time on the KDC server within a maximum difference defined in the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  5. Start kadmin.

    You can use the Graphical Kerberos Administration Tool to add a principal, as explained in How to Create a New Kerberos Principal. To do so, you must log in with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.

    denver # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. (Optional) Create a user principal if a user principal does not already exist.

      You need to create a user principal only if the user associated with this host does not already have a principal assigned to him or her.

      kadmin: addprinc mre
      Enter password for principal mre@EXAMPLE.COM: <Type the password>
      Re-enter password for principal mre@EXAMPLE.COM: <Type it again>
      kadmin: 
    2. (Optional) Create a root principal and add the principal to the server's keytab file.

      This step is required so that the client can have root access to file systems mounted using the NFS service. This step is also required if non-interactive root access is needed, such as running cron jobs as root.

      If the client does not require root access to a remote file system which is mounted using the NFS service, then you can skip this step. The root principal should be a two component principal with the second component the host name of the Kerberos client system to avoid the creation of a realm wide root principal. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the name service.

      kadmin: addprinc -randkey root/client.example.com
      Principal "root/client.example.com" created.
      kadmin: ktadd root/client.example.com
      Entry for principal root/client.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    3. Create a host principal and add the principal to the server's keytab file.

      The host principal is used by remote access services to provide authentication. The principal allows root to acquire a credential, if there is not one already in the keytab file.

      kadmin: addprinc -randkey host/denver.example.com
      Principal "host/denver.example.com@EXAMPLE.COM" created.
      kadmin: ktadd host/denver.example.com
      Entry for principal host/denver.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin:
    4. (Optional) Add the server's NFS service principal to the server's keytab file.

      This step is only required if the client needs to access NFS file systems using Kerberos authentication.

      kadmin: ktadd nfs/denver.example.com
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    5. Quit kadmin.
      kadmin: quit
  6. (Optional) Enable Kerberos with NFS.
    1. Enable Kerberos security modes in the /etc/nfssec.conf file.

      Edit the /etc/nfssec.conf file and remove the “#” that is placed in front of the Kerberos security modes.

      # cat /etc/nfssec.conf
       .
       .
      #
      # Uncomment the following lines to use Kerberos V5 with NFS
      #
      krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
      krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
      krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS
    2. Enable DNS.

      If the svc:/network/dns/client:default service is not enabled, enable it. See the resolv.conf(4) man page for more information.

    3. Restart the gssd service.
      # svcadm restart network/rpc/gss
  7. If you want the client to automatically renew the TGT or to warn users about Kerberos ticket expiration, create an entry in the /etc/krb5/warn.conf file.

    See the warn.conf(4) man page for more information.

Example 21-12 Setting Up a Kerberos Client Using a Non-Solaris KDC

A Kerberos client can be set up to work with a non-Solaris KDC. In this case, a line must be included in the /etc/krb5/krb5.conf file in the realms section. This line changes the protocol that is used when the client is communicating with the Kerberos password-changing server. The format of this line follows.

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
                kpasswd_protocol = SET_CHANGE
        }

Example 21-13 DNS TXT Records for the Mapping of Host and Domain Name to Kerberos Realm

@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                        IN      NS      kdc1.example.com.
kdc1                    IN      A       192.146.86.20
kdc2                    IN      A       192.146.86.21

_kerberos.example.com.             IN      TXT     "EXAMPLE.COM"
_kerberos.kdc1.example.com.        IN      TXT     "EXAMPLE.COM"
_kerberos.kdc2.example.com.        IN      TXT     "EXAMPLE.COM"

Example 21-14 DNS SRV Records for Kerberos Server Locations

This example defines the records for the location of the KDCs, the admin server, and the kpasswd server, respectively.

@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                                   IN      NS      kdc1.example.com.
kdc1                               IN      A       192.146.86.20
kdc2                               IN      A       192.146.86.21

_kerberos._udp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._udp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos-adm._tcp.EXAMPLE.COM     IN      SRV 0 0 749 kdc1.example.com
_kpasswd._udp.EXAMPLE.COM          IN      SRV 0 0 749 kdc1.example.com

Example 21-15 Configuring a Solaris Client to Work with a Multiple Master KDC

The Microsoft Active Directory Kerberos service, provides a KDC that runs on multiple masters. In order for a Solaris Client to be able to update information either the admin_server or the kpasswd_server declaration in /etc/krb5/krb5.conf needs to be updated to list all of the servers. This example shows how to allow the client to update information on the KDC shared between kdc1 and kdc2.

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
                admin_server = kdc2.example.com
                }

How to Disable Verification of the Ticket-Granting Ticket

This procedure disables the security check that checks that the KDC of the host principal stored in the local /etc/krb5/krb5.keytab file is the same KDC that issued the ticket-granting ticket (TGT). This check prevents DNS spoofing attacks. However, for some client configurations, the host principal may not be available, so this check would need to be disabled to allow the client to function. These are the configurations that require that this check is disabled:

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

How to Access a Kerberos Protected NFS File System as the root User

This procedure allows a client to access a NFS file system that requires Kerberos authentication with the root ID privilege. In particular, when the NFS file system is shared with options like: -o sec=krb5,root=client1.sun.com.

How to Configure Automatic Migration of Users in a Kerberos Realm

Users, who do not have a Kerberos principal, can be automatically migrated to an existing Kerberos realm. The migration is achieved by using the PAM framework for the service in use by stacking the pam_krb5_migrate module in the service's authentication stack in the PAM configuration files.

In this example, the gdm and other PAM service names are configured to use the automatic migration. The following configuration parameters are used:

Before You Begin

Set up server1 as a Kerberos client of the realm EXAMPLE.COM. See Configuring Kerberos Clients for more information.

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

  1. Check to see if a host service principal for server1 exists.

    The host service principal in the keytab file of server1 is used to authenticate the server to the master KDC.

    server1 # klist -k
    Keytab name: FILE:/etc/krb5/krb5.keytab
        KVNO Principal
        ---- ------------------------------------------------
           3 host/server1.example.com@EXAMPLE.COM
           3 host/server1.example.com@EXAMPLE.COM
           3 host/server1.example.com@EXAMPLE.COM
           3 host/server1.example.com@EXAMPLE.COM
  2. Make changes to the PAM configuration file.
    1. Update entries for the gdm service.
      # cat /etc/pam.d/gdm
       .
       .
      
      auth definitive         pam_user_policy.so.1
      auth requisite          pam_authtok_get.so.1
      auth required           pam_dhkeys.so.1
      auth sufficient         pam_krb5.so.1
      auth requisite          pam_unix_auth.so.1
      auth required           pam_unix_cred.so.1
      auth optional           pam_krb5_migrate.so.1
    2. (Optional) Force an immediate password change, if needed.

      The newly created Kerberos accounts can have their password expiration time set to the current time (now), in order to force an immediate Kerberos password change. To set the expiration time to now, add the expire_pw option to the lines that use the pam_krb5_migrate module. See the pam_krb5_migrate(5) man page for more information.

      # cat /etc/pam.d/gdm
       .
       .
      auth optional           pam_krb5_migrate.so.1 expire_pw
    3. Add the pam_krb5 module to the account stack.

      This addition allows for password expiration in Kerberos to block access.

      # cat /etc/pam.d/other
       .
       .
      #
      # Default definition for Account management
      # Used when service name is not explicitly mentioned for account management
      #
      account requisite       pam_roles.so.1
      account definitive      pam_user_policy.so.1
      account required        pam_krb5.so.1
      account required        pam_unix_account.so.1
      account required        pam_tsol_account.so.1
      #
    4. Add the pam_krb5 module to the password stack.

      This addition allows for passwords to be updated when the password expire.

      # cat /etc/pam.d/other
       .
       .
      #
      # Default definition for Password management
      #
      password include        pam_authtok_common
      password sufficient     pam_krb5.so.1
      password required       pam_authtok_store.so.1
  3. On the master KDC, update the access control file.

    The following entries grant migrate and inquire privileges to the host/server1.example.com service principal for all users, excepting the root user. It is important that users who should not be migrated are listed in the kadm5.acl file using the U privilege. These entries need to be before the permit all or ui entry. See the kadm5.acl(4) man page for more information.

    kdc1 # cat /etc/krb5/kadm5.acl
    host/server1.example.com@EXAMPLE.COM U root
    host/server1.example.com@EXAMPLE.COM ui *
    */admin@EXAMPLE.COM *
  4. On the master KDC, restart the Kerberos administration daemon.

    This step allows the kadmind daemon to use the new kadm5.acl entries.

    kdc1 # svcadm restart network/security/kadmin
  5. On the master KDC, add entries to the pam.conf file.

    The following entries enable the kadmind daemon to use the k5migrate PAM service, to validate UNIX user password for accounts that require migration.

    # grep k5migrate /etc/pam.conf
    k5migrate        auth    required        pam_unix_auth.so.1
    k5migrate        account required        pam_unix_account.so.1

How to Configure Account Lockout

Example 21-16 Unlocking a Locked Out Principal

In the following example, a user principal is unlocked:

 /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: modify_principal -unlock principal

How to Automatically Renew All Ticket-Granting Tickets (TGTs)

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

  1. Edit the warnd configuration file.

    Add an entry like the following to renew the TGT 30 minutes before the ticket expires and log the message on the users terminal when the renewal succeeds or fails:

    # cat /etc/krb5/warn.conf
    * renew:log terminal 30m
  2. Restart the service.
    # svcadm restart network/security/ktkt_warn

Example 21-17 Configuring TGT Expiration Messages on a Server

The following example shows several ways to configure the renewal and message system for TGTs.

# cat /etc/krb5/warn.conf
#
# renew the TGT 30 minutes before expiration and send message to users terminal
#
gtb@EXAMPLE.COM renew:log terminal 30m
#
# send a warning message to a specific email address 20 minutes before TGT expiration
#
mre@EXAMPLE.COM mail 20m mre@example2.com
#
# renew the TGT 20 minutes before expiration and send an email message on failure
#
bricker@EXAMPLE.COM renew:log-failure mail 20m &
#
# catch-all: any principal not matched above will get an email warning
* mail 20m & 

Example 21-18 Configuring TGT Expiration Messages for a User

In addition to configuring an entry for each user at the system level, each user can configure an individual warnd configuration file, which is named /var/user/$USER/krb-warn.conf. For example:

% cat /var/user/gtb/krb-warn.conf
gtb@EXAMPLE.COM renew:log mail 30m &