HP AB500A - Integrated Lights-Out Advanced Quick guide

Planning and configuration recommendations
for Integrated Lights-Out processors
technology brief, 2nd edition
Abstract.............................................................................................................................................. 3
Introduction......................................................................................................................................... 3
IT environment assessment .................................................................................................................... 3
Planning considerations for network configuration ................................................................................... 4
Private management network............................................................................................................. 4
Network port configurations available to iLO ...................................................................................... 5
iLO common network .................................................................................................................... 5
iLO Shared Network Port .............................................................................................................. 5
iLO on dedicated management network.......................................................................................... 6
Considerations when configuring the iLO network ............................................................................ 7
Network cabling in dense rack environments................................................................................... 7
Out-of-band management using iLO’s virtual serial port..................................................................... 8
iLO configuration................................................................................................................................. 9
Single iLO device............................................................................................................................. 9
Multiple iLO devices ......................................................................................................................... 9
Automated setup .......................................................................................................................... 9
Initial deployment ....................................................................................................................... 10
Naming conventions................................................................................................................... 10
iLO network settings ....................................................................................................................... 10
Proxy servers ............................................................................................................................. 10
Configuring IP port assignments ................................................................................................... 10
IP port assignment for blades ....................................................................................................... 11
Implementing iLO network security architecture...................................................................................... 12
Default local iLO users accounts....................................................................................................... 12
Advantages of directory integration.................................................................................................. 12
How to begin directory implementation ............................................................................................ 13
Methods for directory services implementation................................................................................... 13
HP default schema method .............................................................................................................. 14
Support for nested groups ........................................................................................................... 15
HP extended schema method........................................................................................................... 15
Required Software...................................................................................................................... 15
Extending the directory schema.................................................................................................... 16
Roles......................................................................................................................................... 16
Integrating iLO login into complex network directories........................................................................ 17
Configuring iLO to access the directory service.................................................................................. 18
Local versus directory accounts ........................................................................................................ 18
Additional security considerations .................................................................................................... 19
Two-factor authentication............................................................................................................. 19
Restricting access to the Remote Console port ................................................................................ 20

Protecting SNMP traffic ............................................................................................................... 21
Using iLO with other HP management tools........................................................................................... 21
Integration with HP Systems Insight Manager..................................................................................... 21
Configuring iLO for access with Systems Insight Manager Single Sign-on.............................................. 23
How it works ............................................................................................................................. 23
Integrating iLO usage with Onboard Administrator ............................................................................ 23
Unattended server deployment......................................................................................................... 25
Deploying servers using Rapid Deployment Pack ............................................................................... 25
Taking advantage of advanced Remote Consoling ................................................................................ 26
Configuring and using Shared Remote Console ................................................................................. 26
Configuring and managing Console Replay...................................................................................... 28
Creating a central repository for use with iLO’s virtual media feature ....................................................... 29
Scripted Virtual Media.................................................................................................................... 29
XML scripting ............................................................................................................................. 29
XML examples............................................................................................................................ 30
CLP scripting.............................................................................................................................. 30
Scripting web server requirements ................................................................................................ 31
Managing multiple iLO devices ........................................................................................................... 31
HP Systems Insight Manager ........................................................................................................... 32
CPQLOCFG.EXE, HPONCFG.EXE, and script files ............................................................................. 32
Appendix A ...................................................................................................................................... 33
Using barcode scanning to ease mass-configuration of iLO devices...................................................... 33
Command-line switches................................................................................................................... 34
Deploying iLO devices.................................................................................................................... 34
Updating iLO devices ..................................................................................................................... 35
Appendix B....................................................................................................................................... 36
Using a RAM drive to ease mass-deployment of iLO-based servers....................................................... 36
Overview ...................................................................................................................................... 36
The master boot diskette.................................................................................................................. 36
The custom deployment tool ............................................................................................................ 37
For more information.......................................................................................................................... 39
Call to action .................................................................................................................................... 39

Abstract
This document identifies specific planning and configuration practices for using the HP Integrated
Lights-Out (iLO) and the HP Integrated Lights-Out 2 (iLO 2) management processors to reduce
complexity and simplify management of the datacenter and remote sites. Although, management
processors may not be applicable in all computing environments, HP recommends implementing these
guidelines as appropriate to the specific IT infrastructure.
Introduction
Server remote management is a necessity for IT organizations of all sizes. One of the HP Integrated
Lights-Out (iLO) products is right for any organization where it’s important to minimize downtime,
have the ability to remotely manage servers regardless of condition, and perform complex operations
such as initial server deployments. HP Integrated Lights-Out is HP’s building block management tool.
It improves server experience in initial deployment, reconfiguration, and operation. By setting up
each server to be monitored with iLO HP, administrators can benefit from the long record of
undisputed leadership in lights-out remote management with iLO.
The iLO device is an autonomous management processor that resides on the system board of a host
server. This device contains its own processor, memory, and network interface that allow it to operate
independently from the host server. Using iLO, IT administrators can manage a ProLiant server
remotely through its entire life cycle: initial deployment, operation, and redeployment.
Unlike other management solutions, iLO devices are entirely independent of the state of the operating
system (OS) or server hardware. These devices provide seamless control of remote servers in full
graphics mode (when using the iLO Advanced feature set). The Virtual Media feature of iLO allows IT
administrators to perform remote ROM upgrades and server deployments. All these capabilities
combine to provide administrators with the ability to respond quickly to downtime events, diagnose
OS or server problems remotely, increase uptime, and reduce the loss of business revenue.
This paper discusses system planning, configuration, and deployment of iLO management processors.
It is assumed that the reader is familiar with the general features of iLO. Reference material is
available in the “For more information” section at the end of this document. More information about
iLO technology is also available from the HP website at www.hp.com/servers/ilo.
This document supports both iLO devices; however, certain functions described herein may only be
supported on one and not the other. A designation of “iLO only” or “iLO 2 only” indicates that the
function is exclusive to that device. iLO firmware is backward-compatible. For example, the latest
versions of iLO 2 firmware support any iLO 2 processor. For consistency and best feature support,
use the latest version of iLO 2. If no designation is present then the function is supported on both
devices.
IT environment assessment
Before deploying and configuring an iLO device, it is helpful to assess the IT environment. Table 1
outlines areas to consider when planning the use of Lights-Out technology and the resulting benefits in
the data center.
3

