User Management in ServerView 6.30

Transcription

1 User Guide - English FUJITSU Software ServerView Suite User Management in ServerView 6.30 Centralized Authentication and role-based Authorization Edition March 2014

2 Comments Suggestions Corrections The User Documentation Department would like to know your opinion of this manual. Your feedback helps us optimize our documentation to suit your individual needs. Feel free to send us your comments by to Certified documentation according to DIN EN ISO 9001:2008 To ensure a consistently high quality standard and user-friendliness, this documentation was created to meet the regulations of a quality management system which complies with the requirements of the standard DIN EN ISO 9001:2008. cognitas. Gesellschaft für Technik-Dokumentation mbh Copyright and Trademarks Copyright 2014 Fujitsu Technology Solutions GmbH. All rights reserved. Delivery subject to availability; right of technical modifications reserved. All hardware and software names used are trademarks of their respective manufacturers.

3 Contents 1 Introduction Authorization and authentication concept Target Groups of this Manual Structure of the manual Changes since the previous manual ServerView Suite link collection Documentation for ServerView Suite Notational Conventions User management and security architecture (overview) Prerequisites Global user management using an LDAP directory service Benefits of using a directory service Supported directory services Using Open DJ or an already existing, configured directory service Common user management for the ServerView Suite and the irmc S2/S3/S Role Based Access Control (RBAC) Users, user roles and privileges RBAC implementation in OpenDJ RBAC combined with an already existing configured directory service Single sign-on (SSO) using a CAS service CAS based SSO architecture Single sign-on from the user s point of view User Management in ServerView

4 3 ServerView user management via an LDAP directory service Configuring directory service access ServerView user management with OpenDJ Predefined users and roles Defining / changing the passwords of the predefined users OpenDJ Directory Manager s password Defining / changing the password of svuser Changing predefined passwords of the predefined users Administrator, Monitor, Operator and UserManager Changing the LDAP ports of OpenDJ Changing the LDAP port numbers on Windows systems Changing the LDAP port numbers on Linux systems Managing users, roles and privileges in OpenDJ Starting ServerView User Management Change your own password for OpenDJ User Management wizard Integrating an irmc S2/S3/S4 into ServerView user management with OpenDJ and SSO Integrating an irmc S2/S3/S4 into ServerView user management with OpenDJ Configuring the irmc S2/S3 web interface for CAS-based single sign-on (SSO) authentication Backing up and restoring OpenDJ data Backing up and restoring OpenDJ data on Windows systems Backing up and restoring OpenDJ data on Linux systems Integrating ServerView user management into Microsoft Active Directory Changing the password of the LDAP bind account LDAP Password Policy Enforcement (LPPE) Managing SSL Certificates on the CMS and managed nodes Managing SSL Certificates (Overview) Managing SSL certificates on the CMS A self-signed certificate is created automatically during setup Creating a CA Certificate Software tools to manage certificates and keys User Management in ServerView

5 4.2.4 Replacing the certificate on the Central Management Station (CMS) Replacing the certificate on a Windows system Replacing the certificate on a Linux system Preparing managed nodes for RBAC and client authentication Transferring <system_name>.scs.pem and <system_name>.scs.xml to the managed node Installing the certificate files on a Windows system Installing the certificate files together with the ServerView agents Installing the certificate files on a Windows system where the ServerView agents are already installed Installing the certificate files on a Linux or VMware system Installing the certificate files together with the ServerView agents Installing the certificate files on a Linux/VMware system where the ServerView agents are already installed Installing the certificate via ServerView Update Manager (on a Windows / Linux / VMware system) Using the ServerView Update Manager to install the CMS certificate on the managed node (overview) Installing the CMS certificate on the managed node Uninstalling the CMS certificate from the managed node Role-based permissions for accessing Operations Manager Privilege categories and related privileges Privilege categories (overview) AgentDeploy category AlarmMgr category ArchiveMgr category BackupMgr category Common category ConfigMgr category InvMgr category irmc_mmb category PerfMgr category PowerMon category RackManager category User Management in ServerView

6 RaidMgr category RemDeploy category ReportMgr category SCS category ServerList category UpdMgr category UserMgr category VIOM category Predefined users and roles in OpenDJ Audit logging Audit log storage location Audit log entries Types of audit log entries Header of an audit log entry Structured data of an audit log entry origin element ServerView:env@231 element ServerView:audit@231 element ServerView[.<COMP_NAME>]:msg@231 element ServerView[.<COMP_NAME>]:<operation>@231 element Examples: Entries in the audit log file Appendix 1 - Global irmc S2/S3 user management via an LDAP directory service User management concept for the irmc S2/S Global user management for the irmc S2/S Overview irmc S2/S3 user management via an LDAP directory service (concept) Global irmc S2/S3 user management using roles Organizational unit (OU) SVS Cross-server, global user permissions SVS: Permission profiles are defined via roles SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures Configuration file (XML file) User Management in ServerView

7 Starting SVS_LdapDeployer deploy: Create or modify an LDAP v2 structure delete: Deleting an LDAP v2 structure Typical application scenarios Performing an initial configuration of an LDAP v2 structure Re-generating or expanding an LDAP v2 structure Re-generating an LDAP v2 structure and prompting for and saving authentication data irmc S2/S3 user management via Microsoft Active Directory Configuring irmc S2/S3 LDAP/SSL access at the Active Directory server Assigning user roles to an irmc S2/S3 user irmc S2/S3 user management via Novell edirectory Software components and system requirements Installing Novell edirectory Configuring Novell edirectory Integrating irmc S2/S3 user management in Novell edirectory Assigning an irmc S2/S3 user to a permission group Tips on administering Novell edirectory irmc S2/S3 user management via OpenLDAP Installing OpenLDAP Creating SSL certificates Configuring OpenLDAP Integrating irmc S2/S3 user management in OpenLDAP Tips on OpenLDAP administration Configuring alerting to global irmc S2/S3 users Global alerting Displaying alert roles Assigning irmc S2/S3 users to an alert role SSL copyright Appendix 2 - Global irmc S4 user management via an LDAP directory service User management concept for the irmc S Global user management for the irmc S Overview irmc S4 user management via an LDAP directory service (concept) Global irmc S4 user management using roles User Management in ServerView

8 Organizational unit (OU) SVS Cross-server, global user permissions SVS: Permission profiles are defined via roles SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures Configuration file (XML file) Starting SVS_LdapDeployer deploy: Create or modify an LDAP v2 structure delete: Deleting an LDAPv2 structure Typical application scenarios Performing an initial configuration of an LDAP v2 structure Re-generating or expanding an LDAP v2 structure Re-generating an LDAP v2 structure and prompting for and saving authentication data irmc S4 user management via Microsoft Active Directory Configuring irmc S4 LDAP/SSL access at the Active Directory server Assigning user roles to an irmc S4 user irmc S4 user management via Novell edirectory Software components and system requirements Installing Novell edirectory Configuring Novell edirectory Integrating irmc S4 user management in Novell edirectory Assigning an irmc S4 user to a permission group Tips on administering Novell edirectory irmc S4 user management via OpenLDAP Installing OpenLDAP Creating SSL certificates Configuring OpenLDAP Integrating irmc S4 user management in OpenLDAP Tips on OpenLDAP administration Configuring alerting to global irmc S4 users Global alerting Displaying alert roles Assigning irmc S4 users to an alert role SSL copyright User Management in ServerView

9 1 Introduction This manual describes the authorization and authentication concept on which the global user management and the security architecture of the ServerView Suite and the irmc S2/S3/S4 are based. 1.1 Authorization and authentication concept User management and security architecture of the ServerView Suite and the irmc S2/S3/S3/S4 are based on three fundamental concepts: Global user management using an LDAP directory service Role Based Access Control (RBAC) Single sign-on (SSO) based on a centralized authentication service (CAS) Global user management using an LDAP directory service Users are stored and managed centrally for all related central management stations (CMS) by means of a directory service. The directory service provides all data needed for authentication and authorization. You have the option to use ServerView Operations Manager s own preconfigured directory service (ForgeRock s OpenDJ) or an already operating, configured directory service (e.g. Microsoft Active Directory). Role Based Access Control (RBAC) Role Based Access Control (RBAC) manages access control by defining a set of user roles (security roles). One or more roles are assigned to each user, and one or more user privileges are assigned to each role. RBAC allows you to align your security concept with the structure of your organization by assigning a task-oriented permission profile to each role. RBAC is already implemented in the OpenDJ directory service, which is automatically installed during the installation of ServerView Operations Manager. If you use an already configured directory service such as Active Directory, you have to additionally import the ServerView-specific privileges into it. Subsequently, you can assign the required roles to the users that are supposed to have the associated privileges. User Management in ServerView 9

10 Target Groups of this Manual Single sign-on (SSO) The ServerView Suite provides the single sign-on (SSO) feature for the login to its individual components. The SSO is based on a central authentication service (CAS). SSO means you have to prove your authentication only once. Once your authentication has been successful, you can access all ServerView components without being prompted to log in again at any of them. 1.2 Target Groups of this Manual This manual is intended for system administrators, network administrators and service technicians who already have a basic knowledge of hardware and software. The manual provides an overview of the authorization and authentication concept of the ServerView Suite and describes in detail the steps you have to take to setup ServerView user management or to integrate ServerView user management into the already existing user management of your IT. 10 User Management in ServerView

11 Structure of the manual 1.3 Structure of the manual This manual provides you with information about the following topics: Chapter 2: User management and security architecture (overview) This chapter provides you with an overview of the authorization and authentication concept of the ServerView Suite. Chapter 3: ServerView user management via an LDAP directory service This chapter provides you with information on the following topics: Configuring directory service access. ServerView user management with OpenDJ Integrating ServerView user management into Microsoft Active Directory. Chapter 4: Managing SSL Certificates on the CMS and the managed nodes This chapter provides you with information on the following topics: Managing SSL Certificates (overview). Managing SSL Certificates on the Central Management Station (CMS). Preparing managed nodes for RBAC and client authentication. Chapter 5: Role-based permissions on accessing Operations Manager This chapter provides you with detailed information on the following topics: Privilege categories and related privileges. Predefined users and roles in OpenDJ Chapter 6: Audit logging This chapter provides you with detailed information on CAS-related audit logging, the audit log storage location, and the structure of the audit log entries. User Management in ServerView 11

12 Changes since the previous manual Appendix 1 : irmc S2/S3 user management via an LDAP directory service This chapter provides you with information on the following topics: Global User management concept for the irmc S2/S3. User permissions, permission groups and roles. irmc S2/S3 user management via Microsoft Active Directory, Novell edirectory, OpenLDAP, and OpenDJ. Appendix 2 : irmc S4 user management via an LDAP directory service This chapter provides you with information on the following topics: Global User management concept for the irmc S4. User permissions, permission groups and roles. irmc S4 user management via Microsoft Active Directory, Novell edirectory, OpenLDAP, and OpenDJ. 1.4 Changes since the previous manual This edition of the "User Management in ServerView" manual is valid for the ServerView Operations Manager version 6.30 and replaces the following online manual: ServerView Suite - User Management in ServerView, October 2013 edition. The manual features the following changes and enhancements: A new script has been provided for changing the password of the read-only user account being used for the LDAP queries on Active Directory. This script allows you to change the password without having to restart a Windows service or Linux daemon, see section "Changing the password of the LDAP bind account" on page User Management in ServerView

13 ServerView Suite link collection 1.5 ServerView Suite link collection Via the link collection, Fujitsu Technology Solutions provides you with numerous downloads and further information on the ServerView Suite and PRIMERGY servers. For ServerView Suite, links are offered on the following topics: Forum Service Desk Manuals Product information Security information Software downloads Training I The downloads include the following: Current software versions for the ServerView Suite as well as additional Readme files. Information files and update sets for system software components (BIOS, firmware, drivers, ServerView agents and ServerView update agents) for updating the PRIMERGY servers via ServerView Update Manager or for locally updating individual servers via ServerView Update Manager Express. The current versions of all documentation on the ServerView Suite. You can retrieve the downloads free of charge from the Fujitsu Technology Solutions Web server. For PRIMERGY servers, links are offered on the following topics: Service Desk Manuals Product information Spare parts catalogue User Management in ServerView 13

14 Documentation for ServerView Suite Access to the link collection You can reach the link collection of the ServerView Suite in various ways: 1. Via ServerView Operations Manager. Select Help Links on the start page or on the menu bar. This opens the start page of the ServerView link collection. 2. Via the start page of the online documentation for the ServerView Suite on the Fujitsu Technology Solutions manual server. I You access the start page of the online documentation via the following link: In the selection list on the left, select Industry standard servers. Click the menu item PRIMERGY ServerView Links. This opens the start page of the ServerView link collection. 3. Via the ServerView Suite DVD. In the start window of the ServerView Suite DVD, select the option Select ServerView Software Products. Click Start. This takes you to the page with the software products of the ServerView Suite. On the menu bar select Links. This opens the start page of the ServerView link collection. 1.6 Documentation for ServerView Suite The documentation can be downloaded free of charge from the Internet. You will find the online documentation at under the link x86 Servers. For an overview of the documentation to be found under ServerView Suite as well as the filing structure, see the ServerView Suite sitemap (ServerViewSuite Site Overview). 14 User Management in ServerView

15 Notational Conventions 1.7 Notational Conventions The following notational conventions are used in this manual: V Caution I This symbol points out hazards that can lead to personal injury, loss of data or damage to equipment. This symbol highlights important information and tips. italics fixed font semi-bold fixed font <abc> [Key symbols] Table 1: Notational conventions This symbol refers to a step that you must carry out in order to continue with the procedure. Commands, menu items, names of buttons, options, variables, file names and path names are shown in italics in descriptive text. System outputs are indicated using a fixed font. Commands to be entered via the keyboard are written in a semi-bold fixed font. Angle brackets are used to enclose variables which are to be replaced by actual values. Keys are shown according to their representation on the keyboard. If uppercase letters are to be entered explicitly, then the Shift key is shown, e.g. [SHIFT] - [A] for A. If two keys need to be pressed at the same time, this is shown by placing a hyphen between the two key symbols. References to text or sections of text in this manual are shown with the chapter or section heading and the page on which that chapter or section begins. Screen outputs Please note that the screen output is dependent in part on the system used and therefore some details may not correspond exactly to the output you will see on your system. You may also see system-dependent differences in the menu items available. User Management in ServerView 15

16

17 2 User management and security architecture (overview) The authorization and authentication concept provided by the user management and security architecture of the ServerView Suite is based on three fundamental concepts: "Global user management using an LDAP directory service" on page 20: User names are stored and managed centrally for all related platforms using a directory service. The directory service provides all data needed for authentication and authorization. "Role Based Access Control (RBAC)" on page 23: Role Based Access Control (RBAC) manages user authorization by assigning permissions by means of user roles (security roles). In this case, each role defines a specific, task-oriented permission profile. "Single sign-on (SSO) using a CAS service" on page 26: The various ServerView products have their own Web servers or application servers, which all have to individually determine a user s identify before allowing administrative access. This would require the user to issue repeatedly his or her credentials whenever changing from one product s web pages to the ones of another. With SSO, a user logs in once and is subsequently able to access all systems and services participating at the "SSO domain" without being prompted to log in again at any of them. An "SSO Domain" comprises all systems where authentication is performed using the same CAS service. The following sections provide more detailed information about these concepts. I Interaction between ServerView Operations Manager Ï 5.0 and ServerView Agents < 5.0: ServerView Agents < V5.0 do not support the concepts mentioned above. Nevertheless, you can use ServerView Operations Manager V5.x to perform any operations (including security-relevant operations) for ServerView Agents < V5.0. To enable this, Operations Manager s user/password list must contain valid entries (user/password combinations with the appropriate permissions) for the related managed nodes. The procedure is similar to that used in ServerView Operations Manager < V5.0. Single sign-on is not supported. User Management in ServerView 17

18 Prerequisites 2.1 Prerequisites ServerView Suite user management and security architecture require the following software: JBoss Web server As of version 5.0, ServerView Operations Manager uses the JBoss Web server. The required files are installed automatically together with the ServerView Operations Manager software. JBoss is configured as an independent service referred to as ServerView JBoss Applications Server 7. You can start / stop the service as follows: On Windows Server 2008/2012 systems: Select Administrative Tools - Services I On all Windows systems, you can alternatively use the following CLI commands for starting and stopping the JBoss service: "%WINDIR%\system32\net.exe" start "ServerView JBoss Application Server 7" "%WINDIR%\system32\net.exe" stop "ServerView JBoss Application Server 7" On Linux systems, use the following command: /etc/init.d/sv_jboss start stop LDAP directory service During installation of ServerView Operations Manager, you can select whether you want to use ServerView Operations Manager s internally used OpenDJ directory service or an already existing directory service (e.g. Microsoft Active Directory). 18 User Management in ServerView

19 Prerequisites Centralized Authentication Service (CAS) The CAS service is needed for the single sign-on (SSO) feature. The CAS service caches user credentials on the server side and subsequently authenticates users invisibly when they request for different services. CAS is installed automatically along with the ServerView Operations Manager software. For details on how to install the ServerView Operations Manager, which includes the components mentioned above, please refer to the manuals "ServerView Operations Manager - Installation under Windows" and "ServerView Operations Manager - Installation under Linux". User Management in ServerView 19

20 Global user management using an LDAP directory service 2.2 Global user management using an LDAP directory service The global user management of the ServerView Suite and of the irmc S2/S3/S4 each centrally stores users for all Central Management Stations (CMS) / irmc S2/S3/S4 in the directory of an LDAP directory service. This enables you to manage the users on a central server. The users can therefore be used by all the CMS and irmc S2/S3/S4 that are connected to this server in the network. I Important note: Performing integrated user management based on a common directory service only works for both ServerView users and global irmc S2/S3/S4 users if the irmc S2/S3/S4 is configured to belong to the DEFAULT department. I Throughout this manual, the term "user management of the irmc S2/S3/S4" is used in the sense of "global" irmc S2/S3/S4 user management. Besides, the irmc S2/S3/S4 supports "local" user management, which stores the related user IDs locally in the irmc S2/S3/S4 s non-volatile storage and manages them via the irmc S2/S3/S4 user interfaces (see the "irmc S2/S3 - integrated Remote Management Controller" and the "irmc S4 - integrated Remote Management Controller" manuals for details) Benefits of using a directory service The use of a directory service offers the following benefits: A directory service manages real user identities thus making it possible to use personal identities instead of unspecific local accounts. A directory service uncouples user management from server management. Thus, a server administrator cannot change user rights unless he or she has the right to modify directory service data. ServerView uses the directory service for both authentication and authorization of a user: Authentication validates a user s identity: "Who are you?" Authorization defines a user s rights: "What are you allowed to do?" 20 User Management in ServerView

21 Global user management using an LDAP directory service Furthermore, using a directory service for the CMS allows you to use the same user identifications for logins on the CMS and on the managed servers Supported directory services Directory services supported by the ServerView Suite: The ServerView Suite currently supports the following directory services: OpenDJ (running in "embedded" mode on JBoss). Microsoft Active Directory I During the installation of ServerView Operations Manager you have the option to choose ServerView's internal directory service (OpenDJ). Directory services supported by the irmc S2/S3/S4: The irmc S2/S3/S4 currently supports the following directory services: Microsoft Active Directory Novell edirectory OpenLDAP OpenDJ (running in "embedded" mode on JBoss) Using Open DJ or an already existing, configured directory service Using OpenDJ If you do not specify a separate directory service during the installation of Operations Manager, the setup installs ForgeRock's OpenDJ as its own directory service. The service runs in "embedded" mode on JBoss. Thus, OpenDJ is only available if the service ServerView JBoss Application Server 7 is running. Using an already existing, configured directory service If a directory service (e.g. Microsoft Active Directory) has already been established for the user management in your IT environment, you can use it instead of ServerView's own OpenDJ. User Management in ServerView 21

22 Global user management using an LDAP directory service Common user management for the ServerView Suite and the irmc S2/S3/S4 Using Active Directory, you can set up a cross-server user management comprising all servers managed by the ServerView Suite as well as the related irmc S2/S3/S4. CMS Login Authentication (SSL) irmc S2/S3/S4... Login Authentication (SSL) Directory service (e.g. Active Directory) Central user identifications ServerView RAID Login Authentication (SSL) Figure 1: Shared use of the global users by various components of the ServerView suite Communications between the individual CMS / irmc S2/S3/S4 /... and the central directory service is performed via the TCP/IP protocol LDAP (Lightweight Directory Access Protocol). LDAP makes it possible to access the directory services used most frequently and most suitable for user management. I For security reasons, it is urgently recommended that communication via LDAP is secured by SSL. Otherwise passwords are transmitted in plain text. 22 User Management in ServerView

23 Role Based Access Control (RBAC) 2.3 Role Based Access Control (RBAC) User management of the ServerView Suite as well as global irmc S2/S3/S4 user management is based on role-based access control (RBAC), which enables you to align your security concept with your organization s structure. RBAC is based on the principle of least privilege. This means that no user should have more privileges than are necessary for using a particular ServerView component or performing a particular ServerView-specific task Users, user roles and privileges RBAC controls the assignment of permissions to users by means of user roles instead of directly assigning the corresponding privileges to users: A set of privileges is assigned to each user role. Each set defines a specific, task-oriented permission profile for activities on the ServerView Suite. One or more roles are assigned to each user. The concept of user roles offers important advantages, including: The individual permissions do not need to be assigned to each user or user group individually. Instead, they are assigned to the user role. It is only necessary to adapt the permissions of the user role if the permission structure changes. Several roles may be assigned to each user. In this case, the permissions for this user are defined by the sum of the permissions of all assigned roles. User Management in ServerView 23

24 Role Based Access Control (RBAC) RBAC implementation in OpenDJ RBAC is already implemented in the OpenDJ directory service that is automatically installed during the installation of Operations Manager. Predefined users and roles By default, OpenDJ provides the predefined user roles Administrator, Monitor, Operator, and UserAdministrator, each of them being dedicated to one of the predefined users Administrator, Monitor, Operator, and UserManager, respectively. You can of course align your security concept with your organization s structure by creating additional users, roles, and role-to-user assignments. In figure 2 is shown the concept of role-based assignment of user permissions with the user names Administrator, Monitor, Operator and UserManager and the corresponding roles Administrator, Monitor, Operator and UserAdministrator. Users Administrator Operator Monitor UserManager Roles Administrator Operator Monitor UserAdministrator Privileges e.g. modify alarm config. e.g. access archive mgr. e.g. access serverlist UserMgmt Figure 2: Example of role-based assignment of user permissions I Strictly speaking, OpenDJ predefines two additional users that are comprehensively authorized and dedicated to special purposes: "cn=directory Manager" (OpenDJ's Directory Manager account) and svuser (used for accessing the directory service by CAS and ServerView's security module). The scope of permissions granted by the predefined user roles increases from Monitor (lowest permission level) through Operator up to Administrator (highest permission level). For details, see chapter "Audit logging" on page User Management in ServerView

25 Role Based Access Control (RBAC) I The UserAdministrator role does not match this hierarchy as its only purpose is to provide the privileges allowing for user management with OpenDJ. If an external directory service (e.g. Active Directory) is used for user management in ServerView, the UserAdministrator role is not imported into this directory service. Aligning your security concept with your organization s structure To align your security concept with your organization s structure, the ServerView Suite allows you to conveniently create additional users, roles, and role-to-user assignments by using the User Management link under the Security entry in the SerververView Operations Manager s start page RBAC combined with an already existing configured directory service You can also integrate RBAC user management for the ServerView Suite into your already existing RBAC user management that is based on a configured directory service (e.g. Microsoft Active Directory). See section "Integrating ServerView user management into Microsoft Active Directory" on page 60) for details. User Management in ServerView 25

26 Single sign-on (SSO) using a CAS service 2.4 Single sign-on (SSO) using a CAS service In order to allow users to login to their individual components (e.g. Web services), the ServerView Suite provides the single sign-on (SSO) feature. ServerView implements the SSO mechanism by means of a central authentication service (CAS), which processes the single sign-on procedure in a completely transparent manner from the user s point of view. V Important! Always sign off and close your browser if you have to let your PC unattended! The CAS stores the information on a user s identity in a secure browser cookie (Ticket Granting Cookie, TGC, see page 28), which is deleted when the user explicitly signs off, or when the user closes the browser. An unattended browser session therefore represents a severe security gap. I Requirement for using SSO: The CAS service must be configured for all irmc S2/S3/S4 participating in the SSO domain (see the "irmc S2/S3 - integrated Remote Management Controller" and the "irmc S4 - integrated Remote Management Controller" manual for details). It is absolutely necessary that all systems participating in the SSO domain reference the CMS via the same addressing representation. (An SSO Domain comprises all systems where authentication is performed using the same CAS service.) Thus, for example, if you have installed the ServerView Operations Manager by using the name "my-cms.my-domain", you must specify exactly the same name for configuring the CAS service for an irmc S2/S3/S4. If, instead, you specify only "my-cms" or another IP address of my-cms, SSO will not be enabled between the two systems. 26 User Management in ServerView

27 Single sign-on (SSO) using a CAS service CAS based SSO architecture An SSO architecture is based on the following components and items: CAS service providing the centralized authentication service CAS client as part of any "casified" ServerView Suite component Service Ticket (ST) Ticket Granting Ticket (TGT) Centralized Authentication Service (CAS service) manages user authentication The CAS service manages the central user authentication. For this purpose, the CAS service mediates between the browser on the management console (client system) and the directory service that manages the users. CAS client intercepts and redirects the service request The CAS client is part of any "casified" ServerView Suite component. It is a filter that intercepts any request to the component in order to validate the user's authentication. The CAS client redirects the request to the CAS service, which subsequently processes user authentication. Service Ticket (ST) and Service Granting Ticket (TGT) After having successfully authenticated the user, the CAS service assigns the so-called Ticket Granting Ticket (TGT) to the user. This is technically achieved by setting a corresponding secure browser cookie. Whenever the CAS client of a ServerView Suite component redirects an HTTPS request to the CAS service, the TGT cookie causes the service to create a request specific Service Ticket (ST) and send it back to the CAS client by an additional request parameter. First, the CAS client validates the ST by a direct call to the CAS service and only then passes the original request to the ServerView Suite component. User Management in ServerView 27

28 Single sign-on (SSO) using a CAS service Ticket Granting Cookie (TGC) Once the Web browser has established an SSO session with the CAS service, the Web browser exposes a secure cookie to the CAS service. This cookie contains a string identifying a Ticket Granting Ticket (TGT), and therefore is referred to as the ticket granting cookie (TGT cookie or TGC). I The TGC will be destroyed when the user logs out of CAS or when he/she closes the browser. The Ticket Granting Ticket Cookie has a lifetime that is set in CAS service's configuration file (pre-configured value: 24 hours). Its maximum duration is 24 hours. This means that a user is logged out after 24 hours at the latest. The maximum duration time cannot be modified on an installed system. How CAS based SSO processes an initial single sign-on (SSO) request In figure 3 is illustrated how CAS based single sign-on (SSO) processes an initial single sign-on authentication. Figure 3: SSO architecture using the CAS service 28 User Management in ServerView

29 Single sign-on (SSO) using a CAS service Explanation: 1. A user calls a ServerView Suite component e.g. the Operations Manager by entering the service s URL at the Management Console. 2. This user request is redirected to the CAS service. 3. The CAS service generates a CAS login window, which is displayed at the management console. The CAS login window prompts the user for the login credentials (user name and password). 4. The user enters his login credentials. 5. The CAS service validates user name and password and redirects the request to the originally requested component. In addition, the CAS service sets the TGT cookie and assigns the user the Service Ticket (ST) and Ticket Granting Ticket (TGT). 6. The CAS client sends the Service Ticket to the CAS service for validation. 7. If validation was successful, the CAS service returns the following information: "Service Ticket is ok.", user name. 8. The web application (ServerView component) answers the original request (see step 1). How CAS based SSO processes subsequent SSO requests Once being successfully authenticated to access a service (e.g. the Operations Manager), the user can call another service (e.g. the irmc S2/S3/S4 Web interface) without being prompted for login credentials. In this case the CAS service performs authentication using the Ticket Granting Cookie (TGC) which has been set during a former login procedure for this user. If the TGC matches a valid ticket-granting ticket (TGT), the CAS service automatically issues a service ticket (ST) each time the Web browser sends a request for a service of the "SSO domain". Thus, the user can access the ServerView Suite component without being prompted for credentials. User Management in ServerView 29

30 Single sign-on (SSO) using a CAS service Single sign-on from the user s point of view SSO means that you have to prove your authentication only once, namely to the CAS service: At your first login to a component of the ServerView Suite (e.g. Operations Manager) the CAS service displays a separate window that prompts you for your credentials (user name and password). Once authentication is successful, you can access all ServerView Suite components and irmc S2/S3/S4 of your SSO domain without being prompted to log in at any of them again. (3) CAS login window (1) (4) CAS service (2) (1a) (5) (5) (5) Operations Mgr. other Web app.... irmc S2/S3/S4 Web GUI (1) A user sends an HTTP Request to a ServerView Suite component (e.g. Operations Manager). (1a) CAS internally redirects the request to the CAS service (transparently for the user). (2) The CAS service displays its login window prompting the user for his login credentials. (3) The user enters his user name / password combination and confirms his settings. (4) The CAS service authenticates the user. (5) Once authentication has been successful, the user is allowed to access any other component without being prompted to login again. Figure 4: Single sign-on procedure from the user s point of view 30 User Management in ServerView

31 3 ServerView user management via an LDAP directory service This chapter provides you with information on the following topics: "Configuring directory service access" on page 31 "ServerView user management with OpenDJ" on page 32 "Integrating ServerView user management into Microsoft Active Directory" on page 60 I Important note: To operate both ServerView user management and irmc S2/S3/S4 global user management within the same Organizational Unit (OU) SVS, irmc S2/S3/S4 user management must only use the DEFAULT department. Alert roles cannot be used in the ServerView Suite, i.e. they are ignored by all ServerView components except the irmc S2/S3/S Configuring directory service access Both centralized authentication and role-based authorization of the ServerView user management are based on data that are managed centrally using an LDAP directory service. The information needed for connecting to an LDAP directory service is requested during Operations Manager setup. If want to modify these settings later on, proceed as follows: On Windows systems, repeat the setup performing an upgrade/modify installation. On Linux systems, execute the following command: /opt/fujitsu/serverviewsuite/svom/serverview/tools/changecomputerdetails.sh User Management in ServerView 31

