Reference Guide

Appliance node Ethernet service port and IPMItool

Your appliance provides console access over an Ethernet service port that is on each node. This access requires the use of the

IPMItool. The IPMItool is a network tool similar to SSH or Telnet that interfaces with each node over an Ethernet connection by

using the IPMI protocol. The IPMItool is a Windows utility that negotiates a secure communication channel to access the node

console of an appliance. This utility requires physical access to activate the console.

The node Ethernet service port interface provides the same functions and features as the service SSH interface (Service LAN

interface) and is also subject to the same restrictions. However, users access the interface through an Ethernet port connection

rather than an SSH client. This interface is designed for field service personnel who can connect to the appliance without having

to disturb your network. A dedicated management console is not necessary.

This interface provides a direct point-to-point, non-routable connection. Service personnel can use the Service LAN interface

for console output, SSH access to the PowerStore Service Container and PowerStore Manager including the ICW (Initial

Configuration Wizard). SSH access to the Service Container through the Service LAN interface is always enabled, and cannot

be disabled; however, you manage the service account credential.

For a list of service scripts, refer to the PowerStore Service Scripts Guide.

NFS secure

NFS secure is the use of Kerberos for authenticating users with NFSv3 and NFSv4. Kerberos provides integrity (signing) and

privacy (encryption). Integrity and privacy are not required to be enabled, they are NFS export options.

Without Kerberos, the server relies entirely on the client to authenticate users: the server trusts the client. With Kerberos this is

not the case, the server trusts the Key Distribution Center (KDC). It is the KDC which handles the authentication and manages

accounts (principals) and passwords. Moreover, no password in any form is sent on the wire.

Without Kerberos, the credential of the user is sent on the wire un-encrypted and thus can easily be spoofed. With Kerberos,

the identity (principal) of the user is included in the encrypted Kerberos ticket, which can only be read by the target server and

KDC. They are the only ones to know the encryption key.

In conjunction with NFS secure, AES128 and AES256 encryption in Kerberos is supported. Along with NFS secure, this also

impacts SMB and LDAP. These encryptions are now supported by default by Windows and Linux. These new encryptions are

much more secure; however, it is up to the client whether they are used. From that user principal, the server builds the

credential of that user by querying the active Unix Directory Service (UDS). Since NIS is not secured, it is not recommended to

use it with NFS secure. It is recommended to use Kerberos with LDAP or LDAPS.

NFS secure can be configured through PowerStore Manager.

File protocol relationships

With Kerberos the following is required:

● DNS - You must use DNS name in place of IP addresses.

● NTP - PowerStore must have a configured NTP server.

NOTE: Kerberos relies on the correct time synchronization between the KDC, servers, and client on the network.

● UDS - To build credentials.

● Hostname - Kerberos works with names and not IP addresses.

NFS secure uses one or two service principal names (SPNs) depending on the value of the hostname. If the hostname is in

FQDN format host.domain:

● The short SPN: nfs/host@REALM

● The long SPN: nfs/host.domainFQDN@REALM

If the hostname is not in FQDN format, only the short SPN will be used.

Similar to SMB, where an SMB server can be joined to a domain, an NFS server can be joined to a realm (the Kerberos

equivalent term for domain). There are two options for this:

● Use the configured Windows domain if any

● Entirely configure a UNIX KDC based Kerberos realm

Authentication and access