JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Security Services     Oracle Solaris 11 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.  Using the Basic Audit Reporting Tool (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.  Network Services Authentication (Tasks)

15.  Using PAM

16.  Using SASL

17.  Using Secure Shell (Tasks)

18.  Secure Shell (Reference)

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

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 Enable Only Kerberized Applications

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 Cross-Realm Authentication

You have several ways of linking realms together so that users in one realm can be authenticated in another realm. Cross-realm authentication is accomplished by establishing a secret key that is shared between the two realms. The relationship of the realms can be either hierarchal or directional (see Realm Hierarchy).

How to Establish Hierarchical Cross-Realm Authentication

The example in this procedure uses two realms, ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

Before You Begin

The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.

  1. Become superuser on the first master KDC.
  2. Create ticket-granting ticket service principals for the two realms.

    You must log in with one of the admin principal names that was created when you configured the master KDC.

    # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM
    Enter password for principal krgtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM: <Type password>
    kadmin: addprinc krbtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
    Enter password for principal krgtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type password>
    kadmin: quit

    Note - The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM must be the same in both realms.


  3. Add entries to the Kerberos configuration file (krb5.conf) to define domain names for every realm.
    # cat /etc/krb5/krb5.conf
    [libdefaults]
     .
     .
    [domain_realm]
            .eng.east.example.com = ENG.EAST.EXAMPLE.COM
            .east.example.com = EAST.EXAMPLE.COM

    In this example, domain names for the ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM realms are defined. It is important to include the subdomain first, because the file is searched top down.

  4. Copy the Kerberos configuration file to all clients in this realm.

    For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.

  5. Repeat all of these steps in the second realm.

How to Establish Direct Cross-Realm Authentication

The example in this procedure uses two realms, ENG.EAST.EXAMPLE.COM and SALES.WEST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

Before You Begin

The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.

  1. Become superuser on one of the master KDC servers.
  2. Create ticket-granting ticket service principals for the two realms.

    You must log in with one of the admin principal names that was created when you configured the master KDC.

    # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM
    Enter password for principal 
      krgtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM: <Type the password>
    kadmin: addprinc krbtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
    Enter password for principal 
      krgtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type the password>
    kadmin: quit

    Note - The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM must be the same in both realms.


  3. Add entries in the Kerberos configuration file to define the direct path to the remote realm.

    This example shows the clients in the ENG.EAST.EXAMPLE.COM realm. You would need to swap the realm names to get the appropriate definitions in the SALES.WEST.EXAMPLE.COM realm.

    # cat /etc/krb5/krb5.conf
    [libdefaults]
     .
     .
    [capaths]
        ENG.EAST.EXAMPLE.COM = {
            SALES.WEST.EXAMPLE.COM = .
        }
    
        SALES.WEST.EXAMPLE.COM = {
             ENG.EAST.EXAMPLE.COM = .
        }
  4. Copy the Kerberos configuration file to all clients in the current realm.

    For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.

  5. Repeat all of these steps for the second realm.