Table 1. Assessing the IT environment
Target Criteria Potential improvement
Asset management Where are servers located (in datacenters
or at remote sites)?
Where would it be helpful to use iLO?
How many servers exist in the computing
environment?
Deploying iLO can eliminate the need
for keyboards, video monitors, and
mice, which reduces cabling complexity
and increases server density in the
datacenter.
Systems
management
How are remote sites and data center
servers currently managed?
Can the servers be managed remotely
through lights-out technology?
The iLO device provides seamless
access to the server, which eliminates
the need for an administrator to be
present in front of the server.
Software or
operating system
How many different operating systems are
running on the servers? What is the plan
to take them all to the latest release?
Ensuring that the latest drivers are
downloaded as needed
Security Is the network as secure as possible?
Does the datacenter use virtual private
networks or include firewalls?
Can all servers use directory services and
authentication?
Can the datacenter benefit from two-factor
authentication?
The iLO device provides multiple levels
of security, including directory
authentication, Secure Sockets Layer
(SSL) encryption, event generation for
failed login attempts, lockout of
configuration utilities, enforced delay
after unsuccessful login attempts, two-
factor authentication, and configurable
internet protocol (IP) port assignments.
When planning future server purchases, a customer can determine whether a server includes iLO by
referring to this Web page:
http://h18013.www1.hp.com/products/servers/management/remotemgmt/supported-servers.html.
Customers that have a large installed based of iLO devices and frequently add more may want to
purchase a Master License Agreement (MLA) from HP. An MLA allows the customer to purchase a
single activation key for multiple licenses of the ProLiant Essentials Value Packs, such as the iLO
Advanced Pack. After the MLA is in place with HP, the customer purchases the desired number of
license-only part numbers whenever additional licenses for iLO Advanced are needed. This simplifies
the software licensing process and reduces the amount of physical documentation that is shipped to
the customer. Additional information is available from the HP website:
http://h18004.www1.hp.com/products/servers/proliantessentials/license/licensebuy.html.
Planning considerations for network configuration
Before deploying iLO devices, an administrator should consider the setup and design of the network
on which the iLO devices will reside.
Private management network
The iLO devices allow browser access to the host ProLiant servers through a seamless, hardware-
based, OS-independent remote console. For security reasons, HP recommends that customers
establish a private management network that is separate from their data network and that only
administrators are granted access to that management network. The iLO private management network
uses a shared network port. The autosensing iLO network interface card (NIC) operates at 10/100
megabits per second (Mbps) and links at the same speed as the host.
4

Network port configurations available to iLO
Possible configurations between the system network interface card NIC and the iLO based NIC
provide the user with choices to best suit individual system requirements (Figure 1). Choosing between
these options depends on knowing the benefits and cautions connected with each.
Figure 1. Three methods of iLO connectivity
Server
iLO
Mgmt
Port
Standard
Gigabit
Port
Common Network
Access
Server
iLO
Mgmt
Port
Standard
Gigabit
Port
Corporate Network
Management Network
Dedicated Network
Access
Server
iLO
Mgmt
Port
Shared
Port Access
Corporate/Management
Network
Standard
Gigabit
Port
Corporate/Management
Network
iLO common network
The iLO management port can be connected to the same network used by the server’s main
10/100/1000 NIC to allow iLO control from anywhere on the network. Using a common network
simplifies installation, since all cables attach to the same network; however, iLO management
performance may be hindered by corporate network traffic.
iLO Shared Network Port
The iLO Shared Network Port feature on ProLiant servers allows system administrators to access iLO
using a network connection shared with the host operating system. SNP enables this shared
connection with a single cable. The ProLiant server Shared Network Port feature implements a
sideband connection between the main NIC and the iLO. This sideband connection maintains a
second (and separate) MAC address. This separate MAC address is assigned to iLO and allows iLO
to obtain a separate IP address. Thus, iLO and the server’s NIC each have their own separate MAC
and IP addresses.
With iLO 2 only, shared network port provides a high-speed, full-featured connection to iLO. First
generation, iLO only servers with shared network port are limited-to a low-speed (text only) connection
to iLO when using the shared port.
When teaming host NICs, the iLO Shared Network Port can still be used, however iLO does not
benefit from teaming fault tolerance, nor does Shared Network Port prevent teaming, since iLO and
the host have separate MAC and IP addresses.
This feature reduces the number of network connections required to manage the server. The Shared
Network Port operates as miniature network switch, routing iLO information to the iLO network
interface and server operating system information to the operating system network interface. Using
this routing, where both ports are connected to the corporate network, allows fewer network
connections to the system. This approach enables access to iLO from anywhere on the network. One
5