32 ServerView user management with OpenDJ 3.2 ServerView user management with OpenDJ If you do not specify a separate directory service during the installation of Operations Manager installation, the setup installs ForgeRock's OpenDJ as its own directory service. The service runs in "embedded" mode on JBoss. Thus, OpenDJ is only available if the service ServerView JBoss Application Server 7 is running Predefined users and roles Role Based Access Control (RBAC) is already implemented in the OpenDJ directory service. OpenDJ predefines the user roles Administrator, Monitor, Operator, and UserAdministrator, each of them being dedicated to one of the predefined users Administrator, Operator, Monitor, and UserManager. In addition, OpenDJ predefines two comprehensively authorized users that are dedicated to special purposes. In table 2 on page 33 an overview is given of the user names, passwords and roles that are predefined in OpenDJ. V CAUTION! For better security, it is strongly recommended that you change the predefined passwords as soon as possible. For details on how to change passwords, please refer to the section "Defining / changing the passwords of the predefined users" on page 34. For details on the scope of permissions granted by the individual user roles, see chapter "Role-based permissions for accessing Operations Manager" on page User Management in ServerView

33 ServerView user management with OpenDJ User name Password User role LDAP Distinguished name / Description./. admin cn=directory Manager,cn=Root DNS,cn=config svuser The Password has to be specified during installation of ServerView Operations Manager. This is OpenDJ s Directory Manager account. A root DN (or root user) is generally given full access to all data in the server. In OpenDJ, root users will be allowed to bypass access control evaluation by default. They will have full access to the server configuration and perform most other types of operations. OpenDJ allows the server to be configured with multiple root users. All rights given to root users are assigned through privileges. cn=svuser,ou=users,dc=fujitsu,dc=com This account is used for accessing the directory service by CAS and ServerView's security module. Therefore, you will find the related data in the configuration file <ServerView directory>\jboss\standalone\ svconf\sv-sec-config.xml. Administrator admin Administrator cn=serverview Administrator,ou=users, dc=fujitsu,dc=com Default user for role Administrator. Monitor admin Monitor cn=serverview Monitor,ou=users, dc=fujitsu,dc=com Default user for role Monitor. Operator admin Operator cn=serverview Operator,ou=users, dc=fujitsu,dc=com Default user for role Operator. UserManager admin UserAdministrator cn=serverview UserManager,ou=users, dc=fujitsu,dc=com Table 2: User names, roles and passwords predefined in OpenDJ Default user for role UserAdministrator. User Management in ServerView 33

34 ServerView user management with OpenDJ Defining / changing the passwords of the predefined users I Important note: Do not use the backslash character ("\") within your passwords OpenDJ Directory Manager s password I Please note: The OpenDJ Directory Manager s predefined password is "admin". For security reasons, it is strongly recommended that you change the predefined password. I In the following explanation, the string "new_dm_pw" is a placeholder for the new password. Replace the placeholder with the adequate password you want to use. Changing the OpenDJ Directory Manager s predefined password on Windows systems I Please note: To set up a password containing one or more percent signs (%), you have to double any percent sign when specifying the password in the command line. E.g., you must type hello%%world in the command line for setting up the password hello%world. On Windows systems, proceed as follows to change the predefined password: 1. Open a Windows Command Prompt. 2. Ensure that the environment variables JAVA_HOME and OPENDS_JAVA_HOME are set to the installation directory of the Java Runtime Environment (JRE). If, for example, the JRE is installed under C:\Program Files (x86)\java\jre7, setting the variables is done by entering the following commands: SET JAVA_HOME=C:\Program Files (x86)\java\jre7 SET OPENDS_JAVA_HOME=C:\Program Files (x86)\java\jre7 SET PATH=C:\Program Files (x86)\java\jre7\bin 3. Change directory to <ServerView directory>\opends\bat. 34 User Management in ServerView

35 ServerView user management with OpenDJ 4. Change the OpenDJ Directory Manager's password (here: the predefined password "admin") by entering the following command in one single line: ldappasswordmodify -h localhost -p D "cn=directory Manager" -w admin -a "dn:cn=directory Manager,cn=Root DNs,cn=config" -n "new_dm_pw" -c "admin" 5. Restart the service ServerView JBoss Application Server 7 to activate your password settings. Changing the OpenDJ Directory Manager s predefined password on Linux Systems I Please note: To set up a password containing one or more special characters of the shell, you have to precede ("escape") any special character with a backslash ("\") when specifying the password in the command line. E.g., you must type hello\$world in the command line for setting up the password hello$world. On Linux systems, proceed as follows to change the predefined passwords: 1. Open a command shell. 2. Ensure that the environment variables JAVA_HOME and OPENDS_JAVA_HOME are set to the installation directory of the Java Runtime Environment (JRE). If, for example, the JRE is installed under /usr/java/default, setting the variables is done by entering the following commands: export JAVA_HOME=/usr/java/default export OPENDS_JAVA_HOME=/usr/java/default 3. Change directory to /opt/fujitsu/serverviewsuite/opends/bin. 4. Change the OpenDJ Directory Manager's password by entering the following command in one single line:./ldappasswordmodify -h localhost -p D "cn=directory Manager" -w admin -a "dn:cn=directory Manager,cn=Root DNs,cn=config" -n "new_dm_pw" -c "admin" 5. Restart the ServerView JBoss service to activate your password settings: /etc/init.d/sv_jboss restart User Management in ServerView 35

36 ServerView user management with OpenDJ Defining / changing the password of svuser The administrative user svuser is created in the OpenDJ database during installation of ServerView Operations Manager. I In previous versions, the password of svuser was always installed with the default password admin. Starting with ServerView Operations Manager version 5.50 you may specify the password for user svuser during a dialog based installation. For details on the ServerView Operations Manager setup, please refer to the manuals "Installing ServerView Operations Manager Software under Windows" and "Installing ServerView Operations Manager Software under Linux". I The password for svuser must not be an empty string. Defining / changing the password of svuser on Windows systems You initially define the password of svuser during the ServerView Operations Manager setup: 36 User Management in ServerView

37 ServerView user management with OpenDJ Figure 5: Initially defining the password of svuser (Windows) User Management in ServerView 37

38 ServerView user management with OpenDJ You can change the password of svuser during an upgrade / modify installation of the ServerView Operations Manager: Figure 6: Configuring the password of svuser (Windows) Proceed as follows to change the password of svuser: 1. Select Yes and enter the old password. 2. Click Next to continue. The dialog box shown in figure 5 on page 37 is displayed allowing you to define a new password for svuser. 38 User Management in ServerView

39 ServerView user management with OpenDJ Changing password of svuser on Linux systems You initially configure the password of svuser during the ServerView Operations Manager setup procedure. You may change the password any time by executing the command ChangeComputerDetails.sh. For details on the ServerView Operations Manager setup, please refer to the "Installing ServerView Operations Manager Software under Linux" manual Changing predefined passwords of the predefined users Administrator, Monitor, Operator and UserManager I Please note: The predefined password of the predefined users Administrator, Monitor, Operator and UserManager is "admin". For security reasons, it is strongly recommended that you change the predefined password. The predefined passwords of Administrator, Monitor, Operator and UserManager can be changed by selecting the User Management link in the Operations Manager start window. When clicked by a user with the UserAdministrator role (or a role based on it), UserManagement automatically starts the User Management wizard, which allows you to change all predefined passwords in a single step. I After Operations Manager setup on the CMS has completed successfully, UserManager initially is the only user holding the permissions of the UserAdministrator role. It is therefore recommended as best practice that UserManager changes all predefined passwords in a single step. Please refer to section "Managing users, roles and privileges in OpenDJ" on page 42 for details. User Management in ServerView 39

40 ServerView user management with OpenDJ Changing the LDAP ports of OpenDJ ServerView's OpenDJ is configured to listen on port 1473 (for non-encrypted LDAP connections) and port 1474 (for SSL-encrypted LDAP connections). Normally, you should have no reason to change these port numbers. However, if another application running on your CMS is also listening on one of these ports, you must either change the configuration of this application, or the port configuration of OpenDJ. I In the following explanation, the string "dm_pw" is a placeholder for the password of the OpenDJ Directory Manager. The strings "new_ldap_port" and "new_ldaps_port" are placeholders for the new port numbers of the LDAP port and LDAPS port, respectively Changing the LDAP port numbers on Windows systems On Windows systems, proceed as follows to change the port number: 1. Open a Windows Command Prompt. 2. Ensure that the environment variables JAVA_HOME and OPENDS_JAVA_HOME are set to the installation directory of the Java Runtime Environment (JRE). If, for example, the JRE is installed under C:\Program Files (x86)\java\jre7, setting the variables is done by entering the following commands: SET JAVA_HOME=C:\Program Files (x86)\java\jre7 SET OPENDS_JAVA_HOME=C:\Program Files (x86)\java\jre7 SET PATH=C:\Program Files (x86)\java\jre7\bin 3. Change directory to <ServerView directory>\opends\bat. 4. Change the LDAP port by entering the following command in one single line: dsconfig -D "cn=directory manager" -w dm_pw -n set-connection-handler-prop --handler-name "LDAP Connection Handler" --set listen-port:new_ldap_port 5. Change the LDAPS port by entering the following command in one single line: dsconfig -D "cn=directory manager" -w dm_pw -n set-connection-handler-prop --handler-name "LDAPS Connection Handler" --set listen-port:new_ldap_port 6. Restart the service ServerView JBoss Application Server 7 to activate your LDAP / LDAPS port settings. 40 User Management in ServerView

41 ServerView user management with OpenDJ Changing the LDAP port numbers on Linux systems On Linux systems, proceed as follows to change the port number: 1. Open a command shell. 2. Ensure that the environment variables JAVA_HOME and OPENDS_JAVA_HOME are set to the installation directory of the Java Runtime Environment (JRE). If, for example, the JRE is installed under /usr/java/default, setting the variables is done by entering the following commands: export JAVA_HOME=/usr/java/default export OPENDS_JAVA_HOME=/usr/java/default 3. Change directory to /opt/fujitsu/serverviewsuite/opends/bin. 4. Change the LDAP port by entering the following command in one single line: dsconfig -D "cn=directory manager" -w dm_pw -n set-connection-handler-prop --handler-name "LDAP Connection Handler" --set listen-port:new_ldap_port 5. Change the LDAPS port by entering the following command in one single line:./dsconfig -D "cn=directory manager" -w dm_pw -n set-connection-handler-prop --handler-name "LDAPS Connection Handler" --set listen-port:new_ldaps_port 6. Restart the ServerView JBoss service to activate your LDAP / LDAPS port settings: /etc/init.d/sv_jboss restart User Management in ServerView 41

42 ServerView user management with OpenDJ Managing users, roles and privileges in OpenDJ The ServerView UserManagement wizard allows you to easily perform ServerView user management with OpenDJ. Specifically, the User Management wizard enables you to perform the following tasks: Create, modify, and delete roles. Assign privileges to roles. Create, modify, and delete users. Assign roles to users. I To use the UserManagement wizard you must have been assigned the UserAdministrator role (or a role based on it). Otherwise, you are only allowed to change your own password. 42 User Management in ServerView

43 ServerView user management with OpenDJ Starting ServerView User Management You start ServerView User Management by clicking the User Management link under Security in the Operations Manager start window. Figure 7: ServerView Operations Manager - start window I The User Management link is not shown if during Operations Manager setup a separate directory service (e.g. Active Directory) was specified instead of OpenDJ running in "embedded" mode on JBoss. Depending on whether you have been assigned the privileges granted by the UserAdministrator role, the following applies: If you do not hold the required privileges, the dialog box for changing your own password opens (see page 44). If you hold the required privileges, the User Management wizard is started (see page 45). User Management in ServerView 43

44 ServerView user management with OpenDJ Change your own password for OpenDJ This dialog box allows you to change your own password for OpenDJ. Figure 8: Dialog box for changing you own password for OpenDJ Please insert old password Enter the old password. Please insert new password Enter the new password. Please confirm the new password Reenter the new password for confirmation. OK Enables the new password. Cancel Closes the dialog box without changing the password. 44 User Management in ServerView

45 ServerView user management with OpenDJ User Management wizard The User Management wizard starts with displaying the Role Definition dialog box: Figure 9: User Management wizard - Dialog box "Role Definitions" The User Management wizard consists of four steps. Their sequence is shown in the tree structure on the left. But it is not necessary to work through the steps in this order. Instead, you can also execute each of the three steps Role Definition, User&Password, and Assign Role to User independently of each other. When you have made your settings, the Finish step finally allows you to apply the settings and exit the wizard. The buttons in the bottom right of each step allow you to progress through the wizard: Previous Opens the previous step in the wizard. Next Opens the next step in the wizard. User Management in ServerView 45

46 ServerView user management with OpenDJ Finish Closes the wizard and applies all your settings. I The Finish button is only enabled in the Finish step. Cancel Cancels the wizard without saving your changes. See below for details on the dialog boxes of the User Management wizard. Role Definitions The Role Definitions dialog box allows you to define new roles, delete existing roles, and enable/disable privilege-to-role assignments. The dialog box displays all currently defined roles and related privileges in table form. Figure 10: User Management wizard - Dialog box "Role Definitions" 46 User Management in ServerView

47 ServerView user management with OpenDJ Roles Lists all currently defined roles. The predefined roles Administrator, Monitor, Operator and UserAdministrator are displayed at the top of the list. When you select a role, the related privileges are listed in the Privilege column. ServerView Component Lists all available privilege categories, each of which groups the privileges required for using a specific ServerView component or for performing a specific task. By selecting one ore more categories you can restrict the privileges displayed under Assigned Privilege to those related to the selected categories. I Please refer to section "Privilege categories and related privileges" on page 106 for more detailed information. Assigned Privilege Lists all available privileges. Depending on whether one or more privilege categories are selected under ServerView Component, only the privileges available for the selected categories are visible. You can enable/disable a privilege-to-role assignment by selecting/deselecting the related Assigned option. I The assignment of privileges to the predefined roles Administrator, Monitor, Operator and UserAdministrator is fixed. The corresponding options for the privilege-to-role assignment are deactivated (grayed out). Description of Privilege Gives a short description of the selected privilege. New Clicking New opens the New Role dialog box: Figure 11: User Management wizard - Define a new role User Management in ServerView 47

48 ServerView user management with OpenDJ Name of the role Name of the new role Copy privileges from role Here you can select a previously defined role from a list. In this case, the privileges assigned to the selected role are automatically assigned to the new role. OK Enables the new role and closes the New Role dialog box. The new role is now displayed under Roles. Cancel Cancels the New Role dialog without defining a new role. Delete Deletes the selected role. Reset Resets the currently displayed privilege-to-role assignments to the last stored setting. 48 User Management in ServerView

49 ServerView user management with OpenDJ User and Password The User & Password dialog box lists all user/password combinations currently defined in OpenDJ and allows you to perform the following operations: Define new users. Change passwords of existing users. Delete existing users. Figure 12: User Management wizard - Dialog box "Users & Passwords" I The four predefined users Administrator, Monitor, Operator, and UserManager are displayed at the top of the list and cannot be deleted. However, you can change the passwords of Administrator, Monitor, Operator, and UserManager. At least one unused row with empty input fields for User, Password and Confirm Password is displayed at the bottom of the list allowing you to define new users. User User name User Management in ServerView 49

50 ServerView user management with OpenDJ Password New password Confirm Password Reenter the new password for confirmation. Delete Deletes the related user. Reset Resets the setting of the related user to the last stored setting. 50 User Management in ServerView

51 ServerView user management with OpenDJ Assign Role to User The Assign Role to User dialog box allows you to assign / unassign roles to users. The dialog box displays all defined users and roles in table form. Roles that are assigned to the currently selected user are marked. Figure 13: User Management wizard - Dialog box "Assign Role to User" User Lists all defined users. When you select a user, the roles currently assigned to this user are displayed in the AssignedRoles column with the related Assigned option being selected. I The four predefined users Administrator, Monitor, Operator and UserManager are displayed at the top of the list. The assignment of roles to these users cannot be changed. Assigned Roles Lists all defined roles. Each role is preceded by an Assigned option indicating whether the related role is currently assigned to the selected user (option is selected) or not (option is deselected). You can enable/disable a role-to-user assignment by selecting / deselecting the related Assigned option. User Management in ServerView 51

52 ServerView user management with OpenDJ Privileges Displays the cumulated privileges assigned to the roles that are currently assigned to the selected user. Description of Privilege Gives a short description of the selected privilege. Reset Resets the role-to-user assignments to the last stored setting. Finish The Finish dialog box displays a summary of the steps you have performed in the current User Management session. Clicking Finish will apply your settings and close the wizard. Figure 14: User Management wizard - Dialog box "Finish" 52 User Management in ServerView

53 ServerView user management with OpenDJ Integrating an irmc S2/S3/S4 into ServerView user management with OpenDJ and SSO Configuring an irmc S2/S3/S4 for integration into ServerView user management with OpenDJ as well as for participating in the ServerView Suite SSO domain comprises the following two steps, which you can perform using the irmc S2/S3/S4 web interface: 1. Configure the irmc S2/S3/S4 appropriately for using the OpenDJ directory service that has been installed during ServerView Operations Manager setup. 2. Configure the irmc S2/S3/S4 web interface for CAS-based single sign-on (SSO) authentication within the ServerView Suite. I Important notes: The CAS service must be configured for all irmc S2/S3/S4 participating in the SSO domain (see the "irmc S2/S3 - integrated Remote Management" manual and the "irmc S4 - integrated Remote Management Controller" manual for details). I The following description focuses on the settings required for integrating an irmc S2/S3/S4 into ServerView user management with OpenDJ and for participating in the ServerView Suite SSO domain. For general information on irmc S2/S3/S4 directory service configuration and irmc S2/S3/S4 CAS configuration, see the "irmc S2/S3 - integrated Remote Management Controller" and irmc S4 - integrated Remote Management Controller" manual) Integrating an irmc S2/S3/S4 into ServerView user management with OpenDJ The Directory Service Configuration page of the irmc S2/S3/S4 web interface allows you to configure global irmc S2/S3/S4 user management via the OpenDJ directory service that has been installed during ServerView Operations Manager setup. The required settings are shown in figure 15 and explained below. User Management in ServerView 53

54 ServerView user management with OpenDJ Figure 15: Configuring an irmc S2/S3/S4 for user management with OpenDS/OpenDJ 54 User Management in ServerView

55 ServerView user management with OpenDJ Settings required in the Global Directory Service Configuration group: 1. Select LDAP enabled and LDAP SSL enabled. 2. Under Directory Server Type, select OpenDS and click Apply. 3. Under Primary LDAP Server, make the following settings: LDAP Server: DNS name of the CMS. I You should specify here the same name that you specified when installing the Operations Manager on the CMS. LDAP port: 1473 LDAP SSL port: Under Department Name, specify the default department DEFAULT 5. Under Base DN, enter: dc=fujitsu,dc=com 6. Click Apply to activate your settings. Settings required in the Directory Service Access Configuration group: 1. Under Principal User DN, enter: cn=svuser,ou=users 2. Select Append Base DN to Principal User DN. 3. Select Enhanced User Login and click Apply. 4. Enter the following User Login Search Filter: (uid=%s) 5. Click Test LDAP access to test the status of your LDAP connection, which is subsequently indicated under LDAP status. 6. Click Apply to activate your settings. User Management in ServerView 55

56 ServerView user management with OpenDJ Configuring the irmc S2/S3 web interface for CAS-based single sign-on (SSO) authentication The Centralized Authentication Service (CAS) Configuration page of the irmc S2/S3/S4 web interface allows you to configure the web interface of the related irmc S2/S3/S4 for CAS-based single sign-on (SSO) authentication. The required settings are shown in figure 15: Figure 16: Configuring the irmc S2/S3/S4 for participating in the ServerView Suite SSO domain 56 User Management in ServerView

57 ServerView user management with OpenDJ Make the following settings: 1. Select CAS Enabled. 2. Under CAS Server, enter the DNS name of the CMS. I It is absolutely necessary that all systems participating in the SSO domain reference the Central Management Station (CMS) via the same addressing representation. (An SSO Domain comprises all systems where authentication is performed using the same CAS service.) Thus, for example, if you have installed the ServerView Operations Manager by using the name "my-cms.my-domain", you must specify exactly the same name for configuring the CAS service for an irmc S2/S3/S4. If, instead, you specify only "my-cms" or another IP address of my-cms, SSO will not be enabled between the two systems. 3. Under CAS Login URL and CAS Logout URL, leave the preset values (/cas/login, /cas/logout, /cas/validate) unchanged. 4. Select the Verify SSL Certificate option. I For security reasons, it is strongly recommended that you enable SSL certificate verification. Besides selecting the Verify SSL Certificate option, enabling SSL verification requires the server certificate of the CMS to have been loaded into the truststore of the irmc S2/S3/S4. For how to upload an SSL certificate onto the irmc S2/S3/S4, please see the "irmc S2/S3 - integrated Remote Management Controller" and the "irmc S4 - integrated Remote Management Controller"manual. 5. Under Assign permissions from, select Permissions retrieved via LDAP. 6. Click Apply to activate your settings. User Management in ServerView 57

58 ServerView user management with OpenDJ Backing up and restoring OpenDJ data This section describes how to use the OpenDJ commands backup and restore on the CMS in order to perform the following tasks: Creating a backup of the internal database of the OpenDJ directory server. Restoring the internal database of the OpenDJ directory server from an applicable backup. V CAUTION! When restoring the internal database of the OpenDJ directory server, it is absolutely necessary to use a backup that has been created with the same Operations Manager version as the Operations Manager version currently running on the management station. When changing to a newer Operations Manager version, it is always necessary to create a new backup. Otherwise, important information delivered with the Operations Manager may be destroyed during restoration. I If you have changed any passwords since the backup to be used was created, these changes will be overwritten during restoration Backing up and restoring OpenDJ data on Windows systems To backup the internal database of the OpenDJ directory server, proceed as follows: 1. Stop the service ServerView JBoss Application Server Open a command window in the folder.\serverview Suite\opends\bat. 3. Call: backup.bat -n userroot -d <path to the backup directory> 4. Start the service ServerView JBoss Application Server 7. To restore the internal database of the OpenDJ directory server, proceed as follows: 1. Stop the service ServerView JBoss Application Server Open a command window in the folder.\serverview Suite\opends\bat. 3. Call: <restore.bat -d <path to the backup directory> 4. Start the service ServerView JBoss Application Server User Management in ServerView

59 ServerView user management with OpenDJ Backing up and restoring OpenDJ data on Linux systems To backup the internal database of the OpenDJ directory server, proceed as follows: 1. Stop the JBoss service: /etc/init.d/sv_jboss stop 2. cd /opt/fujitsu/serverviewsuite/opends/bin 3. su svuser 4. Call: sh backup -n userroot -d <path to the backup directory> 5. exit 6. Start the JBoss service: /etc/init.d/sv_jboss start To restore the internal database of the OpenDJ directory server, proceed as follows: 1. Stop the JBoss service: /etc/init.d/sv_jboss stop 2. cd /opt/fujitsu/serverviewsuite/opends/bin 3. su svuser 4. Call: sh restore -d <path to the backup directory> 5. exit 6. Start the JBoss service: /etc/init.d/sv_jboss start User Management in ServerView 59

60 Integrating ServerView user management into Microsoft Active Directory 3.3 Integrating ServerView user management into Microsoft Active Directory I Please note: Configuring the settings for ServerView and irmc S2/S3/S4 user management requires detailed knowledge about Active Directory. Only a person who has adequate knowledge of the Directory Service should perform the operation. Before you can operate the integrated ServerView user management and irmc S2/S3/S4 user management with Microsoft Active Directory, you will have to perform the following preparatory steps: 1. Import the ServerView Suite role definitions (Administrator, Operator, Monitor, see page 32) into Active Directory. 2. Import the irmc S2/S3/S4 role definitions into Active Directory. 3. Assign roles to users. 4. Configure secure LDAP (LDAPS) access to the Active Directory server. These steps are described in detail below. I Prerequisites: The following files are needed for integrating ServerView user management and irmc S2/S3/S4 user management in Active Directory: For ServerView user management: LDIF (Lightweight Directory Interchange Format) file containing the ServerView-specific structures for integration in Active Directory. If, during installation of Operations Manager, you selected Active Directory as the directory service that is to be used, you will find the required LDIF file in the following directory of the CMS on which the Operations Manager is installed: On Windows systems: <ServerView directory>\svcommon\files\svactivedirectory.ldif On Linux systems: /opt/fujitsu/serverviewsuite/svcommon/files/svactivedirectory.ldif 60 User Management in ServerView

61 Integrating ServerView user management into Microsoft Active Directory I For irmc S2/S3/S4 user management: XML configuration file containing the structure information for the SVS structure in XML syntax in Active Directory. The SVS_LdapDeployer (see page 148) generates LDAP structures on the basis of this XML configuration file. The syntax of the configuration file is illustrated in the sample configuration files Generic_Settings.xml and Generic_InitialDeploy.xml that are supplied together with the jar archive SVS_LdapDeployer.jar on ServerView Suite DVD. I Important note: Operating both ServerView user management and irmc S2/S3/S4 global user management within the same Organizational Unit (OU) SVS requires that the irmc S2/S3/S4 is configured to belong to the DEFAULT department. Proceed as follows: 1. Import the ServerView user role definitions. a) Copy the file SVActiveDirectory.ldif into a temporary directory on the Windows system that runs Active Directory. b) Open the Windows command prompt and change to the directory that contains the SVActiveDirectory.ldif file. c) Import the LDIF file using Microsoft s ldifde tool: ldifde -i -e -k -f SVActiveDirectory.ldif I If the ldifde tool is not contained in the PATH variable on your system, you will find it in the directory %WINDIR%\system32. I An already existing LDAP structure is added with new privileges if necessary. However, already existing entries are not affected. The added privileges and roles are displayed in the Active Directory GUI now (see figure 17 on page 62): User Management in ServerView 61

62 Integrating ServerView user management into Microsoft Active Directory Figure 17: Added Privileges and user roles are displayed in the Active directory GUI 2. Import the irmc S2/S3/S4 user role definitions. You use the software tool SVS_LdapDeployer to import the irmc S2/S3/S4 user role definitions into Active Directory. Please refer to section "SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures" on page 148 for details. 62 User Management in ServerView

63 Integrating ServerView user management into Microsoft Active Directory 3. Assign user roles to users and groups. I In the steps described below it is exemplarily assumed that you want to assign the Monitor role to the user "John Baker", who has the user login name "NYBak" in your Active Directory domain "DOMULI01". I The steps described below also apply to assigning roles to irmc S2/S3/S4 users. Please refer to section "Assigning user roles to an irmc S2/S3 user" on page 162 and section "Assigning user roles to an irmc S4 user" on page 241 for details on assigning roles to irmc S2/S3/S4 users. I Please ensure that the LDAP objects containing the account information of the user which you assign roles to are located below the configured User Search Base. (The User Search Base is configured during the setup of the ServerView Operations Manager - for details please look up the corresponding Installation Manual.) I Likewise, if you want to assign a role to a group, please ensure that the LDAP objects of all members of the group are located below the configured User Search Base. a) Select Start - Control Panel - Administrative Tools - Active Directory Users and Computers on the CMS to start the Active Directory GUI. b) In the GUI s tree structure, traverse down the SVS node to the Departments node. Expand the departments CMS and DEFAULT (see figure 18): User Management in ServerView 63

64 Integrating ServerView user management into Microsoft Active Directory Figure 18: The Monitor role is to be assigned to a user (John Baker) 64 User Management in ServerView

65 Integrating ServerView user management into Microsoft Active Directory c) Under SVS - Departments - CMS - AuthRoles, right-click Monitor and select Properties. The Properties Dialog for the Monitor role is displayed: Figure 19: Properties dialog box for the Monitor role d) Select the Members tab and click Add. Figure 20: Properties Dialog for the Monitor - Members tab User Management in ServerView 65

66 Integrating ServerView user management into Microsoft Active Directory The Select Users,... dialog is displayed. Figure 21: Select Users... Dialog e) Click on Advanced.... Figure 22: Selecting the desired user I It might be useful to select the column Login Name in the Search results list, and accelerate the search by restricting the Name by clicking Find Now. 66 User Management in ServerView

67 Integrating ServerView user management into Microsoft Active Directory f) Select the desired user or group and click OK. The user "Baker" is now displayed in the object names list of the superior dialog: Figure 23: Select Users... Dialog: User "Baker" is displayed. g) Click OK. The user "Baker" is now displayed in the Members tab of the Monitor Properties dialog: Figure 24: Properties Dialog for the Monitor - Members tab: User Baker is displayed. h) Repeat steps c to g for the DEFAULT department. User Management in ServerView 67

