This chapter describes the steps to install and configure the Sun Cluster HA for Kerberos data service on Sun Cluster servers.
This chapter contains the following sections:
You must configure Sun Cluster HA for Kerberos as a failover data service. For conceptual information about failover data services, see Chapter 1, Planning for Sun Cluster Data Services, in Sun Cluster Data Services Planning and Administration Guide for Solaris OS and the Sun Cluster Concepts Guide for Solaris OS.
Kerberos servers have two daemons:
Authentication service
The krb5kdc daemon runs on both master and slave Key Distribution Center (KDC) servers. This service provides redundancy because an environment can have a master and one or more slaves that are running this process.
The kadmind daemon runs only on the master server and can handle requests that make updates to the principal/policy database. This single point of failure makes update requests more fragile than krb5kdc. By clustering the master KDC in the Kerberos environment you can provide update requests with greater availability.
For an introduction to Kerberos concepts, refer to Part VI, Kerberos Service, in System Administration Guide: Security Services.
Figure 1–1 lists the Kerberos components of a Sun Cluster environment.
In Figure 1–1, pam_krb5(5), kpasswd(1), kpropd(1M), and kadmin(1M) all send requests to kadmind directly. pam_krb5 and kpasswd make update requests when changing a users password. kadmin is used for general administration of the principal and policy database.
Figure 1–2 shows how databases and configuration information are shared between the cluster nodes and zones through a global or failover file system.
The configuration and keytab files are placed in /etc/krb5. The databases and logging files are kept under /var/krb5. By having these directories on a shared file system, you ensure that the database and configuration are identical. During failover, there should be little impact on client ticket requests, especially if there are slaves in the environment because slaves could be used to service client tickets during the failover period.
Clients that have already established sessions with kadmind by using the kadmin command are dropped after a failover on the cluster. Given the amount of privileges usually given for administrative principals, active kadmin sessions should not be left unattended. They should not run for an extended period of time. This means that kadmin session drops should not occur frequently because they are short lived processes.
Table 1–1 lists the tasks for installing and configuring Sun Cluster HA for Kerberos. Perform these tasks in the order in which they are listed unless otherwise indicated.
Table 1–1 Task Map: Installing and Configuring Sun Cluster HA for Kerberos
Task |
Instructions |
---|---|
(Optional) Configure Sun Cluster HA for Kerberos in Non-Global Zones | |
Install Kerberos | |
Install Sun Cluster HA for Kerberos packages | |
Register and Configure Sun Cluster HA for Kerberos | |
(Optional) Tune the Sun Cluster HA for Kerberos fault monitor | |
Verify the Sun Cluster HA for Kerberosinstallation and configuration |
Verifying Sun Cluster HA for Kerberos Installation and Configuration |
You can configure the Sun Cluster HA for Kerberos service within a non-global zone on Solaris 10 and later versions of the operating system. Given that all the realm's keys are stored in the KDC's principal database, it is helpful to compartmentalize access to system resources, such as file systems, into a non-global zone.
Sun cluster software allows you to create different zones on the same node in which to deploy the Kerberos failover resources, but to provide high availability, create the zones deploying Kerberos failover resources on different nodes.
Kerberos data service is supported on a sparse root non-global zone.
Perform this procedure only if you want to configure the Sun Cluster HA for Kerberos service within a non-global zone.
Configuring the Sun Cluster HA for Kerberos service in a global zone is similar to Installing Kerberos on a node.
If you do not want to configure the Sun Cluster HA for Kerberos service within a non-global zone, do not perform this procedure. Instead, go to Installing Kerberos.
This procedure is written for use on a global file system. In this procedure, the following parameters are used:
Global zone: global
Non-global zone: sparse_zone
Global file system: /global/fs
Create the non-global zone directory and mount it from the global zone. Perform this on each of the cluster nodes.
sparse_zone# mkdir -p /global/fs |
global# zonecfg -z sparse_zone |
zonecfg:sparse_zone> add fs zonecfg:sparse_zone:fs> set dir=/global/fs zonecfg:sparse_zone:fs> set special=/global/fs zonecfg:sparse_zone:fs> set type=lofs zonecfg:sparse_zone:fs> end zonecfg:sparse_zone> verify zonecfg:sparse_zone> commit zonecfg:sparse_zone> exit
global# zoneadm -z sparse_zone reboot |
Where /global/fs is a global file system that has already been configured in the global zone.
The non-global zone's path must be identical to the path of the global zone.
To simplify cluster administration, use the same non-global zone name on each node, where resource groups are to be brought online in the non-global zone.
When you have configured the file system on all the non-global zones, go to How to Install Kerberos. Perform the steps in that procedure in the non-global rather than the global zone.
This section describes the steps to install Kerberos and to enable Kerberos to run as Sun Cluster HA for Kerberos.
Sun Cluster HA for Kerberos uses the Kerberos server and mechanism libraries co-packaged with the Solaris 10 operating system or later versions of the operating system. See the krb5.conf(4) and kdc.conf(4) man pages for information on how to configure the Kerberos environment. The Sun Cluster configuration for Kerberos differs from the Solaris configuration for Kerberos in the following ways:
The Kerberos principal and policy databases are located on the cluster file system, not on a local file system. How to Install Kerberos describes how to configure the server by using a global file system. However, the server can be configured with the HAStoragePlus file system if your environment is heavily loaded with write requests.
A relocatable IP address, not the name of a physical host, identifies the name of a Kerberos server.
In this procedure, the following parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Cluster physical node names = pkdc1.example.com and pkdc2.example.com
Cluster logical hostname = kdc-1.example.com
Become superuser on a cluster member.
Choose the logical hostname that will provide the Kerberos service.
Select the logical hostname so that it corresponds to an IP address set up when you installed the Sun Cluster software. See the Sun Cluster Concepts Guide for Solaris OS for details about logical hostnames.
Create the krb5.conf, kdc.conf, and the other configuration files required to run a Kerberos server, then run the command kdb5_util(1M) as described in the Chapter 23, Configuring the Kerberos Service (Tasks), in System Administration Guide: Security Services.
When populating the hostnames in these configuration files, ensure that they refer to the host's logical name, not the physical name.
This detail ensures that applications running in the same zone as the logical hostname are configured to the corresponding IP addresses.
Here is an example of configuration files with the logical hostnames:
pkdc1# cat /etc/krb5/krb5.conf |
[libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc-1.example.com admin_server = kdc-1.example.com } [domain_realm] .example.com = EXAMPLE.COM [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log kdc_rotate = { period = 1d versions = 10 } [appdefaults] kinit = { renewable = true forwardable = true }
pkdc1# cat /etc/krb5/kdc.conf |
[kdcdefaults] kdc_ports = 88,750 [realms] ACME.COM = { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /etc/krb5/kadm5.keytab acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s default_principal_flags = +preauth }
Make sure that you also have a valid /etc/resolv.conf file and /etc/nsswitch.conf file configured, for example:
pkdc1# cat /etc/resolv.conf |
domain example.com
nameserver 1.2.3.4
nameserver 1.2.3.5
pkdc1# grep dns nsswitch.conf |
hosts: files nis dns
ipnodes: files nis dns
Create the KDC database by running the kdb5_util(1M)
pkdc1# kdb5_util create |
Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password.
Enter KDC database master key:<Type the new master key password> |
Re-enter KDC database master key:<Type the above new master key password> |
Add the following line in the /etc/krb5/kadm5.acl file:
sckrb5-probe/admin@EXAMPLE.COM i
Where:
Realm name chosen in Step 3
The privilege that enables queries to the database for the sckrb5-probe/admin principal
Start the kadmin.local command.
pkdc1# kadmin.local |
Authenticating as principal host/admin@EXAMPLE.COM with password
Use the kadmin.local command to add kadmin and changepw service principals for the fully qualified logical hostname for the cluster, kdc-1.example.com.
kadmin.local: ank -randkey -allow_tgs_req kadmin/kdc-1.example.com |
NOTICE: no policy specified for kadmin/kdc-1.example.com@EXAMPLE.COM; assigning "default" Principal "kadmin/kdc-1.example.com@EXAMPLE.COM" created.
kadmin.local: ank -randkey -allow_tgs_req +password_changing_service \ changepw/kdc-1.example.com |
NOTICE: no policy specified for changepw/kdc-1.example.com@EXAMPLE.COM; assigning "default" Principal "changepw/kdc-1.example.com@EXAMPLE.COM" created. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc-1.example.com changepw/kdc-1.example.com Entry for principal kadmin/kdc-1.example.com with kvno 3, encryption type AES-+ 128 CTS mode with \ 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal kadmin/kdc-1.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal kadmin/kdc-1.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal kadmin/kdc-1.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal changepw/kdc-1.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal changepw/kdc-1.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal changepw/kdc-1.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal changepw/kdc-1.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Add the new service principals for the host services for the fully qualified logical hostname for the cluster, kdc-1.example.com:
kadmin.local: ank -randkey host/kdc-1.example.com |
NOTICE: no policy specified for host/kdc-1.example.com@EXAMPLE.COM; assigning "default" Principal "host/kdc-1.example.com@EXAMPLE.COM" created. kadmin.local: ktadd host/kdc-1.example.com Entry for principal host/kdc-1.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/kdc-1.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/kdc-1.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab \ WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc-1.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to \ keytab WRFILE:/etc/krb5/krb5.keytab.
Fully qualified logical hostname for the cluster
Add a new service principal for the kiprop service for the fully qualified logical hostname for the cluster, kdc-1.example.com.
kadmin.local: ank -randkey kiprop/kdc-1.example.com |
NOTICE: no policy specified for kiprop/kdc-1.example.com@EXAMPLE.COM; assigning "default" Principal "kiprop/kdc-1.example.com@EXAMPLE.COM" created. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kiprop/kdc-1.example.com Entry for principal kiprop/kdc-1.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit \ SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal kiprop/kdc-1.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 \ added to keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal kiprop/kdc-1.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to \ keytab WRFILE:/etc/krb5/kadm5.keytab. Entry for principal kiprop/kdc-1.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added \ to keytab WRFILE:/etc/krb5/kadm5.keytab.
Move the /etc/krb5 and /var/krb5 directories to either a global or a failover file system.
For example, move /etc/krb5 and /var/krb5 to a global file system, /global/fs/, as follows:
pkdc1# mv /etc/krb5 /global/fs/krb-conf |
pkdc1# mv /var/krb5 /global/fs/krb-db |
See the Sun Cluster Software Installation Guide for Solaris OS for information on setting up cluster file systems.
Create symbolic links back to the /etc/krb5 and /var/krb5 directories:
pkdc1# ln -s /global/fs/krb-conf /etc/krb5 |
pkdc1# ln -s /global/fs/krb-db /var/krb5 |
Repeat the symbolic link creation on all the other cluster nodes or zones.
pkdc2# mv /etc/krb5 /etc/krb5.old |
pkdc2# mv /var/krb5 /var/krb5.old |
pkdc2# ln -s /global/fs/krb-conf /etc/krb5 |
pkdc2# ln -s /global/fs/krb-db /var/krb5 |
If you did not install the Sun Cluster HA for Kerberos packages during your initial Sun Cluster installation, perform this procedure to install the packages. To install the packages, use the Sun JavaTM Enterprise System Installation Wizard.
Perform this procedure on each cluster node where you are installing the Sun Cluster HA for Kerberos packages.
You can run the Sun Java Enterprise System Installation Wizard with a command-line interface (CLI) or with a graphical user interface (GUI). The content and sequence of instructions in the CLI and the GUI are similar.
Even if you plan to configure this data service to run in non-global zones, install the packages for this data service in the global zone. The packages are propagated to any existing non-global zones and to any non-global zones that are created after you install the packages.
Ensure that you have the Sun Java Availability Suite DVD-ROM.
If you intend to run the Sun Java Enterprise System Installation Wizard with a GUI, ensure that your DISPLAY environment variable is set.
On the cluster node where you are installing the data service packages, become superuser.
Load the Sun Java Availability Suite DVD-ROM into the DVD-ROM drive.
If the Volume Management daemon vold(1M) is running and configured to manage DVD-ROM devices, the daemon automatically mounts the DVD-ROM on the /cdrom directory.
Change to the Sun Java Enterprise System Installation Wizard directory of the DVD-ROM.
Start the Sun Java Enterprise System Installation Wizard.
# ./installer |
When you are prompted, accept the license agreement.
If any Sun Java Enterprise System components are installed, you are prompted to select whether to upgrade the components or install new software.
From the list of Sun Cluster agents under Availability Services, select the data service for Kerberos.
If you require support for languages other than English, select the option to install multilingual packages.
English language support is always installed.
When prompted whether to configure the data service now or later, choose Configure Later.
Choose Configure Later to perform the configuration after the installation.
Follow the instructions on the screen to install the data service packages on the node.
The Sun Java Enterprise System Installation Wizard displays the status of the installation. When the installation is complete, the wizard displays an installation summary and the installation logs.
(GUI only) If you do not want to register the product and receive product updates, deselect the Product Registration option.
The Product Registration option is not available with the CLI. If you are running the Sun Java Enterprise System Installation Wizard with the CLI, omit this step
Exit the Sun Java Enterprise System Installation Wizard.
Unload the Sun Java Availability Suite DVD-ROM from the DVD-ROM drive.
See Registering and Configuring Sun Cluster HA for Kerberos to register Sun Cluster HA for Kerberos and to configure the cluster for the data service.
This section describes how to register and configure Sun Cluster HA for Kerberos.
To perform this procedure, you need the following information about your configuration.
The name of the resource type for Sun Cluster HA for Kerberos. This name is SUNW.krb5.
The names of the cluster nodes and the non-global zones on the nodes that master the data service.
The network resource that clients use to access the data service. You normally set up this IP address when you install the cluster. See the Sun Cluster Concepts Guide for Solaris OS document for details on network resources.
Become superuser on a cluster node.
Register the resource type for the data service.
# clresourcetype register SUNW.krb5 |
Create a resource group for the network and Kerberos resources to use.
# clresourcegroup create [-n node[,...]] resource-group |
Specifies an optional comma-separated list of zones that can master this resource group. Each entry in this list has the format node. Where node is the node name and address and zone specifies the name of a non-global Solaris zone. To specify the global zone, or to specify a node without local zones, specify only node. These are the nodes or zones on which the data service can run. The order here determines the order in which the nodes or zones are considered as primary during failover. If all of the cluster nodes or zones are potential masters, you do not need to use the -n option.
This list is optional. If you omit this list, the global zone of each cluster node can master the resource group.
Verify that all of the network resources that are to be used have been added to your name service database.
You should have performed this verification during the Sun Cluster installation. See the Chapter 1, Planning the Sun Cluster Configuration, in Sun Cluster Software Installation Guide for Solaris OS for details.
To avoid any failures because of name service lookup, verify that all of the network resources are present in the server's and client's /etc/inet/hosts file. Configure name service mapping in the /etc/nsswitch.conf file on the servers to first check the local files before trying to access NIS or NIS+.
Add a logical hostname to a resource group.
# clreslogicalhostname create -g resource-group \ -h logical-hostname,[logical-hostname] \ [-N netif@node[,...]] lhresource |
Specifies the name of the resource group. This name can be your choice but must be unique for a resource group within the cluster.
Specifies a comma-separated list of network resources (logical hostname or shared address).
Specifies an optional, comma-separated list that identifies the IP Networking Multipathing groups that are on each node. netif can be given as an IP Networking Multipathing group name, such as sc_ipmp0. The node can be identified by the node name or node ID, such as sc_ipmp0@1 or sc_ipmp@phys-schost-1. If you do not specify -N, the clreslogicalhostname command attempts to set the NetIfList property for you based on available IPMP groups or public adapters and the subnet associated with the HostnameList property.
Specifies the logical hostname resource to be created in the associated resource group.
If you require a fully qualified hostname, you must specify the fully qualified name with the -h option and you cannot use the fully qualified form in the resource name.
Sun Cluster does not currently support the use of adapter names for netif.
Add a Kerberos application resource to the resource group.
# clresource create -g resource-group -t SUNW.krb5 \ [-p Network_resources_used=network-resource, ...] \ [-p Port_list=port-number/protocol] resource |
Specifies a comma-separated list of network resources (logical hostnames or shared addresses) that Kerberos will use. If you do not specify this property, the value defaults to all of the network resources that are contained in the resource group.
Specifies a port number and the protocol to be used. If you do not specify this property, the value defaults to 88/tcp,749/tcp,88/udp.
Specifies the name of the resource type to which this resource belongs. This entry is required.
Specifies the name of the resource to be associated with the resource type SUNW.krb5.
The resource is created in the enabled state.
Bring the resource group online:
# clresourcegroup online -M resource-group |
The following example shows how to register Sun Cluster HA for Kerberos on a two-node cluster. At the end of this example, the clresourcegroup command starts Sun Cluster HA for Kerberos.
This example uses the following configuration parameters:
pkdc1.example.com and pkdc2.example.com:sparse_zone
Kerberos is hosted in the global zone on pkdc1.example.com and in the non-global zone “sparse_zone” on pkdc2.example.com.
kdc-1.example.com
krb-rg (for all of the resources)
kdc-1 (logical hostname) and krb-rs (Kerberos application resource)
Register the Kerberos resource type.
# clresourcetype register SUNW.krb5 |
Create the resource group to contain all of the resources.
# clresourcegroup create -n pkdc1.example.com, pkdc2.example.com:sparse_zone krb-rg |
Add the logical hostname resource to the resource group.
# clreslogicalhostname create -g krb-rg -h kdc-1 kdc-1 |
Add a Kerberos application resource to the resource group.
# clresource create -g krb-rg -t SUNW.krb5 krb-rs |
Bring the failover resource group online.
# clresourcegroup online -M krb-rg |
This procedure describes how to configures the HAStoragePlus resource type. This resource type synchronizes actions between HAStorage and Sun Cluster HA for Kerberos and enables you to use a highly available local file system. It is, however, recommended that you use a global file system rather than using HAStoragePlus because Sun Cluster HA for Kerberos is not disk-intensive in most environments.
See Relationship Between Resource Groups and Device Groups in Sun Cluster Data Services Planning and Administration Guide for Solaris OS for background information.
This procedure uses the following configuration parameters:
Cluster physical node names = pkdc1.example.com and pkdc2.example.com:sparse_zone
Cluster logical hostname = kdc-1.example.com
Resource group = krb-rg
Kerberos application resource = krb-rs
HAStoragePlus resource = krb-hasp-rs
Logical hostname resource = kdc-1
Device group associated with the file system:/global/dg1
The /global/dg1 file system contains the krb-db and krb-conf directories which have symbolic links that point to /var/krb5 and /etc/krb5 respectively.
Register the Kerberos resource type.
# clresourcetype register SUNW.krb5 |
Create a resource group.
# clresourcegroup create -n pkdc1.example.com, pkdc2.example.com:sparse_zone krb-rg |
Add the logical hostname resource to the resource group.
# clreslogicalhostname create -g krb-rg -h kdc-1 |
Add the Kerberos application resource to the resource group.
# clresource create -g krb-rg -t SUNW.krb5 krb-rs |
Register the HAStoragePlus resource type
# clresourcetype register SUNW.HAStoragePlus |
Add the HAStoragePlus resource to the resource group.
# clresource create -g krb-rg -t SUNW.HAStoragePlus \ -p FilesystemMounPoints=/global/dg1 \ -p AffinityOn=TRUE krb-hasp-rs |
Bring the failover resource group online.
# clresourcegroup online -M krb-rg |
The Sun Cluster HA for Kerberos fault monitor is contained in the resource that represents Kerberos. You create this resource when you register and configure Sun Cluster HA for Kerberos. For more information, see Registering and Configuring Sun Cluster HA for Kerberos.
System properties and extension properties of this resource control the behavior of the fault monitor. The default values of these properties determine the preset behavior of the fault monitor. The preset behavior should be suitable for most Sun Cluster installations. Therefore, you should tune the Sun Cluster HA for Kerberos fault monitor only if you need to modify this preset behavior.
Tuning the Sun Cluster HA for Kerberos fault monitor involves the following tasks:
Setting the interval between fault monitor probes
Setting the timeout for fault monitor probes
Defining the criteria for persistent faults
Specifying the failover behavior of a resource
Perform these tasks when you register and configure Sun Cluster HA for Kerberos. For more information, see the following sections:
The information that you need to tune theRegistering and Configuring Sun Cluster HA for Kerberos fault monitor is provided in the follow subsection.
The probing consists of checking to see if kadmind(1M) and krb5kdc(1M) are listening to their respective ports. During more thorough probing a new principal is created, the principal is authenticated, and then this principal fetches itself from the database to test the administrative daemon, kadmind.
The probe executes the following steps.
Probe the ports for kadmind(1M) and krb5kdc(1M) to make sure that they are listening. Run the probe command by using the time-out value that the resource property Probe_timeout specifies. The probe is run every Cheap_probe_interval, which by default is every 30 seconds.
Every Thorough_probe_interval (by default 300 seconds) kadmin.local(1M) is used to add a principal. The probe then performs a kinit(1) with the newly created principal. The probe uses the newly created principal to run kadmin(1M) to retrieve its record from the principal database.
The result of these probe commands can be either fail or succeed. If Kerberos successfully responds, the probe returns to its infinite loop, waiting for the next probe time.
If the probe fails, the probe considers this scenario a failure of the Kerberos data service and records the failure in its history. The Kerberos probe considers every failure a complete failure.
Based on the success or failure history, a failure can cause a local restart or a data service failover. Refer to Tuning Fault Monitors for Sun Cluster Data Services in Sun Cluster Data Services Planning and Administration Guide for Solaris OS for further details.
Verify that you have correctly installed and configured Sun Cluster HA for Kerberos.
Configure a Kerberos client to authenticate the newly created server as described in Configuring Kerberos Clients in System Administration Guide: Security Services.
When referencing the server in the client's configuration file, /etc/krb5/krb5.conf, specify the logical hostname of the server. An example of this name could be kdc-1.example.com.
After the client is configured, test the authentication of a user principal by using kinit(1).
# kinit user_name |
Password for user_name@realm_name: |
A user principal that you created previously
Indicates the realm name that was previously configured in the Kerberos environment.
You return to the shell prompt without any error message being output to the terminal.
Test the Kerberos administration service.
# kadmin -p administrative_principal_name |
Authenticating as principal administrative_principal_name@realm_name with password. Password for administrative_principal_name@realm_name: kadmin: quit
An administrative principal that you had previously created.
Indicates the realm name that was previously configured in the Kerberos environment.
You return to the shell prompt without any error message being output to the terminal.