issue to consider when implementing the iLO common network approach is that there will be an
increase in traffic on the corporate network.
A corporate network configuration reduces the amount of networking hardware and infrastructure
required to support iLO because iLO uses existing DNS and DHCP servers and routers. Additionally,
with iLO 2 only, the shared network port performance is comparable to the iLO Dedicated Network
Port.
Note:
The iLO Shared Network Port function is available only on a limited number
of ProLiant servers. This function is supported by both the NIC and iLO
firmware.
Optional use of VLAN tags allows segregation of management traffic.
iLO on dedicated management network
Use of the iLO port on a separate management network improves performance, security, and provides
redundant access to the server when a hardware failure occurs on the corporate network. In this
configuration, iLO cannot be accessed directly from the corporate network.
A separate management network increases the security through the ability to physically control which
workstations are connected to the network.
6

Considerations when configuring the iLO network
Administrators can use a hierarchical decision tree (Figure 2) to analyze the benefits of choosing
particular network configurations.
Figure 2. Planning iLO network implementation
Is there a
dedicated
management
network?
Yes
Should iLO be
accessible
from the
network?
Port
constrained?
Port
constrained?
How to implement iLO
network
Yes No
Deploy iLO on
dedicated network
Use iLO Shared
Network Port
capability (if
available) and
connect to the
production network
Connect iLO to the
Production network
No
Yes
Use iLO Shared Network
Port capability- Assign
VLAN ID to the
management network
and connect to a switch
configured to support
VLAN
Yes
No
No
Connect the dedicated
iLO network to a new
management network
HP recommends using the Dedicated Management Network and the dedicated iLO network port for
highest performance and security. If port constrained, administrators can use the iLO shared network
port with VLAN on supported ProLiant servers.
Network cabling in dense rack environments
When deploying multiple iLO-enabled servers in very dense rack environments, it is beneficial to
consolidate all of the iLO network connections to a rack-mounted hub or access switch (Figure 3). The
administrator may then uplink all Lights-Out Management network traffic via a single output from the
hub/switch into a distribution switch in the enterprise network infrastructure.
Using an access switch for Lights-Out management traffic on the network provides the following
benefits:
•Simplifies cable management inside the rack
•Makes more efficient use of available bandwidth
•Reduces the number of network cables run to the rack for management traffic
•Reduces usage of more expensive enterprise network infrastructure ports
7

Figure 3. Consolidating multiple iLO devices into a single rack-mounted access switch
Out-of-band management using iLO’s virtual serial port
The Virtual Serial Port (iLO) and Remote Serial Console (iLO 2) functions allow access to the physical
serial port of the server virtually through the iLO network connection. These two functions are
technically equivalent; only the names changed between iLO and iLO 2. The Remote Serial Console
option relies on the Virtual Serial Port. The Virtual Serial Port must be correctly enabled and
configured in the host RBSU. There are three methods of accessing the Remote Serial Console or
Virtual Serial Port:
•Using a Windows or Linux browser, a Java applet is launched which provides VT320 console
capability to the serial port connection.
•Using a telnet client, a command can be issued to connect to the serial port.
•Using a SSH client in a manner similar to that from the telnet client.
The Remote Serial Console or Virtual Serial Port function enables access to the Microsoft EMS
(Emergency Management Services) SAC (Special Administration Console), and the Linux serial
console, as well as to the ProLiant System ROM BIOS Serial Console Redirection.
For more information on Remote Serial Console (iLO 2) and Virtual Serial Port (iLO) functions see the
iLO users guide and Integrated Lights-Out Virtual Serial Port papers referenced in “For more information”
at the end of this paper.
8

