Chapter 4. Functional comparison 101
Table 4-3 lists the different agents used by IBM Systems Director when managing IBM
Power-based systems. Be aware that other communication types might be used for different
hardware architectures, which is not covered in this book.
Table 4-3 IBM Systems Director agent communication protocol for Power-managed systems
4.4.3 Security consideration when defining users and groups
System administration is an important aspect of daily operations, and security is an inherent
part of most system administration functions. Also, in addition to securing the operating
environment, it is necessary to closely monitor daily system activities.
Remote command execution By default, dsh relies on the
“classic” rsh command for
remote execution.
Unfortunately, rsh provides only
a minimum security level. The
authorization is based on the
.rhosts file stored in the user’s
home directory. The data
exchanged between the
management server and the
nodes is not encrypted.
By default this relies on the
secure shell (ssh). Should the
remote system ssh server not
respond to the request, then the
remote command will try
regular Telnet. Both TCP
(default) and UDP are
supported.
Tip: When accessing an agentless managed system from Systems Director, it is
considered best practice to configure access using a user account other than root. This
way you can limit the functions performed by the user account and enhance the
information provided for audit purposes.
Managed System Communication Type Encryption used
Agentless Simple Network Management
Protocol (SNMP) v1 and v2.
Not encrypted.
Simple Network Management
Protocol (SNMP) v3.
Advanced Encryption Standard
(AES) or Data Encryption
Standard (DES).
Secure Shell (SSH). Encryption algorithm is
negotiated.
Platform Agent Agentless. Supports the communication
protocols and encryption listed
for the agentless managed
systems.
Common Information Model
(CIM).
If configured, using SSL on port
5989.
Common Agent Tivoli Common Agent
Service 6.x.
Encrypted Web Service (SSL).
Other Service Location Protocol
(SLP).
Not encrypted.
Security Topics Cluster System Management IBM Systems Director
102 IBM CSM to IBM Systems Director Transformation Guide
Most environments require that different users manage different system administration duties.
It is necessary to maintain separation of these duties so that no single system management
user can accidentally or maliciously bypass system security.
When using CSM
CSM relies on the traditional AIX user management approach: using a single system
administrator account named root that can perform all privileged system administration tasks
on the system. Reliance on a single user for all system administration tasks is often seen as a
problem in regard to the separation of duties. While a single administrative account is
acceptable in certain environments, many environments require multiple administrators, with
each administrator responsible for different system administration tasks.
In order to share the administration responsibilities with multiple users of the system, the
historical practice was to either share the password of the root user or create another user
with the same UID as the root user. This method of sharing system administration duties
presents security issues, since each administrator has complete system control and there is
no method to limit the operations that an administrator can perform. Since the root user is the
most privileged user, root users can perform unauthorized operations and can also erase any
audits of these activities, making it impossible to track these administrative actions.
As each user logs in to the system, the user supplies the user name of an account and a
password if the account has one. If the password is correct, the user is logged in to that
account and acquires the access rights and privileges of the account. The /etc/passwd and
/etc/security/passwd files maintain user passwords.
CFM can be used to manage user accounts by using symbolic links to add the password and
group files to the CFM repository. User accounts can be replicated to all nodes in the cluster.
The steps required to set this up are shown. If you use indexed password files, you can
distribute the .idx files using the same method of symbolic links, or you could write a .post
script to have CFM run /usr/sbin/mkpasswd after the initial files have been distributed.
You can also keep user accounts on your cluster nodes separate from the accounts defined
on your management server. To accomplish this, you would copy the actual password and
group files into the CFM repository instead of creating symbolic links. This method would
require additional work to define where the master files reside, and copy them to the
management server before running CFM. Identification and authentication are used to
establish a user's identity.
Most environments require that different users manage different system administration duties.
It is necessary to maintain separation of these duties so that no single system management
user can accidentally or maliciously bypass system security, With AIX 6.1 IBM added
additional security improvements with features like Role Based Access Control (RBAC),
Trusted AIX, and Trusted Execution, allowing system administrators to implement the much
needed user seperations.
When using Systems Director
In IBM Systems Director, users and user groups are based on users and groups that are
defined in the configured registry, which is associated with either the IBM Systems Director
Systems Management Guide operating system or Lightweight Directory Access Protocol
(LDAP). IBM Systems Director uses the user and group information for the purpose of
authentication and authorization.
IBM Systems Director does not provide the capability to create, update, or delete users or
groups in a user registry regardless of where the registry resides. To manage users or groups
in the user registry, use instead the appropriate tool associated with the registry in which the
Chapter 4. Functional comparison 103
users or groups are stored. IBM Systems Director does, however, give you the ability to enter
and edit information for each user or group that describes each in the context of IBM Systems
Director.
Access to particular resources or tasks is done by restrictions based on the user ID or user
group membership and the roles that are defined for each user. For a user to access IBM
Systems Director Server, one of the following conditions must exist:
? The user is a member of a user group that is authorized for IBM Systems Director Server.
? The user is a root user on the management server.
Authorization is the process that determines whether an authenticated user or group has the
necessary privileges to access specific resources. With user authorization, IBM Systems
Director users can perform tasks on specific resources by using the IBM Systems Director
web interface. Use IBM Systems Director to configure the authorizations that provide access
to IBM Systems Director tasks and resources. The authentication flow is depicted in
Figure 4-13.
Figure 4-13 Authentication flow
To log in to the IBM Systems Director web interface and manage the resources that are
discovered by IBM Systems Director, you must have a user account that is associated with a
role that has the appropriate authority.
The following steps are required to authorize an IBM Systems Director user to manage
resources (see Figure 4-13 on page 103)
:
1. If the user account that is needed does not already exist, create it on the operating system
of the system that you want to manage or on the Lightweight Directory Access Protocol
(LDAP) server.
2. Log in to IBM Systems Director as an SMAdministrator.
3. Assign an appropriate role to the user account or group to which the user account belongs
and associate it with the resources that you want the account to manage. You can use any
IBM Systems Director 6.2 Server
IBM Systems Director Console
IBM Systems Director Management Services
IBM Systems Director Agent Services
Director Agents for system manageable endpoints
IBM Director
IPC Agent
IBM Director
Common Agent
on LWP/CAS
IBM Director
Platform Agent
Agentless
SSL
User
Registry
Persistance
Database
Web Service
HTTP
IPC
CAS
SLP
CIM
SLP
DCOM
SSH SNMP
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.