68 Integrating ServerView user management into Microsoft Active Directory 4. Configure secure LDAP (LDAPS) access to the Active Directory server. The installation procedure of the Operations Manager requires configuring LDAP access to the directory server on which user management is performed. Active Directory provides an unsecured LDAP interface on port 389 by default. You can use this interface for test purposes. However, when setting up a production environment, you are recommended to establish a secure LDAPS interface on your Active Directory server. This requires installing a server certificate on this server. I Please refer to Microsoft's ( related documentation "How to enable LDAP over SSL with a third-party certification authority" for detailed information. Please refer to section "Configuring irmc S2/S3 LDAP/SSL access at the Active Directory server" on page 157 or section "Configuring irmc S4 LDAP/SSL access at the Active Directory server" on page 236 for details on configuring irmc S2/S3/S4 LDAP/SSL access. For test purposes, it is sufficient to install a self-signed certificate on the Active Directory server. This can be done very easily with Microsoft's selfssl.exe tool out of the IIS 6.0 Resource Kit Tools (downloadable under Example: For installing a self signed certificate with a key length of 2048 bits and a validity period of two years on server myserver.mydomain, proceed as follows: Open a Windows Command Prompt and enter the following command: selfssl /T /N:CN=myserver.mydomain /K:2048 /V:730 selfssl.exe displays the following messages: Microsoft (R) SelfSSL Version 1.0 Copyright (C) 2003 Microsoft Corporation. All rights reserved. Do you want to replace the SSL settings for site 1 (Y/N)? 68 User Management in ServerView

69 Integrating ServerView user management into Microsoft Active Directory Enter Y. The message "Failed to build the subject name blob: 0x ", which is subsequently displayed, can be ignored because it refers only to the fact that no IIS is installed. However, Active Directory will use the certificate installed just now when being accessed via ldaps: //myserver.mydomain. User "John Baker" can login to the Operations Manager with the user name NYBak now. Baker can perform all functions permitted by the privileges of the Monitor role Changing the password of the LDAP bind account You can change the password of the LDAP bind account used for accessing an "external" directory service like Active Directory in the same manner as described in section "Defining / changing the password of svuser" on page 36. Alternatively, you can use the batch script SetDSPassword. Using this script has the advantage, that no restart of JBoss is performed. Please note, however, that it takes up to five minutes until the configuration change becomes effective. You should therefore always wait five minutes after changing the password before trying to sign on again. SetDSPassword can be called in Windows or Linux environment: Windows Open the Windows command prompt. Change to the <ServerView directory>\jboss\standalone\bin directory. Type SetDSPassword <new password>. I The password may contain any printable characters, including blanks spaces ( ) and double quotation marks ("). If the password contains blank spaces ( ), double quotation marks ("), commas (,), caret characters (^), or any other special characters, it must be surrounded by double quotation marks, e.g. "Pa\\w^rd". Backslashes (\) are interpreted literally, unless they immediately precede a double quotation mark. User Management in ServerView 69

70 Integrating ServerView user management into Microsoft Active Directory A double quotation mark preceded by a backslash (\") is interpreted as a literal double quotation mark character ("). The caret character (^) is not recognized as an escape character or delimiter if the password is surrounded by double quotation marks. Linux Open a terminal, e.g. xterm or gnome-term. Change to the /opt/fujitsu/serverviewsuite/jboss/standalone/bin directory. Type./SetDSPassword <new password>. I The password may contain any printable characters, including blanks spaces ( ) and double quotation marks ("). If the password contains blank spaces ( ), double quotation marks ("), commas (,), caret characters (^), or any other special characters, it must be surrounded by double quotation marks, e.g. "Pa\\w^rd". Backslashes (\) are interpreted literally, unless they immediately precede a double quotation mark. A double quotation mark preceded by a backslash (\") is interpreted as a literal double quotation mark character ("). The caret character (^) is not recognized as an escape character or delimiter if the password is surrounded by double quotation marks LDAP Password Policy Enforcement (LPPE) When a user tries to authenticate to CAS, a number of special cases (exceptions) may occur: Logon currently not possible Password has expired / has to be reset User account disabled / expired / locked Without LPPE, the normal CAS login flow would consider the above scenarios as errors that will prevent authentication. LPPE enhances the standard CAS login by executing the following steps: 70 User Management in ServerView

71 Integrating ServerView user management into Microsoft Active Directory 1. LPPE intercepts the standard authentication flow by detecting the error codes that are returned as part of the LDAP respond payload. 2. LPPE translates the error codes into much more precise error indications and prompts these error indications within the CAS login flow. This allows the user to take a proper action. The login exceptions currently handled by LPPE are listed in table 3. LDAP error code LDAP error text Indication displayed by CAS 530 not permitted to logon at this time 531 not permitted to logon at this workstation 532 password expired 533 account disabled Displays a message upon authentication that the user cannot presently sign on: You are not permitted to logon at this time. Please try again later. Displays a message upon authentication that the account has been disabled and the user should contact an administrator: You are not permitted to logon at this workstation. Please try again later. Displays a message upon authentication that the account password has expired and optionally provides a link to a self-service password management application: Your password has expired. Please change your password. Displays a message upon authentication that the account has been disabled and the user should contact an administrator: This account has been disabled. Please contact the system administrator to regain access. 701 account expired Displays a message upon authentication that the account has expired: Table 3: LDAP error codes Your account has expired. User Management in ServerView 71

72 Integrating ServerView user management into Microsoft Active Directory LDAP error code LDAP error text Indication displayed by CAS 773 user must reset password 775 user account locked Table 3: LDAP error codes Displays a message upon authentication that the account password must be changed, and optionally provides a link to a self-service password management application: You must change your password. Please change your password. Displays a message upon authentication that the account has been disabled and the user should contact an administrator: This account has been disabled. Please contact the system administrator to regain access. Password expiration Furthermore LPPE detects the expected expiry of a user password. If the password is about to expire, then this is indicated within a configured warning period. CAS displays a message upon authentication that the user password will expire soon: Your password expires today! Please change your password now. or Your password expires tomorrow! Please change your password now. or Your password expires in days. Please change your password now. For detecting the expected password expiry, the CAS reads some LDAP attributes from the configured Active Directory service. For that purpose, the following configuration values are required: Domain DN This is the Distinguished Name of the Active Directory domain. 72 User Management in ServerView

73 Integrating ServerView user management into Microsoft Active Directory Example dc=fujitsu,dc=com Valid Days The value of this property specifies the number of days a password is valid. Note that it defines the default value for the case where no maxpwdage attribute is found in Active Directory. This means that a value configured in Active Directory always overrides the setting here. Example 90 Warning Days The value of this property specifies the number of days a user is warned before the password expiry. Please note that there is no corresponding attribute in Active Directory, which means that this value here is the only definition for the password expiry warning time. Example 30 Password URL (optional) This entry specifies an URL to which the user will be redirected in order to change the password. The landing page of this URL must be provided by the user - ServerView does not provide such a web page. If there is no such page in the user's environment the configuration option should be omitted. This entry is optional; usually passwords are changed in the user management of the Active Directory service. Example User Management in ServerView 73

74

75 4 Managing SSL Certificates on the CMS and managed nodes To communicate with web browsers and managed nodes, the CMS uses a Public Key Infrastructure (PKI) with secure SSL connections. This chapter provides you with information on the following topics: "Managing SSL Certificates (Overview)" on page 76 "Managing SSL certificates on the CMS" on page 79 "Preparing managed nodes for RBAC and client authentication" on page 91 User Management in ServerView 75

76 Managing SSL Certificates (Overview) 4.1 Managing SSL Certificates (Overview) To communicate with web browsers and managed nodes, the CMS uses a Public Key Infrastructure (PKI) with secure SSL connections. The CMS authenticates itself at the Web browser via server authentication Web browsers always use an HTTPS connection (i.e. a secure SSL connection) to communicate with a Central Management Station (CMS). Therefore, the JBoss web server on the CMS needs a certificate (X.509 certificate) to authenticate itself to the web browser via server authentication. The X.509 certificate contains all the information required to identify the JBoss web server plus the public key of the JBoss web server. See section "Managing SSL certificates on the CMS" on page 79 for details. The CMS authenticates itself at the managed node via client authentication A managed node (e.g. PRIMERGY server) on which RBAC functionality is used requires X.509 certificate-based client authentication. Therefore, a CMS has to authenticate itself when connecting to a managed node. Client authentication prevents the managed node from being accessed by a non-trusted CMS or by a non-privileged application running on the CMS. Client authentication prerequisites that the certificate of a trusted CMS has been previously installed on the managed node. See section "Preparing managed nodes for RBAC and client authentication" on page 91 for details. 76 User Management in ServerView

77 Managing SSL Certificates (Overview) SSL public key file and security-interceptor configuration file The following files are generated automatically during the Operations Manager setup: <system_name>.scs.pem Self-signed certificate in PEM format. The PEM file also contains the public key. A CMS uses the <system_name>.scs.pem file for the following purposes: Server authentication to web browsers connecting to the CMS. Client authentication on managed nodes on which RBAC functionality is used. For client authentication, the <system_name>.scs.pem file has to be installed on the managed node. <system_name>.scs.xml Configuration file of the security-interceptor. This file is used internally for RBAC validation calls. To enable RBAC functionality on a managed node, the <system_name>.scs.xml file has to be installed on the managed node. Operations Manager setup installs both files in the following directory of the CMS: <ServerView directory>\svcommon\data\download\pki (on Windows Systems) /opt/fujitsu/serverviewsuite/svcommon/data/download/pki (on Linux Systems) I In the following, the files <system_name>.scs.pem and <system_name>.scs.xml are referred to as certificate files for short. User Management in ServerView 77

78 Managing SSL Certificates (Overview) Managing key pairs - keystore and truststore files The Java-based key-and-certificate management of the JBoss web server uses two files to manage key pairs and certificates: In the keystore file (file name: keystore) the JBoss web server stores its own key pairs and certificates. The truststore file (file name: cacerts) contains all certificates the JBoss web server rates as trustworthy. The keystore and truststore files can be found in the following directory: <ServerView directory>\jboss\standalone\svconf\pki (on Windows Systems) /opt/fujitsu/serverviewsuite/jboss/standalone/svconf/pki (on Linux Systems) I Use the keytool utility to handle the keystore and truststore files (see page 81). 78 User Management in ServerView

79 Managing SSL certificates on the CMS 4.2 Managing SSL certificates on the CMS To communicate with the JBoss web server, web browsers always use an HTTPS connection (i.e. a secure SSL connection). Therefore, the JBoss web server needs a certificate (X.509 certificate) to authenticate itself at the web browser. The X.509 certificate contains all the information required to identify the JBoss web server plus the public key of the JBoss web server A self-signed certificate is created automatically during setup A self-signed certificate in PEM format (<system_name>.scs.pem) is created automatically for the (local) JBoss web server during the Operations Manager setup. The setup installs the <system_name>.scs.pem in the following directory: <ServerView directory>\svcommon\data\download\pki (on Windows Systems) /opt/fujitsu/serverviewsuite/svcommon/data/download/pki (on Linux Systems) I When using a self-signed certificate, you will not be involved with setting up your own certificate authority (CA) or with submitting a Certificate Signing Request (CSR) to an external CA. If an update installation of ServerView Operations Manger is required, (e.g. after the name of the CMS has been changed), the self-signed certificate will be automatically replaced during the update installation. I If the JBoss Web server uses a self-signed certificate: When connecting to the JBoss web server, web browsers will issue a certificate error with suggestions on how to proceed. Due to their straightforward availability, self-signed certificates are ideally suited for test environments. However, to fulfill the high-level safety requirements that are typical for productive server management using the Operations Manager, we recommend you to use a Certificate that is signed by a trusted Certificate Authority (CA Certificate). User Management in ServerView 79

80 Managing SSL certificates on the CMS Creating a CA Certificate Certificates are issued by a central authority, the Certificate Authority (CA), by signing the certificates with the CA s private key once the identity of the organization named in the certificate has been checked. The signature is contained in the certificate and is disclosed at the time of connection setup so that the client can verify the trustworthiness of the certificate. I Please note: If an update installation of ServerView Operations Manger is required (e.g. after the name of the CMS has been changed), the CA certificate will not be automatically replaced during the update installation. Instead you have to replace the certificate by your own (see section "Replacing the certificate on the Central Management Station (CMS)" on page 82). The following steps are required in order to create a CA Certificate: 1. Create a Certificate Signing Request (CSR, here: certrq.pem) e.g. by using the openssl tool: openssl req -new -keyout privkey.pem -out certreq.pem -days Submit the CSR to the CA. The CA returns the signed certificate (Certificate Reply), e.g. in PEM format as certreply.pem, or in DER format as certreply.cer. In the following it is supposed that the certificate has PEM format. If needed, you can convert the certificate from DER format to PEM format by using the following command: openssl x509 -in certreply.cer -inform DER -out certreply.pem -outform PEM I If the certificate shall contain an extended key usage, then it is important that the certificate is signed for the key usages server authentication ( ) and client authentication ( ) because it is used both as server certificate and as client certificate. 3. Store the signed certificate to a file. 4. Verify the signed certificate. 80 User Management in ServerView

81 Managing SSL certificates on the CMS Software tools to manage certificates and keys The following software tools are needed for managing certificates and the associated keys: openssl You can download the openssl tool from the Internet, e.g. from the Shining Light Productions website ( Another recommended alternative is to install the Cygwin environment ( I If you are using the openssl tool from the Shining Light Productions website, you must set the environment variable OPENSSL_CONF to the following value: keytool < path to the OpenSSL installation directory>/bin/openssl.cfg You can download the keytool from the Oracle homepage. As the keytool is installed besides the Java Virtual Machine, the utility can be found by default on the Central Management Station: on Windows systems: e.g. under C:\Program Files (x86)\java\jre7\bin on Linux systems: /usr/java/default/bin User Management in ServerView 81

82 Managing SSL certificates on the CMS Replacing the certificate on the Central Management Station (CMS) This section describes the steps you have to perform to replace a certificate by another one. I Prerequisites: Performing the steps described below requires the following: Required software: openssl, keytool (see page 81). Additionally, the following description assumes that the directory containing the keytool is part of the PATH variable. A signed CA certificate (here: certreply.pem) and a private key (here: privkey.pem) must be available. I After having replaced the certificate on the central management station you also have to replace the certificate on the managed nodes (see page 96 for Windows managed nodes or page 97 for Linux/VMware managed nodes). This ensures that the CMS has the continuing ability to authenticate at the managed nodes. 82 User Management in ServerView

83 Managing SSL certificates on the CMS Replacing the certificate on a Windows system Proceed as follows: 1. Stop the JBoss service (see page 18). 2. Remove the keystore file: a) Open the Windows command prompt. b) Change to the <ServerView directory>\jboss\standalone\svconf\pki directory. c) Delete or rename keystore file. 3. Copy the certificate reply signed by the CA (here: certreply.pem) as well as the CA's own certificate (here: certca.pem) to the current directory (<ServerView directory>\jboss\standalone\svconf\pki). 4. Import the certificate reply together with the CA's own certificate in a new keystore file and export the public key (here: keystore.p12): openssl pkcs12 -export -chain -in certreply.pem -inkey privkey.pem -passout pass:changeit -out keystore.p12 -name svs_cms -CAfile certca.pem -caname "%CANAME%" I Substitute the placeholder %CANAME% by the name of the CA which has signed the certificate signing request. 5. (Re)format the keystore file: keytool -importkeystore -srckeystore keystore.p12 -destkeystore keystore -srcstoretype PKCS12 -srcstorepass changeit -deststorepass changeit -destkeypass changeit -srcalias svs_cms -destalias svs_cms -noprompt -v 6. Import the new certificate into the truststore file. This is most easily performed as follows: a) Start the JBoss service. b) Wait until startup has completed. c) Change to the <ServerView directory>\jboss\standalone\bin directory. User Management in ServerView 83

84 Managing SSL certificates on the CMS d) Open a Windows command prompt and enter the following command(s): java -jar install-cert-gui-svcom_v1.70.jar..\svconf\pki\cacerts changeit <system FQDN>:3170 I If you use a configured external directory service (e.g. Active Directory), you must also enter the following command: java -jar install-cert-gui-svcom_v1.70.jar..\svconf\pki\cacerts changeit <system FQDN>:<port> <system FQDN> Fully Qualified Distinguished Name of the respective external directory service system. <port> LDAP port used by the external directory service (most probably: 636). e) The Java program install-cert-gui-svcom_v1.70.jar will display a panel like the following: Figure 25: Add Security Exception 84 User Management in ServerView

85 Managing SSL certificates on the CMS Using this panel, you can select the certificate from the Certificate Chain that you want to import into the truststore. If there is only one entry, then the certificate is self-signed - there is of course no other choice than to import this one. Otherwise there will be at least two certificates, as in the above example: 1. The server certificate. 2. The certificate of the Certificate Authority (CA) which signed the server certificate. In general, it is recommended to import only the CA certificate. This causes any other server certificate signed by the same CA to automatically be trusted, which is beneficial in most cases. I When you call the Java program, the following message is displayed: testconnection(tm,pontresina.servware.abg.firm.net, 3170): SSLException: java.lang.runtimeexception: Unexpected error: java.security.invalidalgorithmparameterexception: the trustanchors parameter must be non-empty writing to truststore..\svconf\pki\cacerts... This does not indicate an error, but only indicates that the new certificate has not yet been imported into the truststore file. f) Create the keystore.pem file in PEM format. Proceed as follows: Change back to the following directory: <ServerView directory>\jboss\standalone\svconf\pki. Apply the following command: openssl pkcs12 -in keystore.p12 -passin pass:changeit -nodes -out keystore.pem -passout pass: Copy the keystore.pem file to the following directory of the CMS: <ServerView directory>\jboss\standalone\svconf\pki User Management in ServerView 85

86 Managing SSL certificates on the CMS g) Create the file <system_name>.scs.pem in PEM format. Proceed as follows: Apply the following command: openssl pkcs12 -in keystore.p12 -passin pass:changeit - out <system_name>.scs.pem -passout pass: Copy the created certificate <system_name>.scs.pem to the following directory on the CMS: <ServerView directory>\svcommon\data\download\pki For this purpose, apply the following command: COPY <system_name>.scs.pem "<ServerView directory>\svcommon\data\download\pki\ <system_name>.scs.pem" If the ServerView agents are installed on the CMS: Copy the created certificate <system_name>.scs.pem also into the following directory on the Management Station: <ServerView directory>\remote Connector\pki A possibly already existing certificate of the same name will be replaced on the CMS. 7. Restart the JBoss service and the ServerView services to activate your changes. 86 User Management in ServerView

87 Managing SSL certificates on the CMS Replacing the certificate on a Linux system Proceed as follows: 1. Stop the JBoss service (see page 18). 2. Remove the keystore file: a) Open a terminal, e.g. xterm or gnome-term. b) Change to the /opt/fujitsu/serverviewsuite/jboss/standalone/svconf/pki directory. c) Delete or rename the keystore file. 3. Import the certificate reply signed by the CA (here: certreply.pem) together with the CA's own certificate (here: certca.pem) in a new keystore file and export the public key (here: keystore.p12): openssl pkcs12 -export -chain -in certreply.pem -inkey privkey.pem -passout pass:changeit -out keystore.p12 -name "svs_cms" -CAfile certca.pem -caname "%CANAME%" I Substitute the placeholder %CANAME% by the name of the CA which has signed the certificate request. 4. (Re)format the keystore file: keytool -importkeystore -srckeystore keystore.p12 -destkeystore keystore -srcstoretype PKCS12 -srcstorepass changeit -deststorepass changeit -destkeypass changeit -srcalias svs_cms -destalias svs_cms -noprompt -v 5. Import the new certificate into the truststore file. This is most easily performed as follows: a) Start the JBoss service. b) Wait until startup has completed. c) Change to the../../bin directory. User Management in ServerView 87

88 Managing SSL certificates on the CMS d) Open a terminal window and enter the following command(s): java -jar install-cert-gui-svcom_v1.70.jar../conf/pki/cacerts changeit <system FQDN>:3170 I If you use a configured external directory service (e.g. Active Directory), you must also enter the following command: java -jar install-cert-gui-svcom_v1.70.jar../conf/pki/cacerts changeit <system FQDN>:<port> <system FQDN> Fully Qualified Distinguished Name of the respective system. <port> LDAP port used by the external directory service (most probably: 636). e) The Java program install-cert-gui-svcom_v1.70.jar will display a panel like the following: Figure 26: Add Security Exception 88 User Management in ServerView

89 Managing SSL certificates on the CMS Using this panel, you can select the certificate from the Certificate Chain that you want to import into the truststore. If there is only one entry, then the certificate is self-signed - there is of course no other choice than to import this one. Otherwise there will be at least two certificates, as in the above example: 1. The server certificate. 2. The certificate of the Certificate Authority (CA) which signed the server certificate. In general, it is recommended to import only the CA certificate. This causes any other server certificate signed by the same CA to automatically be trusted, which is beneficial in most cases. I When you call the Java program, the following message is displayed: testconnection(tm,pontresina.servware.abg.firm.net, 3170): SSLException: java.lang.runtimeexception: Unexpected error: java.security.invalidalgorithmparameterexception: the trustanchors parameter must be non-empty writing to truststore..\svconf\pki\cacerts... This does not indicate an error, but only indicates that the new certificate has not yet been imported into the truststore file. f) Create the keystore.pem file in PEM format. Proceed as follows: Apply the following command: openssl pkcs12 -in keystore.p12 -passin pass:changeit -nodes -out keystore.pem -passout pass:changeit Open the keystore.pem file with a text editor and delete any text lines except the following: header and footer lines marked with "-----", encrypted data block lines Copy the keystore.pem file to the following directory of the CMS: /opt/fujitsu/serverviewsuite/jboss/standalone/svconf/pki User Management in ServerView 89

90 Managing SSL certificates on the CMS g) The CA certificate must be copied as <system_name>.scs.pem to the following directory of the CMS: /opt/fujitsu/serverviewsuite/svcommon/data/download/pki Proceed as follows: Apply the following command: cp certca.pem /opt/fujitsu/serverviewsuite/svcommon/data/download/pki/ <system_name>.scs.pem 6. Restart the JBoss service to activate your changes. 90 User Management in ServerView

91 Preparing managed nodes for RBAC and client authentication 4.3 Preparing managed nodes for RBAC and client authentication Preparing a managed node for RBAC and client authentication requires the following steps: 1. Transferring the certificate files (<system_name>.scs.pem) and <system_name>.scs.xml) to the managed node. 2. Installing the transferred files on the managed node Transferring <system_name>.scs.pem and <system_name>.scs.xml to the managed node Once the Operations Manager setup on the CMS is completed successfully, you will find the files <system_name>.scs.pem and <system_name>.scs.xml in the following directory of the CMS: <ServerView directory>\svcommon\data\download\pki (on Windows Systems) /opt/fujitsu/serverviewsuite/svcommon/data/download/pki (on Linux Systems) You can transfer the files to the managed node "manually" or, in a more convenient way, download them from the CMS. I Requirement to download the files: A web browser must be available on the managed node. User Management in ServerView 91

92 Preparing managed nodes for RBAC and client authentication To download the files, proceed as follows: 1. Enter the following URL in the browser on the managed node: I Important: The URL must be mandatorily terminated by a slash (/). <system_name> For <system_name> type the DNS name or IP address of the CMS. The following window opens displaying the files that are ready for download: Figure 27: Downloading mycms.scs.pem and mycms.scs.xml from the CMS mycms 2. For each file, right-click the corresponding link and select Save target as... to store the file on the managed node. I Save target as... may store the.pem file as an.html file. In this case, please change the file s suffix from.html to.pem manually to ensure that the file will be used. 92 User Management in ServerView

93 Preparing managed nodes for RBAC and client authentication Installing the certificate files on a Windows system You have the following options of installing the certificate files <system_name>.scs.pem and <system_name>.scs.xml: Initially installing the certificate files together with the ServerView agents. Installing the certificate files on a managed node where the ServerView agents have already been installed (e.g. if it is necessary to replace the initially installed self-signed certificate with a certificate of a trusted CA due to a corresponding replacement on the CMS) Installing the certificate files together with the ServerView agents I In this case, the certificate files must be installed on the managed node before the ServerView Agents are actually installed. The following describes how to install the certificate files on a Windows system. On details on how to install the ServerView agents, refer to the corresponding sections of the "ServerView Agents for Windows" manual. Installing via packed setup Proceed as follows: 1. Copy the packed agents setup file (ServerViewAgents_Win_i386.exe or ServerViewAgents_Win_x64.exe) to a network share or a local directory on the managed node. 2. In the directory containing the setup file: Create a new directory pki (abbreviated for "public key infrastructure"). 3. Transfer the certificate files <system_name>.scs.pem and <system_name>.scs.xml to the new pki directory. You can also transfer multiple certificates for multiple trusted CMS. 4. Run packed setup (see the manual "ServerView Agents for Windows" for details). All certificates in the pki directory are installed into the appropriate location during the setup of the ServerView agents. User Management in ServerView 93

94 Preparing managed nodes for RBAC and client authentication Installing via unpacked setup Proceed as follows: 1. Unpack the packed setup files ServerViewAgents_Win_i386.exe or ServerViewAgents_Win_x64.exe to a network share or a local directory on the managed node. Setup.exe, ServerViewAgents_xxx.msi and other files are created. 2. In the directory containing the setup files: Create a new directory pki (abbreviated for "public key infrastructure"). 3. Transfer the certificate files <system_name>.scs.pem and <system_name>.scs.xml to the new pki directory. You can also transfer multiple certificates for multiple trusted CMS. 4. Run Setup.exe (see the manual "ServerView Agents for Windows" for details). All certificates in the pki directory are installed into the appropriate location during the setup of the ServerView agents. Installing from the ServerView Suite DVD I It is not possible to install the ServerView agents and certificates directly from ServerView Suite DVD. Proceed as follows: 1. Copy the packed or unpacked agent setup files from the ServerView Suite DVD to a network share or a local directory on the managed node. 2. In the directory containing the setup file(s): Create a new directory pki (abbreviated for "public key infrastructure"). 3. Transfer the certificate files <system_name>.scs.pem and <system_name>.scs.xml to the new pki directory. You can also transfer multiple certificates for multiple trusted CMS. 4. Run packed setup (see the manual "ServerView Agents for Windows" for details). All certificates in the pki directory are installed into the appropriate location during the setup of the ServerView agents. 94 User Management in ServerView

95 Preparing managed nodes for RBAC and client authentication Installing the certificate files on a Windows system where the ServerView agents are already installed Proceed as follows: 1. Locate the path (in the following <scspath> for short) of the ServerView Remote Connector Service (SCS) on the managed node. The default path is as follows: For x64 systems: C:\Program Files (x86)\fujitsu\serverview Suite\Remote Connector For i386 systems: C:\Program Files\Fujitsu\ServerView Suite\Remote Connector 2. Transfer the certificate files <system_name>.scs.pem and <system_name>.scs.xml to the SCS certificates folder <scspath>\pki. The new or changed certificates will be reloaded by the SCS within 10 seconds or after a restart of the Remote Connector Service. User Management in ServerView 95

96 Preparing managed nodes for RBAC and client authentication Installing the certificate files on a Linux or VMware system You have the following options of installing the certificate files <system_name>.scs.pem and <system_name>.scs.xml: Initially installing the certificate files together with the ServerView agents. Installing the certificate files on a managed node where the ServerView agent have already been installed (e.g. if it is necessary to replace the initially installed self-signed certificate with a certificate of a trusted CA due to a corresponding replacement on the CMS) Installing the certificate files together with the ServerView agents I In this case, the certificate files should be transferred to the managed node before you enter the shell command that actually starts the installation. I The following describes how to install the certificate files on a Linux/VMware system. On details on how to install the ServerView agents, refer to the corresponding sections of the "ServerView Agents for Linux" manual. Installing from the ServerView Suite DVD 1. Transfer the <system_name>.scs.pem and <system_name>.scs.xml to the /temp directory. 2. Export the environment variable SV_SCS_INSTALL_TRUSTED by entering export SV_SCS_INSTALL_TRUSTED=/tmp 3. Enter the command: sh srvmagtdvd.sh [-R] The certificate files <system_name>.scs.pem and <system_name>.scs.xml are imported. The new or changed certificates will be reloaded by the SCS within 10 seconds or after a restart of the Remote Connector Service. 96 User Management in ServerView

97 Preparing managed nodes for RBAC and client authentication Installing from a directory 1. Transfer the <system_name>.scs.pem and <system_name>.scs.xml to the local directory that contains the modules of the ServerView agents. 2. Enter the command: sh./srvmagt.sh [option] install The certificate files <system_name>.scs.pem and <system_name>.scs.xml are imported. Installing with the rpm command 1. Transfer the <system_name>.scs.pem and <system_name>.scs.xml to a local directory <cert dir>. 2. Export the environment variable SV_SCS_INSTALL_TRUSTED by entering export SV_SCS_INSTALL_TRUSTED=<cert dir> 3. Enter the command: rpm -U ServerViewConnectorService-<scs-version>.i386.rpm The certificate files <system_name>.scs.pem and <system_name>.scs.xml are imported Installing the certificate files on a Linux/VMware system where the ServerView agents are already installed Proceed as follows: 1. Start a terminal (as root). 2. Locate the path (in the following <scspath> for short) of the ServerView Remote Connector Service (SCS) on the managed node. The default path is as follows: /opt/fujitsu/serverviewsuite/scs/pki 3. Transfer the <system_name>.scs.pem and <system_name>.scs.xml files to a local directory. 4. Enter the following command: cp -p <system_name>.scs.pem <system_name>.scs.xml <scspath> The new or changed certificates will be reloaded by the SCS within 10 seconds or after a restart of the Remote Connector Service. User Management in ServerView 97