iLO configuration
Each iLO device can be configured individually in multiple ways: through the ROM-Based Setup Utility
(RBSU), through the web browser interface, through the Command Line Protocol (CLP), or through a
scripted setup over the network or from the host. This allows the administrator to configure iLO using
the appropriate means for their environment, and enables 1:1 configuration (such as using a browser)
or 1:many configuration (such as using a scripted setup).
Single iLO device
RBSU is the recommended method to set up a single iLO device initially. RBSU allows configuration of
the iLO network address as well as a local user account. After initial setup using iLO RBSU, the iLO
device is available on the network; and subsequent configuration and management can be
accomplished by other means. RBSU is available every time the server is booted and can be run
remotely using the iLO Remote Console. RBSU is not intended for continued administration. Other
tools such as the web browser or scripting tools are better suited for that.
See the iLO User Guide for more information about ea the configuration methods discussed here.
Links to the iLO User Guides may be found on the ‘For more information’ page at the end of this
document.
Multiple iLO devices
Administrators faced with the deployment of multiple iLO compliant servers should employ efficient
configuration and management methods.
Automated setup
Deploying a large number of iLO-enabled servers is best accomplished by using several OS specific,
automated setup enablers. These enablers include the Lights-Out Configuration Utility
(CPQLOCFG.EXE), the Online Configuration Utility (HPONCFG.EXE), and a Perl interpreter that
communicates with iLO. These utilities support the use of script files allowing administrators to
configure and manage user accounts on multiple iLO devices simultaneously. HP has developed and
made available sample XML and Perl scripts files that can be adjusted for the targeted environment.
Additionally, HP recommends using a bar code scanner (see Appendix A) to further facilitate
automation.
Administrators can expand or change the sample XML scripts to perform other functions such as to
power up or down servers or determine who has access rights to iLO. The iLO User Guide includes
the supported XML commands for additional script development.
Appendix A discusses, in detail, how to use these utilities, their respective sample script files and the
bar code reader in order to automate the deployment and configuration of multiple iLO devices.
The CPQLOCFG.EXE, HPONCFG.EXE, and the sample scripts files are available from the HP website
at the links found in Table 2. The CPQLOCFG.EXE version 2.5 or greater must be used for iLO
devices.
Table 2. Links to Online Configuration utilities and XML scripting samples
Software Links
CPQLOCFG.EXE http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang
=en&cc=US&swItem=MTX-
5ee197c5bd7641359f45d876b1&prodTypeId=15351&prodSeriesId=397989
HPONCFG.EXE
for Windows
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lan
g=en&cc=us&prodTypeId=18964&prodSeriesId=1146658&prodNameId=1135772
&swEnvOID=1005&swLang=8&mode=2&taskId=135&swItem=MTX-
ea306043175c40bcb35952a862
9

Software Links
HPONCFG.EXE
for Linux
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang
=en&cc=us&prodTypeId=18964&prodSeriesId=1146658&prodNameId=1135772&s
wEnvOID=2025&swLang=8&mode=2&taskId=135&swItem=MTX-
0e9ae397b9224e3dae2fb457d5
XML scripting
sample for
Windows
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang
=en&cc=us&prodTypeId=18964&prodSeriesId=1146658&prodNameId=1135772&s
wEnvOID=1005&swLang=8&mode=2&taskId=135&swItem=MTX-
84d9a19b43b84516ac2d26d01f
Initial deployment
HP recommends using a bar code scanner to further facilitate automation. Appendix A discusses, in
detail, how to use these utilities, their respective sample script files and the bar code reader in order
to automate the deployment and configuration of multiple iLO devices.
HP recommends that administrators use these sample files and a bar code reader to scan all the
passwords and Domain Name System or Service (DNS) names from the network settings tag into a
spreadsheet or database. (An administrator can manually enter the passwords and DNS names into a
spreadsheet; however, manual entry is much more time-consuming and error-prone than scanning.)
Then, using the appropriate XML script, the administrator can configure the group of iLO devices, add
the license keys for the iLO Advanced functionality, upgrade firmware on the iLO devices, add a new
user, or change user privileges.
After initially configuring iLO, it is possible to continue deploying the server, including the operating
system installation. Various methods are available to perform OS installation and configuration,
including iLO virtual media, Rapid Deployment Pack, or custom installation tools. Appendix B outlines
a sample custom installation tool that allows installation of the operating system during a mass
deployment operation.
Naming conventions
When deploying many iLO devices, it is helpful to name them according to a consistent convention,
for example: ServerName_iLO. This convention clearly identifies which server is hosting the iLO
device and makes it easier to set up proxy settings for wildcard usage.
iLO network settings
The Network Settings and DCHP/DNS tabs of the Network section allow administrators to view and
modify network settings for iLO 2. The Network Settings tab of the Network section displays NIC IP
address, subnet mask, and other TCP/IP related settings. All users can view the Network Settings, but
only users with the Configure iLO 2 Settings privilege can change these settings.
Proxy servers
Each iLO device can be accessed by its short name (for example, remote21), fully qualified name (for
example, remote21.domain.com), or Internet protocol (IP) address. The browser needs to be
configured to bypass the proxy server for each method used to access the iLO device.
Configuring IP port assignments
Administrators can manually configure the HTTP, Remote Console, and Virtual Media ports used by
the iLO device. Normally, a web browser automatically attempts to connect with port 80 when given
an IP address. Using the port configuration capability, the administrator can redirect the HTTP,
Remote Console, and Virtual Media ports to administrator-defined ports (Table 3). This redirection
prevents others from accessing the HTTP, Remote Console, and Virtual Media ports without specific
knowledge of the port numbers. Once the HTTP port is re-directed, a user must specify that port along
with the IP address to access the login screen. This may be particularly useful for customers who wish
10

