Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Security Services Oracle Solaris 11 Information Library |
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)
Part V Authentication Services and Secure Communication
14. Network Services Authentication (Tasks)
17. Using Secure Shell (Tasks)
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)
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 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 (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
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
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)
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).
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.
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.
# 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.
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.
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.
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.
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 = . }
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.