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 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 (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)
NFS services use UNIX user IDs (UIDs) to identify a user and cannot directly use GSS credentials. To translate the credential to a UID, a credential table that maps user credentials to UNIX UIDs might need to be created. See Mapping GSS Credentials to UNIX Credentials for more information on the default credential mapping. The procedures in this section focus on the tasks that are necessary to configure a Kerberos NFS server, to administer the credential table, and to initiate Kerberos security modes for NFS-mounted file systems. The following task map describes the tasks that are covered in this section.
Table 21-2 Configuring Kerberos NFS Servers (Task Map)
|
In this procedure, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
NFS server = denver.example.com
admin principal = kws/admin
The master KDC must be configured. To fully test the process, you need several clients.
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 by the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
Follow the instructions in Configuring Kerberos Clients.
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:
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.
Repeat this step for each unique interface on the system that might be used to access NFS data. If a host has multiple interfaces with unique names, each unique name must have its own NFS service principal.
kadmin: addprinc -randkey nfs/denver.example.com Principal "nfs/denver.example.com" created. kadmin:
Repeat this step for each unique service principal created in Step a.
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:
kadmin: quit
Normally, the Kerberos service generates appropriate maps between the GSS credentials and the UNIX UIDs. The default mapping is described in Mapping GSS Credentials to UNIX Credentials. If the default mapping is not sufficient, see How to Create a Credential Table for more information.
See How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes for more information.
The gsscred credential table is used by an NFS server to map Kerberos credentials to a UID. By default, the primary part of the principal name is matched to a UNIX login name. For NFS clients to mount file systems from an NFS server with Kerberos authentication, this table must be created if the default mapping is not sufficient.
Change the mechanism to files.
# gsscred -m kerberos_v5 -a
The gsscred command gathers information from all sources that are listed with the passwd entry in the svc:/system/name-service/switch:default service. You might need to temporarily remove the files entry, if you do not want the local password entries included in the credential table. See the gsscred(1M) man page for more information.
Before You Begin
This procedure requires that the gsscred table has already been created on the NFS server. See How to Create a Credential Table for instructions.
# gsscred -m mech [ -n name [ -u uid ]] -a
Defines the security mechanism to be used.
Defines the principal name for the user, as defined in the KDC.
Defines the UID for the user, as defined in the password database.
Adds the UID to principal name mapping.
Example 21-3 Adding a Multiple Component Principal to the Credential Table
In the following example, an entry is added for a principal named sandy/admin, which is mapped to UID 3736.
# gsscred -m kerberos_v5 -n sandy/admin -u 3736 -a
Example 21-4 Adding a Principal in a Different Domain to the Credential Table
In the following example, an entry is added for a principal named sandy/admin@EXAMPLE.COM, which is mapped to UID 3736.
# gsscred -m kerberos_v5 -n sandy/admin@EXAMPLE.COM -u 3736 -a
This procedure provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID.
# cat /etc/krb5/krb5.conf [libdefaults] default_realm = CORP.EXAMPLE.COM . [realms] CORP.EXAMPLE.COM = { . auth_to_local_realm = SALES.EXAMPLE.COM . }
Example 21-5 Mapping Credentials Between Realms Using the Same Password File
This example provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID. On the client system, add entries to the krb5.conf file.
# cat /etc/krb5/krb5.conf [libdefaults] default_realm = CORP.EXAMPLE.COM . [realms] CORP.EXAMPLE.COM = { . auth_to_local_realm = SALES.EXAMPLE.COM . }
Troubleshooting
See Observing Mapping From GSS Credentials to UNIX Credentials to help with the process of troubleshooting credential mapping problems.
This procedure enables a NFS server to provide secure NFS access using different security modes or flavors. When a client negotiates a security flavor with the NFS server, the first flavor that is offered by the server that the client has access to is used. This flavor is used for all subsequent client requests of the file system shared by the NFS server.
The klist command reports if there is a keytab file and displays the principals. If the results show that no keytab file exists or that no NFS service principal exists, you need to verify the completion of all the steps in How to Configure Kerberos NFS Servers.
# klist -k Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal ---- --------------------------------------------------------- 3 nfs/denver.example.com@EXAMPLE.COM 3 nfs/denver.example.com@EXAMPLE.COM 3 nfs/denver.example.com@EXAMPLE.COM 3 nfs/denver.example.com@EXAMPLE.COM
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
share -F nfs -o sec=mode file-system
Specifies the security modes to be used when sharing the file system. When using multiple security modes, the first mode in the list is used as the default.
Defines the path to the file system to be shared.
All clients that attempt to access files from the named file system require Kerberos authentication. To access files, the user principal on the NFS client should be authenticated.
You need not follow this procedure if you are not using the automounter to access the file system or if the default selection for the security mode is acceptable.
file-system auto_home -nosuid,sec=mode
Alternatively, you could use the mount command to specify the security mode, but this alternative does not take advantage of the automounter.
# mount -F nfs -o sec=mode file-system
Example 21-6 Sharing a File System With One Kerberos Security Mode
In this example, Kerberos authentication must succeed before any files can be accessed through the NFS service.
# share -F nfs -o sec=krb5 /export/home
Example 21-7 Sharing a File System With Multiple Kerberos Security Modes
In this example, all three Kerberos security modes have been selected. Which mode is used is negotiated between the client and the NFS server. If the first mode in the command fails, then the next is tried. See the nfssec(5) man page for more information.
# share -F nfs -o sec=krb5:krb5i:krb5p /export/home