to access iLO through a firewall and use HP Systems Insight Manager (HP SIM) as the data collection
vehicle for port changes.
For an iLO device to work properly when going across routers using port blocking and/or firewalls,
ports 23, 80, 443, and 17988 must be open.
Table 3.Default port locations for iLO
Port
Number
Protocol Can Port Number
be Changed?
Supports Enabled by
default
22 SSH Yes SSH Connections Yes
23 Telnet Yes Remote graphical console
Remote text console
virtual serial port
Yes
80 Remote Insight
browser port
Yes HTTP interface to iLO
management board
Yes
161 SNMP get/set No HP SIM polls No
162 SNMP trap No HP SIM agent events No
443 Remote Insight
browser access
encrypted port
Yes SSL access to iLO
management board
Encrypted XML access
Yes
636 Lightweight
Directory Assisted
Protocol (LDAP)
Yes Secure connection to the
directory server
Yes, if directory
support is
enabled
3389 Terminal Services
Pass-Through
(RDP)
Yes Terminal Services session-
software-based remote
console using Microsoft®
Windows® OS (RDC/TS)
Yes
9300 Telnet Yes Multi-user remote console No
17988 Virtual Media Yes Virtual Media Yes
17990 Telnet Yes Console replay No
Note:
The inability to access the iLO management ports is often confused with
incorrect proxy settings. When in doubt, disable proxy in Internet Explorer
or Netscape.
IP port assignment for blades
ProLiant BL p-Class blades support Enclosure Static IP Addressing (ESIP) and ProLiant BL c-Class blades
support Enclosure Bay IP Addressing (EBIPA). This allows each iLO installation to determine network
parameters such as IP address and host name, but without requiring network services like DHCP.
Initially configuring an enclosure via the iLO in the blade in bay 1 allows rapid deployment of
subsequent blades in the enclosure, without requiring these network services. Should a blade using
ESIP be redeployed, reset iLO to defaults.
11

ProLiant BL c-Class blades support Enclosure-Based IP Addressing (EBIPA), an extended version of
ESIP. Configured via the Onboard Administrator, this simplifies deployment of c-Class blades.
Implementing iLO network security architecture
Before pursuing any single method of access, administrators should be aware that there are a number
of ways to manage user access to iLO. The available management options include:
•Local iLO user accounts, which are the default method
•Directory-based user accounts
•Onboard Administrator access to iLO in c-Class blades
•HP SIM access to iLO using Single Sign-On
•Two-Factor (Smart Card) authentication
Default local iLO users accounts
iLO’s standard login security, which uses local user accounts for authentication/authorization, is a
secure and appropriate solution for smaller installations. Administrators can configure a maximum of
12 users for authentication/authorization. The user list must be entered and maintained separately for
each iLO device. Therefore, it can prove limiting when using a large number of iLO-enabled servers.
The recommended way to implement iLO login security on larger, more complex networks is to
integrate it with the network’s existing directory services using iLO’s LDAP-based directory support.
Advantages of directory integration
An administrator can integrate directory services to improve security. As a licensed feature, directory
services integration is supported by current iLO firmware and allows an administrator to authenticate
a user and authorize user privileges by means of the same login process employed throughout the rest
of the network.
The advantages of integrating directory services are:
•Fewer credentials are required. The creation of user accounts is not required on each iLO device
that supports directories. If a user exists in the directory, then the account can be used for lights-out
processors. After the lights-out processor is configured, adding the user to the appropriate group
grants them access to all associated lights-out processors. ILO records the user activity in the event
logs using their directory name, leaving an audit trail.
•Users are less likely to share an iLO account when they can use their directory user accounts. This
reduces potential “anonymous” access or the treatment of iLO user accounts as “roles.”
•The directory becomes the single point for password maintenance, instead of each iLO instance.
This allows implementation of a secure password policy and avoids the downsides of maintaining
password lists.
•Centralized network administration is enabled after a lights-out processor is configured to use the
directory. User administration can take place in a single place, the management console, instead of
at each lights-out processor.
•The directory scales well to larger populations.
Using directory access provides greater protection against malicious attacks. For instance, using a
local account, each network connected iLO presents a unique logon opportunity for an intruder.
However, with directory services, the intruder would have only a single access point to multiple iLO
devices. Additionally, after each unsuccessful logon attempt, the iLO introduces a progressively longer
delay before presenting subsequent logon prompts. This design thwarts automated attacks and
reduces the chance that intruders may log in to any iLO device.
12

How to begin directory implementation
Information helpful for understanding directory implementation is available in the Integration Note,
"Integrating HP ProLiant Lights-Out processors with Microsoft Active Directory" available in ‘For more
information’ at the end of this paper.
Figure 4 details the process for directory implementation and the basic decisions administrators must
make.
Figure 4. Directory implementation
Can schema
extensions be
applied to
the directory?
Yes
Using MS
Active
Directory?
Directory implementation decision process
No
Scalability Questions:
Yes
Use Group-based Default Schema
Perhaps directory
integration does not fit the
environment.
Consider deploying an
evaluation directory server
to evaluate the benefits of
directory integration.
No
No
Consensus?
Use HP Schema
Extensions
Deploy an instance of HP Default
Schema and assess if this is compatible
with current policies and procedures
Schema extensions can always be
deployed later.
Yes
•Are iLO rights likely to change for
a directory group of users?
For example, would a group be assigned iLO rights, such as ‘access
Remote Console’, but later have those rights revoked?
Consider: If one user groupis used for provisioning and deploying a
system, but another group is used for operation after deployment,
this could be an instance of rights changing.
Yes
•Are regular scripted iLO
configuration changes a problem? If this is expected to happen frequently schema-based is more
attractive because the changes happen in a single place, the
directory. I the default Schema case, group rights changes are rolled
out (via scripting) to all iLO targets.
•Will more than 5 groups be used
to regulate iLO rights?
If a single group is used to administer all iLOs, this can be
accomplished through either schema-based or default schema, but if
there are multiple groups of iLOs and multiple groups of users
encompassing more than 5 group distributions, it may be more
attractive to use the HP schema extensions.
NOTE:
An administrator may want to disable local user accounts or remove them
entirely after successfully integrating Directory Services with lights-out
processors.
Methods for directory services implementation
Using directory services is one of the best ways to manage multiple lights-out devices. HP offers
flexible directory implementations to suit a variety of needs. The first implementation uses the HP
Default Schema (sometimes referred to as Schema-free method) allows the use of directory services
without altering the schema. The second implementation uses HP Schema extensions to make the
directory the central place for user administration.
13

