Solaris Kerberos Client Configuration

From Docupedia

Note: This page was recently imported from an old text source. It will be cleaned up and wikified as time permits. -- bklang

LDAP and Kerberos on Solaris 10 A Configuration Guide


Contents

[edit]

For Clients

Prerequisites

[edit]

DNS

Check for proper DNS resolver configuration. The nameservers should be configured and the DNS search domain should have the Kerberos realm (in our case domain.example) as the first entry. Make sure that /etc/hosts has the hostname defined. It must be in the same format as below, with the fully qualified domain name listed before the short version: 

127.0.0.1 localhost.localdomain localhost
10.0.0.1 hostname.example.com hostname
[edit]

System Domain Name

Check that the system domainname is set to the lower case version of your realm. Add this to the file /etc/defaultdomain and check by running /bin/domainname. If the domain name is not set then set it with 

# /bin/domainname example.com
# echo "example.com" > /etc/defaultdomain
# echo "domain example.com" >> /etc/resolv.conf
[edit]

System Time

Ensure the system time is correct. Verify an NTP daemon is installed, or install one. Ensure it is configured properly and the time is synchronized externally.


[edit]

Kerberos Configuration

[edit]

Check Packages are Installed

Check that the following two packages are installed, or install them: SUNWkrbr, SUNWkrbu (Kerberos version 5 support)

[edit]

Updated krb5.conf

Delete the existing /etc/krb5/krb5.conf. Install the text below into that file instead: 

[libdefaults]
        dns_lookup_realm = on
        dns_lookup_kdc = on
[realms]
        EXAMPLE.COM = {
                admin_server = kadmin.example.com
        }
[appdefaults]
	renewable = true
	forwardable = true

Note that to make future primary KDC failover easier, the kadmin.domain.example entry in DNS should be a CNAME to the primary KDC.

  1. Symlink /etc/krb5/krb5.conf to /etc/krb5.conf (for legacy compatibility)
  1. Create and install a host keytab

ssh to any one of the KDCs and run kadmin Remember that you will be prompted for your "admin" instance's password instead of your normal login password: 

$ kadmin

Authenticating as principal username/admin@EXAMPLE.COM with password. Password for username/admin@EXAMPLE.COM:

At the "kadmin: prompt you will be creating a host principal for the hostname being added to the realm. The format is "host/hostname.example.com". The -randkey option is used to create a secure key without specifying a password. 

kadmin:  addprinc -randkey host/hostname.example.com
WARNING: no policy specified for host/hostname.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/hostname.example.com@EXAMPLE.COM" created.

Next create a keytab for use on the new host. We will extract the key into "hostname.keytab": 

kadmin:  ktadd -k hostname.keytab host/hostname.domain.example
Entry for principal host/hostname.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:hostname.keytab.
Entry for principal host/hostname.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:hostname.keytab.
Entry for principal host/hostname.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:hostname.keytab.
Entry for principal host/hostname.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:hostname.keytab.

Exit kadmin with CTRL-D or "exit"

Copy the newly created keytab to the host being configured.

      • NOTE: This keytab is the equivalent of a stored password. As it contains
      • sensitive information it should be copied securely using scp.
      • Remember to remove the file from the KDC after the file is copied.

Once the keytab is copied to the host being added to the realm, move the keytab to /etc/krb5/krb5.keytab and set the permissions to root:sys 0600

[edit]

Converting to Network Services

      • NOTE: Before continuing into the next step, open a "root" shell on the host being
      • added to the realm. Up to this point none of the configuration will have
      • a negative impact on users attempting to log in or use the system. However
      • in the next step the login process is modified. To guard against error, keep this
      • root shell open until the next note like this appears in this document.
  1. Install an updated PAM configuration file

The file is too long to paste here. An example file will be included with these directions. Alternatively copy the /etc/pam.conf from any already kerberized host (including any of the KDCs).


  1. Test logins

Login as "root" on the system console to ensure it still works.

      • NOTE: If the login of "root" on the system console is successful, it is
      • now safe to close your lifeboat root shell. All modifications which are
      • potentially destructive to the login mechanism are now complete.
  1. Remove duplicate user entries

Using a combination of "getent" and vi, check to ensure that any object that is defined in LDAP does NOT have an entry in each of the three local db files: /etc/passwd, /etc/shadow, /etc/group. The only exception to this is users listed in supplemental groups may remain even if they are defined in LDAP. It is only necessary to remove the object defined in LDAP from the local system file db.

Retrieved from "http://docs.alkaloid.net/index.php/Solaris_Kerberos_Client_Configuration"