98 Preparing managed nodes for RBAC and client authentication Installing the certificate via ServerView Update Manager (on a Windows / Linux / VMware system) I Prerequisites: ServerView Update agent and ServerView agents must be as of Version 5.0. For each managed node displayed in the server list, the update mechanism of the ServerView Update Manager allows you to install the CMS certificate on the managed node directly from the server list. As in the case of other update components, the Update Manager offers you the CMS certificate as software available for installation. You can automatically transfer the certificate to a managed node by creating and starting an update job. For this purpose, each certificate file generated for the CMS must be located in the repository that is assigned to the Update Manager (pathname:...\tools\certificates (Windows) and.../tools/certificates (Linux / VMware): At the regular initial configuration of the repository, the configuration wizard of the Update Manager automatically adds the certificates to the repository at the end of the configuration. During an update installation the certificates are automatically added to the repository by executing the corresponding install scripts. I Important! It is only allowed to specify a local repository because the added data is exclusively valid for the respective CMS. 98 User Management in ServerView

99 Preparing managed nodes for RBAC and client authentication Using the ServerView Update Manager to install the CMS certificate on the managed node (overview) You can control the installation of the CMS certificate on the managed node by using the Update Manager main window as described below. For details on the ServerView Update Manager, refer to the "ServerView Update Manager" manual. Server Details tab of the Update Manager main window (before installing the CMS certificate on the managed node) As long as the CMS certificate is not installed on a managed node, "not certified" is displayed for this node under Agent Access in the Server Details tab (see figure 28). I If not both ServerView update agent and ServerView agents on a managed node are as of version 5.0, the string "restricted" or "unrestricted" is displayed for this node under Agent Access in the Server Details tab. Figure 28: Update Manager Main window - Server Details tab (CMS certificate not yet installed) User Management in ServerView 99

100 Preparing managed nodes for RBAC and client authentication Update Details tab of the Update Manager main window (before installing the CMS certificate on the managed node) In the Upgrades view of the Update Details tab, a separate line indicates the option to install the CMS certificate on the selected node (see figure 29). Figure 29: Update Manager Main window - Update Details tab (CMS certificate not yet installed) Now you can create and start a new update job that performs this installation on the managed node. (The update job may optionally comprise additional update components.) For details on how to create an update job, refer to the "ServerView Update Manager" manual. 100 User Management in ServerView

101 Preparing managed nodes for RBAC and client authentication Server Details tab of the Update Manager main window (after successful installation of the CMS certificate on the CMS window) Once the CMS certificate has been successfully installed on the managed node, "certified" is displayed for this node under Agent Access in the Server Details tab (see figure 30). Figure 30: Update Manager Main window - Server Details tab (CMS certificate successfully installed) User Management in ServerView 101

102 Preparing managed nodes for RBAC and client authentication Update Details tab of the Update Manager main window (after successful installation of the CMS certificate on the CMS window) Once the CMS certificate has been successfully installed on the managed node, a separate line in the Installed Updates view of the Update Details tab informs of the successful installation of the CMS certificate on the managed node (see figure 31). Figure 31: Update Manager Main window - Update Details tab (CMS certificate successfully installed) 102 User Management in ServerView

103 Preparing managed nodes for RBAC and client authentication Installing the CMS certificate on the managed node To install the CMS certificate on a managed node, proceed as follows: 1. Open the Update Manager main window (see figure 28). 2. Under All Servers, select the managed node on which you want to install the CMS certificate. 3. In the Upgrades view of the Update Details tab (see figure 29), select the line indicating the option to install the CMS certificate on the selected node. 4. Create and start a new update job that installs the CMS certificate on the managed node Uninstalling the CMS certificate from the managed node To uninstall the CMS certificate from a managed node, proceed as follows: 1. Open the Update Manager main window (see figure 28). 2. Under All Servers, select the managed node from which you want to uninstall the CMS certificate. 3. In the Downgrades view of the Update Details tab, select the line that displays "Uninstall" in the New Version column (see figure 32 on page 104). 4. Create and start a new update job that uninstalls the CMS certificate from the managed node. User Management in ServerView 103

104 Figure 32: Update Manager Main window - Update Details tab (Downgrades view)

105 5 Role-based permissions for accessing Operations Manager Role-Based Access Control (RBAC) manages user authorization by assigning permissions based on user roles (security roles). Each role allows you to define a specific, task-oriented permission profile. The RBAC implementation of the ServerView Suite groups privileges into categories, each of which corresponds to a specific ServerView component. This chapter explains the following: All categories and the related privileges The predefined roles Administrator, Monitor, Operator and UserAdministrator and associated privileges. User Management in ServerView 105

106 Privilege categories and related privileges 5.1 Privilege categories and related privileges The privileges allowing you to use the individual ServerView components or to perform ServerView-specific tasks are grouped into privilege categories (called categories for short). Each category corresponds to a specific ServerView component and comprises all privileges allowing you to use the related ServerView component or perform a component-specific task Privilege categories (overview) The following privilege categories are available in the ServerView suite: Privilege category Related ServerView component / task AgentDeploy Deployment of ServerView agents AlarmMgr Alarm management ArchiveMgr Archive Manager BackupMgr Database backup Common General ServerView Suite-specific privileges ConfigMgr Server Configuration Manager (SCU) and remote Power Management InvMgr Inventory Manager irmc_mmb Baseboard Management Controller and BladeServer-MMB PerfMgr Performance Manager and Threshold Manager PowerMon Power Monitor RackManager Rack Manager RaidMgr RAID Manager RemDeploy Deployment Manager and Installation Manager ReportMgr Only supported for compatibility reasons. SCS ServerView Connector Service ServerList Server List UpdMgr Update Manager UserMgr User Management in OpenDJ VIOM Virtual IO Manager Table 4: Privilege categories and related ServerView components / tasks 106 User Management in ServerView

107 Privilege categories and related privileges AgentDeploy category The PerformAgentDeployment privilege of the AgentDeploy category is required to deploy ServerView agents to managed nodes. Privilege Permission Scope PerformAgentDeployment Deploy SV Agents to nodes. CMS Table 5: Privilege of the AgentDeploy category AlarmMgr category The AlarmMgr category comprises the privileges required for performing the various tasks of the ServerView event management. Privilege Permission Scope AccessAlarmMgr Access the Alarm Monitor. CMS ModifyAlarmConfig Modify alarm settings via the Alarm Configuration link in the Operations Manager s start window. CMS Note: This privilege should only be assigned to a user already holding the AccessServerList privilege. PerformAlarmAcknowledge Acknowledge alarms. All PerformMIBIntegration Integrate new MIBs. Managed node Table 6: Privileges of the AlarmMgr category User Management in ServerView 107

108 Privilege categories and related privileges ArchiveMgr category The ArchiveMgr category comprises the privileges required for accessing Archive Manager and for creating, modifying and deleting archives. Privilege Permission Scope AccessArchiveMgr Access the Archive Manager. CMS ModifyArchives Create, modify and delete archives CMS Table 7: Privileges of the ArchiveMgr category BackupMgr category The BackupMgr category comprises the privileges required for managing backups of the Operations Manager Database. Privilege Permission Scope ModifyBackup Create/delete a backup of the Operations CMS Manager Database. PerformBackupRestore PerformBackupTransfer Table 8: Privileges of the BackupMgr category Restore the Operations Manager Database. Upload/download a backup of the Operations Manager Database CMS CMS 108 User Management in ServerView

109 Privilege categories and related privileges Common category The Common category comprises the privileges required for performing common ServerView Suite-specific tasks. Privilege Permission Scope AccessOnlineDiagnostics Start Online diagnostics on a managed Managed node node. AccessPrimeCollect Start PrimeCollect on a managed node. Managed node AccessRemoteManagement Start remote management tools. All ConfigPKI Modify a keystore or truststore, i.e. import and export certificates. All ModifyCMSSettings Modify local configuration settings on the CMS. ModifyPasswordTable Modify the password table. CMS PerformDownload Download data from the ServerView CMS installation directory onto the CMS PerformLocateToggle Toggle the identity LED Managed node PerformServerErrorAck Acknowledge an error on a server CMS Table 9: Privileges of the Common category All User Management in ServerView 109

110 Privilege categories and related privileges ConfigMgr category The ConfigMgr category comprises the privileges required for accessing and using the Server Configuration Manager as well as the privileges required for the remote power management function of Operations Manager. Privilege Permission Scope AccessServerConfig Access the Server Configuration Manager. All ModifyPowerOnOffSettings Execute shutdown commands and modify shutdown settings. All ModifyServerConfig Table 10: Privileges of the ConfigMgr category Modify Server Configuration of managed nodes by using the Server Configuration manager. All InvMgr category The InvMgr category comprises the privileges required for accessing the Inventory Manager and for creating / modifying / deleting / running DataCollections and Reports. Privilege Permission Scope AccessInvMgr Access the Inventory Manager. CMS ModifyCollections Create, modify and delete DataCollections and related definitions. CMS ModifyDiagnostics ModifyReports View and delete task-related log and export data. Create, modify and delete reports and related definitions. CMS CMS PerformCollections Run DataCollections. CMS PerformReports Run reports. CMS Table 11: Privileges of the InvMgr category 110 User Management in ServerView

111 Privilege categories and related privileges irmc_mmb category The irmc_mmb category comprises the privileges required for accessing and using an irmc S2/S3/S4 / MMB. I Important note: The privileges beginning with the prefix "Ipmi" are based on the permissions specified in the IPMI Specification. Under IPMI, the user configuration is channel-specific. Thus, users can have different privileges depending on whether they are accessing the irmc S2/S3/S4 / MMB via the LAN channel or via the serial channel. Exactly one Ipmi Lan privilege level and one Ipmi Serial privilege level must be specified for each user / role. Privilege Permission Scope CfgConnectionBlade Permission to configure the Connection Managed node Blade. IpmiLanOem IpmiLanOperator IpmiLanUser IpmiSerialOem IpmiSerialOperator IpmiSerialUser irmcsettings RemoteStorage Table 12: Privileges of the irmc_mmb category OEM specific IPMI privilege level OEM on all LAN connections. The OEM level includes the standard IPMI privilege level administrator and additionally allows to execute OEM functions. Standard IPMI privilege level operator on all LAN connections. Standard IPMI privilege level user on all LAN connections. OEM specific IPMI privilege level OEM on all serial connections. The OEM level includes the standard IPMI privilege level administrator and additionally allows to execute OEM functions. Standard IPMI privilege level operator on all serial connections. Standard IPMI privilege level user on all serial connections. Permission to modify the irmc S2/S3/S4 settings (configuration) Permission to use the Remote Storage function of the irmc S2/S3/S4. Managed node Managed node Managed node Managed node Managed node Managed node Managed node Managed node User Management in ServerView 111

112 Privilege categories and related privileges Privilege Permission Scope UserAccounts VideoRedirection Table 12: Privileges of the irmc_mmb category Permission to create, delete or modify user accounts in the local database of the irmc S2/S3/S4 / MMB. Permission to open a video redirection session via irmc S2/S3/S4. Managed node Managed node PerfMgr category The PerfMgr category comprises the privileges required for accessing and using the Performance Manager and the Threshold Manager. Privilege Permission Scope AccessPerformanceMgr Access the Performance Manager. CMS AccessThresholdMgr Access the Threshold Manager. CMS Table 13: Privileges of the PerfMgr category Note: This privilege should only be assigned to a user already holding the AccessServerList privilege PowerMon category The AccessPowerMonitor privilege of the PowerMon category is required for accessing and using the Power Monitor. Privilege Permission Scope AccessPowerMonitor Access the Power Monitor. CMS Table 14: Privilege of the PowerMon category 112 User Management in ServerView

113 Privilege categories and related privileges RackManager category The RackManager category comprises the privileges required for activities relating to rack management. Privilege Permission Scope AccessRack View rack groups (also known as facility All management). AccessUserGroup View user-defined groups. All ModifyRack Edit rack positions; group unassigned All systems into racks. ModifyTask Create new tasks. All ModifyUserGroup Create and modify user-defined groups. All Table 15: Privileges of the RackManager category RaidMgr category The RaidMgr category comprises the privileges required for accessing the RAID Manager and modifying the RAID configuration. Privilege Permission Scope AccessRaidMgr Access the RAID Manager (read access) All ModifyRaidConfig Modify the RAID configuration (read/write access) All Table 16: Privileges of the RaidMgr category User Management in ServerView 113

114 Privilege categories and related privileges RemDeploy category The RemDeploy category comprises the privileges required for performing installation and deployment activities. Privilege Permission Scope AccessDeploymentMgr Access the Installation Manager. CMS AccessDeploymentMgr2 Access the Deployment Manager. CMS ModifyDmNode Create, modify and delete servers; export and import the Deployment Configuration. All ModifyDmSettings PerformDmCreateImage PerformDmDeployImage Modify the Global Settings of the Deployment Manager. Create a cloning image or a snapshot image of a server. Restore a cloning image or a snapshot image to a server. PerformDmInstallServer Install a server. All PerformDmPowerOperations Power a system on/off. All Table 17: Privileges of the RemDeploy category All All All ReportMgr category The ReportMgr category and the related AccessReportMgr privilege are only supported for compatibility reasons. You may therefore ignore it. Privilege Permission Scope AccessReportMgr Access the Report Manager CMS Table 18: Privileges of the ReportMgr category 114 User Management in ServerView

115 Privilege categories and related privileges SCS category The ModifyTrustedHosts privilege of the SCS category is required for modifying trusted hosts settings. Privilege Permission Scope ModifyTrustedHosts Modify trusted hosts settings. Managed node Table 19: Privilege of the SCS category Note: This privilege can only be assigned to a user already holding the ConfigPKI privilege ServerList category The ServerList category comprises the privileges required for accessing the ServerList and performing the related operations. Privilege Permission Scope AccessServerList Access the ServerList (including the implicit permission to access Single System view of all systems). CMS ModifyNode Create, modify and delete servers and groups. CMS PerformArchiveImport Import archives. CMS PerformConnectivityTest Perform a connectivity test. CMS PerformDiscovery Discover nodes (e.g. Servers) and access server browser. CMS PerformExploration Note: This privilege can only be assigned to a user already holding the privileges PerformConnectivityTest and ModifyNode. Start the 'explore' task on nodes. CMS Note: This privilege can only be assigned to a user already holding the ModifyNode privilege. PerformPowerOperations Power on/off; reboot a system. CMS Table 20: Privileges of the ServerList category User Management in ServerView 115

116 Privilege categories and related privileges UpdMgr category The UpdMgr category comprises the privileges required for accessing the ServerView Download Manager / Repository Manager / Update Manager and performing corresponding update management-related tasks. Privilege Permission Scope AccessDownloadMgr Access the Download Manager. CMS AccessRepositoryMgr Access the Repository Manager. CMS AccessUpdateMgr Access the Update Manager. CMS DeleteJob Delete a job. CMS DeleteReleasedJob Delete a released job. CMS ModifyUpdateConfig Access the Update Configuration. CMS PerformCleanUp Cleanup the update agent's data on a managed node. CMS PerformCopyJob Copy a job with Firmware/Software updates. CMS PerformCopyReleasedJob Copy a released job. CMS PerformCreateJob Create a job with Firmware/Software CMS updates. PerformReleaseJob Release a job. CMS Table 21: Privileges of the UpdMgr category 116 User Management in ServerView

117 Privilege categories and related privileges UserMgr category The UserMgr category comprises the privileges required for accessing the User Management wizard and for using it to perform the following tasks: Create, modify, delete users. Define and modify roles. Assign roles to users. Privilege Permission Scope AccessUserMgr Access the User Management wizard. CMS PerformUserMgt Use the User Management wizard to perform user management in OpenDJ. CMS Table 22: Privileges of the UserMgr category VIOM category The AccessVIOM privilege of the VIOM category is required for accessing the ServerView Virtual-IO Manager (VIOM). Privilege Permission Scope AccessVIOM Access VIOM. All Table 23: Privilege of the VIOM category User Management in ServerView 117

118 Predefined users and roles in OpenDJ 5.2 Predefined users and roles in OpenDJ OpenDJ predefines the user roles Administrator, Monitor, Operator and UserAdministrator that are permanently assigned to the predefined users Administrator, Monitor and UserManager respectively. The following table shows which privileges are granted by the predefined roles. Category Privilege Predefined User / Role Administrator / Administrator Operator / Operator Monitor / Monitor UserManager/ UserAdministrator AgentDeploy PerformAgentDeployment X AlarmMgr AccessAlarmMgr X X X - ModifyAlarmConfig X PerformAlarmAcknowledge X X - - PerformMIBIntegration X X - - ArchiveMgr AccessArchiveMgr X X - - ModifyArchives X X - - BackupMgr ModifyBackup X PerformBackupRestore X PerformBackupTransfer X Common AccessOnlineDiagnostics X X - - AccessPrimeCollect X X X - AccessRemoteManagement X X - - ConfigPKI X ModifyCMSSettings X ModifyPasswordTable X PerformDownload X X - - PerformLocateToggle X X - - PerformServerErrorAck X X - - Table 24: Privileges granted by the predefined roles 118 User Management in ServerView

119 Predefined users and roles in OpenDJ Category Privilege Predefined User / Role Administrator / Administrator Operator / Operator Monitor / Monitor UserManager/ UserAdministrator ConfigMgr AccessServerConfig X ModifyPowerOnOffSettings X X - - ModifyServerConfig X InvMgr AccessInvMgr X X - - ModifyCollections X ModifyDiagnostics X X - - ModifyReports X PerformCollections X X - - PerformReports X X - - irmc_mmb CfgConnectionBlade X IpmiLanOem X IpmiLanOperator - X - - IpmiLanUser - - X - IpmiSerialOem X IpmiSerialOperator - X - - IpmiSerialUser - - X - irmcsettings X RemoteStorage X UserAccounts X VideoRedirection X X - - PerfMgr AccessPerformanceMgr X X - - AccessThresholdMgr X X - - PowerMon AccessPowerMonitor X X X - Table 24: Privileges granted by the predefined roles User Management in ServerView 119

120 Predefined users and roles in OpenDJ Category Privilege Predefined User / Role Administrator / Administrator Operator / Operator Monitor / Monitor UserManager/ UserAdministrator RackManager AccessRack X X X - AccessUserGroup X X X - ModifyRack X X - - ModifyTask X ModifyUserGroup X X - - RaidMgr AccessRaidMgr X X X - ModifyRaidConfig X X - - RemDeploy AccessDeploymentMgr X AccessDeploymentMgr2 X X X - ModifyDmNode X X - - ModifyDmSettings X PerformDmCreateImage X X - - PerformDmDeployImage X PerformDmInstallServer X PerformDmPowerOperations X X - - SCS ModifyTrustedHosts X ServerList AccessServerList X X X - ModifyNode X X - - PerformArchiveImport X X - - PerformConnectivityTest X X X - PerformDiscovery X X - - PerformExploration X X - - PerformPowerOperations X X - - Table 24: Privileges granted by the predefined roles 120 User Management in ServerView

121 Predefined users and roles in OpenDJ Category Privilege Predefined User / Role Administrator / Administrator Operator / Operator Monitor / Monitor UserManager/ UserAdministrator UpdMgr AccessDownloadMgr X AccessRepositoryMgr X AccessUpdateMgr X X - - DeleteJob X DeleteReleasedJob X X - - ModifyUpdateConfig X PerformCleanUp X PerformCopyJob X PerformCopyReleasedJob X X - - PerformCreateJob X PerformReleaseJob X UserMgr AccessUserMgr X Perform UserMgt X VIOM AccessVIOM X Table 24: Privileges granted by the predefined roles User Management in ServerView 121

122

123 6 Audit logging Audit logging allows you to assign any action within an IT system to a person who is responsible for it. Unlike error logging, audit logging focuses on recording successful actions. Audit logging is not performed for the purposes of monitoring the system. It enables authorized persons to subsequently evaluate processes in the system (revision). The entries recorded during audit logging are retained long-term. The description of the recording formats must also be retained, together with the audit log, in order to ensure that the entries can still be interpreted correctly after a long period of time. ServerView provides component-specific logging of a user s actions. I Currently, the Central Authentication Service (CAS) is the only ServerView component that creates audit log entries. User Management in ServerView 123

124 Audit log storage location 6.1 Audit log storage location Audit log storage information on Windows systems On Windows systems, the audit log information is written to the Application event log: Figure 33: The ServerView Audit log is part of the Windows Application event log Audit log storage information on Linux systems On Linux systems, the audit log information is written to the UTF-8-encoded audit.log file, which is located in the directory /var/log/fujitsu/serverviewsuite/jboss. A new audit.log file is created daily. The predecessor of the current audit.log file is renamed audit.log.<yyyy-mm-dd>.log, where <YYYY-MM-DD> indicates the respective previous day s date. 124 User Management in ServerView

125 Audit log entries 6.2 Audit log entries Each line in the audit log file represents an audit log entry. The structure of the entries in the audit log file is based on RFC 5424 (Syslog protocol). Each logging entry consists of a header followed by the structured data: The header comprises the list of fields that are present for every entry. The structured data (STRUCTURED-DATA in RFC 5424) describes the logged action in detail. I You will find a detailed description of the syntax elements in RFC For examples of logging entries, see section "Examples: Entries in the audit log file" on page 133). User Management in ServerView 125

126 Audit log entries Types of audit log entries Three types of audit log entries are distinguished: INIT entry The INIT entry is always the first entry of the audit log file and is structured as follows: Header element origin element element Free text following the structured data <operation> entry An <operation> entry refers to an operation <operation> that was executed on the ServerView Component specified by <COMP_Name>. An <operation> entry is structured as follows: Header element Free text following the structured data STOP entry The STOP entry is usually the last entry in the audit log file and is structured as follows: Header element Free text following the structured data I The STOP entry may be missing if the logged component was terminated abnormally. The following sections describe in detail the audit log entry components (header, elements) mentioned above. 126 User Management in ServerView

127 Audit log entries Header of an audit log entry The header comprises the following fields, with every two separated by a space: Field contents <108>1 / <110>1 Description According to RFC 5424, the meaning of these numbers is as follows: <108> 1 results from <(13 * 8) + 4> 1 and specifies in detail: Syslog facility: 13 (log audit) Syslog severity: 4 (warning) Syslog protocol: version 1 <110> 1 results from <(13 * 8) + 6> 1 and specifies in detail: Syslog facility: 13 (log audit) Syslog severity: 6 (informational) Syslog protocol: version 1 Timestamp The timestamp follows the format specified by RFC Computer name Computer name ServerView component Name of the ServerView component. Currently, ServerView.CAS is the only ServerView component writing log entries. - Constant in every line. The process ID is not logged (as per RFC 5424). MsgId Name of the operation in printable format. In the case of Version 3 Server entries, these are operations of the ServerView components. Table 25: Header of an audit log entry Example <110> T09:42: :00 compa1 ServerView.CAS - LOGIN User Management in ServerView 127