These two methods accomplish integration with a network’s directory services in the following
manner.
•HP Default Schema method (without HP Schema Extensions). This method allows the iLO to
authenticate a user against groups that already exist in the network’s directory schema. The Default
Schema method is more straightforward, leveraging the existing directory structure for
authentication and avoiding potential issues and complexities associated with modifying the
directory structure and dealing with domain and forest trust relationships.
•HP Extended Schema method. This provides the ultimate flexibility and granularity in creating an
iLO authentication scheme by extending the network directory to include both iLO and Roles
objects.
Table 4 examines the considerations involved in choosing a schema for integration.
Table 4. Pros and cons for each method
Method 1: HP Extended Schema Method 2: HP Default Schema (or Schema-free)
Provides full access control of all
iLO devices from one central
location (the directory).
Directory user accounts can be authenticated without
extending the directory schema and without installing plug-
ins on the management console.
Pros
Administrators use Role objects
within the directory to group users
who require the same access rights
to iLO.
Administrators add users to existing or newly created group
objects within the directory to give them a specific group of
access rights to iLO.
Requires that the directory schema
be extended.
Requires that the distinguished name of group objects and
specific access rights granted to the groups must be
configured on each (every) iLO device that requires access
by directory users.
Cons
Requires that plug-ins provided by
HP are installed on the management
console, so that new object types
can be created and manipulated in
the directory.
Requires ActiveX to be enabled on client systems that are
used to access iLO for maximum flexibility and ease of use.
This method is only supported with Active Directory.
HP default schema method
The HP default schema method, also known as HP schema-free, allows access to iLO and can be
controlled using directories without requiring schema extensions. This is accomplished by using a
login script to get the user’s login credentials (user name and password) and session information from
iLO and combine these into a security cookie. This cookie is then used by iLO to make sure that the
user has access to the pages and resources he or she is trying to use. This feature requires a minimum
iLO firmware version of 1.80 for iLO or 1.10 for iLO 2.
The user authenticates against the directory, but authorization of iLO privileges occurs locally at the
iLO. The iLO device must be configured with one or more security groups, with each group
corresponding to a group in Microsoft Active Directory. Each iLO security group is configured to
allow specific iLO privileges. When a user attempts to login to iLO, the user credentials are presented
to the directory. If the user is authenticated, a list of security groups that have this user as a member is
returned to the iLO device. The iLO looks up the group(s) in its local group database, and, if found,
the privileges associated with the group(s) are established for the user.
The local group database on each iLO device can easily be managed using the iLO group
configuration tools. However, most of the user administration is managed in the directory.
14

If the default schema method is being deployed, it is not necessary to extend the directory schema
with the HP schema extensions. If the directory schema has previously been extended, the default
schema method may also be deployed.
The default schema method of authenticating directory users is supported only with Microsoft Active
Directory. When using this method to authenticate directory user accounts, the Directory Server field
on the Directory Settings page on iLO should be configured with one of the following:
•The DNS name of the domain (domain.com). This setting provides redundancy of directory servers.
•The DNS name of the directory server, or a list of DNS names of all directory servers separated by
a ‘,’comma, or a space, or both.
NOTE:
It is not recommended to specify the IP address of the directory server when
iLO is configured to use the default schema method unless search contexts
are also configured. It will prevent authentication with the username in the
form of domain\username or username@domain. If the IP address is
specified here, the distinguished name of the user must be provided on the
iLO login page or a short name that will resolve to the distinguished name
once the search contexts are applied. See the respective iLO User’s Guide
for more details and information on configuring search contexts.
See the “HP Integrated Lights-Out 1.80 User Guide” section on “maximum login flexibility”. The guide
is referenced in the “For more information” at the end of this paper.If the client and iLO are in
different DNS domains, one of the two might not be able to resolve the directory server name to an IP
address. This will prevent a user from authenticating with a login name of domain\username or
username@domain, the distinguished name of the user will need to be specified on the login screen.
Support for nested groups
With the release of iLO 2, 1.30 Advanced and iLO 1.19 Advanced firmware, iLO now uses Secure
ID when communicating with directory services for authentication, rather than distinguished name.
This means that individual members of a nested group (I.e. a group that is contained within one of the
directory groups that iLO has been configured to authenticate against) can now be authenticated
against the network directory.
Previously, users could only be authenticated if they were a direct member of one of the directory
groups that was designated by iLO.
HP extended schema method
Required Software
To enable directory services using the extended schema method, system administrators must have iLO
firmware version 1.40 or above, the iLO Advanced feature set, and the HP Smart Component
installation software. Table 5 provides links to download the required software
Table 5. Software required to enable directory services using the extended schema
Software Location
iLO firmware
version 1.40 or
above
www.hp.com/servers/ilo
the iLO Advanced
feature set,
www.hp.com/servers/ilo
15

