Skip Navigation Links | |
Exit Print View | |
System Administration Guide: Security Services Oracle Solaris 10 8/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. Controlling Access to Devices (Tasks)
5. Using the Basic Audit Reporting Tool (Tasks)
6. Controlling Access to Files (Tasks)
7. Using the Automated Security Enhancement Tool (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Role-Based Access Control (Reference)
Part IV Cryptographic Services
13. Oracle Solaris Cryptographic Framework (Overview)
14. Oracle Solaris Cryptographic Framework (Tasks)
15. Oracle Solaris Key Management Framework
Part V Authentication Services and Secure Communication
16. Using Authentication Services (Tasks)
19. Using Oracle Solaris Secure Shell (Tasks)
20. Oracle Solaris Secure Shell (Reference)
21. Introduction to the Kerberos Service
22. Planning for the Kerberos Service
23. Configuring the Kerberos Service (Tasks)
Configuring the Kerberos Service (Task Map)
Configuring Additional Kerberos Services (Task Map)
How to Manually Configure a Master KDC
How to Configure a KDC to Use an LDAP Data Server
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
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 Manually Configure a Kerberos Client
How to Disable Verification of the Ticket Granting Ticket (TGT)
How to Access a Kerberos Protected NFS File System as the root User
How to Configure Automatic Migration of Users in a Kerberos Realm
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
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
24. Kerberos Error Messages and Troubleshooting
25. Administering Kerberos Principals and Policies (Tasks)
26. Using Kerberos Applications (Tasks)
27. The Kerberos Service (Reference)
Part VII Oracle Solaris Auditing
28. Oracle Solaris Auditing (Overview)
29. Planning for Oracle Solaris Auditing
30. Managing Oracle Solaris Auditing (Tasks)
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.
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.
|
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.
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
Before You Begin
This procedure uses an installation profile. See How to Create a Kerberos Client Installation Profile.
You need to provide the password for the clntconfig principal to complete the process.
client# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile 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#
Example 23-7 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#
This procedure uses the kclient installation utility without a installation profile.
You need to provide the following information:
Kerberos realm name
KDC master host name
Administrative principal name
Password for the administrative principal
Example 23-8 Running the kclient Installation Utility
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 ! #
In this procedure, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com
NFS server = denver.example.com
Client = client.example.com
admin principal = kws/admin
User principal = mre
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Note - Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in the Online Help URL in the Graphical Kerberos Administration Tool.
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://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
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.
Starting with the Solaris 10 5/08release, 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.
Starting with the Solaris 10 5/08release, 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.
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.
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:
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:
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 /etc/resolv.conf file.
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:
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:
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:
kadmin: quit
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
If the /etc/resolv.conf file has not already been created, then create this file as the service principal canonicalization is dependent upon DNS to do this. See the resolv.conf(4) man page for more information.
After the /etc/resolv.conf file has been created or modified you must then restart the gssd daemon to reread any changes.
# svcadm restart network/rpc/gss
See the warn.conf(4) man page for more information.
Example 23-9 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 23-10 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 23-11 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
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. 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:
The client IP address is dynamically assigned. For instance, a DHCP client.
The client is not configured to host any services, so no host principal was created.
The host key is not stored on the client.
If the verify_ap_req_nofail option is set to false, the TGT verification process is not enabled. See the krb5.conf(4) man page for more information about this option.
client # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false ...
Note - The verify_ap_req_nofail option can be entered in either the [libdefaults] or the [realms] section of the krb5.conf file. If the option is in the [libdefaults]section, the setting is used for all realms. If the option is in the [realms]section, the setting only applies to the defined realm.
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.
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:
This principal is used to provide root equivalent access to NFS mounted file systems that require Kerberos authentication. 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 /etc/resolv.conf file.
kadmin: addprinc -randkey root/client.example.com Principal "root/client.example.com" created. kadmin:
This step is required if you added a root principal 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.
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:
kadmin: quit
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 /etc/pam.conf.
In this example, the dtlogin and other PAM service names are configured to use the automatic migration. The following configuration parameters are used:
Realm name = EXAMPLE.COM
Master KDC = kdc1.example.com
Machine hosting the migration service = server1.example.com
Migration service principal = host/server1.example.com
Before You Begin
Setup server1 as a Kerberos client of the realm EXAMPLE.COM. See Configuring Kerberos Clients for more information.
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
# cat /etc/pam.conf . . # # dtlogin service (explicit because of pam_krb5_migrate) # dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_cred.so.1 dtlogin auth sufficient pam_krb5.so.1 dtlogin auth requisite pam_unix_auth.so.1 dtlogin auth optional pam_krb5_migrate.so.1
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 which use the pam_krb5_migrate module. See the pam_krb5_migrate(5) man page for more information.
# cat /etc/pam.conf . . dtlogin auth optional pam_krb5_migrate.so.1 expire_pw
This addition allows for password expiration in Kerberos to block access.
# cat /etc/pam.conf . . # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account required pam_krb5.so.1 other account required pam_unix_account.so.1
This addition allows for passwords to be updated when the password expire.
# cat /etc/pam.conf . . # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1
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 *
This step allows the kadmind daemon to use the new kadm5.acl entries.
kdc1 # svcadm restart network/security/kadmin
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