128 Audit log entries Structured data of an audit log entry The header of the audit log entry is followed by the structured data describing the event. The structured data is separated from the header by a space. The structured data is made up of a list of elements (SD-ELEMENT in RFC 5424), each of which is enclosed in square brackets ([ ]). Inside the square brackets, each element first contains an element name (SD- NAME in RFC 5424), followed by a list of parameters in the form of key/"value" pairs (SD-PARAM in RFC 5424). Each of the values is enclosed in double quotation marks ("). The sequence of the elements is not specified. The elements and values that are present depend on the event concerned and are described in more detail below. The audit logging entries contain the following elements, where COMP_NAME denotes the respective component name. I The element with the name ServerView.COMP_NAME:audit@231 is contained in every entry. All other elements are optional origin element The origin element is contained in entries with the MsgId INIT. The element name origin and the meaning of its parameters is registered with the Internet Assigned Numbers Authority (IANA) for RFC 5424, and therefore does not have the The origin element contains information as to which product from which vendor has created the logging entry. Parameter software swversion enterpriseid Meaning Product name (always ServerView) and component name (e.g. CAS). Version of the ServerView component at the time the audit logging was created. Private enterprise number registered for a company with IANA. The private enterprise number for Fujitsu Technology Solutions is 231. Table 26: Audit log entry - origin element 128 User Management in ServerView

129 Audit log entries element The element is only contained in logging entries with the Msgid INIT. It contains information on the runtime environment. Parameter javahome javavendor jbossuserdir jbossuserhome jbossusername osname osversion Meaning Java installation directory Java Runtime Environment vendor The JBoss user s current working directory The JBoss user s home directory The JBoss user s account name Operating system name Operating system version Table 27: Audit log entry - ServerView:env@231 element ServerView:audit@231 element The ServerView:audit@231 entry is part of every audit log entry. "231" is the private enterprise number registered for Fujitsu Technology Solutions with the Internet Assigned Numbers Authority (IANA). The suffix "@231" thus identifies the element as a reserved element for Fujitsu Technology Solutions as per RFC Parameter result Meaning Specifies whether the operation was performed successfully. Possible values are: "success": The operation was executed. "failure": The operation failed. Table 28: Audit log entry - ServerView:audit@231 element User Management in ServerView 129

130 Audit log entries element The entry is part of every audit log entry. It contains the ID that corresponds to the message explaining the current operation. <COMP_NAME> denotes the ServerView component issuing the audit log entry. Several messages apply to all ServerView components. In these cases the.<comp_name> part of the name is omitted. "231" is the private enterprise number registered for Fujitsu Technology Solutions with the Internet Assigned Numbers Authority (IANA). The thus identifies the element as a reserved element for Fujitsu Technology Solutions as per RFC Parameter messageid Meaning Message ID corresponding to the message that explains the current operation. Table 29: Audit log entry - ServerView[.<COMP_NAME>]:msg@231 element ServerView[.<COMP_NAME>]:<operation>@231 element This element is specific to ServerView components and is contained once in each audit log entry with the Msgid <operation>. The element describes the details of an operation request. I The precise parameters contained in an element depend on the respective operation and its result. Currently, the only ServerView components supporting audit logging are the Central Authentication Service (COMP_NAME = CAS) and the Security Token Service (COMP_NAME = STS). The following describes the structure of the audit log entries made by the ServerView components CAS and STS. 130 User Management in ServerView

131 Audit log entries ServerView component CAS The following audit log entry is made whenever a user tries to sign on to a ServerView session. MSG-ID = LOGIN SD-ID = ServerView.CAS:login@231 Parameter address user tgt Meaning IP address of the client system. User ID specified with the login operation. CAS Ticket Granting Ticket created with the login operation. Table 30: Audit log entry - parameters of ServerView.CAS:login@231 The following audit log entry is made whenever a user signs out of a ServerView session. MSG-ID = LOGOUT SD-ID = ServerView.CAS:logout@231 Parameter address user tgt Meaning IP address of the client system. User ID specified with the logout operation. CAS Ticket Granting Ticket created with the login operation. Table 31: Audit log entry - parameters of ServerView.CAS:logout@231 User Management in ServerView 131

132 Audit log entries ServerView component STS The following audit log entry is made when an STS client acquires a binary security token containing a CAS Ticket Granting Ticket (TGT). MSG-ID = RST_ISSUE_TGT SD-ID = ServerView.STS:rstIssueTgt@231 Parameter address user tgt Meaning IP address of the client system. User ID specified with Username Token in the RST "issue TGT" request. CAS Ticket Granting Ticket created with the RST operation. Table 32: Audit log entry - parameters of ServerView.STS:rstIssueTgt@231 The following audit log entry is made when an STS client acquires a binary security token containing a CAS Service Ticket (ST). MSG-ID = RST_ISSUE_ST SD-ID = ServerView.STS:rstIssueSt@231 Parameter address tgt st Meaning IP address of the client system. CAS Ticket Granting Ticket specified with the Binary Security Token in the RST request. The CAS Service Ticket created with the RST "issue ST" request. Table 33: Audit log entry - parameters of ServerView.STS:rstIssueSt@231 The following audit log entry is made when an STS client acquires a binary security token containing a CAS Service Ticket (ST). MSG-ID = VALIDATE SD-ID = ServerView.STS:validate@231 Parameter address st user Meaning IP address of the client system. CAS Service Ticket created with the RST "issue ST" request. User ID specified with the Username Token in the RST "issue TGT" request. Table 34: Audit log entry - parameters of ServerView.STS:validate@ User Management in ServerView

133 Audit log entries Examples: Entries in the audit log file The following examples show the audit logging entries of ServerView's Central Authentication Service (CAS). New lines have been added for better readability. INIT entry The following INIT entry contains the elements origin, and plus free text following the structured data: <110> T08:33: :00 pontresina ServerView.CAS - INIT [ServerView:audit@231 result="success"] [ServerView:env@231 javahome="c:\\program Files\\Java\\jre7" javavendor="sun Microsystems Inc." javaversion="1.6.0_26" jbossuserdir="c:\\program Files\\Fujitsu\\ServerView Suite\\jboss\\bin" jbossuserhome="d:\\profiles\\jbossrun" jbossusername="jbossrun" osname="windows XP" osversion="5.1"] [ServerView:msg@231 messageid="logging.syslog.operation.init"] [origin enterpriseid="231" software="serverview.cas" swversion= "SVCOM_V1.50/3.3.2"] Audit started LOGIN entry (unsuccessful login) The following LOGIN entry contains the element ServerView:audit@231 plus free text following the structured data. This entry represents a "warning" entry caused by an unsuccessful login. <108> T08:38: :00 pontresina ServerView.CAS - LOGIN [ServerView.CAS:login@231 address=" "] [ServerView.CAS:msg@231 messageid= "error.authentication.credentials.bad"] [ServerView:audit@231 result="failure"] The credentials you provided cannot be determined to be authentic. User Management in ServerView 133

134 Audit log entries LOGIN entry (successful login) The following LOGIN entry caused by a successful login contains the element ServerView:audit@231 plus free text following the structured data. <110> T08:38: :00 pontresina ServerView.CAS - LOGIN [ServerView.CAS:login@231 address=" " tgt= "TGT-1-VS0g93zTt2dZQ1WX1texuXNEmJKvw21HelXqXIScvMKVi7XOBY-cas" user="administrator"] [ServerView.CAS:msg@231 messageid="screen.success.header"] [ServerView:audit@231 result="success"] Log In Successful LOGOUT entry The following LOGOUT entry contains the element ServerView:audit@231 plus free text following the structured data. <110> T08:38: :00 pontresina ServerView.CAS - LOGOUT [ServerView.CAS:logout@231 address=" " tgt= "TGT-1-VS0g93zTt2dZQ1WX1texuXNEmJKvw21HelXqXIScvMKVi7XOBY-cas" user="administrator"] [ServerView.CAS:msg@231 messageid="screen.logout.header"] [ServerView:audit@231 result="success"] Logout successful STOP entry The following STOP entry contains the element ServerView:audit@231 plus free text following the structured data. <110> T08:39: :00 pontresina ServerView.CAS - STOP [ServerView:audit@231 result="success"] [ServerView:msg@231 messageid"logging.syslog.operation.stop"] Audit terminated 134 User Management in ServerView

135 7 Appendix 1 - Global irmc S2/S3 user management via an LDAP directory service User management for the irmc S2/S3 uses two different types of user identifications: Local user identifications are stored locally in the irmc S2/S3 s nonvolatile storage and are managed via the irmc S2/S3 user interfaces. Global user identifications are stored in the central data store of a directory service and are managed via this directory service s interfaces. The following directory services are currently supported for global irmc S2/S3 user management: Microsoft Active Directory Novell edirectory OpenLDAP ForgeRock s OpenDJ (In conjunction with SeverView, this directory service runs in "embedded" mode on JBoss). This chapter provides information on the following topics: User management concept for the irmc S2/S3 User permissions Global user management on the irmc S2/S3 I For details on the local user management for the irmc S2/S3, please refer to the manual irmc S2/S3 - integrated Remote Management Controller. I In SeverView s OpenDJ running in "embedded" mode on JBoss, the E- Mail settings functionality of the irmc S2/S3 is not supported. User Management in ServerView 135

136 User management concept for the irmc S2/S3 7.1 User management concept for the irmc S2/S3 User management for the irmc S2/S3 permits the parallel administration of local and global user identifications. When validating the authentication data (user name, password) which users enter when logging in to one of the irmc S2/S3 interfaces, irmc S2/S3 proceeds as follows (see also figure 34 on page 137): 1. The irmc S2/S3 compares the user name and password with the locally stored user identifications: If the user is authenticated successfully by irmc S2/S3 (user name and password are valid, then the user can log in. Otherwise, the irmc S2/S3 continues the verification with step The irmc S2/S3 authenticates itself at the directory service via LDAP with a user name and password, determines the user rights by means of an LDAP query and checks whether the user is authorized to work with these at the irmc S2/S User Management in ServerView

137 User management concept for the irmc S2/S3 irmc S2/S3 web interface Login SSH Login Telnet Login Serial interface Login SSL SSH User name, password SSL SSH irmc S2/S3 local user identifications SSL User name, password SSL LDAP login Directory service Global user identifications Figure 34: Login authentication via the irmc S2/S3 I Although optional, the use of SSL for the LDAP connection between the irmc S2/S3 and directory service is recommended. An SSL-secured LDAP connection between irmc S2/S3 and the directory service guarantees secure data exchange, and in particular the secure transfer of the user name and password data. SSL login via the irmc S2/S3 web interface is only required if LDAP is active (LDAP enable option, see the manual irmc S2/S3 - integrated Remote Management Controller). User Management in ServerView 137

138 Global user management for the irmc S2/S3 7.2 Global user management for the irmc S2/S3 The global user IDs for the irmc S2/S3 are managed centrally using an LDAP directory service. The following directory services are currently supported for irmc S2/S3 user management: Microsoft Active Directory Novell edirectory OpenLDAP OpenDS / ForgeRock s OpenDJ This section provides you with information about the following topics: Overview of global user management for the irmc S2/S3 Concept of global user management for the irmc S2/S3 using an LDAP directory service Configuring global irmc S2/S3 user management in the directory service (generating the permissions structures specific to irmc S2/S3 in the directory service). Global irmc S2/S3 user management via Microsoft Active Directory Global irmc S2/S3 user management via Novell edirectory Global irmc S2/S3 user management via OpenLDAP / OpenDS / OpenDJ I Alongside the measures described in this section which you perform in the directory service, global user management also requires you to configure the local LDAP settings at the irmc S2/S3. You may configure the local LDAP settings either at the irmc S2/S3 web interface (see the manual irmc S2/S3 - integrated Remote Management Controller), using the Server Configuration Manager. I Please note: Configuring the settings for global irmc S2/S3 user management requires detailed knowledge about the Directory Service used. Only a person who has adequate knowledge of the Directory Service should perform the operation. 138 User Management in ServerView

139 Global user management for the irmc S2/S Overview The global user IDs for the irmc S2/S3 are stored centrally for all platforms in the directory service's directory. This makes it possible to manage the user identifications on a central server. They can therefore be used by all the irmc S2/S3s that are connected to this server in the network. Furthermore, using a directory service for the irmc S2/S3 makes it possible to use the same user identifications for logins at the irmc S2/S3s as are used for the operating system of the managed servers. I Global user management is currently not supported for the following irmc S2/S3 functions: Login via IPMI-over-LAN Console redirection via SOL irmc 1 Login Authentication irmc 2... Login Authentication Directory service Global user identifications irmc n Login Authentication Figure 35: Shared use of the global user identifications by multiple irmcs Communication between the individual irmc S2/S3s and the central directory service is performed via the TCP/IP protocol LDAP (Lightweight Directory Access Protocol). LDAP makes it possible to access the directory services which are most frequently used and most suitable for user management. Optionally, communication via LDAP can be secured by SSL. User Management in ServerView 139

140 Global user management for the irmc S2/S irmc S2/S3 user management via an LDAP directory service (concept) I The concept of directory service-based, global irmc S2/S3 user management described below applies equally to the directory services Microsoft Active Directory, Novell edirectory, OpenLDAP, and OpenDS / OpenDJ. The figures are based on the example of the Active Directory Users and Computers console in the Microsoft Active Directory user interface. I The following characters are reserved as metacharacters for search strings in LDAP: *, \, &, (, ),,!, =, <, >, ~, : You must therefore not use these characters as components of Relative Distinguished Names (RDN) Global irmc S2/S3 user management using roles Global irmc S2/S3 user management via an LDAP directory server requires no extension to the standard directory server schema. Instead, all the information that is relevant for the irmc S2/S3, including the user permissions (privileges), is provided via additional LDAP groups and organizational units (OUs) which are combined in separate OUs in a domain of the LDAP directory server (see figure 37 on page 143). irmc S2/S3 users obtain their privileges by being assigned a role (user role) declared in the organizational unit (OU) SVS. Assigning permissions with user roles (abbreviated to: roles) Global user management on the irmc S2/S3 (firmware version 3.77 or later) controls the assignment of permissions by means of user roles. In this case, each role defines a specific, task-oriented permission profile for activities on the irmc S2/S3. Several roles can be assigned to each user with the result that the permissions for this user are defined by the sum of the permissions of all the assigned roles. 140 User Management in ServerView

141 Global user management for the irmc S2/S3 figure 36 illustrates the concept of role-based assignment of user permissions with the roles Administrator, Maintenance, Observer and UserKVM. Mr. Miller Ms. Smith Mr. Baker Administrator Maintenance Observer UserKVM User Mgmnt. AVR Rem. Storage irmc Settings irmc Info Figure 36: Role-based assignment of user permissions The concept of user roles offers important advantages, including: The individual permissions do not need to be assigned to each user or user group individually. Instead, they are assigned to the user role. It is only necessary to adapt the permissions of the user role in the event that the permission structure changes. User Management in ServerView 141

142 Global user management for the irmc S2/S Organizational unit (OU) SVS The firmware for the irmc S2 as of firmware version 3.77A and the irmc S3 support LDAP v2 structures that are stored in the OU SVS. LDAP v2 structures are all set for future functional extensions. I An additional OU (irmcgroups), which is supported for compatibility reasons, allows you to perform global user management also on irmc S2s with a firmware version < 3.77 and on irmcs. For detail please refer to the manuals "irmc S2/S3 - integrated Remote Management Controller" edition May 2011 and former editions. "irmc - integrated Remote Management Controller". SVS contains the OUs Declarations, Departments and User Settings: Declarations contains a list of the defined roles and the list of predefined irmc S2/S3 user permissions. Departments contains the groups for the user privileges. User Settings contains details specific to users or user groups such as the mail format (for alerting) and the groups for the user shells. I In the case of Microsoft Active Directory, for example, the entries for the irmc S2/S3 users are located in the standard OU Users. Unlike the standard users, however, irmc S2/S3 users are also members of one or more groups of the OU SVS. I Important note: Operating both ServerView user management and irmc S2/S3 global user management within the same Organizational Unit (OU) SVS requires that the irmc S2/S3 is configured to belong to the DEFAULT department. 142 User Management in ServerView

143 Global user management for the irmc S2/S3 Figure 37: The OU SVS in the domain fwlab.firm.net I As of Version 3.6x of the firmware, the user entries for the irmc S2/S3 can be located at any points below the base domain. Permission groups can also be located at any point within the base domain. User Management in ServerView 143

144 Global user management for the irmc S2/S Cross-server, global user permissions In large enterprises, the servers which are managed via irmc S2/S3 are usually assigned to different departments. Furthermore, the administrator permissions for the managed servers are also often assigned on a departmentspecific basis. I Important note: Operating both ServerView user management and irmc S2/S3 global user management within the same Organizational Unit (OU) SVS requires that the irmc S2/S3 is configured to belong to the DEFAULT department. Departments are combined in the OU Departments The OU Departments combines the servers which are managed by irmc S2/S3 to form a number of groups. These correspond to the departments in which the same user IDs and permissions apply. In figure 38 on page 145, for example, these are the departments DeptX, DeptY and Others. The entry Others is optional, but recommended. Others is a predefined department name subsuming all those servers which do not belong to another department. There are no restrictions concerning the number of departments (OUs) listed under Departments. I When configuring the directory service at the irmc S2/S3 via the irmc S2/S3 web interface (see the manual irmc S2/S3 - integrated Remote Management Controller) or via the Server Configuration Manager you specify the name of the department to which the managed server with the relevant irmc S2/S3 belongs. If there is no department of this name in the LDAP directory, then the permissions present in the Others department are used. figure 38 on page 145 presents an example of this type of organizational structure on the basis of Active Directory Users and Computers. 144 User Management in ServerView

145 Global user management for the irmc S2/S3 Figure 38: Organizational structure of the domain fwlab.firm.net User Management in ServerView 145

146 Global user management for the irmc S2/S SVS: Permission profiles are defined via roles The associated user roles (authorization roles) that are required are listed directly below each department (figure 38 on page 145). All the roles listed here must be defined in the OU Declarations. Otherwise, there are no restrictions concerning the number of roles. The names of the roles can be chosen as required subject to certain syntactic requirements imposed by the employed directory service. Each authorization role defines a specific, task-oriented permission profile for activities on the irmc S2/S3. I The alert roles are listed as well as the authorization roles. Each alert role defines a specific alerting profile for alerting (see section Configuring alerting to global irmc S2/S3 users on page 205). Displaying user roles If you select a department (e.g. DeptX) under SVS in the structure tree for Active Directory Users and Computers (see figure 39) (1) and expand the associated nodes DeptX Authorization Roles, the user roles defined for this department (here: DeptX) are displayed (2). (1) (2) Figure 39: Display of the user roles in the Users and Computers snap-in 146 User Management in ServerView

147 Global user management for the irmc S2/S3 Displaying the Active Directory folders to which a user is member of If you select a user (e.g. kvms4) under Users in the structure tree for Active Directory Users and Computers (see figure 40) (1) and open the Properties dialog box for this user by choosing Properties Members from the context menu, the permission groups to which the user belongs (here: kvms4) are displayed in the Members tab (2). (2) (1) Figure 40: Properties dialog box for the user kvms4 User Management in ServerView 147

148 Global user management for the irmc S2/S SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures To allow global irmc S2/S3 user management to be able to handled using a directory service, the structure(s) (OU) SVS must be created in the LDAP directory service. You use the SVS_LdapDeployer to generate and modify the SVS structures. The SVS_LdapDeployer is a Java archive (SVS_LdapDeployer.jar) provided on your ServerView Suite DVD. This section describes: The configuration file of the SVS_LdapDeployer SVS_LdapDeployer The commands and options of the SVS_LdapDeployer Typical application scenarios Configuration file (XML file) SVS_LdapDeployer generates LDAP structures on the basis of an XML configuration file. This input file contains the structure information for the structure(s) SVS structure in XML syntax. I The syntax of the configuration file is illustrated in the sample configuration files Generic_Settings.xml and Generic_InitialDeploy.xml that are supplied together with the jar archive SVS_LdapDeployer.jar on ServerView Suite DVD. I Valid connection data for the connection to the directory server must always be entered under <Settings> in the input file. You can also optionally enter the authentication data for accessing the server. Alternatively, you can specify the authentication data in the command line of the SVS_LdapDeloyer. If you do not specify the authentication data in the configuration file or in the command line when calling the SVS_LdapDeployer, the SVS_LdapDeployer prompts you to enter the authentication data at runtime. 148 User Management in ServerView

149 Global user management for the irmc S2/S Starting SVS_LdapDeployer Proceed as follows to start the SVS_LdapDeployer: Save the Java archive (jar archive) SVS_LdapDeployer.jar in a folder on the directory server. Open the command interface of the directory server. Switch to the folder in which the jar archive SVS_LdapDeployer.jar has been stored. Call the SVS_LdapDeployer using the following syntax: java -jar SVS_LdapDeployer.jar <command> <file> [<option>...] I You are informed about the various steps that are being performed while the SVS_LdapDeployer is running. You will find detailed information in the file log.txt, which is created in the execution folder every time that SVS_LdapDeployer is run. I In the following, the terms "LDAPv1 structure" and "LDAPv2 structure" are used to denote ServerView-specific configuration layouts of the authorization data and do not refer to version 1 and 2 of the LDAP protocol. I The -import and -sychronize commands (see below) are only needed in connection with LDAPv1 structures (irmc S2s with a firmware version < 3.77 and irmcs). For detail please refer to the manuals "irmc S2/S3 - integrated Remote Management Controller" edition May 2011 and former editions. "irmc - integrated Remote Management Controller". <command> Specifies the action to be performed. The following commands are available: -deploy Creates an LDAP structure for global RMC S2/S3 user management on the directory server (see page 151). -delete Deletes an LDAP structure used for global irmc S2/S3 user management from the directory server (see page 153). User Management in ServerView 149

150 Global user management for the irmc S2/S3 <file> -import Creates an equivalent LDAP v2 structure from an existing LDAP v1 structure. -synchronize Makes corresponding changes in an existing LDAP v1 structure to reflect any changes that you make in an LDAP v2 structure. The configuration file (.xml) used as an input file by SVS_LdapDeploy. This configuration file contains the structure information for the SVS structure in XML syntax. I The syntax of the configuration file is illustrated in the sample configuration files Generic_Settings.xml and Generic_InitialDeploy.xml that are supplied together with the jar archive SVS_LdapDeployer.jar on ServerView Suite DVD. <option> [<option>...] Option(s) that control execution of the specified command. The following sections describe in detail the individual commands available in SVS_LdapDeployer together with the associated options. I The SVS_LdapDeployer generates all the required subtrees including all the groups but not the relations between users and groups. You create and assign user entries to groups by means of the corresponding tools in the employed directory service after generating the OU SVS in the directory service. 150 User Management in ServerView

151 Global user management for the irmc S2/S deploy: Create or modify an LDAP v2 structure The -deploy command allows you to create a new LDAP structure on the directory server or to add new entries to an existing LDAP structure. I Before you delete entries from an existing LDAP structure, you must first delete the LDAP structure itself using -delete (see page 153) and then generate it again using a suitably adapted configuration file. Syntax: -deploy <file> [-structure {v1 v2 both}] [ -username <user>] [ -password <password>][ -store_pwd <path>][ -kloc <path>] [ -kpwd [<key-password>]] <file> XML file containing the configuration data. I The <Data> section in the configuration file must contain all the necessary roles and departments required for initially generating or expanding a structure. -structure v1 -structure v2 -structure both Creates an LDAP v1 structure or an LDAP v2 structure or an LDAP v1 and an LDAP v2 structure. I User management for the irmc S2 as of firmware version 3.77A and for the irmc S3 always requires an LDAP v2 structure. -username <user> User name for logging in to the directory server. -password <password> Password for the user <user>. User Management in ServerView 151

152 Global user management for the irmc S2/S3 -store_pwd Encrypts the password <password> using a randomly generated key and saves the encrypted password in the configuration file after -deploy has been executed successfully. By default, the randomly generated key is stored in the folder in which the SVS_LdapDeployer is executed. V CAUTION! You should save the randomly generated key in a safe place. If the predefined target folder is not adequate for your security needs, or if the folder in which the key is saved can also be accessed by other users, use the options -kloc and -kpwd to save the key securely. -kloc <path> Saves the randomly generated key under <path>. If you do not specify this option, the key is saved in the folder in which SVS_LdapDeployer is executed. -kpwd [<password>] Specifies a password to protect the randomly generated key. If you do not specify <password>, the password is automatically generated on the basis of a snapshot of the current runtime environment. 152 User Management in ServerView

153 Global user management for the irmc S2/S delete: Deleting an LDAP v2 structure The -delete command allows you to remove an LDAPv2 structure from the directory server. Syntax: -delete <file> [-structure {v1 v2 both}] [ -username <user>] [ -password <password>][ -store_pwd <path>][ -kloc <path>] [ -kpwd [<key-password>]] <file> XML file that specifies the structure to be deleted. -structure v1 -structure v2 -structure both Deletes an LDAP v1 structure or an LDAP v2 structure or an LDAP v1 and an LDAP v2 structure. I User management for the irmc S2 as of firmware version 3.77A and for the irmc S3 always requires an LDAP v2 structure. -username <user> User name for logging in to the directory server. -password <password> Password for the user <user>. -stor_pwd Encrypts the password <password> using a randomly generated key and saves the encrypted password in the configuration file after -delete has been executed successfully. By default, the randomly generated key is stored in the folder in which the SVS_LdapDeployer is executed. V CAUTION! You should save the randomly generated key in a safe place. If the predefined target folder is not adequate for your security needs, or if the folder in which the key is saved can also be accessed by other users, use the options kloc and -kpwd to save the key securely. -kloc <path> Saves the randomly generated key under <path>. If you do not specify this option, the key is saved in the folder in which SVS_LdapDeployer is executed. User Management in ServerView 153

154 Global user management for the irmc S2/S3 -kpwd [<password>] Specifies a password to protect the randomly generated key. If you do not specify <password>, the password is automatically generated on the basis of a snapshot of the current runtime environment Typical application scenarios Two typical scenarios for using SVS_LdapDeployer are described below Performing an initial configuration of an LDAP v2 structure You wish to set up global user management for an irmc S2/S3 (firmware 3.77 or later) for the first time. In order to do this, you require an LDAP v2 structure. Recommended method: Generate the Department definition for LDAP v2 structures (SVS): java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml -structure v Re-generating or expanding an LDAP v2 structure You wish to re-generate an LDAP v2 structure or expand an existing LDAP v2 structure. Recommended method: java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml -structure -structure v2 or java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml 154 User Management in ServerView

155 Global user management for the irmc S2/S Re-generating an LDAP v2 structure and prompting for and saving authentication data You wish to re-generate an LDAP v2 structure. The authentication data is to be provided and saved using the command line. Recommended method: java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml -store_pwd -username admin -password admin I After the login data has been saved, you can connect to the directory server using SVS_LdapDeployer without specifying a user name and password. The SVS_LdapDeployer then uses the values stored in the XML configuration file, provided that these are available. SVS_LdapDeployer can only use a saved password if it can decrypt it. This requires you to execute SVS_LdapDeployer in the same runtime environment that applied for the previous call with -store_pwd (see page 152). In this context, the same runtime environment means the same the user on the same computer or a user with permission to access the folder under which they key is stored (-kloc option, see page 152). I You can also use user accounts that have already been saved when you call SVS_LdapDeployer in the future. Furthermore, other authentication data can also be used temporarily by explicitly specifying the data in the command line or when requested to do so by SVS_LdapDeployer. User Management in ServerView 155

156 Global user management for the irmc S2/S irmc S2/S3 user management via Microsoft Active Directory This section describes how you integrate irmc S2/S3 user management in Microsoft Active Directory. I Prerequisite: An LDAP v2 structure has already been generated in the Active Directory service (see section SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures on page 148). You must perform the following steps to integrate irmc S2/S3 user management in Microsoft Active Directory: 1. Configure irmc S2/S3 LDAP/SSL access at the Active Directory server. 2. Assign irmc S2/S3 users to irmc S2/S3 user groups in Active Directory. 156 User Management in ServerView

157 Global user management for the irmc S2/S Configuring irmc S2/S3 LDAP/SSL access at the Active Directory server I The irmc S2/S3-LDAP integration uses the SSL implementation developed by Eric Young on the basis of the OpenSSL Project. A reproduction of the SSL copyright can be found on page 213. An RSA certificate is required before irmc S2/S3 can use LDAP via SSL. The following steps are involved in configuring LDAP access: 1. Install an Enterprise CA 2. Generate an RSA certificate for the domain controller. 3. Install the RSA certificate on the server Installing the Enterprise CA I A CA is a certification authority for certificates. An Enterprise CA (certification authority for enterprises) can be installed on the domain controller itself or on another server. Installation directly on the directory server is simpler since fewer steps are required than when installing on another server. Below is a description of how to install the Enterprise CA on a server other than the domain controller. I To install and configure Enterprise CA successfully, you require an Active Directory environment and an installed IIS (Internet Information Services). Proceed as follows to install an Enterprise CA: In the Windows start menu, choose: Start - Control Panel - Software - Add/Remove Windows Components In the wizard for Windows components, choose Certificate Services under Components. Double-click on Certificate Services and make sure that the Certificate Services Web Enrollment Support and Certificate Services CA options are selected. Choose Enterprise root CA. Select the option Use custom settings to generate the key pair and CA certificate. User Management in ServerView 157

158 Global user management for the irmc S2/S3 Select Microsoft Base DSS Cryptographic Provider to create DSA certificates of length 1024 bytes. Export the public certification authority certificate (CA Certificate). To do this, proceed as follows: Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Navigate to Certificates (Local Computer) - Trusted Root Certification Authorities - Certificates and double-click. Double-click on the certificate from the newly created certification authority. Click on the Details tab in the certificate window. Click on Copy to File. Choose a file name for the certification authority certificate and click on Finish. Load the public certification authority certificate to the certificate directory Trusted Root Certification Authorities on the domain controller. To do this, proceed as follows: Transfer the file containing the certification authority certificate to the domain controller. In Windows Explorer, open the certificate from the newly created certification authority. Click on Install Certificate. Under Place all certificates in the following store click on Browse and choose Trusted Root Certification Authorities. Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Add the snap-in for the current user s certificates. Copy the certification authority certificate (CA Certificate) from the current user s Trusted Root Certification Authorities directory to the local computer's Trusted Root Certification Authorities. 158 User Management in ServerView

159 Global user management for the irmc S2/S3 Creating a domain controller certificate Proceed as follows to create an RSA certificate for the domain controller: Create a file named request.inf with the following content: [Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=<full path of domain controller host>" KeySpec = 1 KeyLength = 1024 Exportable = TRUE MachineKeySet = TRUE SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID= ; this is for Server Authentication In the file request.inf, adapt the specification under Subject= to the name of the employed domain controller, e.g. Subject = CN=domino.fwlab.firm.net. Enter the following command in the Windows prompt window: certreq -new request.inf request.req Enter the following URL in the certification authority browser: Click on Request a Certificate. Click on advanced certificate request. Click on Submit a certificate request. Copy the content of the file request.req to the Saved Request window. Select the Web Server certificate template. Download the certificate and save it (e.g. in the file request.cer). User Management in ServerView 159

160 Global user management for the irmc S2/S3 Enter the following command in the Windows prompt window: certreq -accept request.cer Export the certificate with the private key. To do this, proceed as follows: Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Navigate to Certificates (Local Computer) - Personal Certificates - Certificates. Double-click on the new server certification authentication certificate. Click on the Details tab in the certificate window. Click on Copy to File. Select Yes, export the private key. Assign a password. Choose a file name for the certificate and click on Finish. 160 User Management in ServerView

161 Global user management for the irmc S2/S3 Installing the domain controller certificate on the server Proceed as follows to install the domain controller certificate on the server: Copy the domain controller certificate file that has just been created to the domain controller. Double-click on the domain controller certificate. Click on Install Certificate. Use the password which you assigned when exporting the certificate. Under Place all certificates in the following store click on Browse and choose Personal Certificates. Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Add the snap-in for the current user s certificates. Copy the domain controller certificate from the current user s Personal Certificates directory to the local computer's Personal Certificates directory. User Management in ServerView 161

162 Global user management for the irmc S2/S Assigning user roles to an irmc S2/S3 user You can assign user roles (authorization roles) to irmc S2/S3 users either on the basis of the user entry, or on the basis of the role entry / group entry I The example below uses the LDAP v2 structure to describe assignment based on the role entry in the OU SVS. The assignment procedure on the basis of the user entry is very similar. I The users must be entered in the groups manually in Active Directory. Proceed as follows: Open the snap-in Active Directory Users and Computers. Figure 41: Active Directory Users and Computers snap-in Double-click the authorization role (here: Administrator). The Administrator Properties dialog opens (see figure 42 on page 163): 162 User Management in ServerView

163 Global user management for the irmc S2/S3 Figure 42: Administrator Properties dialog Select the Members tab. Click on the Add... button. The Select Users, Contacts, or Computers dialog opens (see figure 43 on page 164). User Management in ServerView 163

164 Global user management for the irmc S2/S3 Figure 43: Select Users, Contacts, or Computers dialog Click on the Locations... button. The Locations dialog opens. Figure 44: Locations dialog Select the container (OU) containing your users. (By default, this is the OU Users.) Click OK to confirm. The Select Users, Contacts, or Computers dialog opens (see figure 45 on page 165). I Users may also be entered at a different location in the directory. 164 User Management in ServerView

165 Global user management for the irmc S2/S3 Figure 45: Select Users, Contacts, or Computers dialog Click on the Advanced... button. The Select Users, Contacts, or Computers extended dialog opens (see figure 46 on page 166). User Management in ServerView 165

166 Global user management for the irmc S2/S3 Figure 46: Select Users, Contacts, or Computers dialog - searching Click the Find Now button to display all the users in your domain. Under Search results: in the display area you can now view the search result (see figure 47 on page 167). 166 User Management in ServerView

167 Global user management for the irmc S2/S3 Figure 47: Select Users, Contacts, or Computers dialog - displaying the search results Select the users who are to be added to the group and click OK to confirm. The selected users are now displayed (see figure 48 on page 168). User Management in ServerView 167

168 Global user management for the irmc S2/S3 Figure 48: Select Users, Contacts, or Computers dialog - confirming the search results Confirm by clicking OK. 168 User Management in ServerView

169 Global user management for the irmc S2/S irmc S2/S3 user management via Novell edirectory This section provides you with information about the following topics: The Novell edirectory system components and system requirements Installing Novell edirectory Configuring Novell edirectory Integrating irmc S2/S3 user management in Novell edirectory Tips on administering Novell edirectory. I The installation and configuration of Novell edirectory are described in detail below. No extensive edirectory knowledge is required. If you are already familiar with Novell edirectory, you can skip the next three sections and continue with section Integrating irmc S2/S3 user management in Novell edirectory on page Software components and system requirements I Use the specified version or a more recent version of the components listed below. Novell edirectory (formerly NDS) consists of the following software components: edirectory 8.8: _0800_Linux_88-SP1_FINAL.tar.gz edirectory 8.8: edir_88_iman26_plugins.npm imanager: iman_26_linux_64.tgz for SuSE, iman_26_linux_32.tgz otherwise ConsoleOne: c1_136f-linux.tar.gz The following system requirements must be fulfilled in order to install and operate Novell edirectory: OpenSSL must be installed. I If OpenSSL is not already installed: 512 MB free RAM Install OpenSSL, before starting the Novell edirectory installation. User Management in ServerView 169

170 Global user management for the irmc S2/S Installing Novell edirectory To install Novell edirectory, it is necessary to install the following components: edirectory Server and administrations utilities imanager (administrations utility) ConsoleOne (administrations utility) I Prerequisites for the installation of Novell edirectory: A Linux server operating system must be fully installed and running. The firewall must be configured for connections to the following ports: 8080, 8443, 9009, 81, 389, 636. For OpenSuSE, you configure this in the file /etc/sysconfig/susefirewall2: Add the entry FW_SERVICES_EXT_TCP to the file /etc/sysconfig/susefirewall2 as follows: FW_SERVICES_EXT_TCP=" " In accordance with the edirectory Installation Guide, the system must be set up for multicast routing. For SuSE Linux, proceed as follows: Create or (if it already exists) open the file /etc/sysconfig/network/ifroute-eth0. Add the following line to /etc/sysconfig/network/ifroute-eth0: eth0 This adapts eth0 to the system configuration. 170 User Management in ServerView

171 Global user management for the irmc S2/S3 I Prerequisites for the installation of the edirectory Server, the edirectory utilities, the imanager and ConsoleOne: The root permission is required in order to perform installation. All the files required for the installation must have been copied to a directory (e.g. /home/edirectory) before you can use the procedure below to perform installation. These files are as follows: _0800_Linux_88-SP1_FINAL.tar.gz iman_26_linux_64.tgz c1_136f-linux.tar.gz Installing the edirectory Server and administration utilities Proceed as follows: Log in with root permission (superuser). Switch to the directory containing the files required for installation (in our example: /home/edirectory): cd /home/edirectory Extract the archive _0800_Linux_88-SP1_FINAL.tar.gz: tar -xzvf _0800_Linux_88-SP1_FINAL.tar.gz After extraction, /home/edirectory has a new subdirectory named edirectory. Installing edirectory Server Go to the setup subdirectory of this edirectory directory: cd edirectory/setup Call the installation script./nds-install :./nds-install Accept the EULA with y and confirm with the [Enter] key. If you are asked which program you want to install: Enter 1 to install the Novell edirectory server and press the [Enter] key to confirm. The edirectory packages are then installed. User Management in ServerView 171

172 Global user management for the irmc S2/S3 After installation of the Novell edirectory Server, you must update the names for the paths to the edirectory in a number of environment variables and export these variables. To do this, open your configuration file (in the example: /etc/bash.bashrc) and enter the following lines in the specified sequence ahead of # End of... : export PATH/opt/novell/eDirectory/bin:/opt/novell/eDirectory/ sbin:$path export LD_LIBRARY_PATH=/opt/novell/eDirectory/lib:/ opt/novell/edirectory/lib/nds-modules:/opt/novell/ lib:$ld_library_path export MANPATH=/opt/novell/man:/opt/novell/eDirectory/ man:$manpath export TEXTDOMAINDIR=/opt/novell/eDirectory/share/ locale:$textdomaindir Close the terminal and open a new terminal in order to export the environment variables. Installing the edirectory administration utilities Go to the setup subdirectory of the edirectory directory: cd edirectory/setup Call the installation script:./nds-install Accept the EULA with y and confirm with the [Enter] key. If you are asked which program you want to install: Enter 2 to install the Novell edirectory administration utilities and press the [Enter] key to confirm. The edirectory administration utilities are then installed. 172 User Management in ServerView

173 Global user management for the irmc S2/S3 Installing and calling imanager I imanager is the recommended tool for installing Novell edirectory. Whether installing in SLES10 or in OpenSuSE, you use the archive *_64.tgz. Proceed as follows: Log in with root permission (superuser). Go to the directory /home/edirectory: cd /home/edirectory Extract the archive iman_26_linux_64.tgz: tar -xzvf iman_26_linux_64.tgz After extraction, /home/edirectory has a new subdirectory named imanager. Go to the installs subdirectory of imanager: cd imanager/installs/linux Call the installation script:./imanagerinstalllinux.bin Select the language for the output of installation messages. Click through and accept the EULA. Select 1- Novell imanager 2.6, Tomcat, JVM for imanager installation. Select 1- Yes for plug-in download. Press [Enter] to use the default path for the download. The installation program searches the internet for downloads. This can take a few minutes. You are then asked to select the plug-ins that you want to install. Select All to download all the plug-ins. Select 1- Yes to install the locally available plug-ins. Press [Enter] to use the default path for installation. Select 2- No for automatic Apache configuration (optional). Accept the default port (8080) for Tomcat. Accept the default SSL port (8443) for Tomcat. User Management in ServerView 173

174 Global user management for the irmc S2/S3 Accept the default JK connector port (9009) for Tomcat. Enter the administration user ID (e.g. root.fts ) for the user with the appropriate administration permissions. Enter the tree name (e.g. fwlab ) for the user with the appropriate administration permissions. Accept the summary of your entries which is displayed with 1-OK... in order to terminate installation. Logging in to Novell imanager After installation, you can use the following URL to log in at imanager via a web browser. address of the edirectory server>:8443/nps I Novell recommends that you use Microsoft Internet Explorer or Mozilla Firefox as your web browser. In Mozilla Firefox, it is possible that not all the context menu's pop-up windows will be displayed. 174 User Management in ServerView

175 Global user management for the irmc S2/S3 Installing and starting ConsoleOne ConsoleOne is another administration tool for Novell edirectory. Proceed as follows to install ConsoleOne: Log in with root permission (superuser) at edirectory Server. Go to the directory /home/edirectory: cd /home/edirectory Extract the ConsoleOne archive c1_136f-linux.tar.gz: tar -xzvf c1_136f-linux.tar.gz After extraction, /home/edirectory has a new subdirectory named Linux. Go to the directory Linux: cd Linux Call the installation script c1-install:./c1-install Select the language for the output of installation messages. Enter 8 to install all the snap-ins. ConsoleOne needs the path to an installed Java runtime environment. You can export the corresponding path name to the environment variable C1_JRE_HOME. However, the system-wide export of the path name requires modifications in the bash profile. I Since root permission is required in order to work with ConsoleOne, it is, in principle, sufficient to export the ID superuser Root. However, the system-wide export of the path name is presented below. This means that normal users can also work with ConsoleOne if they have root permission. User Management in ServerView 175

176 Global user management for the irmc S2/S3 Proceed as follows: Open the configuration file for editing (in the example: /etc/bash.bashrc) Enter the following line in the configuration file in front of # End of... : export C1_JRE_HOME=/opt/novell/j2sdk1.4.2_05/jre I The java runtime environment installed together with edirectory is used here. However, you can also specify the path name of any other Java runtime environment installed on the edirectory Server. ConsoleOne obtains the available tree hierarchies either via the local configuration file hosts.nds or via the SLP service and multicast. Proceed as follows to insert your tree hierarchy in the configuration file: Go to the configuration directory: cd /etc Generate the file hosts.nds if it does not yet exist. Open the file hosts.nds and insert the following lines: #Syntax: TREENAME.FQDN:PORT MY_Tree.mycomputer.mydomain:81 Starting ConsoleOne You start ConsoleOne in the system prompt using the following command: /usr/consoleone/bin/consoleone 176 User Management in ServerView

177 Global user management for the irmc S2/S Configuring Novell edirectory Perform the following steps to configure Novell edirectory: 1. Create an NDS tree 2. Configure edirectory for LDAP. 3. Test edirectory access via LDAP Browser. Creating an NDS tree Create an NDS (Network Directory Service) tree using the utility ndsmanage. ndsmanage requires the following information to do this: TREE NAME Unique name in the network for the new NDS tree, e.g. MY_TREE. Server Name Name of an instance of server class in edirectory. For Server Name,you specify the name of the PRIMERGY server on which the LDAP server is running, for example. lin36-root-0. Server Context Fully distinguished name (fully distinguished name of the object path and attributes) of the container which contains the server object, e.g. dc= organization.dc=mycompany. Admin User Fully distinguished name (fully distinguished name of the object path and attributes) of the user with permission to perform administration, e.g. cn= admin.dc=organization.dc=mycompany NCP Port Specify port 81. Instance Location Specify the path: /home/root/instance0 Configuration File Specify the following file: /home/root /instance0/ndsconf Password for admin user Enter the administrator password here. User Management in ServerView 177

178 Global user management for the irmc S2/S3 Proceed as follows to configure the NDS tree: Open a command box. Go to the directory /home/edirectory. Start the utility ndsmanage by entering the command ndsmanage: ndsmanage Enter c to generate a new instance of the class server. Enter y to continue configuration. Enter y to create a new tree. ndsmanage then queries the values for TREE NAME, Server Name, Server Context etc. in sequence (see page 177). Once input is complete, ndsmanage configures the NDS tree. After configuring the NDS tree, restart the PRIMERGY server in order to activate the configuration, i.e. to recreate the NDS tree. Configuring edirectory for LDAP The following steps are involved in configuring edirectory for LDAP: Install Role Based Services (RBS) Install plug-in modules Configure Role Based Services (RBS) Configure edirectory with/without SSL/TLS support Proceed as follows to complete the individual points: Log in under the administrator ID (Admin) at imanager via a web browser. 178 User Management in ServerView

179 Global user management for the irmc S2/S3 Installing Role Based Services (RBS). Install RBS using the imanager Configuration Wizard. Proceed as follows: In imanager, select the Configure tap (by clicking on the desk icon). In the Configure tab, select Role Based Services - RBS Configuration Start the RBS Configuration Wizard. Assign RBS2 to the container that is to be managed. (In the example above, this is mycompany.) Installing plug-in modules Proceed as follows: In imanager, select the Configure tap (by clicking on the desk icon). In the Configure tab, select Plug-in installation - Available Novell Plug-in Modules In the modules listed in the page Available Novell Plug-in Modules, select the edirectory-specific package edir_88_iman26_plugins.npm. Click Install. Configuring Role Based Services (RBS) In the page Available Novell Plug-in Modules, select all the modules that are required for LDAP integration. If you are not certain, select all the modules. Click Install. Configuring edirectory for SSL/TLS-secured access I During edirectory installation, a temporary certificate is generated with the result that access to the edirectory is secured by SSL/TLS by default. However, since the irmc S2/S3 firmware is configured for the use of RSA/MD5 certificates, SSL/TLS-secured, global irmc S2/S3 user management via edirectory requires an RSA/MD5 certificate of 1024 bytes in length. User Management in ServerView 179

180 Global user management for the irmc S2/S3 You create an RSA/MD5 certificate of length 1024 bytes as follows using ConsoleOne: Log into the LDAP server under your administrator ID (Admin) and start ConsoleOne. Navigate to your corporate structure's root directory (e.g. treename/mycompany/myorganisation). Select New Object - NDSPKI key material - custom to create a new object of class NDSPKI:Key Material. In the dialog which is then displayed, specify the following values: bits 2. SSL or TLS 3. signature RSA/MD5 A new signature of the required type is created. To activate the newly created certificate for the SSL-secured LDAP connection, perform the following steps in imanager: Start imanager via the web browser. Log in at imanager with valid authentication data. Select LDAP - LDAP Options - LDAP Server - Connection. The Connection tab contains a drop-down list which displays all the certificates installed on the system. Select the required certificate in the drop-down list. Configuring edirectory for non-ssl-secured access I Anonymous login and the transfer of plain text passwords via nonsecured channels are deactivated by default in edirectory. Consequently, web browser login at the edirectory server is only possible via an SSL connection. If you want to use LDAP without SSL then you must perform the following steps: 1. Enable a non-ssl-secured LDAP- connection. 2. Relax the bind restrictions. 3. Reload the LDAP configuration. 180 User Management in ServerView

181 Global user management for the irmc S2/S3 Proceed as follows: 1. Enable a non-ssl-secured LDAP- connection. Start imanager via the web browser. Log in at imanager with valid authentication data. Select the Roles and Tasks view. Select LDAP - LDAP Options - LDAP Server - Connection. In the Connection tab, deactivate the option Require TLS for all Operations. Select LDAP - LDAP Options - LDAP Group - General. In the General tab, deactivate the option Require TLS for Simple Binds with password. 2. Relax the bind restrictions. Log in at imanager with valid authentication data. In the object tree, navigate to the LDAP Server object. Click with the mouse to highlight the LDAP Server object and select Modify Object in the associated context menu. In the right-hand content frame, open the Other sheet. Under Valued Attributes, select ldapbindrestrictions Click the Edit button. Set the value to 0. Click OK. In the Other sheet, click the Apply button. 3. Reload the LDAP configuration. Start ConsoleOne and log in to edirectory. Click on the Base DN object at the left of the window (e.g. Mycompany). The LDAP server object is then displayed on the right-hand side of the window. Right-click to highlight the LDAP Server object and select Properties... in the associated context menu. In the General tab, click Refresh NLDAP Server Now. User Management in ServerView 181

182 Global user management for the irmc S2/S3 Testing edirectory access via LDAP Browser. After successfully completing steps 1-3 above, you should be able to establish a connection to edirectory via the LDAP Browser utility. You can use Jarek Gavor's LDAP Browser (see page 199) to test this connection as follows: Try to log in at edirectory under the administrator ID (in the example: admin) via an SSL connection. If this attempt fails, proceed as follows: Check that SSL is active (see page 180). Figure 49: Testing LDAP access to edirectory: SSL activated Try to log in at edirectory under the administrator ID (in the example: admin) via a non-ssl-secured connection. 182 User Management in ServerView

183 Global user management for the irmc S2/S3 Figure 50: Testing LDAP access to edirectory: SSL not activated If the login fails again: Relax the bind restrictions (see page 180) Integrating irmc S2/S3 user management in Novell edirectory I Prerequisite: An LDAP v2 structure has already been generated in the edirectory directory service (see section SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures on page 148). You must perform the following steps in order to integrate irmc S2/S3 user management in Novell edirectory: Generating the principal irmc user. Declare the irmc groups and user permissions in edirectory. Assign users to the permission groups. User Management in ServerView 183

184 Global user management for the irmc S2/S3 LDAP authentication process for irmc S2/S3 users in edirectory The authentication of a global irmc S2/S3 user on login at the irmc S2/S3 is performed in accordance with a predefined process (see page 136). figure 51 on page 184 illustrates this process for global irmc S2/S3 user management with Novell edirectory. The establishment of a connection and login with the corresponding login information is referred to as a BIND operation. SSL-based communication irmc S2/S3: Bind as Principal User 1 irmc S2/S3 is authenticated irmc S2/S3 2 3 irmc S2/S3 determines the fully-qualified DN of User1 Bind with User1's DN User1 is authenticated edirectory User permissions 4 irmc S 2/S3 determines the user permissions of User1 1) The irmc S2/S3 logs in at the edirectory server with the predefined, known permission data (irmc S2 setting) as Principal User and waits for the successful bind. 2) The irmc S2/S3 asks the edirectory server to provide the fully qualified Distinguished Name (DN) of the user with cn=user1. edirectory determines the DN from the preconfigured subtree (irmc S2 setting). 3) The irmc S2/S3 logs in at the edirectory server with the fully-qualified DN of the user User1 and waits for the successful bind. 4) The irmc S2/S3 asks the edirectory server to provide the user permissions of the user User1. Figure 51: Authentication diagram for global irmc S2/S3 permissions 184 User Management in ServerView

185 Global user management for the irmc S2/S3 I You configure the Principal User's permission data and the subtree which contains the DNs in the page Directory Service Configuration page of the irmc S2/S3 web interface (see the manual irmc S2/S3 - integrated Remote Management Controller). I A user's CN must be unique within the searched subtree. Creating the Principal User for the irmc S2/S3 Proceed as follows to create the Principal User for the irmc S2/S3: Log in at imanager with valid authentication data. Select Roles and Tasks. Select Users - Create User. Enter the necessary specifications in the displayed template. I The Principal User's Distinguished Name (DN) and password must match the corresponding specifications for the irmc S2/S3 configuration (see the manual irmc S2/S3 - integrated Remote Management Controller). The user's Context: may be located at any position in the tree. Assign the Principal User search permissions for the following subtrees: Subtree (OU) SVS Subtree (OU) that contains the users (e.g. people). Assigning user permissions to the irmc groups and users By default, an object in edirectory possesses only very limited query and search permissions in an LDAP tree. If an object is to be able to query all the attributes in one or more subtrees, you must assign this object the corresponding permissions. You may assign permissions either to an individual object (i.e. a specific user) or to a group of objects which are collated in the same organizational unit (OU) such as SVS or people. In this case, the permissions assigned to an OU and identified as inherited are automatically passed on to the objects in this group. User Management in ServerView 185

186 Global user management for the irmc S2/S3 I To integrate irmc S2/S3 user management in Novell edirectory, it is necessary to assign search permissions to the following objects (trustees): Principal User Subtree which contains the irmc S2/S3 users Detailed information on how to do this can be found below. Proceed as follows to assign an object search permissions for all attributes: Start imanager via the web browser. Log in at imanager with valid authentication data. In imanager, click the Roles and Tasks button. In the menu tree structure, select Rights - Rights to Other Objects. The page Rights to Other Objects is displayed. Under Trustee Name, specify the name of the object (in figure 52 on page 187 SVS.sbdr4) to which the permission is to be granted. Under Context to Search From, specify the edirectory subtree (SVS) which imanager is to search through for all the objects for which the trustee Users currently has read permission. Click OK. A progress display indicates the status of the search. Once the search operation has been completed, the page Rights to Other Objects is displayed with the results of the search (see figure 52 on page 187). 186 User Management in ServerView

187 Global user management for the irmc S2/S3 Figure 52: imanager - Roles and Tasks - Rights To Other Objects I If no object is displayed under Object Name, then the trustee currently has no permissions within the specified context. Assign the trustee additional permissions if necessary: Click Add Object. Use the object selector button to select the object for which you want to assign the trustee a permission. Click Assigned Rights. If the property [All Attributes Rights] is not displayed: Click Add Property. The Add Property window is displayed (see figure 53 on page 188). User Management in ServerView 187

188 Global user management for the irmc S2/S3 Figure 53: imanager - Roles and Tasks - Rights To Other Objects - Add Property Highlight the property [All Attributes Rights] and click OK to add it. For the property [All Attributes Rights], enable the options Compare, Read and Inherit and click OK to confirm. This authorizes the user/user group to query all the attributes in the selected object's subtree. Click Apply to activate your settings. 188 User Management in ServerView

189 Global user management for the irmc S2/S Assigning an irmc S2/S3 user to a permission group You can assign irmc S2/S3 users (for instance from the OU people) to the irmc permission groups either starting from the user entry (preferable if there only a few user entries) or starting from the role entry / group entry (preferable if there are a lot of user entries). I The following example shows the assignment of irmc S2/S3 users from an OU people to a permission group. The assignment starting from the group entry / role entry is explained. The assignment procedure on the basis of the user entry is very similar. I The users must be entered in the groups manually in edirectory. Proceed as follows: Start imanager via the web browser. Log in at imanager with valid authentication data. Select Roles and Tasks. Select Groups - Modify Group. The Modify Group page is displayed. Perform the following steps for all the permission groups to which you want to assign irmc S2/S3 users: Use the object selector button to select the permission group to which you want to add irmc S2/S3 users. In the example of the LDAP v2 structure (see figure 54 on page 190) this is: Administrator.AuthorizationRoles.DeptX.Departments.SVS.sbrd4. User Management in ServerView 189

190 Global user management for the irmc S2/S3 Select the Members tab. The Members tab of the Modify Group page is displayed: Figure 54: imanager - Roles and Tasks - Modify Group - Members tab (LDAP v2) Perform the following steps for all the users of the OU people which you want to assign to the irmc group: Click the object selector button. The Object Selector (Browser) window is opened (see figure 55 on page 191). 190 User Management in ServerView

191 Global user management for the irmc S2/S3 Figure 55: Assigning users to the irmc group - selecting users In the Object Selector (Browser) window, select the required user(s) in the OU people and click OK to confirm. The selected users are now listed in the display area in the Members tab of the Modify Group page (see figure 54 on page 190). User Management in ServerView 191

192 Global user management for the irmc S2/S3 Figure 56: Display of the selectedirmc S2/S3 users in the Members LDAP v2 tab Confirm with Apply or OK in order to add the selected users to the irmc group (here:....svs.sbdr4). 192 User Management in ServerView

193 Global user management for the irmc S2/S Tips on administering Novell edirectory. Restarting the NDS daemon Proceed as follows to restart the NDS daemon: Open the command box. Log in with root permission. Execute the following command: rcndsd restart If, for any unidentifiable reason, the nldap daemon fails to start: Start the lndap daemon manually : /etc/init.d/nldap restart If imanager does not respond: Restart imanager: /etc/init.d/novell-tomcat4 restart Reloading the configuration of the NLDAP server Proceed as follows: Start ConsoleOne and log in to edirectory. I If you are starting ConsoleOne for the first time, no tree is configured. Proceed as follows to configure a tree: Under My World, select the node NDS. In the menu bar, select: File - Authenticate Enter the following authentication data for login: 1. Login-Name: root 2. Password: <password> 3. Tree: MY_TREE 4. Context: mycompany User Management in ServerView 193

194 Global user management for the irmc S2/S3 In the left-hand part of the window, click the Base DN object (Mycompany). The LDAP Server object is then displayed in the right-hand side of the window. Right-click on the LDAP Server object and select Properties... in the context menu. In the General tab, click the Refresh NLDAP Server Now button. Configuring the NDS message trace The nds daemon generates debug and log messages which you can trace using the ndstrace tool. The purpose of the configuration described below is to redirect the output from ndstrace to a file and display the content of this file at another terminal. For this latter task, you use the screen tool. The following procedure is recommended: Open the command box (e.g. bash). Configuring ndstrace Go to the edirectory directory /home/edirectory: cd /home/edirectory Start screen by means of the command screen. Start ndstrace with the command ndstrace. Select the modules that you want to activate. For example, if you want to display the times at which events occurred, enter dstrace TIME. I You are very strongly recommended to activate the modules LDAP and TIME by making the following entry: dstrace LDAP TIME Terminate ndstrace by entering quit. This terminates the configuration of ndstrace. 194 User Management in ServerView

195 Global user management for the irmc S2/S3 Outputting messages at a second terminal Start ndstrace and redirect message output: ndstrace -l >ndstrace.log Use the following key combination to open a second terminal: [Ctrl] + [a], [Ctrl] + [c] Activate log recording: tail -f./ndstrace.log To switch between the virtual terminals, use the key combination [Ctrl] + [a], [Ctrl] + [0]. (The terminals are numbered from 0 to 9) User Management in ServerView 195

196 Global user management for the irmc S2/S irmc S2/S3 user management via OpenLDAP This section provides you with information about the following topics: Installing OpenLDAP (Linux). Creating an SSL certificate. Configuring OpenLDAP. Integrating irmc S2/S3 user management in OpenLDAP. Tips on OpenLDAP administration Installing OpenLDAP I Before installing OpenLDAP, you must configure the firewall for connections to the ports 389 and 636. For OpenSuSE, proceed as follows: In the file, /etc/sysconfig/susefirewall2 extend the option FW_SERVICES_EXT_TCP as follows: FW_SERVICES_EXT_TCP= To install the packages OpenSSL and OpenLDAP2 from the distribution medium, use the setup tool YaST Creating SSL certificates You should create a certificate with the following properties: Key length: 1024 bits md5rsaenc You use OpenSSL to create key pairs and signed certificates (self-signed or signed by an external CA). For more detailed information, see the OpenSSL home page at The following links provide instructions on setting up a CA and creating test certificates: User Management in ServerView

197 Global user management for the irmc S2/S3 Following certificate creation, you must have the following three PEM files: Root certificate: root.cer.pem Server certificate: server.cer.pem Private key: server.key.pem I The private key must not be encrypted with a pass phrase since you should only assign the LDAP daemon (ldap) read permission for the file server.key.pem. You use the following command to remove the pass phrase: openssl rsa -in server.enc.key.pem -out server.key.pem Configuring OpenLDAP Proceed as follows to configure OpenLDAP: Start the Yast setup tool and select LDAP-Server-Configuration. Under Global Settings/Allow Settings, activate the setting LDAPv2-Bind. Select Global Settings/TLS Settings: Activate the setting TLS. Declare the paths of the files created during installation (see section Installing OpenLDAP on page 196). Make sure that certificates and private keys in the file system can be read by the LDAP service. Since openldap is executed under the uid/guid=ldap, you can do this by setting the owner of the files with the certificates and private keys to ldap, or by assigning the LDAP daemon ldap read permission for the files containing the certificates and private keys. Select Databases to create a new database. User Management in ServerView 197

198 Global user management for the irmc S2/S3 I If the configuration created by YaST does not function overall, check that the following obligatory entries are present in the file /etc/openldap/slapd.conf: allow bind_v2 TLSCACertificateFile /path/to/ca-certificate.pem TLSCertificateFile /path/to/certificate.pem TLSCertificateKeyFile /path/to/privat.key.pem I If the configuration created by YaST for SSL does not function, check that the following entry is present in the configuration file /etc/sysconfig/openldap: OPENLDAP_START_LDAPS= yes 198 User Management in ServerView

199 Global user management for the irmc S2/S Integrating irmc S2/S3 user management in OpenLDAP I Prerequisite: An LDAP v2 structure has already been generated in the OpenLDAP directory service (see section SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures on page 148). The integration of irmc S2/S3 user management in OpenLDAP comprises the following steps: Generating the principal irmc user. Creating the new irmc S2/S3 user and assigning this user to the permission group. I To generate the Principal User (ObjectClass: Person) use an LDAP browser, for example the LDAP Browser\Editor published by Jarek Gawor (see page 199). LDAP Browser\Editor published by Jarek Gawor The LDAP Browser\Editor published by Jarek Gawor is easy to use via a graphical user interface. The tool is available for download in the internet. Proceed as follows to install the LDAP Browser\Editor: Unpack the Zip archive Browser281.zip to an installation directory of your choice. Set the environment variable JAVA_HOME to the installation directory for the JAVA runtime environment, e.g.: JAVA_HOME=C:\Program Files\Java\jre7 User Management in ServerView 199

200 Global user management for the irmc S2/S3 Generating the Principal User I To generate the Principal User (ObjectClass: Person) use an LDAP browser, for example the LDAP Browser\Editor published by Jarek Gawor (see page 199). The text below describes how you use the Jarek Gawor LDAP Browser\Editor to generate the Principal User. Proceed as follows: Start the LDAP Browser. Log in at the OpenLDAP directory service with valid authentication data. Select the subtree (subgroup) in which the Principal User is to be created. The Principal User can be created anywhere in the tree. Open the Edit menu. Select Add Entry. Select Person. Edit the Distinguished Name DN. I The Principal User's Distinguished Name (DN) and password must match the corresponding specifications for the irmc S2/S3 configuration (see the manual irmc S2/S3 - integrated Remote Management Controller). Click Set and enter a password. Enter a Surname SN. Click Apply. 200 User Management in ServerView

201 Global user management for the irmc S2/S3 Creating the new irmc S2/S3 user and assigning this user to the permission groups I To create a new user (ObjectClass Person) and assign a user to the permission group, you use an LDAP browser, for example the Jarek Gawor LDAP Browser\Editor (see page 199). The following text describes how you use the Jarek Gawor LDAP Browser\Editor to create a new irmc S2/S3 user and add this user to the permission group. Proceed as follows: Start the LDAP Browser. Log in at the OpenLDAP directory service with valid authentication data. Create a new user. To do this, proceed as follows: Select the subtree (subgroup) in which the new user is to be created. The new user can be created anywhere in the tree. Open the Edit menu. Select Add Entry. Select Person. Edit the Distinguished Name DN. Click Set and enter the password. Enter a Surname SN. Click Apply. User Management in ServerView 201

202 Global user management for the irmc S2/S3 Assign the user you have just created to the permission group. To do this, proceed as follows: Select the SVS subtree (subgroup) to which the user is to belong, i.e. cn=userkvm,ou=yourdepartment,ou=departments,ou=svs, dc=myorganisation,dc=mycompany Open the Edit menu. Select Add Attribute. Specify Member as the attribute name. As the value, specify the fullyqualified DN of the user you have just created, i.e. cn=userkvm,ou=yourdepartment,ou=departments,ou=svs, dc=myorganisation,dc=mycompany 202 User Management in ServerView

203 Global user management for the irmc S2/S Tips on OpenLDAP administration Restarting the LDAP service Proceed as follows to restart the LDAP service: Open the command box. Log in with root permission. Enter the following command: rcldap restart Message logging The LDAP daemon uses the Syslog protocol for message logging. I The logged messages are only displayed if a log level other than 0 is set in the file /etc/openldap/slapd.conf. For an explanation of the various levels, see: table 35 on page 204 provides an overview of the log levels and their meanings. User Management in ServerView 203

204 Global user management for the irmc S2/S3 Log level Meaning -1 Comprehensive debugging 0 No debugging 1 Log function calls 2 Test packet handling 4 Heavy trace debugging 8 Connection management 16 Show sent/received packets 32 Search filter processing 64 Configuration file processing 128 Processing of access control lists 256 Status logging for connections/operations/events 512 Status logging for sent entries 1024 Output communication with shell backends Output results of entry parsing. Table 35: OpenLDAP - log levels 204 User Management in ServerView

205 Global user management for the irmc S2/S Configuring alerting to global irmc S2/S3 users alerting to global irmc S2/S3 users is integrated in the global irmc S2/S3 user management system. This means that it can be configured and handled centrally for all platforms using a directory server. Appropriately configured global user IDs can receive alerts from all irmc S2/S3s that are connected to a directory server in the network. I Prerequisites The following requirements must be met for alerting: Global alerting requires Version 3.77A or later of the irmc S2/S3 firmware, as an LDAP v2 structure is required. A principal user must have been configured in the irmc S2/S3 web interface who has been granted permission to search in the LDAP tree (see the manual irmc S2/S3 - integrated Remote Management Controller). When configuring the LDAP settings on the Directory Service Configuration page (see the manual irmc S2/S3 - integrated Remote Management Controller), alerting must have been enabled under Directory Service Alert Configuration. User Management in ServerView 205

206 Global user management for the irmc S2/S Global alerting Alert roles are required for global alerting via the directory server. These are defined in addition to the authorization roles in the configuration file of the SVS_LdapDeployer (see page 148). Displaying alerting groups (alert roles) An alert role groups together a selection of alert types (e.g. temperature threshold exceeded), each with an assigned severity (e.g. critical ). Assigning a user to a particular alert group specifies what alert types and severities the user will be alerted of by . The syntax of the alert roles is illustrated in the sample configuration files Generic_Settings.xml and Generic_InitialDeploy.xml that are supplied together with the jar archive SVS_LdapDeployer.jar on ServerView Suite DVD. Displaying alert types The following alert types are supported: Alert type FanSens Temperat HWError Security SysHang POSTErr SysStat DDCtrl NetInterf RemMgmt SysPwr Memory Others Table 36: Alert types Cause Fan sensors Temperature sensors Critical hardware error Security System hung POST error System status Disk drives and controllers Network interface Remote Management Power management Memory Miscellaneous Each alert type can be assigned one of the following severity levels: Warning, Critical, All, (none). 206 User Management in ServerView

207 Global user management for the irmc S2/S3 Preferred mail server. For global alerting, the setting Automatic is used on the preferred mail server: If the cannot be successfully sent immediately, for instance if the first mail server is not available, the is sent to the second mail server. Supported mail formats The following formats are supported: Standard Fixed Subject ITS-Format Fujitsu REMCS Format I If a mail format other than Standard is used, you must add the users to the corresponding mail format group. LDAP table If alerting is configured (see page 209) and the option LDAP Alert Enable is selected, the irmc S2/S3 sends s to the following users when an alert is issued (see the manual irmc S2/S3 - integrated Remote Management Controller): all appropriately configured local irmc S2/S3 users, all global irmc S2/S3 users registered in the LDAP table for this alert. The LDAP table is initially created by the irmc S2/S3 firmware the first time the irmc S2/S3 is started and then updated at regular intervals. The size of the LDAP table is limited to a maximum of 64 LDAP alert roles and a maximum of 64 global irmc S2/S3 users for whom alerting is configured. I It is recommended that you use distribution lists for global alerting. User Management in ServerView 207

208 Global user management for the irmc S2/S3 The LDAP directory server gets the following information from the table for the purposes of alerting: List of the global irmc S2/S3 users for whom alerting is configured. For each global irmc S2/S3 user: List of the configured alerts for each alert type (type and severity). Required mail format. The LDAP table is updated in the following circumstances: when the irmc S2/S3 is started for the first time or restarted, when the LDAP configuration is changed, at regular intervals (optional). You specify the update interval as part of the LDAP configuration in the irmc S2/S3 web interface (under the option LDAP Alert Table Refresh (see the manual irmc S2/S3 - integrated Remote Management Controller, and the LDAP Alert Table Refresh option). 208 User Management in ServerView

209 Global user management for the irmc S2/S3 Configuring global alerting on the directory server This section describes how to configure alerting on the directory server. I Settings must also be made for the irmc S2/S3. You configure these in the irmc S2/S3 web interface (see manual irmc S2/S3 - integrated Remote Management Controller). Proceed as follows: In the directory service, enter the addresses of the users to whom s are to be sent. I The method used to configure the addresses differs depending on the directory service used (Active Directory, edirectory or OpenLDAP). Create a configuration file in which the alert roles are defined. Start the SVS_LdapDeployer using this configuration file in order to generate a corresponding LDAP v2 structure (SVS) on the directory server (see page 149 and page 155). User Management in ServerView 209

210 Global user management for the irmc S2/S Displaying alert roles After the LDAP v2 structure has been generated, the newly created OU SVS is displayed in Active Directory, for instance, together with the components Alert Roles and Alert Types under Declarations and together with the component Alert Roles under DeptX (see figure 57): Under Declarations, Alert Roles displays all the defined alert roles and all the alert types are displayed under Alert Types (1). Under DeptX, Alert Roles displays all the alert roles that are valid in the OU DeptX (2). (1) (2) Figure 57: OU SVS with alert roles I To ensure that s are sent to the users in the individual alert roles, the relevant department must be configured in irmc S2/S3 (in figure 57: DeptX) (see the manual irmc S2/S3 - integrated Remote Management Controller). 210 User Management in ServerView

211 Global user management for the irmc S2/S3 If you select an alert role (e.g. StdSysAlerts) under SVS Departments DeptX Alert Roles in the structure tree for Active Directory Users and Computers (see figure 58) (1), and open the Properties dialog box for this alert role by choosing Properties Members from the context menu, all the users that belong to the alert role (here: StdSysAlerts) are displayed in the Members tab (2). (2) (1) Figure 58: Users assigned to the alert role StdSysAlert User Management in ServerView 211

212 Global user management for the irmc S2/S Assigning irmc S2/S3 users to an alert role You can assign irmc S2/S3 users to alert roles either on the basis of the user entry, or on the basis of the role entry. In the various different directory services (Microsoft Active Directory, Novell edirectory and OpenLDAP), irmc S2/S3 users are assigned to irmc S2/S3 alert roles in the same way in which irmc S2/S3 users are assigned to irmc S2/S3 authorization roles and using the same tools. In Active Directory, for instance, you make an assignment by clicking Add... in the Properties dialog box of the Active Directory Users and -Computers snap-in (see figure 58 on page 211). 212 User Management in ServerView

213 Global user management for the irmc S2/S SSL copyright The irmc S2/S3-LDAP integration uses the SSL implementation developed by Eric Young on the basis of the OpenSSL Project. User Management in ServerView 213

214 Global user management for the irmc S2/S3 214 User Management in ServerView

215 8 Appendix 2 - Global irmc S4 user management via an LDAP directory service User management for the irmc S4 uses two different types of user identifications: Local user identifications are stored locally in the irmc S4 s non-volatile storage and are managed via the irmc S4 user interfaces. Global user identifications are stored in the central data store of a directory service and are managed via this directory service s interfaces. The following directory services are currently supported for global irmc S4 user management: Microsoft Active Directory Novell edirectory OpenLDAP ForgeRock s OpenDJ (In conjunction with SeverView, this directory service runs in "embedded" mode on JBoss). This chapter provides information on the following topics: User management concept for the irmc S4 User permissions Global user management on the irmc S4 I For details on the local user management for the irmc S4, please refer to the manual irmc S4 - integrated Remote Management Controller. I In SeverView s OpenDJ running in "embedded" mode on JBoss, the E- Mail settings functionality of the irmc S4 is not supported. User Management in ServerView 215

216 User management concept for the irmc S4 8.1 User management concept for the irmc S4 User management for the irmc S4 permits the parallel administration of local and global user identifications. When validating the authentication data (user name, password) which users enter when logging in to one of the irmc S4 interfaces, irmc S4 proceeds as follows (see also figure 59 on page 217): 1. The irmc S4 compares the user name and password with the locally stored user identifications: If the user is authenticated successfully by irmc S4 (user name and password are valid, then the user can log in. Otherwise, the irmc S4 continues the verification with step The irmc S4 authenticates itself at the directory service via LDAP with a user name and password, determines the user rights by means of an LDAP query and checks whether the user is authorized to work with these at the irmc S User Management in ServerView

217 User management concept for the irmc S4 irmc S4 web interface Login SSH Login Telnet Login Serial interface Login SSL SSH User name, password SSL SSH irmc S4 local user identifications SSL User name, password SSL LDAP login Directory service Global user identifications Figure 59: Login authentication via the irmc S4 I Although optional, the use of SSL for the LDAP connection between the irmc S4 and directory service is recommended. An SSL-secured LDAP connection between irmc S4 and the directory service guarantees secure data exchange, and in particular the secure transfer of the user name and password data. SSL login via the irmc S4 web interface is only required if LDAP is active (LDAP enable option, see the manual irmc S4 - integrated Remote Management Controller). User Management in ServerView 217

218 Global user management for the irmc S4 8.2 Global user management for the irmc S4 The global user IDs for the irmc S4 are managed centrally using an LDAP directory service. The following directory services are currently supported for irmc S4 user management: Microsoft Active Directory Novell edirectory OpenLDAP OpenDS / ForgeRock s OpenDJ This section provides you with information about the following topics: Overview of global user management for the irmc S4 Concept of global user management for the irmc S4 using an LDAP directory service Configuring global irmc S4 user management in the directory service (generating the permissions structures specific to irmc S4 in the directory service). Global irmc S4 user management via Microsoft Active Directory Global irmc S4 user management via Novell edirectory Global irmc S4 user management via OpenLDAP / OpenDS / OpenDJ I Alongside the measures described in this section which you perform in the directory service, global user management also requires you to configure the local LDAP settings at the irmc S4. You may configure the local LDAP settings either at the irmc S4 web interface (see the manual irmc S4 - integrated Remote Management Controller), using the Server Configuration Manager. I Please note: Configuring the settings for global irmc S4 user management requires detailed knowledge about the Directory Service used. Only a person who has adequate knowledge of the Directory Service should perform the operation. 218 User Management in ServerView

219 Global user management for the irmc S Overview The global user IDs for the irmc S4 are stored centrally for all platforms in the directory service's directory. This makes it possible to manage the user identifications on a central server. They can therefore be used by all the irmc S4s that are connected to this server in the network. Furthermore, using a directory service for the irmc S4 makes it possible to use the same user identifications for logins at the irmc S4s as are used for the operating system of the managed servers. I Global user management is currently not supported for the following irmc S4 functions: Login via IPMI-over-LAN Console redirection via SOL irmc 1 Login Authentication irmc 2... Login Authentication Directory service Global user identifications irmc n Login Authentication Figure 60: Shared use of the global user identifications by multiple irmcs Communication between the individual irmc S4s and the central directory service is performed via the TCP/IP protocol LDAP (Lightweight Directory Access Protocol). LDAP makes it possible to access the directory services which are most frequently used and most suitable for user management. Optionally, communication via LDAP can be secured by SSL. User Management in ServerView 219

220 Global user management for the irmc S irmc S4 user management via an LDAP directory service (concept) I The concept of directory service-based, global irmc S4 user management described below applies equally to the directory services Microsoft Active Directory, Novell edirectory, OpenLDAP, and OpenDS / OpenDJ. The figures are based on the example of the Active Directory Users and Computers console in the Microsoft Active Directory user interface. I The following characters are reserved as metacharacters for search strings in LDAP: *, \, &, (, ),,!, =, <, >, ~, : You must therefore not use these characters as components of Relative Distinguished Names (RDN) Global irmc S4 user management using roles Global irmc S4 user management via an LDAP directory server requires no extension to the standard directory server schema. Instead, all the information that is relevant for the irmc S4, including the user permissions (privileges), is provided via additional LDAP groups and organizational units (OUs) which are combined in separate OUs in a domain of the LDAP directory server (see figure 62 on page 222). irmc S4 users obtain their privileges by being assigned a role (user role) declared in the organizational unit (OU) SVS. Assigning permissions with user roles (abbreviated to: roles) Global user management on the irmc S4 (firmware version 3.77 or later) controls the assignment of permissions by means of user roles. In this case, each role defines a specific, task-oriented permission profile for activities on the irmc S4. Several roles can be assigned to each user with the result that the permissions for this user are defined by the sum of the permissions of all the assigned roles. 220 User Management in ServerView

221 Global user management for the irmc S4 figure 61 illustrates the concept of role-based assignment of user permissions with the roles Administrator, Maintenance, Observer and UserKVM. Mr. Miller Ms. Smith Mr. Baker Administrator Maintenance Observer UserKVM User Mgmnt. AVR Rem. Storage irmc Settings irmc Info Figure 61: Role-based assignment of user permissions The concept of user roles offers important advantages, including: The individual permissions do not need to be assigned to each user or user group individually. Instead, they are assigned to the user role. It is only necessary to adapt the permissions of the user role in the event that the permission structure changes. User Management in ServerView 221

222 Global user management for the irmc S Organizational unit (OU) SVS The firmware for the irmc S4 supports LDAP v2 structures that are stored in the OU SVS. LDAP v2 structures are all set for future functional extensions. SVS contains the OUs Declarations, Departments and User Settings: Declarations contains a list of the defined roles and the list of predefined irmc S4 user permissions. Departments contains the groups for the user privileges. User Settings contains details specific to users or user groups such as the mail format (for alerting) and the groups for the user shells. I In the case of Microsoft Active Directory, for example, the entries for the irmc S4 users are located in the standard OU Users. Unlike the standard users, however, irmc S4 users are also members of one or more groups of the OU SVS. I Important note: Operating both ServerView user management and irmc S4 global user management within the same Organizational Unit (OU) SVS requires that the irmc S4 is configured to belong to the DEFAULT department. Figure 62: The OU SVS in the domain fwlab.firm.net 222 User Management in ServerView

223 Global user management for the irmc S4 I As of Version 3.6x of the firmware, the user entries for the irmc S4 can be located at any points below the base domain. Permission groups can also be located at any point within the base domain Cross-server, global user permissions In large enterprises, the servers which are managed via irmc S4 are usually assigned to different departments. Furthermore, the administrator permissions for the managed servers are also often assigned on a department-specific basis. I Important note: Operating both ServerView user management and irmc S4 global user management within the same Organizational Unit (OU) SVS requires that the irmc S4 is configured to belong to the DEFAULT department. Departments are combined in the OU Departments The OU Departments combines the servers which are managed by irmc S4 to form a number of groups. These correspond to the departments in which the same user IDs and permissions apply. In figure 63 on page 224, for example, these are the departments DeptX, DeptY and Others. The entry Others is optional, but recommended. Others is a predefined department name subsuming all those servers which do not belong to another department. There are no restrictions concerning the number of departments (OUs) listed under Departments. I When configuring the directory service at the irmc S4 via the irmc S4 web interface (see the manual irmc S4 - integrated Remote Management Controller) or via the Server Configuration Manager you specify the name of the department to which the managed server with the relevant irmc S4 belongs. If there is no department of this name in the LDAP directory, then the permissions present in the Others department are used. figure 63 on page 224 presents an example of this type of organizational structure on the basis of Active Directory Users and Computers. User Management in ServerView 223

224 Global user management for the irmc S4 Figure 63: Organizational structure of the domain fwlab.firm.net 224 User Management in ServerView

225 Global user management for the irmc S SVS: Permission profiles are defined via roles The associated user roles (authorization roles) that are required are listed directly below each department (figure 63 on page 224). All the roles listed here must be defined in the OU Declarations. Otherwise, there are no restrictions concerning the number of roles. The names of the roles can be chosen as required subject to certain syntactic requirements imposed by the employed directory service. Each authorization role defines a specific, task-oriented permission profile for activities on the irmc S4. I The alert roles are listed as well as the authorization roles. Each alert role defines a specific alerting profile for alerting (see section Configuring alerting to global irmc S4 users on page 284). Displaying user roles If you select a department (e.g. DeptX) under SVS in the structure tree for Active Directory Users and Computers (see figure 64) (1) and expand the associated nodes DeptX Authorization Roles, the user roles defined for this department (here: DeptX) are displayed (2). (1) (2) Figure 64: Display of the user roles in the Users and Computers snap-in User Management in ServerView 225

226 Global user management for the irmc S4 Displaying the Active Directory folders to which a user is member of If you select a user (e.g. kvms4) under Users in the structure tree for Active Directory Users and Computers (see figure 65) (1) and open the Properties dialog box for this user by choosing Properties Members from the context menu, the permission groups to which the user belongs (here: kvms4) are displayed in the Members tab (2). (2) (1) Figure 65: Properties dialog box for the user kvms4 226 User Management in ServerView

227 Global user management for the irmc S SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures To allow global irmc S4 user management to be able to handled using a directory service, the structure(s) (OU) SVS must be created in the LDAP directory service. You use the SVS_LdapDeployer to generate and modify the SVS structures. The SVS_LdapDeployer is a Java archive (SVS_LdapDeployer.jar) provided on your ServerView Suite DVD. This section describes: The configuration file of the SVS_LdapDeployer SVS_LdapDeployer The commands and options of the SVS_LdapDeployer Typical application scenarios Configuration file (XML file) SVS_LdapDeployer generates LDAP structures on the basis of an XML configuration file. This input file contains the structure information for the structure(s) SVS structure in XML syntax. I The syntax of the configuration file is illustrated in the sample configuration files Generic_Settings.xml and Generic_InitialDeploy.xml that are supplied together with the jar archive SVS_LdapDeployer.jar on ServerView Suite DVD. I Valid connection data for the connection to the directory server must always be entered under <Settings> in the input file. You can also optionally enter the authentication data for accessing the server. Alternatively, you can specify the authentication data in the command line of the SVS_LdapDeloyer. If you do not specify the authentication data in the configuration file or in the command line when calling the SVS_LdapDeployer, the SVS_LdapDeployer prompts you to enter the authentication data at runtime. User Management in ServerView 227

228 Global user management for the irmc S Starting SVS_LdapDeployer Proceed as follows to start the SVS_LdapDeployer: Save the Java archive (jar archive) SVS_LdapDeployer.jar in a folder on the directory server. Open the command interface of the directory server. Switch to the folder in which the jar archive SVS_LdapDeployer.jar has been stored. Call the SVS_LdapDeployer using the following syntax: java -jar SVS_LdapDeployer.jar <command> <file> [<option>...] I You are informed about the various steps that are being performed while the SVS_LdapDeployer is running. You will find detailed information in the file log.txt, which is created in the execution folder every time that SVS_LdapDeployer is run. I In the following, the terms "LDAPv1 structure" and "LDAPv2 structure" are used to denote ServerView-specific configuration layouts of the authorization data and do not refer to version 1 and 2 of the LDAP protocol. I The -import and -sychronize commands (see below) are only needed in connection with LDAPv1 structures (irmc S2s with a firmware version < 3.77 and irmcs). For detail please refer to the manuals "irmc S2 - integrated Remote Management Controller" edition May 2011 and former editions. "irmc - integrated Remote Management Controller". <command> Specifies the action to be performed. The following commands are available: -deploy Creates an LDAP structure for global RMC S4 user management on the directory server (see page 230). -delete Deletes an LDAP structure used for global irmc S4 user management from the directory server (see page 232). 228 User Management in ServerView

229 Global user management for the irmc S4 <file> -import Creates an equivalent LDAP v2 structure from an existing LDAP v1 structure. -synchronize Makes corresponding changes in an existing LDAP v1 structure to reflect any changes that you make in an LDAP v2 structure. The configuration file (.xml) used as an input file by SVS_LdapDeploy. This configuration file contains the structure information for the SVS structure in XML syntax. I The syntax of the configuration file is illustrated in the sample configuration files Generic_Settings.xml and Generic_InitialDeploy.xml that are supplied together with the jar archive SVS_LdapDeployer.jar on ServerView Suite DVD. <option> [<option>...] Option(s) that control execution of the specified command. The following sections describe in detail the individual commands available in SVS_LdapDeployer together with the associated options. I The SVS_LdapDeployer generates all the required subtrees including all the groups but not the relations between users and groups. You create and assign user entries to groups by means of the corresponding tools in the employed directory service after generating the OU SVS in the directory service. User Management in ServerView 229

230 Global user management for the irmc S deploy: Create or modify an LDAP v2 structure The -deploy command allows you to create a new LDAP structure on the directory server or to add new entries to an existing LDAP structure. I Before you delete entries from an existing LDAP structure, you must first delete the LDAP structure itself using -delete (see page 232) and then generate it again using a suitably adapted configuration file. Syntax: -deploy <file> [-structure {v1 v2 both}] [ -username <user>] [ -password <password>][ -store_pwd <path>][ -kloc <path>] [ -kpwd [<key-password>]] <file> XML file containing the configuration data. I The <Data> section in the configuration file must contain all the necessary roles and departments required for initially generating or expanding a structure. -structure v1 -structure v2 -structure both Creates an LDAP v1 structure or an LDAP v2 structure or an LDAP v1 and an LDAP v2 structure. I User management for the irmc S4 always requires an LDAP v2 structure. -username <user> User name for logging in to the directory server. -password <password> Password for the user <user>. 230 User Management in ServerView

231 Global user management for the irmc S4 -store_pwd Encrypts the password <password> using a randomly generated key and saves the encrypted password in the configuration file after -deploy has been executed successfully. By default, the randomly generated key is stored in the folder in which the SVS_LdapDeployer is executed. V CAUTION! You should save the randomly generated key in a safe place. If the predefined target folder is not adequate for your security needs, or if the folder in which the key is saved can also be accessed by other users, use the options -kloc and -kpwd to save the key securely. -kloc <path> Saves the randomly generated key under <path>. If you do not specify this option, the key is saved in the folder in which SVS_LdapDeployer is executed. -kpwd [<password>] Specifies a password to protect the randomly generated key. If you do not specify <password>, the password is automatically generated on the basis of a snapshot of the current runtime environment. User Management in ServerView 231

232 Global user management for the irmc S delete: Deleting an LDAPv2 structure The -delete command allows you to remove an LDAPv2 structure from the directory server. Syntax: -delete <file> [-structure {v1 v2 both}] [ -username <user>] [ -password <password>][ -store_pwd <path>][ -kloc <path>] [ -kpwd [<key-password>]] <file> XML file that specifies the structure to be deleted. -structure v1 -structure v2 -structure both Deletes an LDAP v1 structure or an LDAP v2 structure or an LDAP v1 and an LDAP v2 structure. I irmc S4 always requires an LDAP v2 structure. -username <user> User name for logging in to the directory server. -password <password> Password for the user <user>. -stor_pwd Encrypts the password <password> using a randomly generated key and saves the encrypted password in the configuration file after -delete has been executed successfully. By default, the randomly generated key is stored in the folder in which the SVS_LdapDeployer is executed. V CAUTION! You should save the randomly generated key in a safe place. If the predefined target folder is not adequate for your security needs, or if the folder in which the key is saved can also be accessed by other users, use the options kloc and -kpwd to save the key securely. -kloc <path> Saves the randomly generated key under <path>. If you do not specify this option, the key is saved in the folder in which SVS_LdapDeployer is executed. 232 User Management in ServerView

233 Global user management for the irmc S4 -kpwd [<password>] Specifies a password to protect the randomly generated key. If you do not specify <password>, the password is automatically generated on the basis of a snapshot of the current runtime environment Typical application scenarios Two typical scenarios for using SVS_LdapDeployer are described below Performing an initial configuration of an LDAP v2 structure You wish to set up global user management for an irmc S4 (firmware 3.77 or later) for the first time. In order to do this, you require an LDAP v2 structure. Recommended method: Generate the Department definition for LDAP v2 structures (SVS): java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml -structure v Re-generating or expanding an LDAP v2 structure You wish to re-generate an LDAP v2 structure or expand an existing LDAP v2 structure. Recommended method: java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml -structure -structure v2 or java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml User Management in ServerView 233

234 Global user management for the irmc S Re-generating an LDAP v2 structure and prompting for and saving authentication data You wish to re-generate an LDAP v2 structure. The authentication data is to be provided and saved using the command line. Recommended method: java -jar SVS_LdapDeployer.jar -deploy myinitialdeploy.xml -store_pwd -username admin -password admin I After the login data has been saved, you can connect to the directory server using SVS_LdapDeployer without specifying a user name and password. The SVS_LdapDeployer then uses the values stored in the XML configuration file, provided that these are available. SVS_LdapDeployer can only use a saved password if it can decrypt it. This requires you to execute SVS_LdapDeployer in the same runtime environment that applied for the previous call with -store_pwd (see page 231). In this context, the same runtime environment means the same the user on the same computer or a user with permission to access the folder under which they key is stored (-kloc option, see page 231). I You can also use user accounts that have already been saved when you call SVS_LdapDeployer in the future. Furthermore, other authentication data can also be used temporarily by explicitly specifying the data in the command line or when requested to do so by SVS_LdapDeployer. 234 User Management in ServerView

235 Global user management for the irmc S irmc S4 user management via Microsoft Active Directory This section describes how you integrate irmc S4 user management in Microsoft Active Directory. I Prerequisite: An LDAP v2 structure has already been generated in the Active Directory service (see section SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures on page 227). You must perform the following steps to integrate irmc S4 user management in Microsoft Active Directory: 1. Configure irmc S4 LDAP/SSL access at the Active Directory server. 2. Assign irmc S4 users to irmc S4 user groups in Active Directory. User Management in ServerView 235

236 Global user management for the irmc S Configuring irmc S4 LDAP/SSL access at the Active Directory server I The irmc S4-LDAP integration uses the SSL implementation developed by Eric Young on the basis of the OpenSSL Project. A reproduction of the SSL copyright can be found on page 292. An RSA certificate is required before irmc S4 can use LDAP via SSL. The following steps are involved in configuring LDAP access: 1. Install an Enterprise CA 2. Generate an RSA certificate for the domain controller. 3. Install the RSA certificate on the server Installing the Enterprise CA I A CA is a certification authority for certificates. An Enterprise CA (certification authority for enterprises) can be installed on the domain controller itself or on another server. Installation directly on the directory server is simpler since fewer steps are required than when installing on another server. Below is a description of how to install the Enterprise CA on a server other than the domain controller. I To install and configure Enterprise CA successfully, you require an Active Directory environment and an installed IIS (Internet Information Services). Proceed as follows to install an Enterprise CA: In the Windows start menu, choose: Start - Control Panel - Software - Add/Remove Windows Components In the wizard for Windows components, choose Certificate Services under Components. Double-click on Certificate Services and make sure that the Certificate Services Web Enrollment Support and Certificate Services CA options are selected. Choose Enterprise root CA. Select the option Use custom settings to generate the key pair and CA certificate. 236 User Management in ServerView

237 Global user management for the irmc S4 Select Microsoft Base DSS Cryptographic Provider to create DSA certificates of length 1024 bytes. Export the public certification authority certificate (CA Certificate). To do this, proceed as follows: Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Navigate to Certificates (Local Computer) - Trusted Root Certification Authorities - Certificates and double-click. Double-click on the certificate from the newly created certification authority. Click on the Details tab in the certificate window. Click on Copy to File. Choose a file name for the certification authority certificate and click on Finish. Load the public certification authority certificate to the certificate directory Trusted Root Certification Authorities on the domain controller. To do this, proceed as follows: Transfer the file containing the certification authority certificate to the domain controller. In Windows Explorer, open the certificate from the newly created certification authority. Click on Install Certificate. Under Place all certificates in the following store click on Browse and choose Trusted Root Certification Authorities. Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Add the snap-in for the current user s certificates. Copy the certification authority certificate (CA Certificate) from the current user s Trusted Root Certification Authorities directory to the local computer's Trusted Root Certification Authorities. User Management in ServerView 237

238 Global user management for the irmc S4 Creating a domain controller certificate Proceed as follows to create an RSA certificate for the domain controller: Create a file named request.inf with the following content: [Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=<full path of domain controller host>" KeySpec = 1 KeyLength = 1024 Exportable = TRUE MachineKeySet = TRUE SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID= ; this is for Server Authentication In the file request.inf, adapt the specification under Subject= to the name of the employed domain controller, e.g. Subject = CN=domino.fwlab.firm.net. Enter the following command in the Windows prompt window: certreq -new request.inf request.req Enter the following URL in the certification authority browser: Click on Request a Certificate. Click on advanced certificate request. Click on Submit a certificate request. Copy the content of the file request.req to the Saved Request window. Select the Web Server certificate template. Download the certificate and save it (e.g. in the file request.cer). 238 User Management in ServerView

239 Global user management for the irmc S4 Enter the following command in the Windows prompt window: certreq -accept request.cer Export the certificate with the private key. To do this, proceed as follows: Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Navigate to Certificates (Local Computer) - Personal Certificates - Certificates. Double-click on the new server certification authentication certificate. Click on the Details tab in the certificate window. Click on Copy to File. Select Yes, export the private key. Assign a password. Choose a file name for the certificate and click on Finish. User Management in ServerView 239

240 Global user management for the irmc S4 Installing the domain controller certificate on the server Proceed as follows to install the domain controller certificate on the server: Copy the domain controller certificate file that has just been created to the domain controller. Double-click on the domain controller certificate. Click on Install Certificate. Use the password which you assigned when exporting the certificate. Under Place all certificates in the following store click on Browse and choose Personal Certificates. Enter mmc in the Windows prompt window to start the Management Console. Add the snap-in for local computer certificates. Add the snap-in for the current user s certificates. Copy the domain controller certificate from the current user s Personal Certificates directory to the local computer's Personal Certificates directory. 240 User Management in ServerView

241 Global user management for the irmc S Assigning user roles to an irmc S4 user You can assign user roles (authorization roles) to irmc S4 users either on the basis of the user entry, or on the basis of the role entry / group entry I The example below uses the LDAP v2 structure to describe assignment based on the role entry in the OU SVS. The assignment procedure on the basis of the user entry is very similar. I The users must be entered in the groups manually in Active Directory. Proceed as follows: Open the snap-in Active Directory Users and Computers. Figure 66: Active Directory Users and Computers snap-in Double-click the authorization role (here: Administrator). The Administrator Properties dialog opens (see figure 67 on page 242): User Management in ServerView 241

242 Global user management for the irmc S4 Figure 67: Administrator Properties dialog Select the Members tab. Click on the Add... button. The Select Users, Contacts, or Computers dialog opens (see figure 68 on page 243). 242 User Management in ServerView

243 Global user management for the irmc S4 Figure 68: Select Users, Contacts, or Computers dialog Click on the Locations... button. The Locations dialog opens. Figure 69: Locations dialog Select the container (OU) containing your users. (By default, this is the OU Users.) Click OK to confirm. The Select Users, Contacts, or Computers dialog opens (see figure 70 on page 244). I Users may also be entered at a different location in the directory. User Management in ServerView 243

244 Global user management for the irmc S4 Figure 70: Select Users, Contacts, or Computers dialog Click on the Advanced... button. The Select Users, Contacts, or Computers extended dialog opens (see figure 71 on page 245). 244 User Management in ServerView

245 Global user management for the irmc S4 Figure 71: Select Users, Contacts, or Computers dialog - searching Click the Find Now button to display all the users in your domain. Under Search results: in the display area you can now view the search result (see figure 72 on page 246). User Management in ServerView 245

246 Global user management for the irmc S4 Figure 72: Select Users, Contacts, or Computers dialog - displaying the search results Select the users who are to be added to the group and click OK to confirm. The selected users are now displayed (see figure 73 on page 247). 246 User Management in ServerView

247 Global user management for the irmc S4 Figure 73: Select Users, Contacts, or Computers dialog - confirming the search results Confirm by clicking OK. User Management in ServerView 247

248 Global user management for the irmc S irmc S4 user management via Novell edirectory This section provides you with information about the following topics: The Novell edirectory system components and system requirements Installing Novell edirectory Configuring Novell edirectory Integrating irmc S4 user management in Novell edirectory Tips on administering Novell edirectory. I The installation and configuration of Novell edirectory are described in detail below. No extensive edirectory knowledge is required. If you are already familiar with Novell edirectory, you can skip the next three sections and continue with section Integrating irmc S4 user management in Novell edirectory on page Software components and system requirements I Use the specified version or a more recent version of the components listed below. Novell edirectory (formerly NDS) consists of the following software components: edirectory 8.8: _0800_Linux_88-SP1_FINAL.tar.gz edirectory 8.8: edir_88_iman26_plugins.npm imanager: iman_26_linux_64.tgz for SuSE, iman_26_linux_32.tgz otherwise ConsoleOne: c1_136f-linux.tar.gz The following system requirements must be fulfilled in order to install and operate Novell edirectory: OpenSSL must be installed. I If OpenSSL is not already installed: 512 MB free RAM Install OpenSSL, before starting the Novell edirectory installation. 248 User Management in ServerView

249 Global user management for the irmc S Installing Novell edirectory To install Novell edirectory, it is necessary to install the following components: edirectory Server and administrations utilities imanager (administrations utility) ConsoleOne (administrations utility) I Prerequisites for the installation of Novell edirectory: A Linux server operating system must be fully installed and running. The firewall must be configured for connections to the following ports: 8080, 8443, 9009, 81, 389, 636. For OpenSuSE, you configure this in the file /etc/sysconfig/susefirewall2: Add the entry FW_SERVICES_EXT_TCP to the file /etc/sysconfig/susefirewall2 as follows: FW_SERVICES_EXT_TCP=" " In accordance with the edirectory Installation Guide, the system must be set up for multicast routing. For SuSE Linux, proceed as follows: Create or (if it already exists) open the file /etc/sysconfig/network/ifroute-eth0. Add the following line to /etc/sysconfig/network/ifroute-eth0: eth0 This adapts eth0 to the system configuration. User Management in ServerView 249

250 Global user management for the irmc S4 I Prerequisites for the installation of the edirectory Server, the edirectory utilities, the imanager and ConsoleOne: The root permission is required in order to perform installation. All the files required for the installation must have been copied to a directory (e.g. /home/edirectory) before you can use the procedure below to perform installation. These files are as follows: _0800_Linux_88-SP1_FINAL.tar.gz iman_26_linux_64.tgz c1_136f-linux.tar.gz Installing the edirectory Server and administration utilities Proceed as follows: Log in with root permission (superuser). Switch to the directory containing the files required for installation (in our example: /home/edirectory): cd /home/edirectory Extract the archive _0800_Linux_88-SP1_FINAL.tar.gz: tar -xzvf _0800_Linux_88-SP1_FINAL.tar.gz After extraction, /home/edirectory has a new subdirectory named edirectory. Installing edirectory Server Go to the setup subdirectory of this edirectory directory: cd edirectory/setup Call the installation script./nds-install :./nds-install Accept the EULA with y and confirm with the [Enter] key. If you are asked which program you want to install: Enter 1 to install the Novell edirectory server and press the [Enter] key to confirm. The edirectory packages are then installed. 250 User Management in ServerView

251 Global user management for the irmc S4 After installation of the Novell edirectory Server, you must update the names for the paths to the edirectory in a number of environment variables and export these variables. To do this, open your configuration file (in the example: /etc/bash.bashrc) and enter the following lines in the specified sequence ahead of # End of... : export PATH/opt/novell/eDirectory/bin:/opt/novell/eDirectory/ sbin:$path export LD_LIBRARY_PATH=/opt/novell/eDirectory/lib:/ opt/novell/edirectory/lib/nds-modules:/opt/novell/ lib:$ld_library_path export MANPATH=/opt/novell/man:/opt/novell/eDirectory/ man:$manpath export TEXTDOMAINDIR=/opt/novell/eDirectory/share/ locale:$textdomaindir Close the terminal and open a new terminal in order to export the environment variables. Installing the edirectory administration utilities Go to the setup subdirectory of the edirectory directory: cd edirectory/setup Call the installation script:./nds-install Accept the EULA with y and confirm with the [Enter] key. If you are asked which program you want to install: Enter 2 to install the Novell edirectory administration utilities and press the [Enter] key to confirm. The edirectory administration utilities are then installed. User Management in ServerView 251

252 Global user management for the irmc S4 Installing and calling imanager I imanager is the recommended tool for installing Novell edirectory. Whether installing in SLES10 or in OpenSuSE, you use the archive *_64.tgz. Proceed as follows: Log in with root permission (superuser). Go to the directory /home/edirectory: cd /home/edirectory Extract the archive iman_26_linux_64.tgz: tar -xzvf iman_26_linux_64.tgz After extraction, /home/edirectory has a new subdirectory named imanager. Go to the installs subdirectory of imanager: cd imanager/installs/linux Call the installation script:./imanagerinstalllinux.bin Select the language for the output of installation messages. Click through and accept the EULA. Select 1- Novell imanager 2.6, Tomcat, JVM for imanager installation. Select 1- Yes for plug-in download. Press [Enter] to use the default path for the download. The installation program searches the internet for downloads. This can take a few minutes. You are then asked to select the plug-ins that you want to install. Select All to download all the plug-ins. Select 1- Yes to install the locally available plug-ins. Press [Enter] to use the default path for installation. Select 2- No for automatic Apache configuration (optional). Accept the default port (8080) for Tomcat. Accept the default SSL port (8443) for Tomcat. 252 User Management in ServerView

253 Global user management for the irmc S4 Accept the default JK connector port (9009) for Tomcat. Enter the administration user ID (e.g. root.fts ) for the user with the appropriate administration permissions. Enter the tree name (e.g. fwlab ) for the user with the appropriate administration permissions. Accept the summary of your entries which is displayed with 1-OK... in order to terminate installation. Logging in to Novell imanager After installation, you can use the following URL to log in at imanager via a web browser. address of the edirectory server>:8443/nps I Novell recommends that you use Microsoft Internet Explorer or Mozilla Firefox as your web browser. In Mozilla Firefox, it is possible that not all the context menu's pop-up windows will be displayed. User Management in ServerView 253

254 Global user management for the irmc S4 Installing and starting ConsoleOne ConsoleOne is another administration tool for Novell edirectory. Proceed as follows to install ConsoleOne: Log in with root permission (superuser) at edirectory Server. Go to the directory /home/edirectory: cd /home/edirectory Extract the ConsoleOne archive c1_136f-linux.tar.gz: tar -xzvf c1_136f-linux.tar.gz After extraction, /home/edirectory has a new subdirectory named Linux. Go to the directory Linux: cd Linux Call the installation script c1-install:./c1-install Select the language for the output of installation messages. Enter 8 to install all the snap-ins. ConsoleOne needs the path to an installed Java runtime environment. You can export the corresponding path name to the environment variable C1_JRE_HOME. However, the system-wide export of the path name requires modifications in the bash profile. I Since root permission is required in order to work with ConsoleOne, it is, in principle, sufficient to export the ID superuser Root. However, the system-wide export of the path name is presented below. This means that normal users can also work with ConsoleOne if they have root permission. 254 User Management in ServerView

255 Global user management for the irmc S4 Proceed as follows: Open the configuration file for editing (in the example: /etc/bash.bashrc) Enter the following line in the configuration file in front of # End of... : export C1_JRE_HOME=/opt/novell/j2sdk1.4.2_05/jre I The java runtime environment installed together with edirectory is used here. However, you can also specify the path name of any other Java runtime environment installed on the edirectory Server. ConsoleOne obtains the available tree hierarchies either via the local configuration file hosts.nds or via the SLP service and multicast. Proceed as follows to insert your tree hierarchy in the configuration file: Go to the configuration directory: cd /etc Generate the file hosts.nds if it does not yet exist. Open the file hosts.nds and insert the following lines: #Syntax: TREENAME.FQDN:PORT MY_Tree.mycomputer.mydomain:81 Starting ConsoleOne You start ConsoleOne in the system prompt using the following command: /usr/consoleone/bin/consoleone User Management in ServerView 255

256 Global user management for the irmc S Configuring Novell edirectory Perform the following steps to configure Novell edirectory: 1. Create an NDS tree 2. Configure edirectory for LDAP. 3. Test edirectory access via LDAP Browser. Creating an NDS tree Create an NDS (Network Directory Service) tree using the utility ndsmanage. ndsmanage requires the following information to do this: TREE NAME Unique name in the network for the new NDS tree, e.g. MY_TREE. Server Name Name of an instance of server class in edirectory. For Server Name,you specify the name of the PRIMERGY server on which the LDAP server is running, for example. lin36-root-0. Server Context Fully distinguished name (fully distinguished name of the object path and attributes) of the container which contains the server object, e.g. dc= organization.dc=mycompany. Admin User Fully distinguished name (fully distinguished name of the object path and attributes) of the user with permission to perform administration, e.g. cn= admin.dc=organization.dc=mycompany NCP Port Specify port 81. Instance Location Specify the path: /home/root/instance0 Configuration File Specify the following file: /home/root /instance0/ndsconf Password for admin user Enter the administrator password here. 256 User Management in ServerView

257 Global user management for the irmc S4 Proceed as follows to configure the NDS tree: Open a command box. Go to the directory /home/edirectory. Start the utility ndsmanage by entering the command ndsmanage: ndsmanage Enter c to generate a new instance of the class server. Enter y to continue configuration. Enter y to create a new tree. ndsmanage then queries the values for TREE NAME, Server Name, Server Context etc. in sequence (see page 256). Once input is complete, ndsmanage configures the NDS tree. After configuring the NDS tree, restart the PRIMERGY server in order to activate the configuration, i.e. to recreate the NDS tree. Configuring edirectory for LDAP The following steps are involved in configuring edirectory for LDAP: Install Role Based Services (RBS) Install plug-in modules Configure Role Based Services (RBS) Configure edirectory with/without SSL/TLS support Proceed as follows to complete the individual points: Log in under the administrator ID (Admin) at imanager via a web browser. User Management in ServerView 257

258 Global user management for the irmc S4 Installing Role Based Services (RBS). Install RBS using the imanager Configuration Wizard. Proceed as follows: In imanager, select the Configure tap (by clicking on the desk icon). In the Configure tab, select Role Based Services - RBS Configuration Start the RBS Configuration Wizard. Assign RBS2 to the container that is to be managed. (In the example above, this is mycompany.) Installing plug-in modules Proceed as follows: In imanager, select the Configure tap (by clicking on the desk icon). In the Configure tab, select Plug-in installation - Available Novell Plug-in Modules In the modules listed in the page Available Novell Plug-in Modules, select the edirectory-specific package edir_88_iman26_plugins.npm. Click Install. Configuring Role Based Services (RBS) In the page Available Novell Plug-in Modules, select all the modules that are required for LDAP integration. If you are not certain, select all the modules. Click Install. Configuring edirectory for SSL/TLS-secured access I During edirectory installation, a temporary certificate is generated with the result that access to the edirectory is secured by SSL/TLS by default. However, since the irmc S4 firmware is configured for the use of RSA/MD5 certificates, SSL/TLS-secured, global irmc S4 user management via edirectory requires an RSA/MD5 certificate of 1024 bytes in length. 258 User Management in ServerView

259 Global user management for the irmc S4 You create an RSA/MD5 certificate of length 1024 bytes as follows using ConsoleOne: Log into the LDAP server under your administrator ID (Admin) and start ConsoleOne. Navigate to your corporate structure's root directory (e.g. treename/mycompany/myorganisation). Select New Object - NDSPKI key material - custom to create a new object of class NDSPKI:Key Material. In the dialog which is then displayed, specify the following values: bits 2. SSL or TLS 3. signature RSA/MD5 A new signature of the required type is created. To activate the newly created certificate for the SSL-secured LDAP connection, perform the following steps in imanager: Start imanager via the web browser. Log in at imanager with valid authentication data. Select LDAP - LDAP Options - LDAP Server - Connection. The Connection tab contains a drop-down list which displays all the certificates installed on the system. Select the required certificate in the drop-down list. Configuring edirectory for non-ssl-secured access I Anonymous login and the transfer of plain text passwords via nonsecured channels are deactivated by default in edirectory. Consequently, web browser login at the edirectory server is only possible via an SSL connection. If you want to use LDAP without SSL then you must perform the following steps: 1. Enable a non-ssl-secured LDAP- connection. 2. Relax the bind restrictions. 3. Reload the LDAP configuration. User Management in ServerView 259

260 Global user management for the irmc S4 Proceed as follows: 1. Enable a non-ssl-secured LDAP- connection. Start imanager via the web browser. Log in at imanager with valid authentication data. Select the Roles and Tasks view. Select LDAP - LDAP Options - LDAP Server - Connection. In the Connection tab, deactivate the option Require TLS for all Operations. Select LDAP - LDAP Options - LDAP Group - General. In the General tab, deactivate the option Require TLS for Simple Binds with password. 2. Relax the bind restrictions. Log in at imanager with valid authentication data. In the object tree, navigate to the LDAP Server object. Click with the mouse to highlight the LDAP Server object and select Modify Object in the associated context menu. In the right-hand content frame, open the Other sheet. Under Valued Attributes, select ldapbindrestrictions Click the Edit button. Set the value to 0. Click OK. In the Other sheet, click the Apply button. 3. Reload the LDAP configuration. Start ConsoleOne and log in to edirectory. Click on the Base DN object at the left of the window (e.g. Mycompany). The LDAP server object is then displayed on the right-hand side of the window. Right-click to highlight the LDAP Server object and select Properties... in the associated context menu. In the General tab, click Refresh NLDAP Server Now. 260 User Management in ServerView

261 Global user management for the irmc S4 Testing edirectory access via LDAP Browser. After successfully completing steps 1-3 above, you should be able to establish a connection to edirectory via the LDAP Browser utility. You can use Jarek Gavor's LDAP Browser (see page 278) to test this connection as follows: Try to log in at edirectory under the administrator ID (in the example: admin) via an SSL connection. If this attempt fails, proceed as follows: Check that SSL is active (see page 259). Figure 74: Testing LDAP access to edirectory: SSL activated Try to log in at edirectory under the administrator ID (in the example: admin) via a non-ssl-secured connection. User Management in ServerView 261

262 Global user management for the irmc S4 Figure 75: Testing LDAP access to edirectory: SSL not activated If the login fails again: Relax the bind restrictions (see page 259) Integrating irmc S4 user management in Novell edirectory I Prerequisite: An LDAP v2 structure has already been generated in the edirectory directory service (see section SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures on page 227). You must perform the following steps in order to integrate irmc S4 user management in Novell edirectory: Generating the principal irmc user. Declare the irmc groups and user permissions in edirectory. Assign users to the permission groups. 262 User Management in ServerView

263 Global user management for the irmc S4 LDAP authentication process for irmc S4 users in edirectory The authentication of a global irmc S4 user on login at the irmc S4 is performed in accordance with a predefined process (see page 216). figure 76 on page 263 illustrates this process for global irmc S4 user management with Novell edirectory. The establishment of a connection and login with the corresponding login information is referred to as a BIND operation. SSL-based communication irmc S4: Bind as Principal User 1 irmc S4 is authenticated irmc S4 2 3 irmc S4 determines the fully-qualified DN of User1 Bind with User1's DN User1 is authenticated edirectory User permissions 4 irmc S4 determines the user permissions of User1 1) The irmc S4 logs in at the edirectory server with the predefined, known permission data (irmc S4 setting) as Principal User and waits for the successful bind. 2) The irmc S4 asks the edirectory server to provide the fully qualified Distinguished Name (DN) of the user with cn=user1. edirectory determines the DN from the preconfigured subtree (irmc S4 setting). 3) The irmc S4 logs in at the edirectory server with the fully-qualified DN of the user User1 and waits for the successful bind. 4) The irmc S4 asks the edirectory server to provide the user permissions of the user User1. Figure 76: Authentication diagram for global irmc S4 permissions User Management in ServerView 263

264 Global user management for the irmc S4 I You configure the Principal User's permission data and the subtree which contains the DNs in the page Directory Service Configuration page of the irmc S4 web interface (see the manual irmc S4 - integrated Remote Management Controller). I A user's CN must be unique within the searched subtree. Creating the Principal User for the irmc S4 Proceed as follows to create the Principal User for the irmc S4: Log in at imanager with valid authentication data. Select Roles and Tasks. Select Users - Create User. Enter the necessary specifications in the displayed template. I The Principal User's Distinguished Name (DN) and password must match the corresponding specifications for the irmc S4 configuration (see the manual irmc S4 - integrated Remote Management Controller). The user's Context: may be located at any position in the tree. Assign the Principal User search permissions for the following subtrees: Subtree (OU) SVS Subtree (OU) that contains the users (e.g. people). Assigning user permissions to the irmc groups and users By default, an object in edirectory possesses only very limited query and search permissions in an LDAP tree. If an object is to be able to query all the attributes in one or more subtrees, you must assign this object the corresponding permissions. You may assign permissions either to an individual object (i.e. a specific user) or to a group of objects which are collated in the same organizational unit (OU) such as SVS or people. In this case, the permissions assigned to an OU and identified as inherited are automatically passed on to the objects in this group. 264 User Management in ServerView

265 Global user management for the irmc S4 I To integrate irmc S4 user management in Novell edirectory, it is necessary to assign search permissions to the following objects (trustees): Principal User Subtree which contains the irmc S4 users Detailed information on how to do this can be found below. Proceed as follows to assign an object search permissions for all attributes: Start imanager via the web browser. Log in at imanager with valid authentication data. In imanager, click the Roles and Tasks button. In the menu tree structure, select Rights - Rights to Other Objects. The page Rights to Other Objects is displayed. Under Trustee Name, specify the name of the object (in figure 77 on page 266 SVS.sbdr4) to which the permission is to be granted. Under Context to Search From, specify the edirectory subtree (SVS) which imanager is to search through for all the objects for which the trustee Users currently has read permission. Click OK. A progress display indicates the status of the search. Once the search operation has been completed, the page Rights to Other Objects is displayed with the results of the search (see figure 77 on page 266). User Management in ServerView 265

266 Global user management for the irmc S4 Figure 77: imanager - Roles and Tasks - Rights To Other Objects I If no object is displayed under Object Name, then the trustee currently has no permissions within the specified context. Assign the trustee additional permissions if necessary: Click Add Object. Use the object selector button to select the object for which you want to assign the trustee a permission. Click Assigned Rights. If the property [All Attributes Rights] is not displayed: Click Add Property. The Add Property window is displayed (see figure 78 on page 267). 266 User Management in ServerView

267 Global user management for the irmc S4 Figure 78: imanager - Roles and Tasks - Rights To Other Objects - Add Property Highlight the property [All Attributes Rights] and click OK to add it. For the property [All Attributes Rights], enable the options Compare, Read and Inherit and click OK to confirm. This authorizes the user/user group to query all the attributes in the selected object's subtree. Click Apply to activate your settings. User Management in ServerView 267

268 Global user management for the irmc S Assigning an irmc S4 user to a permission group You can assign irmc S4 users (for instance from the OU people) to the irmc permission groups either starting from the user entry (preferable if there only a few user entries) or starting from the role entry / group entry (preferable if there are a lot of user entries). I The following example shows the assignment of irmc S4 users from an OU people to a permission group. The assignment starting from the group entry / role entry is explained. The assignment procedure on the basis of the user entry is very similar. I The users must be entered in the groups manually in edirectory. Proceed as follows: Start imanager via the web browser. Log in at imanager with valid authentication data. Select Roles and Tasks. Select Groups - Modify Group. The Modify Group page is displayed. Perform the following steps for all the permission groups to which you want to assign irmc S4 users: Use the object selector button to select the permission group to which you want to add irmc S4 users. In the example of the LDAP v2 structure (see figure 79 on page 269) this is: Administrator.AuthorizationRoles.DeptX.Departments.SVS.sbrd User Management in ServerView

269 Global user management for the irmc S4 Select the Members tab. The Members tab of the Modify Group page is displayed: Figure 79: imanager - Roles and Tasks - Modify Group - Members tab (LDAP v2) Perform the following steps for all the users of the OU people which you want to assign to the irmc group: Click the object selector button. The Object Selector (Browser) window is opened (see figure 80 on page 270). User Management in ServerView 269

270 Global user management for the irmc S4 Figure 80: Assigning users to the irmc group - selecting users In the Object Selector (Browser) window, select the required user(s) in the OU people and click OK to confirm. The selected users are now listed in the display area in the Members tab of the Modify Group page (see figure 79 on page 269). 270 User Management in ServerView

271 Global user management for the irmc S4 Figure 81: Display of the selectedirmc S4 users in the Members LDAP v2 tab Confirm with Apply or OK in order to add the selected users to the irmc group (here:....svs.sbdr4). User Management in ServerView 271

272 Global user management for the irmc S Tips on administering Novell edirectory. Restarting the NDS daemon Proceed as follows to restart the NDS daemon: Open the command box. Log in with root permission. Execute the following command: rcndsd restart If, for any unidentifiable reason, the nldap daemon fails to start: Start the lndap daemon manually : /etc/init.d/nldap restart If imanager does not respond: Restart imanager: /etc/init.d/novell-tomcat4 restart Reloading the configuration of the NLDAP server Proceed as follows: Start ConsoleOne and log in to edirectory. I If you are starting ConsoleOne for the first time, no tree is configured. Proceed as follows to configure a tree: Under My World, select the node NDS. In the menu bar, select: File - Authenticate Enter the following authentication data for login: 1. Login-Name: root 2. Password: <password> 3. Tree: MY_TREE 4. Context: mycompany 272 User Management in ServerView

273 Global user management for the irmc S4 In the left-hand part of the window, click the Base DN object (Mycompany). The LDAP Server object is then displayed in the right-hand side of the window. Right-click on the LDAP Server object and select Properties... in the context menu. In the General tab, click the Refresh NLDAP Server Now button. Configuring the NDS message trace The nds daemon generates debug and log messages which you can trace using the ndstrace tool. The purpose of the configuration described below is to redirect the output from ndstrace to a file and display the content of this file at another terminal. For this latter task, you use the screen tool. The following procedure is recommended: Open the command box (e.g. bash). Configuring ndstrace Go to the edirectory directory /home/edirectory: cd /home/edirectory Start screen by means of the command screen. Start ndstrace with the command ndstrace. Select the modules that you want to activate. For example, if you want to display the times at which events occurred, enter dstrace TIME. I You are very strongly recommended to activate the modules LDAP and TIME by making the following entry: dstrace LDAP TIME Terminate ndstrace by entering quit. This terminates the configuration of ndstrace. User Management in ServerView 273

274 Global user management for the irmc S4 Outputting messages at a second terminal Start ndstrace and redirect message output: ndstrace -l >ndstrace.log Use the following key combination to open a second terminal: [Ctrl] + [a], [Ctrl] + [c] Activate log recording: tail -f./ndstrace.log To switch between the virtual terminals, use the key combination [Ctrl] + [a], [Ctrl] + [0]. (The terminals are numbered from 0 to 9) 274 User Management in ServerView

275 Global user management for the irmc S irmc S4 user management via OpenLDAP This section provides you with information about the following topics: Installing OpenLDAP (Linux). Creating an SSL certificate. Configuring OpenLDAP. Integrating irmc S4 user management in OpenLDAP. Tips on OpenLDAP administration Installing OpenLDAP I Before installing OpenLDAP, you must configure the firewall for connections to the ports 389 and 636. For OpenSuSE, proceed as follows: In the file, /etc/sysconfig/susefirewall2 extend the option FW_SERVICES_EXT_TCP as follows: FW_SERVICES_EXT_TCP= To install the packages OpenSSL and OpenLDAP2 from the distribution medium, use the setup tool YaST Creating SSL certificates You should create a certificate with the following properties: Key length: 1024 bits md5rsaenc You use OpenSSL to create key pairs and signed certificates (self-signed or signed by an external CA). For more detailed information, see the OpenSSL home page at The following links provide instructions on setting up a CA and creating test certificates: User Management in ServerView 275

276 Global user management for the irmc S4 Following certificate creation, you must have the following three PEM files: Root certificate: root.cer.pem Server certificate: server.cer.pem Private key: server.key.pem I The private key must not be encrypted with a pass phrase since you should only assign the LDAP daemon (ldap) read permission for the file server.key.pem. You use the following command to remove the pass phrase: openssl rsa -in server.enc.key.pem -out server.key.pem Configuring OpenLDAP Proceed as follows to configure OpenLDAP: Start the Yast setup tool and select LDAP-Server-Configuration. Under Global Settings/Allow Settings, activate the setting LDAPv2-Bind. Select Global Settings/TLS Settings: Activate the setting TLS. Declare the paths of the files created during installation (see section Installing OpenLDAP on page 275). Make sure that certificates and private keys in the file system can be read by the LDAP service. Since openldap is executed under the uid/guid=ldap, you can do this by setting the owner of the files with the certificates and private keys to ldap, or by assigning the LDAP daemon ldap read permission for the files containing the certificates and private keys. Select Databases to create a new database. 276 User Management in ServerView

277 Global user management for the irmc S4 I If the configuration created by YaST does not function overall, check that the following obligatory entries are present in the file /etc/openldap/slapd.conf: allow bind_v2 TLSCACertificateFile /path/to/ca-certificate.pem TLSCertificateFile /path/to/certificate.pem TLSCertificateKeyFile /path/to/privat.key.pem I If the configuration created by YaST for SSL does not function, check that the following entry is present in the configuration file /etc/sysconfig/openldap: OPENLDAP_START_LDAPS= yes User Management in ServerView 277

278 Global user management for the irmc S Integrating irmc S4 user management in OpenLDAP I Prerequisite: An LDAP v2 structure has already been generated in the OpenLDAP directory service (see section SVS_LdapDeployer - Generating, maintaining and deleting the SVS structures on page 227). The integration of irmc S4 user management in OpenLDAP comprises the following steps: Generating the principal irmc user. Creating the new irmc S4 user and assigning this user to the permission group. I To generate the Principal User (ObjectClass: Person) use an LDAP browser, for example the LDAP Browser\Editor published by Jarek Gawor (see page 278). LDAP Browser\Editor published by Jarek Gawor The LDAP Browser\Editor published by Jarek Gawor is easy to use via a graphical user interface. The tool is available for download in the internet. Proceed as follows to install the LDAP Browser\Editor: Unpack the Zip archive Browser281.zip to an installation directory of your choice. Set the environment variable JAVA_HOME to the installation directory for the JAVA runtime environment, e.g.: JAVA_HOME=C:\Program Files\Java\jre7 278 User Management in ServerView

279 Global user management for the irmc S4 Generating the Principal User I To generate the Principal User (ObjectClass: Person) use an LDAP browser, for example the LDAP Browser\Editor published by Jarek Gawor (see page 278). The text below describes how you use the Jarek Gawor LDAP Browser\Editor to generate the Principal User. Proceed as follows: Start the LDAP Browser. Log in at the OpenLDAP directory service with valid authentication data. Select the subtree (subgroup) in which the Principal User is to be created. The Principal User can be created anywhere in the tree. Open the Edit menu. Select Add Entry. Select Person. Edit the Distinguished Name DN. I The Principal User's Distinguished Name (DN) and password must match the corresponding specifications for the irmc S4 configuration (see the manual irmc S4 - integrated Remote Management Controller). Click Set and enter a password. Enter a Surname SN. Click Apply. User Management in ServerView 279

280 Global user management for the irmc S4 Creating the new irmc S4 user and assigning this user to the permission groups I To create a new user (ObjectClass Person) and assign a user to the permission group, you use an LDAP browser, for example the Jarek Gawor LDAP Browser\Editor (see page 278). The following text describes how you use the Jarek Gawor LDAP Browser\Editor to create a new irmc S4 user and add this user to the permission group. Proceed as follows: Start the LDAP Browser. Log in at the OpenLDAP directory service with valid authentication data. Create a new user. To do this, proceed as follows: Select the subtree (subgroup) in which the new user is to be created. The new user can be created anywhere in the tree. Open the Edit menu. Select Add Entry. Select Person. Edit the Distinguished Name DN. Click Set and enter the password. Enter a Surname SN. Click Apply. 280 User Management in ServerView

281 Global user management for the irmc S4 Assign the user you have just created to the permission group. To do this, proceed as follows: Select the SVS subtree (subgroup) to which the user is to belong, i.e. cn=userkvm,ou=yourdepartment,ou=departments,ou=svs, dc=myorganisation,dc=mycompany Open the Edit menu. Select Add Attribute. Specify Member as the attribute name. As the value, specify the fullyqualified DN of the user you have just created, i.e. cn=userkvm,ou=yourdepartment,ou=departments,ou=svs, dc=myorganisation,dc=mycompany User Management in ServerView 281

282 Global user management for the irmc S Tips on OpenLDAP administration Restarting the LDAP service Proceed as follows to restart the LDAP service: Open the command box. Log in with root permission. Enter the following command: rcldap restart Message logging The LDAP daemon uses the Syslog protocol for message logging. I The logged messages are only displayed if a log level other than 0 is set in the file /etc/openldap/slapd.conf. For an explanation of the various levels, see: table 37 on page 283 provides an overview of the log levels and their meanings. 282 User Management in ServerView

283 Global user management for the irmc S4 Log level Meaning -1 Comprehensive debugging 0 No debugging 1 Log function calls 2 Test packet handling 4 Heavy trace debugging 8 Connection management 16 Show sent/received packets 32 Search filter processing 64 Configuration file processing 128 Processing of access control lists 256 Status logging for connections/operations/events 512 Status logging for sent entries 1024 Output communication with shell backends Output results of entry parsing. Table 37: OpenLDAP - log levels User Management in ServerView 283

284 Global user management for the irmc S Configuring alerting to global irmc S4 users alerting to global irmc S4 users is integrated in the global irmc S4 user management system. This means that it can be configured and handled centrally for all platforms using a directory server. Appropriately configured global user IDs can receive alerts from all irmc S4s that are connected to a directory server in the network. I Prerequisites The following requirements must be met for alerting: Global alerting requires Version 3.77A or later of the irmc S4 firmware, as an LDAP v2 structure is required. A principal user must have been configured in the irmc S4 web interface who has been granted permission to search in the LDAP tree (see the manual irmc S4 - integrated Remote Management Controller). When configuring the LDAP settings on the Directory Service Configuration page (see the manual irmc S4 - integrated Remote Management Controller), alerting must have been enabled under Directory Service Alert Configuration. 284 User Management in ServerView

285 Global user management for the irmc S Global alerting Alert roles are required for global alerting via the directory server. These are defined in addition to the authorization roles in the configuration file of the SVS_LdapDeployer (see page 227). Displaying alerting groups (alert roles) An alert role groups together a selection of alert types (e.g. temperature threshold exceeded), each with an assigned severity (e.g. critical ). Assigning a user to a particular alert group specifies what alert types and severities the user will be alerted of by . The syntax of the alert roles is illustrated in the sample configuration files Generic_Settings.xml and Generic_InitialDeploy.xml that are supplied together with the jar archive SVS_LdapDeployer.jar on ServerView Suite DVD. Displaying alert types The following alert types are supported: Alert type FanSens Temperat HWError Security SysHang POSTErr SysStat DDCtrl NetInterf RemMgmt SysPwr Memory Others Table 38: Alert types Cause Fan sensors Temperature sensors Critical hardware error Security System hung POST error System status Disk drives and controllers Network interface Remote Management Power management Memory Miscellaneous Each alert type can be assigned one of the following severity levels: Warning, Critical, All, (none). User Management in ServerView 285

286 Global user management for the irmc S4 Preferred mail server. For global alerting, the setting Automatic is used on the preferred mail server: If the cannot be successfully sent immediately, for instance if the first mail server is not available, the is sent to the second mail server. Supported mail formats The following formats are supported: Standard Fixed Subject ITS-Format Fujitsu REMCS Format I If a mail format other than Standard is used, you must add the users to the corresponding mail format group. LDAP table If alerting is configured (see page 288) and the option LDAP Alert Enable is selected, the irmc S4 sends s to the following users when an alert is issued (see the manual irmc S4 - integrated Remote Management Controller): all appropriately configured local irmc S4 users, all global irmc S4 users registered in the LDAP table for this alert. The LDAP table is initially created by the irmc S4 firmware the first time the irmc S4 is started and then updated at regular intervals. The size of the LDAP table is limited to a maximum of 64 LDAP alert roles and a maximum of 64 global irmc S4 users for whom alerting is configured. I It is recommended that you use distribution lists for global alerting. 286 User Management in ServerView

287 Global user management for the irmc S4 The LDAP directory server gets the following information from the table for the purposes of alerting: List of the global irmc S4 users for whom alerting is configured. For each global irmc S4 user: List of the configured alerts for each alert type (type and severity). Required mail format. The LDAP table is updated in the following circumstances: when the irmc S4 is started for the first time or restarted, when the LDAP configuration is changed, at regular intervals (optional). You specify the update interval as part of the LDAP configuration in the irmc S4 web interface (under the option LDAP Alert Table Refresh (see the manual irmc S4 - integrated Remote Management Controller, and the LDAP Alert Table Refresh option). User Management in ServerView 287

288 Global user management for the irmc S4 Configuring global alerting on the directory server This section describes how to configure alerting on the directory server. I Settings must also be made for the irmc S4. You configure these in the irmc S4 web interface (see manual irmc S4 - integrated Remote Management Controller). Proceed as follows: In the directory service, enter the addresses of the users to whom s are to be sent. I The method used to configure the addresses differs depending on the directory service used (Active Directory, edirectory or OpenLDAP). Create a configuration file in which the alert roles are defined. Start the SVS_LdapDeployer using this configuration file in order to generate a corresponding LDAP v2 structure (SVS) on the directory server (see page 228 and page 234). 288 User Management in ServerView

289 Global user management for the irmc S Displaying alert roles After the LDAP v2 structure has been generated, the newly created OU SVS is displayed in Active Directory, for instance, together with the components Alert Roles and Alert Types under Declarations and together with the component Alert Roles under DeptX (see figure 82): Under Declarations, Alert Roles displays all the defined alert roles and all the alert types are displayed under Alert Types (1). Under DeptX, Alert Roles displays all the alert roles that are valid in the OU DeptX (2). (1) (2) Figure 82: OU SVS with alert roles I To ensure that s are sent to the users in the individual alert roles, the relevant department must be configured in irmc S4 (in figure 82: DeptX) (see the manual irmc S4 - integrated Remote Management Controller). User Management in ServerView 289

290 Global user management for the irmc S4 If you select an alert role (e.g. StdSysAlerts) under SVS Departments DeptX Alert Roles in the structure tree for Active Directory Users and Computers (see figure 83) (1), and open the Properties dialog box for this alert role by choosing Properties Members from the context menu, all the users that belong to the alert role (here: StdSysAlerts) are displayed in the Members tab (2). (2) (1) Figure 83: Users assigned to the alert role StdSysAlert 290 User Management in ServerView

291 Global user management for the irmc S Assigning irmc S4 users to an alert role You can assign irmc S4 users to alert roles either on the basis of the user entry, or on the basis of the role entry. In the various different directory services (Microsoft Active Directory, Novell edirectory and OpenLDAP), irmc S4 users are assigned to irmc S4 alert roles in the same way in which irmc S4 users are assigned to irmc S4 authorization roles and using the same tools. In Active Directory, for instance, you make an assignment by clicking Add... in the Properties dialog box of the Active Directory Users and -Computers snap-in (see figure 83 on page 290). User Management in ServerView 291

292 Global user management for the irmc S SSL copyright The irmc S4-LDAP integration uses the SSL implementation developed by Eric Young on the basis of the OpenSSL Project. 292 User Management in ServerView

293 Global user management for the irmc S4 User Management in ServerView 293

294 Global user management for the irmc S4 294 User Management in ServerView