Software Location
HP Smart
Component
installation for
directories support
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lan
g=en&cc=us&prodTypeId=18964&prodSeriesId=1146658&prodNameId=1135772
&swEnvOID=1005&swLang=8&mode=2&taskId=135&swItem=MTX-UNITY-I23896
Note:
The directory integration package runs under Windows only but has general
content applicable to other OS.
This software includes:
•Schema Installer, which extends the existing directory schema.
•Management Snap-in Installer, which provides snap-ins to manage iLO objects in an existing
directory-enabled IT environment.
•Migration Utilities (HPQLOMIG.EXE and HPQLOMGC.EXE), which automate the process of
upgrading the firmware. The utilities also configure the iLO management processors (objects), turn
on directory authentication, and create the iLO objects in the directory.
Extending the directory schema
The schema is a set of rules that define the directory (in terms of tree structure), object types, object
attributes, and relationships. However, the base (or initial) schema does not define all of the objects
that can be stored within the directory. For example, the base schema does not recognize an iLO
management processor as an object and is not aware of its attributes or relationships. Therefore, the
schema must be extended to define the iLO management processor in terms of object classes and
attributes within the schema.
HP recommends that the administrator carefully review the document Integrating HP ProLiant Lights-
Out processors with Microsoft® Active Directory before deploying any iLO management processors
within the directory. This schema works on all directories that are compliant with LDAP version 3.
These integration notes are available in ‘For more information’ section at the end of this paper.
When using Microsoft Active Directory and the HP schema extensions, the administrator must make
changes to the directory server before extending the schema. The schema extensions cannot be
removed after they are installed. Therefore, it is very important that the administrator understands the
changes that will be made before extending the schema. The schema extension tool will require the IP
address or DNS name of the server that owns the schema master role. The administrator must use the
Active Directory Schema Tool to configure that server to allow schema updates.
When deploying iLO to use Microsoft Active Directory with the default schema method, it is not
necessary to install the HP schema extensions as the iLO will use native Active Directory groups.
If the Microsoft Active Directory schema has already been extended with the HP schema, this will not
prevent iLOs that use the default schema method from authenticating. Therefore, some iLO devices
can be configured to use the HP schema, and others can be configured for the default schema.
However, a single iLO device cannot be configured to use both simultaneously.
Roles
Using role-based access allows the administrator to control user access to iLO objects and the rights
and privileges available to them in that role. For example, the administrator might set up a role called
“local admin” and another role called “regional admin.” Someone defined as having the role of
16

“local admin” can access only the rights specified for that role (such as login access and Remote
Console) and only at specified times (such as from 8:00 a.m. to 5:00 p.m.) and locations (such as
from a specific IP address).
Roles can model very complex relationships and it is important to remember that users can be
grouped into one or more roles. An iLO device object in the directory service may have multiple role
objects associated with it. Be aware that a user's total privileges to a device are an accumulation of
privileges from all roles associated with the device. One way to simplify role management is to
associate existing user groups with roles, and then manage the membership of the groups instead of
the membership of the roles.
Finally, any role object that is related to the iLO device should be placed in a partition housed on the
directory server that iLO is referencing. The iLO device will be reading all of the role objects that
manage it; and if iLO has to contact a different server to read the role object, it may result in long
latencies or the possibility that iLO cannot read the role object and therefore deny access to a
legitimate user.
Integrating iLO login into complex network directories
Many large corporate networks may have very sophisticated domain structures, including multiple
domain tree forests. The forest-and-tree model is a structural context for interconnecting multiple
network domains. Trees represent sets of shared domains, while forests are comprised of one or more
domain trees that don’t share a namespace. Forest-and-tree model implementations become necessary
due to:
•Sheer size and complexity of the organizational structure
•Integration of once separate corporate networks into a single network structure
When using either of the directory services authentication methods, it is possible to create scenarios in
which iLO’s user logins fail to authenticate against the directory because of issues with domain and
forest trust relationships. This is exacerbated by the fact that in many cases, this includes extension of
a long-standing schema structure to add iLO user authentication.
When using the default schema method, no new objects are created in the directory structure.
However, iLO does make use of both the user object and the security group objects of which the user
is a member in order to authenticate the user and his privileges against the directory. For
authentication to work properly, there must be existing trust relationships between the domain
containing the user object and the domain(s) containing the security group objects of which the user is
a member. For most directory structures this is not an issue, since domains within a domain tree are
usually created with built-in trust relationships. However, it can become an issue in complex directory
structures consisting of a forest of separate domain trees.
In the extended schema method, the directory structure relationships are more complex. When
installed, iLO schema extensions create two new objects in the Directory schema..
•iLO object
•HPQ Roles object
These new objects interact with the pre-existing user objects when authenticating an iLO user against
the directory. Because these objects were created later, they can end up in different domain trees or
even different forests in the directory schema. In order for login authentication to work in these
situations, all three directory objects – the users, the iLO, and the HPQ Roles – must exist in domain
trees and/or forests that have mutual trust relationships (see Figure 5).
17

Figure 5. Directory implementation
ABCcorp.com ABCHoldings.com
Sales.ABCCorp.com Finance.ABCcorp.com Finance.ABCHoldings.comSales.ABCHoldings.com
Two Way Transitive Trust
Directory Forest with Two Domain Trees
Users Users
iLO
iLO Role
Users
iLO iLO Role
Users
Configuring iLO to access the directory service
The directory server field can be configured with a DNS name or an IP address. The DNS name can
be the DNS name of a single server or the DNS name of a domain. This field can be configured with
multiple IP addresses or DNS names separated with a comma or space.
The directory service may be configured to have a single DNS name that points to multiple TCP/IP
addresses. If the directory service is configured for multi-hosting, HP recommends configuring iLO to
access the directory server using the DNS name rather than an IP address. This configuration allows
iLO to attempt a connection with any address returned in the lookup of the DNS name, which can
provide redundancy. This option may be more desirable than using a DNS name that resolves to a
single IP address.
If the administrator configures the directory server addresses using IP addresses or a single address
DNS name, HP recommends never using the host server of an iLO device as the directory server for
that iLO device. If the server is down, the directory service is down. For example, if the administrator
uses iLO to power off the server, the connection to the directory will be lost. The administrator will be
unable to log in using the directory account and will have to use a local iLO account to power on the
server remotely.
For security, iLO communicates with directory servers using LDAP protocol over an SSL connection.
Therefore, any plan to attach a directory server for iLO User Authentication must include configuration
to support SSL sessions. Microsoft Active Directory servers are by default NOT configured for SSL
sessions and must be changed in order to support iLO User Authentication.
Local versus directory accounts
It is important to remember that local iLO user accounts still exist, even after iLO is configured to use
directory services. HP recommends using the local accounts only if the directory service has not been
configured, if the directory service is unavailable, or if the administrator cannot authenticate to the
18

directory service. To increase security, an administrator using directory accounts may want to disable
local accounts or remove them entirely.
Additional security considerations
In addition to implementing directory services, administrators ensure security by including two-factor
certificates, restricting port access, and protecting SNMP traffic.
Two-factor authentication
Many environments benefit from additional security such as a physical token in addition to user
credentials for access. This security is called two-factor authentication where the two factors are a
password or PIN, and a private key for a digital certificate. As a licensed feature, current iLO
firmware supports two-factor authentication.
Two factor authentication is web based and doesn’t work with SSH and scripting. Additionally, it can
only be used with the web-based interface to iLO, and only with Microsoft Internet Explorer. iLO
employs digital certificates to authenticate users when the Two-Factor Authentication feature is
enforced. Directory users and local iLO users can interoperate with two-factor authentication.
The administrator should obtain the public certificate of the certificate authority (CA) which issues user
certificates in the organization. This certificate must be configured as the trusted CA certificate in iLO.
For local iLO users, the administrator must obtain the public certificate of each user requiring access
to iLO. Use the iLO User Administration page to configure the public certificate for each user and the
View/Modify feature to add the appropriate certificate to each local user account.
For directory users, the administrator should pick the certificate field to be used for authentication. The
certificate field may vary depending on the directory integration method.
Using the Two-Factor Authentication Settings page, the administrator can use the Directory User field
to choose which type of user identification from the certificate is presented to the directory services
(Table 6). These identification types are:
•The distinguished name contained in the certificate's 'Subject' attribute
•The e-mail-like user name in The Subject Alternative Name (SAN) attribute, if there is a SAN
attribute included as part of the certificate.
19

Table 6. Example of distinguished and SAN user names
Authentication
Method
Directory User Field User Identification
distinguished name [email protected],OU=IT,DC=MyCompany,DC=com Default Schema
SAN [email protected]
Use of the SAN will:
•Authenticate against MS Active Directory, since AD has LDAP extensions that can map the SAN to
the correct user.
•Not authenticate against Novell eDirectory by itself.
•Authenticate against Novell if you have configured appropriate search context info. on iLO's
Directory Settings page.
NOTE:
When using the HP extended schema method, HP recommends selecting the
SAN option on the Two-Factor Authentication Settings page. SAN will
always work if the extended schema method is being used. The certificate
subject may not work if the DN is not the same as the subject. The only time
SAN would not work is if the UPN field (inside of the SAN) was not
configured as the user's email address, but it's the standard to populate this
field with the user’s email address.
For more detailed instructions about setting up Two Factor Authentication see the “HP Integrated
Lights-Out 2 User Guide” at;
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf
Restricting access to the Remote Console port
Because Telnet is not an inherently secure protocol, administrators may be reluctant to use its
functionality. The following describes how iLO overcomes this limitation and facilitates secure Telnet
access. The Remote Console port (port 23) allows an authorized user to establish a Remote Console
session with the host server. To provide tighter security, a user with supervisor rights can restrict
access to the Remote Console port and can turn on Remote Console encryption. The following lists
indicate the available options for access to the iLO and iLO 2 Remote Console ports respectively:
iLO Remote Console settings
•The Remote Console port is always disabled. A user trying to access the Remote Console will
always be denied access when this setting is in place. This setting provides the highest security, but
it may not allow adequate management capabilities.
•The Remote Console port is set to “auto-enable.” This setting is the default for the Remote Console
port. This setting disables the port except when iLO senses the Remote Console applet starting. In
that case, iLO automatically enables the Remote Console port and automatically disables it when
the Remote Console session has ended. The iLO device actively refuses any other connection
attempt to port 23 so that the host server will be inaccessible via a standard Telnet application. iLO
maintains exclusive control over the port when using the remote console applet.
•The Remote Console is enabled. An authorized user can access the Remote Console port at any
time. This allows a Telnet connection or a Remote Console applet connection to be made to the
Remote Console port.
20