Deployment & Sizing Strategies - BeyondTrust€¦ · deployment plan no longer meets the ever...

Deployment & Sizing Strategies

Lieberman RED Identity Management

5.5.2.2

Copyright © 2003–2017 Lieberman Software Corporation.

All rights reserved.

The software contains proprietary information of Lieberman Software Corporation; it is provided

under a license agreement containing restrictions on use and disclosure and is also protected by

copyright law. Reverse engineering of the software is prohibited.

Due to continued product development this information may change without notice. The

information and intellectual property contained herein is confidential between Lieberman Software

and the client and remains the exclusive property of Lieberman Software. If there are any

problems in the documentation, please report them to Lieberman Software in writing. Lieberman

Software does not warrant that this document is error-free.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any

form or by any means, electronic, mechanical, photocopying, recording or otherwise without the

prior written permission of Lieberman Software.

Microsoft, Windows, Word, Office, SQL Server, SQL Express, Access, MSDE, and MS-DOS are either

registered trademarks or trademarks of Microsoft Corporation in the United States and/or other

countries. Other brands and product names are trademarks of their respective owners.

Lieberman Software Corporation

1875 Century Park East, Suite 1200

Los Angeles, CA 90067

(310) 550-8575

Support: https://liebsoft.zendesk.com

Website: http://www.liebsoft.com

iii

Contents

CHAPTER 1 INTRODUCTION TO DEPLOYING LIEBERMAN RED IDENTITY MANAGEMENT ..........5

1.1 Limited Warranty ..................................................................................................................... 6

1.2 License Agreement ................................................................................................................... 6

CHAPTER 2 PLANNING FOR DEPLOYMENT ..............................................................................9

2.1 What Platforms will be Managed? .........................................................................................11

2.1.1 Windows Considerations ................................................................................................11 2.1.2 Linux/UNIX Considerations .............................................................................................14 2.1.3 Cisco Device Considerations ...........................................................................................16 2.1.4 AS400 Considerations .....................................................................................................18 2.1.5 OS390 Considerations ....................................................................................................19 2.1.6 IPMI Device (Lights Out) Considerations ........................................................................19 2.1.7 Database Considerations ................................................................................................20

2.1.7.1 SQL Database Considerations .................................................................................................. 21 2.1.7.2 Oracle Database Considerations ............................................................................................. 22 2.1.7.3 Sybase ASE Considerations ...................................................................................................... 23 2.1.7.4 MySQL and MariaDB Considerations ....................................................................................... 23 2.1.7.5 PostgreSQL Database Considerations ..................................................................................... 24 2.1.7.6 Teradata Considerations ......................................................................................................... 25 2.1.7.7 DB2 Considerations ................................................................................................................. 25

2.1.8 Xerox Phaser Printer Considerations ..............................................................................26 2.1.9 LDAP Considerations ......................................................................................................27 2.1.10 McAfee ePolicy Orchestrator Considerations ............................................................28 2.1.11 SAP Considerations .....................................................................................................29 2.1.12 Oracle WebLogic Considerations................................................................................30 2.1.13 IBM WebSphere Considerations ................................................................................31 2.1.14 Azure Active Directory Considerations .......................................................................31 2.1.15 Amazon Web Services Considerations .......................................................................32 2.1.16 RackSpace Public Cloud Considerations .....................................................................33 2.1.17 SalesForce Considerations ..........................................................................................33 2.1.18 Softlayer Considerations ............................................................................................34 2.1.19 VMware ESX Considerations ......................................................................................35 2.1.20 Other SSH & Telnet Considerations ............................................................................35

2.2 Where are the Target Systems Located? ...............................................................................37

2.3 What Accounts will be Managed? ..........................................................................................37

2.4 Will High Availability be Employed? .......................................................................................38

2.5 How will the Infrastructure be Deployed? .............................................................................38

2.6 Firewall Considerations ..........................................................................................................40

2.7 When to use Zone Processors ................................................................................................43

iv Contents

2.7.1 Zone Processor Use Case Scenarios ...............................................................................44 2.7.2 Deploying Zone Processors ............................................................................................50 2.7.3 Zone Processor Support Files .........................................................................................54

CHAPTER 3 DEPLOYMENT STRATEGIES ................................................................................. 57

3.1 Deployment: Single Server No HA ..........................................................................................58

3.2 Deployment: Multi-System No HA .........................................................................................59

3.3 Deployment: Multi-System Minimum HA ..............................................................................59

3.4 Deployment: Multi-System Full HA ........................................................................................61

3.5 Deployment: Application Launching Minimum ......................................................................62

3.6 Deployment: Application Launching Recommended .............................................................63

3.7 Customer Deployments ..........................................................................................................64

CHAPTER 4 SIZING ............................................................................................................... 69

4.1 Licensing .................................................................................................................................69

4.2 Database Host Sizing ..............................................................................................................72

4.3 Management Console and Zone Processor Sizing..................................................................76

4.4 Web App and Service Host Sizing ...........................................................................................78

4.5 Application Launcher Sizing ....................................................................................................79

4.6 Session Recording Sizing.........................................................................................................80

CHAPTER 5 INDEX ................................................................................................................ 81

5

Lieberman RED Identity Management can be deployed centrally to manage one or more domains,

whether trusted or untrusted, as well as adding management capabilities to DMZ systems or offline

machines across multiple platforms. The goal of management, in the context of Lieberman RED

Identity Management is to gain control of privileged credentials, privileged sessions, remove

permanent administrative access, and audit when the access is granted, to whom, and what they

did with that access.

Lieberman RED Identity Management can perform thousands of management operations per

minute from a single node, infrastructure permitting. This makes it one of the fastest management

platforms in this space available and ideal for incident response. By placing Lieberman RED Identity

Management at the center of your network, it can integrated with Identity and access management

product, governance products, security assessment products, orchestration products, and help

provide automated incident response.

This guide describes some of the key concepts when deploying Lieberman RED Identity

Management including database concepts, zone processors, high availability, and more. This guide

also includes examples of real deployments and explanations.

IN THIS CHAPTER

Limited Warranty ...................................................................................... 6

License Agreement .................................................................................... 6

Chapter 1 Introduction to

Deploying Lieberman RED

Identity Management

6 Introduction to Deploying Lieberman RED Identity Management

1.1 LIMITED WARRANTY The media (optional) and manual that make up this software are warranted by Lieberman Software

Corporation to be free of defects in materials and workmanship for a period of 30-days from the

date of your purchase. If you notify us within the warranty period of such defects in material and

workmanship, we will replace the defective manual or media (if either were supplied).

The sole remedy for breach of this warranty is limited to replacement of defective materials and/or

refund of purchase price and does not include any other kinds of damages.

Apart from the foregoing limited warranty, the software programs are provided "AS-IS," without

warranty of any kind, either expressed or implied. The entire risk as to the performance of the

programs is with the purchaser. Lieberman Software does not warrant that the operation will be

uninterrupted or error-free. Lieberman Software assumes no responsibility or liability of any kind

for errors in the programs or documentation of/for consequences of any such errors.

This agreement is governed by the laws of the State of California.

Should you have any questions concerning this Agreement, or if you wish to contact Lieberman

Software, please write:




You can also keep up to date on the latest upgrades via our website at http://www.liebsoft.com or

e-mail us at: [email protected].

1.2 LICENSE AGREEMENT This is a legal and binding contract between you, the end user, and Lieberman Software

Corporation. By using this software, you agree to be bound by the terms of this agreement. If you

do not agree to the terms of this agreement, you should return the software and documentation, as

well as all accompanying items promptly for a refund.

1. Your Rights: Lieberman Software Corporation hereby grants you the right to use a single copy of

Lieberman RED Identity Management to control the licensed number of systems and/or devices.

2. Copyright. The SOFTWARE is owned by Lieberman Software Corporation and is protected by

United States copyright law and international treaty provisions. Therefore, you must treat the

software like any other copyrighted material (e.g. a book or musical recording) except that you may

either (a) make one copy of the SOFTWARE solely for backup and archival purposes, or (b) transfer

Introduction to Deploying Lieberman RED Identity Management 7

the SOFTWARE to a single hard disk provided you keep the original solely for backup and archival

purposes. The manual is a copyrighted work. Also-you may not make copies of the manual for any

purpose other than the use of the software.

3. Other Restrictions: You may not rent or lease the SOFTWARE. You may not reverse engineer,

de-compile, or disassemble the SOFTWARE that is provided solely as executable programs (EXE

files). If the SOFTWARE is an update, any transfer must include the update and all prior versions.

When used lawfully, this software periodically transmits to us the serial number and network

identification information of the machine running the software. No personally identifiable

information or usage details are transmitted to us in this case. The program does not contain any

spyware or remote control functionality that may be activated remotely by us or any other third

party.




310.550.8575

Support: https://liebsoft.zendesk.com

Website: http://www.liebsoft.com

9

Lieberman RED Identity Management requires some basic installation pre-requisites:

• Database

• IIS Web Server

• Service Account(s)

There are also some advanced features:

• Application Launching

• Session Recording

• Zone Processing

The database will be Microsoft SQL 2008 or later with Microsoft SQL 2014 or 2016 recommended.

The IIS Web Server will be hosted on Windows Server 2012 R2 or Windows Server 2016. A service

account is required for the web application to access the database. The same service account or a

different one (recommended) can be used for the deferred processor or zone processors to perform

scheduled jobs.

The system will require Microsoft .Net Framework v4.5.2 or later versions from the CLRv4 family.

The management console and deferred and zone processors may also need Windows Management

Framework v4 or later. See the installation guide for more information on specific pre-requisites.

There are no permanent agents deployed with Lieberman RED Identity Management so network

connectivity will be required across a variety of ports depending on what is being managed. See the

installation guide for more information on specific port pre-requisites.

When planning for a deployment you will need to answer six basic questions:

• What platforms will be managed and where?

• Where are those platforms physically and logically located?

Chapter 2 Planning for

Deployment

10 Planning for Deployment

• For Windows domains or AD joined Linux/UNIX hosts, are there trusts in place between the

various domains?

• What accounts will be managed on those platforms and what accounts will perform the

management?

• How much high availability infrastructure will we use during this deployment and for what

components?

• How will the infrastructure supporting Lieberman RED Identity Management be deployed?

This chapter will help define the questions further and describe options.

One important element to keep in mind as you plan for deployment is that needs change and new

challenges arise during projects like this. Unlike some competing products, if you find your original

deployment plan no longer meets the ever evolving needs, you can simply change the design and

move systems and related information around as needed to meet these new requirements. If you

need more capacity, add more capacity. Capacity comes in the form of server resources like CPU

and RAM and capacity comes in the form of more supporting infrastructure like additional web

servers or zone processors. If you need to move managed systems between management sets due

to zone processor requirements, delegation requirements or anything else, do so without fear of

losing any password information.

IN THIS CHAPTER

What Platforms will be Managed? .......................................................... 11

Where are the Target Systems Located? ................................................ 37

What Accounts will be Managed? ........................................................... 37

Will High Availability be Employed? ........................................................ 38

How will the Infrastructure be Deployed? .............................................. 38

Firewall Considerations ........................................................................... 40

When to use Zone Processors ................................................................. 43

Planning for Deployment 11

2.1 WHAT PLATFORMS WILL BE MANAGED? The question of what platforms will be managed relates directly to additional pre-requisites such as

additional database providers, additional required components, ports and therefore firewall rules,

as well as information regarding password policies, change frequencies, etc..

This section describes considerations for the management targets supported by Lieberman RED

Identity Management. The sections are presented in the default order listed in the management

console, account store view.

2.1.1 Windows Considerations

Windows systems are typically domain joined systems and are managed with remote RPC calls.

Windows systems, unlike other managed platforms provide management of subsystems, e.g.

services, tasks, etc., via additional RPC calls beyond the normal system management RPC calls.

How a Windows system is managed may vary depending on whether the target system is trusted or

not.

Consider the following topics:

Account Discovery

Local systems will allow administrators to enumerate all accounts on a Windows systems. For Active

Directory, if you are not an administrator, you may successfully refresh portions of active directory

for which you have read access to, though you will still receive a non-fatal error during the refresh

as you will be unable to refresh domain controller system information without administrative rights.

Password Management

When changing a local account password, the change can occur by an administrative account or by

the target account changing its own password. When performing an administrative password

change, a password reset is actually being performed. When an account is used to change its own

password, a change, not a reset, is being performed.

When changing a domain account, this change can occur by an administrative account or by the

target account changing its own password or by a delegated reset. The rights required for domain

account password management by different accounts will vary based on the target account.

In the default case, an administrator can change any other user's passwords, including other

administrators. A user who has been delegated the reset password permission can reset any user's

password, unless that user is in a protected group, unless you have modified the default


permissions in Active Directory for the AdminSDHolder object to allow such changes by lower

powered users.

once permissions are defined on AdminSDHolder, a process called SDProp will periodically enforce

those permissions. Thus if you change permissions on a protected account or group, those

permissions will be replaced with those defined by AdminSDHolder when SDProp runs.

As of this writing, this is the list of protected accounts and groups in Active Directory by Operating

System:

Windows

2000 <SP4

Windows 2000 SP4 -

Windows Server 2003

RTM

Windows

Server 2003

SP1+

Windows Server 2008 -

Windows Server 2016

Account Operators Account

Operators

Account Operators

Administrator Administrator Administrator

Administrator

s

Administrators Administrators Administrators

Backup Operators Backup

Operators

Backup Operators

Cert Publishers

Domain

Admins

Domain Admins Domain Admins Domain Admins

Domain Controllers Domain

Controllers

Domain Controllers

Enterprise

Admins

Enterprise Admins Enterprise

Admins

Enterprise Admins

Krbtgt Krbtgt Krbtgt

Print Operators Print Operators Print Operators

Read-only Domain

Controllers


Replicator Replicator Replicator

Schema

Admins

Schema Admins Schema Admins Schema Admins

Server Operators Server

Operators

Server Operators

Windows Server 2012 R2 (and Windows 8.1) also introduced a special protected groups called

Protected Users. Your domain based service accounts should not be placed in this group. For more

information, please refer to Microsoft documentation:

https://technet.microsoft.com/en-us/library/dn466518(v=ws.11).aspx

(https://technet.microsoft.com/en-us/library/dn466518(v=ws.11).aspx)

Ports and Protocols

Windows management will occur via various RPCs over a range of ports including port 445, 135 and

ephemeral ports. Basic system refresh and local password management occurs over port 445 for all

recent versions of Windows. Older versions of Windows, like Windows NT4 will accept management

over ports 137 - 139.

Ephemeral ports are used during account usage discovery and password propagation. The

ephemeral port range varies by Windows distribution and can be controlled in the Windows

registry. The default ephemeral port range is as follows:

• Windows 2003 and earlier = 1025 - 5000

• Windows 2008 and later = 49152 - 65535

These port ranges must be accounted for when configuring firewall rules for management of these

hosts.

Windows Propagations

The service account performing management of the target Windows system must be an

administrator to perform a refresh of account usage or perform password propagation. Below are

special considerations for some of the possible Windows propagations.

• Windows Services - This uses the service control manager (SCM) to manage services. You can

interactively call the SCM using the sc.exe program on a Windows machine. Management for

this interface occurs over standard SMB port 445.

https://technet.microsoft.com/en-us/library/dn466518(v=ws.11).aspx


Clustered services represent another management issue for administrators. The cluster API is OS

specific. That means a Windows 2008 R2 cluster can only be remotely managed by another

Windows 2008 R2 host. This concept is the same for Server 2012, Server 2012 R2, and Server

2016. If you will be managing clustered resources on Version-X of the Windows operating

system, but Lieberman RED Identity Management is hosted on Version-Y, you will likely need

host a zone processor on a server running Windows Version-X.

• Windows Scheduled Tasks - This uses the iTask interface over port 135 and ephemeral ports.

The task interface is backwards compatible but not forward compatible. This means a Server

2012 R2 cannot manage a Server 2016 system's scheduled tasks.

• SCOM RunAs Accounts - Management and discovery of SCOM requires the SCOM SDK files be

placed in the same directory as the Lieberman RED Identity Management executables.

• SharePoint - Only a single admin port can be defined per installation of Lieberman RED Identity

Management. This means management of multiple installations of SharePoint farms from a

single instance of Lieberman RED Identity Management will require all SharePoint instances be

set to use the same administrative port. The farm account cannot be managed by the

SharePoint propagation. Rather, you must run an arbitrary process to call stsadm.exe from a

command line to update this account.

• COM+ - Remote COM+ access is not enabled by default. Attempting to refresh or propagate to a

COM+ application in this state will generate a non-critical error during management operations.

COM+ Remote Access must be enabled through the Application Server role or my enabling it in

the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3 and setting

RemoteAccessEnabled=1.

• DCOM - Enumeration and management of the Windows DCOM system leverages remote

registry. If the remote registry service is not running when this operation is performed, DCOM

discovery and propagation will fail.

• .Net Config Files - This propagation is for management of the ASP.NET Data Sources object in IIS

allowing IIS websites to connect to databases. Management of this item will deploy a temporary

helper service to the target Windows machine called LiebsoftRemoteSvc.exe to

\\serverName\admin$\LiebRmt. When the operation is finished, the file will self terminate

and be removed. Anti-Virus programs can cause problems with this process.

2.1.2 Linux/UNIX Considerations

Linux and UNIX systems, also inclusive of OSX, Solaris, or other *NIX based platforms are managed

by an interactive terminal session, very much like what an administrator will encounter when using

other remote terminal products like PuTTy.


One of the hard parts about *NIX management is the number of distributions throughout the world,

let alone at a single customer's location. Different distributions can change many things regarding

how management can occur such as password policy, encryption and MAC algorithms, password

change interaction process, etc. Add to this any custom configurations such as login banners,

prompt changes, type of account logging in, sudo replacements, and you have a lot to overcome to

successfully manage any possible *NIX platform out there.


Authentication

Authentication to a *NIX host when establishing an SSH session can occur using a certificate or

password. Users can be either local or from a central directory. While all scenarios are supported by

Lieberman RED Identity Management, each requires different considerations and planning,

especially when using certificates. You must know how your systems require authentication.

Account Discovery

Account discovery for *NIX systems and Lieberman RED Identity Management relies on the ability

to read from /etc/shadow and /etc/password. Any permission or policy that prevents the Lieberman

RED Identity Management login account from reading this file, up to and including the files don't

exist in the /etc directory or at all will prevent account enumeration from working.

Versions of Lieberman RED Identity Management prior to version 5.5.0, would copy the files from

the *NIX host using SCP to the local Lieberman RED Identity Management host for local parsing. This

has since changed with version 5.5.0 and later. The new process lists the contents of the files within

the session which in turn allows for quicker operations and a low powered account that is allowed

to use sudo to cat the files, specifically: sudo cat /etc/shadow.

Password Management

Lieberman RED Identity Management can perform password management using a variety of

methods. It is important to know which account will be managed and which account will manage it.

Finally, you must know exactly what process is followed to perform that management. Management

of passwords is performed using answer files (see the Admin Guide for more information). An

answer file identifies what input is given to the system and what the expected output from that

command will be. Any deviation can cause the password change job to incorrectly report the final

status of the operation.

Common password management scenarios include:

• Root changing its own password.


• Low powered account changing its own password.

• Low powered account will su to root, and root will change its own password.

• Low powered account will login and run a command using sudo to change another password.

Each of the scenarios just listed can be different from machine to machine, even for the same

distribution. This it is important to know how each of your target *NIX systems operate.

Ports and Protocols

Modern *NIX systems will use SSH as the defacto protocol for management operations. SSH uses a

single port which defaults to TCP 22. If you are using Telnet for any reason, the default port is 23,

but that can also be changed. Whether using SSH or Telnet, you will need to know the target port if

you are configured to use an alternate port.

Ports are configured in the answer files used for password management. If multiple systems are on

different ports, you will need multiple answer files.

If using Telnet, passwords cannot be programmatically passed, as they can with SSH. This means

when using Telnet, your answer files must include not only the management steps but also the login

process and you must edit/work with the Telnet portion of the answer file.

2.1.3 Cisco Device Considerations

Cisco devices are managed by an interactive terminal session, very much like what an administrator

will encounter when using other remote terminal products like PuTTy.

One of the hard parts about Cisco management is the changes introduced with various IOS revisions

over time and custom configurations. Custom configurations can change many things regarding how

management can occur such as password policy, encryption and MAC algorithms, password change

interaction process, etc.


Authentication

Authentication to a Cisco device when establishing an SSH session can occur using a certificate or




Account Discovery

Cisco devices are not supported for account discovery.


Password Management








Common password management scenarios include:

• Logging in as a vty account, switching to enable mode and changing the enable

password/secret.

• Logging in as a vty account, switching to enable mode and changing the original vty account

password.

• Logging in as a TACACS enabled account on a Cisco device joined to TACACS to change its own

password.

• The same scenarios above but the login account is a priv15 account.

Each of the scenarios listed can be different from device to device or customer to customer, even

for the same physical device. This it is important to know how each of your target devices operate.

If you login to the Cisco device as a non-priv15 user, you will need to enter enable mode which

means you need an enable password to start with before you can change the enable password.

Then you must know if you intend to set the enable secret or the enable password. After that

process is complete, you may need to also perform a write memory command and possibly also a

copy run start command to write and save the configuration, then again you may not. The need to

perform either of the final actions is configuration dependent and IOS version dependent. Inclusion

of TACACS and TACACS joined devices can further convolute this concept.

When using TACACS accounts that will change their own password, the password must change

more frequently than the password expiration cycle. The process for such a change with Lieberman

RED Identity Management will require an initial successful login to a joined Cisco device after which

the account will re-SSH to the same device and initiate the userChangePassword function.

Ports and Protocols

Cisco devices ship with Telnet enabled by default and SSH must be enabled. It is highly

recommended you use SSH for all password management to avoid the transmission of clear text

passwords.


SSH uses a single port which defaults to TCP 22. If you are using Telnet for any reason, the default

port is 23, but that can also be changed. Whether using SSH or Telnet, you will need to know the

target port if you are configured to use an alternate port.






2.1.4 AS400 Considerations

AS400 systems management varies by version and configuration to some extent.


Authentication

Authentication to an AS400 host when establishing an SSH session can occur using a certificate or

password. Users can be either local or from a central directory. Telnet can only support password

authentication. While all scenarios are supported by Lieberman RED Identity Management, each

requires different considerations and planning, especially when using certificates. You must know

how your systems require authentication.

Account Discovery

Account discovery is not supported for AS400 systems.

Password Management


methods.

Ports and Protocols

When not using SSH connectivity, they rely on a 5250 terminal. 5250 terminal emulation is

supported in Lieberman RED Identity Management through an add-on component provided by

DN-Computing (https://dn-computing.com).

5250 terminals run over telnet, with or without SSL. You must know which port to use and if SSL is

enabled.

If using SSH, be aware of the target SSH port as well as allowed encryption and HMAC algorithms.


2.1.5 OS390 Considerations

OS390 systems management varies by version and configuration to some extent.


Authentication

Authentication to an OS390 host when establishing an SSH session can occur using a certificate or

password. Users can be either local or from a central directory. Telnet can only support password

authentication. While all scenarios are supported by Lieberman RED Identity Management, each

requires different considerations and planning, especially when using certificates. You must know

how your systems require authentication.

Account Discovery

Account discovery is not supported for OS390 systems.

Password Management


methods.

Ports and Protocols

When not using SSH connectivity, they rely on a 3270 terminal. 3270 terminal emulation is

supported in Lieberman RED Identity Management through an add-on component provided by

DN-Computing (https://dn-computing.com).

3270 terminals run over telnet, with or without SSL. You must know which port to use and if SSL is

enabled.

If using SSH, be aware of the target SSH port as well as allowed encryption and HMAC algorithms.

2.1.6 IPMI Device (Lights Out) Considerations

IPMI devices, also known as Integrated Lights Out or Lights Out management devices cover a

broad range of devices from many manufacturers. The IPMI specification was created by Intel and

given to the world.



Authentication

Authentication to an IPMI device can occur using local credentials. This means the password for the

management account must be known to Lieberman RED Identity Management for initial

management.

Account Discovery

Account discovery is supported on IPMI devices.

Password Management

Lieberman RED Identity Management expects the login account, defined when enrolling the IPMI

device, to be able to read all IPMI properties and change passwords.

Ports and Protocols

IPMI runs over UDP port 623. IPMI over Lan must be enabled on the target device and the target

device must conform to the IPMI v1.5 or 2.0 specification. IPMI over Lan is not always enabled

automatically and may require administrative configuration to enabled it.

UDP port 623 is not typically opened by default on routed segments protected by firewalls. Contact

your firewall administrator for more help on this matter.

Known IPMI Device Issues

HP ILO 2 device require BIOS revision 2.05 to be compatible with the IPMI specification. BIOS

revisions earlier than 2.05 will likely encounter management errors until the BIOS can be upgraded.

2.1.7 Database Considerations

Each database platform has its own provider that must be installed. Where the provider is installed

will depend on which Lieberman RED Identity Management host will be managing the target

database. For example, if host ZP1 will be managing Oracle databases, and host ZP2 will be

managing Teradata databases, then ZP1 needs the 32bit Oracle OLEDB provider installed while ZP2

needs the Teradata 32bit provider installed.

This section lists any known configuration requirements for target managed databases.

See the installation guide for more information on obtaining and installing database providers and

management account considerations.


2.1.7.1 SQL DATABASE CONSIDERATIONS

Microsoft SQL Server versions 2000 through 2016 are supported for management and account

discovery.


Authentication

Authentication to a Microsoft SQL server can be performed using an explicit SQL account (e.g. sa) or

a trusted account from the local Windows host or joined directory. When working with a SQL server

from a trusted domain, it is expected that the account running the console or scheduling service will

be granted the appropriate permissions to the target SQL server or that the SQL Server will permit

and be enrolled a proper explicit SQL server account.

If attempting to manage a SQL instance on an untrusted host, relative to the Lieberman RED Identity

Management component server host, you will only be able to use an explicit SQL Server account.

Account Discovery

Account discovery is supported for target SQL Server instances provided the connection account has

the Control Server server permission or is a member of the sysadmin role.

Password Management

Lieberman RED Identity Management can manage passwords for target SQL Server instances

provided the connection account has the Control Server server permission or is a member of the

sysadmin role.

Ports and Protocols

For most installations of SQL server, including clustered resources, there will be no additional steps

to take. However, SQL server does allow the configuration for the requirement of an SSL protected

connection. If the connection is enabled for SSL or TLS 1.0, you will not need any additional

software, but you will need to be aware of this fact when enrolling the SQL Server instance.

If the SQL Server instance is configured to require TLS 1.2, you will need to install the latest SQL

Server native client on any host that will manage such a SQL Server instance.

SQL server listens on port 1433 by default, but this port can be configured per IP address or SQL

instance. Be aware of any port changes to the SQL server or named instance requirements.


2.1.7.2 ORACLE DATABASE CONSIDERATIONS

Oracle databases are supported for management and account discovery. The versions supported by

Lieberman RED Identity Management will vary based on the installed provider. See below for more

information.


Authentication

Authentication to an Oracle database can be performed using an explicit account only. Directory

accounts are not supported for management of Oracle databases.

Account Discovery

Account discovery is supported for target Oracle database instances.

Password Management

Lieberman RED Identity Management can manage passwords for target Oracle databases.

Ports and Protocols

For most installations of Oracle databases, including clustered resources, there will be no additional

steps beyond installing the proper OLEDB provider on the Lieberman RED Identity Management

host performing the management.

Oracle listens on port 1521 by default, but this port can be configured based on service/sid name.

Be aware of port changes and to the names configured in the listeners file on the target Oracle

database host. It will be helpful to obtain the listener file from the target Oracle databases.

Provider Limitations

Oracle artificially restricts management of down level database versions. Refer to Oracle

documentation for more help. Lieberman RED Identity Management supports use of 32bit Oracle

OLEDB providers from version 11 and version 12.

• Oracle Client Version 11 supports oracle databases version 9 - 11g.

• Oracle Client Version 12 supports Oracle database version 10gR2 - 12


2.1.7.3 SYBASE ASE CONSIDERATIONS

Sybase databases are supported for management and account discovery. See below for more

information.


Authentication

Authentication to an Sybase database can be performed using an explicit account only. Directory

accounts are not supported for management of Sybase databases.

Account Discovery

Account discovery is supported for target Sybase database instances.

Password Management

Lieberman RED Identity Management can manage passwords for target Sybase databases.

Ports and Protocols

For most installations of Sybase databases, including clustered resources, there will be no additional



Sybase listens on port 5000 by default, but this port can be changed. Be aware of port changes.

2.1.7.4 MYSQL AND MARIADB CONSIDERATIONS

MySQL and MariaDB databases are supported for management and account discovery. See below

for more information.


Authentication

Authentication to an MySQL database can be performed using an explicit account only. Directory

accounts are not supported for management of MySQL databases.

MySQL uses a scheme to identify the source of the login account. For example, root@localhost can

only login at localhost while root@% can login from any host. Your MySQL instances must each be


configured with an account that allows access from your Lieberman RED Identity Management host

servers.

You will need to know the default database name to connect to.

Account Discovery

Account discovery is supported for target MySQL database instances.

Password Management

Lieberman RED Identity Management can manage passwords for target MySQL databases.

Ports and Protocols

For most installations of MySQL databases, including clustered resources, there will be no additional



MySQL listens on port 3306 by default, but this port can be changed. Be aware of port changes.

2.1.7.5 POSTGRESQL DATABASE CONSIDERATIONS

PostgreSQL databases are supported for management and account discovery. See below for more

information.


Authentication

Authentication to an PostgreSQL database can be performed using an explicit account only.

Directory accounts are not supported for management of PostgreSQL databases.

PostgreSQL authentication does not allow remote connections from anywhere out of the box and

rules must be established to allow communications from specific hosts or networks.


Account Discovery

Account discovery is supported for target PostgreSQL database instances.

Password Management

Lieberman RED Identity Management can manage passwords for target PostgreSQL databases.


Ports and Protocols

For most installations of PostgreSQL databases, including clustered resources, there will be no

additional steps beyond installing the proper OLEDB provider on the Lieberman RED Identity

Management host performing the management.

PostgreSQL listens on port 5432 by default, but this port can be changed. Be aware of port changes.

2.1.7.6 TERADATA CONSIDERATIONS

Teradata databases are supported for management and account discovery. See below for more

information.


Authentication

Authentication to an Teradata database can be performed using an explicit account only. Directory

accounts are not supported for management of Teradata databases.


Account Discovery

Account discovery is supported for target Teradata database instances.

Password Management

Lieberman RED Identity Management can manage passwords for target Teradata databases.

Ports and Protocols

For most installations of Teradata databases, including clustered resources, there will be no

additional steps beyond installing the proper OLEDB provider on the Lieberman RED Identity

Management host performing the management.

Teradata listens on port 1025 by default, but this port can be changed. Be aware of port changes.

2.1.7.7 DB2 CONSIDERATIONS

DB2 Database support associated account enumeration only.



Authentication

Authentication to an DB2 database can be performed using any non-managed account.


Account Discovery

Account discovery is supported for target DB2 database instances.

Password Management

There is no password management for DB2 databases as the accounts DB2 uses come from the local

host or from a central directory.

Ports and Protocols

For most installations of DB2 databases, including clustered resources, there will be no additional



DB2 listens on port 50000 by default, but this port can be changed. Be aware of port changes.

2.1.8 Xerox Phaser Printer Considerations

Xerox Phaser printers are simple to manage and have only once account: Administrator.


Authentication

Authentication to a Xerox Phaser Printer occurs over SNMP via the administrator account. This

account can be renamed which means you must be aware of the current name of this account.

Account Discovery

Account discovery is not supported for Xerox Phaser printers as there is only one account.

Password Management

Lieberman RED Identity Management can perform password management for Xerox Phaser

printers, but will use the administrator account to change its own password.


Ports and Protocols

All management operations are performed via SNMP. The default SNMP port is 161. SNMP relies on

a community name to aid in authentication. The default community name is public. The community

name is subject to change during printer configuration. SNMP with SSL is not supported at this time.

2.1.9 LDAP Considerations

LDAP directories are supported for discovery and management. You will need to know a login name

and the base LDAP path among other properties. See the admin guide for information on enrolling

LDAP directories.

There are four LDAP directory nodes re-defined in Lieberman RED Identity Management. All four

nodes operate the same way. The difference between any of the nodes is the default search and

attribute parameters. You may use any node for any LDAP compliant directory you intend to

discover and manage.


Authentication

To authenticate to an LDAP directory, you need the following information:

• Target server - the target server to query.

• Base LDAP path - the base LDAP path from which to begin the query.

• Authentication type - Integrated authentication is for Active Directory domains, anonymous

authentication passes the anonymous username and no password, while explicit authentication

passes a specific username and password. You must be aware of how the login username and

password must be formatted and whether simple authentication is required or not.

• Login name and login format (simple vs not-simple logins).

• Port and protocol information - see below.

Account Discovery

Account discovery is supported by Lieberman RED Identity Management for LDAP directories. To

properly identify accounts you will need to know what the proper LDAP search filter is and the

proper object identifier property is for your target LDAP directory.

Searches will start at the base LDAP path.


Assuming the base LDAP path and search filter is correct, the search may still fail if the LDAP

authentication record is configured to use paged queries but the directory cannot use paged queries

(or vice versa).

Password Management

Lieberman RED Identity Management can perform password management for LDAP users provided

the login account has the ability to reset target user passwords.

Ports and Protocols

All management operations are performed via LDAP. LDAP listed on port 389 by default, but

directories can be configured for alternate LDAP ports or to use SSL. LDAP with SSL defaults to port

636. Typically, the port configuration doesn't change but the requirement for SSL (or TLS) may be

required, where by default it is not.

2.1.10 McAfee ePolicy Orchestrator Considerations

McAfee ePolicy Orchestrator password changes occur by directly manipulating information in the

ORION table or the ePO database, which runs on Microsoft SQL Server. Access to this database must

be available to Lieberman RED Identity Management.


Authentication

Authentication to a Microsoft SQL server can be performed using an explicit SQL account (e.g. sa) or

a trusted account from the local Windows host or joined directory. When working with a SQL server

from a trusted domain, it is expected that the account running the console or scheduling service will

be granted the appropriate permissions to the target SQL server or that the SQL Server will permit

access with a proper explicit SQL server account.

If attempting to manage a SQL instance on an untrusted host, relative to the Lieberman RED Identity

Management component server host, you will only be able to use an explicit SQL Server account.

Account Discovery

Account discovery is supported for target McAfee ePO instances provided the connection account

has the ability to read from the ORION table.


Password Management

Lieberman RED Identity Management can manage passwords for target McAfee ePO instances

provided the connection account has the the ability to write/update the ORION table.

Ports and Protocols

For most installations of SQL server, including clustered resources, there will be no additional steps

to take. However, SQL server does allow the configuration for the requirement of an SSL protected

connection. If the connection is enabled for SSL or TLS, management of EPO accounts will not be

possible.

SQL server listens on port 1433 by default, but this port can be configured per IP address or SQL

instance. Be aware of any port changes to the SQL server or named instance requirements.

2.1.11 SAP Considerations

Management of SAP targets is specific to SAP accounts in the core SAP product. Management can

occur directly or through a NetWeaver gateway.


Authentication

Authentication to an SAP instance can occur with a local SAP account or a trusted account from

another directory.

If not using a gateway, you will need to know the following information:

• System Number

• Client

• Destination

• Table Name - default table name is USERLIST and Column Index is 0.

If using a gateway, you need to know the following information:

• HTTP or Non-HTTP port

• URL Path to the server

• The Netweaver add-on must be installed on the gateway host.


Account Discovery

Account discovery is supported for target SAP instances for accounts found in the core SAP product.

Password Management

Lieberman RED Identity Management can manage passwords for target SAP instances.

Ports and Protocols

Ports will vary based on your use of the Netweaver Gateway vs direct connection.

Other Requirements

Librfc32.dll must be provided and copied into the \Windows\system32 directory of the Lieberman

RED Identity Management host that will manage the SAP instance.

2.1.12 Oracle WebLogic Considerations

Management of Oracle WebLogic targets is specific to accounts in the core WebLogic product.


Authentication

Authentication to a WebLogic instance must use a local WebLogic account.

Account Discovery

Account discovery is supported for target WebLogic instances for accounts found in the core

WebLogic product.

Password Management

Lieberman RED Identity Management can manage passwords for target WebLogic instances.

Ports and Protocols

Ports for WebLogic can vary with installation and the use of SSL. The default ports are 7001 and

7002 with SSL.

Other Requirements

An EAR file must be installed as an enterprise application and start with the WebLogic instance.


2.1.13 IBM WebSphere Considerations

Management of IBM WebSphere targets is specific to accounts in the core WebSphere product.


Authentication

Authentication to a WebSphere instance must use a local WebSphere account.

Account Discovery

Account discovery is supported for target WebSphere instances for accounts found in the core

WebSphere product.

Password Management

Lieberman RED Identity Management can manage passwords for target WebSphere instances.

Ports and Protocols

Ports for WebSphere can vary with installation and the use of SSL. The default ports are 9080 and

9443 with SSL.

Other Requirements

An EAR file must be installed as an enterprise application and start with the WebSphere instance.

2.1.14 Azure Active Directory Considerations

Management of Azure Active Directory accounts is supported by Lieberman RED Identity

Management.


Authentication

Authentication to Azure AD will use an Azure AD account supplied as an email address. You will also

require the following information:

• Client ID

• Tenant ID

• Subscription ID


• Management Certificate and Certificate password - optional - used for discovering systems in

the Azure instance.

Account Discovery

Account discovery is supported for Azure AD.

Password Management

Lieberman RED Identity Management can manage passwords for Azure AD accounts. Standard

Active Directory account management permissions apply.

Ports and Protocols

All management functions will occur over an HTTPS connection. If the Lieberman RED Identity

Management host cannot connect directly to the internet, you may also need to configure a proxy

server connection when enrolling the Azure instance.

Other Requirements

If using Azure AD as an authentication source for users logging into the web application, an

application must also be configured in Azure AD. See the Admin Guide for more information.

2.1.15 Amazon Web Services Considerations

Management of Amazon Web Services accounts is supported by Lieberman RED Identity

Management.


Authentication

Authentication to Amazon will use an Amazon account configured with an API certificate. This

certificate (alternate name and password) is what will be used for AWS management.

Account Discovery

Account discovery is supported for AWS.

Password Management

Lieberman RED Identity Management can manage passwords for AWS accounts.


Ports and Protocols



server connection when enrolling the AWS instance.

2.1.16 RackSpace Public Cloud Considerations

Management of RackSpace accounts is supported by Lieberman RED Identity Management.


Authentication

Authentication to RackSpace will use an explicit username and password.

Account Discovery

Account discovery is supported for RackSpace.

Password Management

Lieberman RED Identity Management can manage passwords for RackSpace accounts.

Ports and Protocols



server connection when enrolling the RackSpace instance.

2.1.17 SalesForce Considerations

Management of SalesForce accounts is supported by Lieberman RED Identity Management.


Authentication

Authentication to SalesForce will use an account supplied as an email address.

An application must be configured in SalesForce to allow connectivity. From this application will

require the following information:

• Consumer Key


• Consumer Secret

Account Discovery

Account discovery is supported for SalesForce accounts that are enrolled with the Chatter service.

Password Management

Lieberman RED Identity Management can manage passwords for SalesForce accounts provided the

login user is permitted to change passwords and the application allows that sort of management.

Ports and Protocols



server connection when enrolling the SalesForce instance.

Other Requirements

If using SalesForce as an authentication source for users logging into the web application, an

application must also be configured to allow authentication in SalesForce. See the Admin Guide for

more information.

2.1.18 Softlayer Considerations

Management of Softlayer accounts is supported by Lieberman RED Identity Management.


Authentication

Authentication to Softlayer will use an explicit username and password.

Account Discovery

Account discovery is supported for Softlayer.

Password Management

Lieberman RED Identity Management can manage passwords for Softlayer accounts.


Ports and Protocols



server connection when enrolling the Softlayer instance.

2.1.19 VMware ESX Considerations

Management of VMware ESX accounts is supported by Lieberman RED Identity Management.


Authentication

Authentication to VMware ESX will use an explicit username and password.

Account Discovery

Account discovery is supported for VMware ESX.

Password Management

Lieberman RED Identity Management can manage passwords for VMware ESX accounts.

Ports and Protocols


Management host cannot connect directly to the ESX host, you may also need to configure a proxy

server connection when enrolling the VMware ESX instance.

2.1.20 Other SSH & Telnet Considerations

Most any network device that can be managed via SSH or Telnet can be managed by Lieberman RED

Identity Management, even if there is not a specific node for the target system, for example F5

devices.

Custom account stores can be created for these devices or these devices can be added to other

SSH/Telnet based nodes, such as the Linux/UNIX node.



Authentication

Authentication to an SSH host when establishing an SSH session can occur using a certificate or




Account Discovery

Account discovery for SSH systems and Lieberman RED Identity Management relies on the ability to

read from /etc/shadow and /etc/password. Any permission or policy that prevents the Lieberman

RED Identity Management login account from reading this file, up to and including the files don't

exist in the /etc directory or at all will prevent account enumeration from working.

Versions of Lieberman RED Identity Management prior to version 5.5.0, would copy the files from

the SSH host using SCP to the local Lieberman RED Identity Management host for local parsing. This

has since changed with version 5.5.0 and later. The new process lists the contents of the files within

the session which in turn allows for quicker operations and a low powered account that is allowed

to use sudo to cat the files, specifically: sudo cat /etc/shadow.

Password Management








Ports and Protocols

Modern SSH systems will use SSH as the defacto protocol for management operations. SSH uses a

single port which defaults to TCP 22. If you are using Telnet for any reason, the default port is 23,

but that can also be changed. Whether using SSH or Telnet, you will need to know the target port if

you are configured to use an alternate port.







2.2 WHERE ARE THE TARGET SYSTEMS LOCATED? Where the targets systems are physically located, relative to the Lieberman RED Identity

Management hosts, can affect the deployment strategy. For example:

• An Amazon Web Services instance must be managed, however, no hosts are allowed direct

connectivity to the internet. You must configure the use of a proxy server in order to manage

the target AWS instance.

• A Linux machine that resides in a DMZ must be managed. You could deploy a zone processor

(and install the crossPlatformSupportLibrary) into the DMZ or stand up another Lieberman RED

Identity Management instance in the DMZ or open up specific firewall ports.

• If the systems are located across a high speed WAN link, you might consider deploying a zone

processor or managing directly from the central location.

Logical separation is just as important as physical separation. In this case logical separation refers to

trusted versus untrusted systems. Trusted systems, Windows systems in particular, are very easy to

manage from a central location with a single trusted account. Untrusted Windows systems can

potentially be managed by the central instance of Lieberman RED Identity Management if managing

just a local account password, but when it comes to propagating the password to items like tasks,

COM, and others, account impersonation becomes an issue and must be accounted for.

Determining where the system are located, both physically and logically, helps design an effective

infrastructure.

2.3 WHAT ACCOUNTS WILL BE MANAGED? What accounts will be managed and which accounts will perform the management is an important

consideration.

In the *NIX world, more so than the Windows world, there are many options for who will perform a

management task and in what context. For example:

A low powered account will login and will manage its own password. In this case, the account will

issue passwd. In order to change its own password, it must be able to:

• Change its own password.


• Not be in violation of the minimum password age policy.

• Not be in violation of the password history policy.

• Not violate password requirements regarding length and complexity.

Whereas a root account performing a password change can change any users password, issuing

passwd userName. Regarding a root account, there is nothing else to consider. In some cases, a root

account can set passwords that do not comply with the configured password length and complexity

requirements and minimum age and history policies are not even considered.

This same concept applies to all password changes across every platform: what account will login

and what account will be changed.

2.4 WILL HIGH AVAILABILITY BE EMPLOYED? High availability should be employed whenever possible. All components of Lieberman RED Identity

Management support a highly available configuration. In most cases, an HA deployment is a

function of the infrastructure the solution is installed on.

• Database - Install the database as a cluster, database availability group (SQL AlwaysOn), or

mirror. Potentially replicate the database to an alternate location.

• Web - Configure IIS hosts to be load balanced using Microsoft load balancing or an external

hardware load balancer.

• Management Console - Deploy multiple management consoles on multiple servers.

• Deferred/Zone Processors - Deploy multiple deferred or zone processors on multiple servers.

• Application Launcher - Configure Microsoft RDS in an RDS farm.

Virtualizing these host servers adds additional HA aspects such as virtual machine fail over, hot

migration, etc..

High Availability is no replacement for a good disaster recovery (DR) strategy, so be sure to perform

regular database and VM backups, no matter what HA strategy is employed!

2.5 HOW WILL THE INFRASTRUCTURE BE DEPLOYED? How the infrastructure will be deployed will be impacted by the physical and logical layout of the

network. The general guidelines are:

• Choose the best location for your active database. Management consoles, web applications,

web services, and deferred/zone processors must be able to communicate directly with this


database. Typically clustered resources (cluster, AlwaysOn, Mirror) are located on the same

LAN. Databases may then be replicated to off-site databases.

• Web application and web service hosts should be kept logically close to the database host. The

information sent from client to web app/service or vice versa is relatively small compared to the

work sent between the web application/service host and database. It is best to ensure a fast

and reliable connection between the database and web application/service host, even when

web application users are far away or over a slow link.

• Management consoles are typically installed on a central server and accessed via a remote

desktop session. It is best to ensure a fast and reliable connection between the database and

the primary management console even when managers must use RDS over a slow link.

• Zone Processors should be deployed to the same network as managed targets. This minimizes

the number of firewall configurations required and keeps management traffic close to the

managed targets.

• Application Launcher servers will be kept close to the systems they are connecting to with

launched applications. These need connectivity to the web service hosts and users must be able

to use remote desktop services (remote app) to the these bastion hosts.

• Session recording, specifically the free session recording included with the application launcher

feature, will be installed on the application launcher hosts. However, recorded files must be

written back to a central location that can be accessed by the streaming media server(s).

Microsoft's distributed file system (DFS) is often use to make this deployment easier.

Choosing to deploy on physical or virtual systems, on premise or in the cloud, is a choice you must

make. Most deployments happen on virtual machines located on premise, though all of these

scenarios, or combinations of these scenarios, are fully supported. There is no inherent difference

to deploying on premise versus in the cloud and the basic connectivity and infrastructure

requirements remain the same.

No component of Lieberman RED Identity Management will work if the database is offline or

inaccessible. A deferred/zone processors need constant connectivity to the database to maintain

functionality. If a deferred processor attempts to start when the database is unavailable, it will fail

to start and must be manually started. Web applications and web services will attempt a new

connection to the database on each activation attempt. This means there is no additional steps

required to start a web service or application if the database is unavailable at any time.


2.6 FIREWALL CONSIDERATIONS Firewall configurations must be considered when deploying Lieberman RED Identity Management.

There are many components in Lieberman RED Identity Management that must speak with each

other and with other systems. Here are some of the communications that occur:

• In the basic scenario, the management console, zone processors, deferred processors, web

application and web services all require communication with the central database. The

database listens on a specific port, by default, 1433.

• Management occurs from the management console or zone/deferred processors over a variety

of ports depending on the management targets.

• Users will connect to the web application and web services over HTTPS. HTTPS defaults to port

443.

• If they click an application launch link, the user will be directed to a remote app session (RDS).

RDS defaults to port 3389.

• The RDS server will require web service connectivity over HTTPS which defaults to port 443.


• The RDS server will create a connection from itself to the management target with a specific

application which may further operate on a variety of ports.


2.7 WHEN TO USE ZONE PROCESSORS Lieberman RED Identity Management can perform many different types of work such as system

discovery, account discovery, password rotation and propagation, and more. You can perform this

work interactively (by the user running the administrative console) or can schedule this work to be

performed at a scheduled time. Creating work for Lieberman RED Identity Management to perform

creates a job.

To run a job which is scheduled for the future requires a service be present to run these jobs.

Historically, the service Lieberman RED Identity Management provided for this was simply called the

“Deferred Processor” or “Default Deferred Processor”

Over time it became necessary for Lieberman RED Identity Management to service multiple

segments or divisions of a single company. In the original design premise, the design of default

deferred processor proved insufficient and/or inefficient to handle the needs of companies with

multiple network segments or divisions. This led to the evolution of the deferred processor into

what is presently referred to as a Zone Processor.

The design premise of what is called a zone processor is to specifically handle multiple network

segments or divisions within a company. In recent years, the zone processor has evolved to handle

not only multiple network segments and divisions, but also to be able to handle specific job types.

It is these evolutions that has led to some confusion about when or why or where a zone processor

may be necessary. It is the purpose of this section to identify multiple cases and design & purchase

decisions regarding zone processors.

Code wise, there is no difference between a ZP and a DP; they start off life as the exact same files.

Functionally, the difference is significant:

• A deferred processor handles all job types for all systems in all management sets.

• A zone processors handles specific job types for any systems in one or more specific

management sets.

The deferred processor is simply installed. It will run any and all jobs against any and all systems in

any and all management sets. The deferred processor does not account for additional zone

processor assignments. As such, the deferred processor will run any and all jobs against any and all

systems in any and all management sets.

A zone processor is assigned to at least one specific management set and at least one specific job

type (e.g. password rotation). As such the zone processor will only run that specific job type against

that specific set of systems defined in that specific management set. A zone processor will never try

to manage anything else.


Zone Processors are a licensed feature of Lieberman RED Identity Management.

2.7.1 Zone Processor Use Case Scenarios

The question of when to deploy a deferred processor is easy to answer: deploy a deferred processor

when you wish to schedule jobs to run in the future without a human present and there is no need

to segregate any of the system management.

The question of when to deploy a zone processor is also easy to answer: deploy a zone processor

when you wish to schedule jobs to run in the future without a human present and there is a need to

segregate at least some of the system management or the WAN links are already slow and

saturated or there are security concerns around management….

The third scenario shows a hybridization of the ZP vs. DP design: let the processor run against any

management set, but restrict the processor to a specific job type. This additional scenario became

possible once Lieberman RED Identity Management could define what job types a zone processor

could run. With this scenario, it is not quite as black and white as it once was when trying to license

or design a zone processor topology.

The following scenarios are designed to show when it would be necessary to have zone processors

with or without a deferred processor and in what configurations they would be found.

Scenario 1: All Access Everywhere #1

In a well-connected network with high speed highly reliable links where there is no well-defined

internal security boundaries, or if there are boundaries, they will not be managed by this instance of

Lieberman RED Identity Management then one or more deferred processors will suit the customer

just fine.

This scenario will make use of:

• One or more deferred processors only. There is no need for multiple consoles or zone

processors.




Lieberman RED Identity Management, or where the customer simply wishes to improve the job

processing throughput of the job scheduling system, multiple deferred processors or multiple

deferred processors and zone processors will be sufficient.


In Lieberman RED Identity Management, a single job processor can handle only one job at a time.

This can lead to other jobs getting backed up in the job queue until a job processor becomes

available. If there are two processors, then two jobs may run simultaneously. This concept will scale

linearly. More processors means more jobs at the same time.


• Multiple deferred processors and/or multiple zone processors. No special configuration of

anything is required.




Lieberman RED Identity Management then one or more deferred processors will suit the customer

just fine.

Additionally, the customer wants to ensure password change jobs do not interfere with account

elevation jobs.

The last requirement could indicate a desire - not necessarily a need - to install an additional

deferred processor or zone processor to manage any and all management sets and simply be

restricted to account elevation jobs.

This scenario will make use of either:

• Multiple deferred processors where one or more DPs runs all job types and additionally one or

more DPs runs only account elevation jobs. Multiple consoles required.

• One or more deferred processors to handle all job types and one or more zone processors to

handle only account elevation jobs.

There are no pros or cons to either choice. The path to choose will depend on the desire to have

every processor manage any system or have a specific [zone] processor be limited in scope to

specific systems.

Scenario 4: WAN Links with All Access Everywhere #1

In a scenario where the customer’s organization is divided into multiple geographical regions

separated by WAN links (wide area networks) where WAN traffic is NOT a concern, where there is

no well-defined internal security boundaries, or if there are boundaries, they will not be managed

by this instance of Lieberman RED Identity Management then one or more deferred processors will

suit the customer just fine.



• One or more deferred processors only. There is no need for multiple consoles or zone

processors.

Scenario 5: WAN Links with All Access Everywhere #2

In a scenario where the customer’s organization is divided into multiple geographical regions

separated by WAN links (wide area networks) where WAN traffic IS a concern, it will be highly

recommended, and likely customer required, to use zone processors.

In this scenario, the customer will be concerned about the amount of traffic that Lieberman RED

Identity Management will send over a WAN link from a central point. Rightfully so, hundreds of

simultaneous connections from a single source can be problematic over slow and/or unreliable long

distance links or where there is a need from the customer’s perspective to not send management

traffic over the link.

At this point is will be necessary to determine the number of locations/regions/offices that will

require a zone processor and if it is a hard requirement to NOT send traffic over the link or only a

“SHOULD NOT send traffic over the link but is OK if it does” type of requirement.

If this is a hard requirement to ensure no management traffic goes over the WAN link, then each

segment, including the segment where Lieberman RED Identity Management is actually located, will

need its own zone processor. Further, Lieberman RED Identity Management must have the default

deferred processor(s) configured to not run discovery/refresh jobs or management jobs. The DP

may still be present and running and processing management set updates, but should be configured

to not perform any systems management. A management set will be required for each segment

where there will be a zone processor.

If this is a soft requirement where the customer would prefer a zone processor to handle a job

locally on the segment, but it is OK if the management traffic traverses the WAN links, then

configure zone processors in each of the zones and let the default deferred processor continue with

its default configuration to manage anything anywhere. It should be noted to the customer, that

this is not a system of preference, it is a system of availability. If the default deferred processor is

available before a ZP for a zone is available, the default deferred processor will run the job over the

WAN links, even if the ZP could have run the job just one second later.

Scenario 6: A Customer with a DMZ

A DMZ (de-militarized zone) is a section of a network where traffic is explicitly cut off from the rest

of the network. The customer thinks in terms of the internal network (where they are), the DMZ

(where the secured servers are) and the external network (AKA the internet).


When the customer has a DMZ to manage, they have four choices for Lieberman RED Identity

Management configuration:

• Completely open the firewall to allow the Lieberman RED Identity Management host full access

into the DMZ from the internal network. This will likely never happen as it defeats the purpose

of having the DMZ.

• Allow the Lieberman RED Identity Management host to establish a VPN (private on-demand

connection) into the DMZ and have full access from the internal network. This also, will likely

never happen as it defeats the purpose of having the DMZ.

• Stand up a separate instance of Lieberman RED Identity Management in the DMZ. This

sometimes happens, but since it at least doubles the MS Windows, and MS SQL licensing

requirements plus the Lieberman RED Identity Management management requirements, this

rarely happens. Creating a standalone instance of Lieberman RED Identity Management is not a

bad design decision as it fully separates the infrastructure and exposure if Lieberman RED

Identity Management ever gets compromised internally or externally, but it is one that rarely

gains traction.

• Install a zone processor in the DMZ to handle the DMZ systems. Allow that zone processor

(known host) access through the firewall (one direction, one port, known host) to the

Lieberman RED Identity Management central database (known destination, known port). This is

often the most accepted scenario when working with DMZ as it is familiar, comfortable, easy to

manage, easy to understand, easy to secure, and the customer does not have to contend with

Lieberman’s version of application security.

Building on option 4, as this is the most used zone processor scenario, the customer will want -

really the customer will need - to setup zone processors for each zone. In this scenario there are

only two zones: internal and DMZ.

The customer may allow the deferred processor to run but should (read must) turn off the ability of

the deferred processor to perform password changes or discoveries. It should be relegated to admin

activity reports and management set updates only.

The customer will need one zone processor for the internal network and one for the DMZ.

If the last two items are not configured as described, the following will occur:

• The default deferred processor may attempt to manage DMZ systems. This will fail as the DMZ

does not allow incoming connections from the internal network.

• Item 1, will cause the job to fail. This will cause unnecessary alerts to be generated from

Lieberman RED Identity Management and cause unnecessary human response.


• As the deferred processor can decide what jobs are most past due more quickly than a ZP, it will

likely begin to monopolize the job (which keeps failing and generating alerts) which creates a

vicious cycle where the job can never run and exhausts retries causing the job to never actually

run successfully on schedule. This will cause the password change cycle to become out of spec

and possibly the client to be out of compliance.

Scenario 7: Customer with WAN Links and DMZs

See scenario 6. A DMZ will essentially mandate a zone processor for every zone and proper (limited)

configuration of the deferred processor to not run password change or discovery jobs.

Scenario 8: Customer Has Trust Issues

This scenario applies to managing Windows workstations and servers only.

In the Windows world, there is a concept of trust. Trust is what allows an identity from one domain

to access a resource in another domain. If there is a trust in place and going in the correct direction

(it is possible for A to trust B but for B to not trust A) and Lieberman RED Identity Management is in

on the correct side of that trust, then things are relatively easy. But if there is no trust or Lieberman

RED Identity Management is on the wrong side of that trust, then things are going to be more

complex.

If there are trusts in place and Lieberman RED Identity Management is on the correct side of the

trust, then refer to the previously described scenarios.

If there are no trusts in place or Lieberman RED Identity Management is on the incorrect side of the

trust, then zone processors will likely be necessary if the customer desires to manage the whole

network through a single instance if Lieberman RED Identity Management. This will require further

investigation. Specifically determine:

Will the customer solely be dealing with password changes (domain or local) and not propagating

those password changes to scheduled tasks, IIS, COM/DCOM or other remote COM related items?

• If the answer to this entire question is “yes, the scope will be limited AND no we will not

propagate to any of those items”, zone processors may not be required. Alternate

administrators or cached credentials could be used in this scenario so long as the customer’s

environment falls under scenario 1, 2 or 3. If the customer’s scenario falls under case 4, 5 or 6 a

zone processor will likely be required.

• If the answer to the question indicates that propagation may be required, then likely, a zone

processor will be required.


If zone processors are a requirement there would be no less than two zone processors (assuming

only two domains. The actual number of zone processors required will be determined through

further discovery of the total number of untrusted domains, DMZs, regions, etc. as defined in the

prior scenarios.

Scenario 9: Clustered Services

This scenario applied to managing Windows servers only.

Lieberman RED Identity Management can propagate passwords. This means that once the password

is changed for the account in question, Lieberman RED Identity Management can also update all the

other references for the account such as those used by Windows services.

Windows allows for clustered services. Clustering is a means of ensuring that even if the service in

question (email, database, web, etc.) go down on one server, there is a duplicate service on another

machine that will stay functional and continue to provide service to the customer.

Lieberman RED Identity Management can propagate password changes to Windows clustered

services. However, there are some considerations:

• The most important consideration is that starting with Windows Server 2008, the management

of clustered services is no longer backward or forward compatible.

• Clustered services running on a Windows Server 2008 host cannot be managed by a Windows

Server 2012 host or vice versa.

• This is a limitation imposed by Microsoft.

So when dealing with a customer who is managing clustered services the important question is if

the clustered services are hosted on a version of Windows that is exactly the same as the Windows

OS that is running Lieberman RED Identity Management.

If the operating systems are not the same, then zone processors will be required. This scenario, to

guarantee there are no problems during password propagation, will require that all zones including

the zone where Lieberman RED Identity Management is hosted, will require a zone processor. The

default deferred processor, if left enabled, must be configured to NOT perform password

management jobs to guarantee the correct zone processor with the correct OS requirements

manages the services or there will be a service outage or possible failover/destruction of the

cluster.


2.7.2 Deploying Zone Processors

Management sets are used to define the lists of systems that a zone processor will be responsible

for. Thus proper planning of management sets is essential to proper deployment of zone

processors.

Consider a network with only two segments: internal and DMZ. At a minimum, two management

sets will be created, one for each zone. In turn, a zone processor will be deployed and assigned to

each specific management set. In this way, when you create a job destined for an internal system, it

is run by the internal zone processor. Similarly, when you create a job destined for a server in the

DMZ, it is run by the zone processor in the DMZ.

Zone processors require direct connectivity to the database. This communication is unidirectional

from a known source to a known destination over a known port. Specifically, the communication is

initiating from the zone processor host to the central database over the SQL communications port.

At a Glance

When the zone processor feature is enabled, the Zone Processors button will be available in the

Stored Jobs dialog, available by clicking the Jobs button in the management console.

Zone Processors can be deployed by pushing the zone processors files and settings from the

management console (by clicking install) on the Zone Processors dialog, or by using the standalone

installer, available in the in the SupplementalInstallers folder within the installation directory. The

standalone installer must be configured for each zone you are deploying a zone processor to.

When installing a zone processor, pre-requisites such as .Net framework requirements, Windows

Management Framework requirements, and required database provider requirements are not

verified. If the correct database provider is not present when the zone processor attempts to

startup, the startup process will fail.

Pushing a Zone Processor

When pushing a zone processor, you will require file system and remote registry access to the

target host. If either of these is unavailable, the push will fail. When pushing a zone processor, the

database configuration will be identical to that currently configured for the management console.

1) In the management console, click the Jobs button.

2) On the Stored Jobs dialog, click Zone Processors. Note, if you don't see the Zone Processors

button, the feature is not enabled.

3) Click Install.


4) Supply the following information:

Installation system - this is the name (simple, IP, or FQDN) for the ZP host.

Unique instance ID - This is instance ID of this zone processor. It must be unique on that system

to avoid collisions with other zone processors hosted on the same system.

Service account FQDN - The qualified name of the account that will run the service. It must be an

administrator of the target host and be granted logon as a service. If using integrated

authentication to the database, this account must also have proper database access as defined

in the installation guide.

Local file path for service - The physical location for the zone processor and its supporting files

to be copied to.

Enabled job types - Specify the types of jobs this zone processor will be allowed to perform.


Management Sets - Specify one or more management sets this zone processor will be

responsible for managing. Note that if a job is created against a system in another management

set, where the system is also a member of this target management set, this zone processor will

attempt to manage that system. Remove all management sets to allow the zone processor to

manage all management sets.

5) Click OK to begin the process. The files will be copied, the registry configured, but you will need

to start the service as a separate step.

Zone Processors Via Standalone Installer

When a zone processor cannot be automatically pushed, such as when dealing with an untrusted

system or DMZ, use the zone processor standalone installer located in the SupplementalInstallers

directory.

6) Launch CreateZoneInstaller.exe.


7) Supply the following information:

Installer Template - This value will already be configured.

New Installer - This is the new file that will be created and distributed to the target ZP host(s).

Job Log Path - Change the log file path for jobs if desired.

Service Log Path - Change the log file path for the zone processor scheduling service if desired.

Zone ID - This is instance ID of this zone processor. It must be unique on that system to avoid

collisions with other zone processors hosted on the same system.

Service Account Username - The qualified name of the account that will run the service. It must

be an administrator of the target host and be granted logon as a service. If using integrated

authentication to the database, this account must also have proper database access as defined

in the installation guide.

Service Account Password - The password for the service account. Click the Encrypt button to

encrypt the password inside of the created installer package. If you don't encrypt the password,

the password will be kept in clear text in the installer package.

Management Set Affinity - Define one or more management sets to assign to the zone

processor. If assigning more than one management set, separate management set names by a

semi-colon.

Job Affinity - Define the job types this zone processor will run.

Database Settings - If no settings are made, this installer will use the same database settings

currently defined in the console, even if they might not work for this specific zone processor.

Click the ellipses (...) next to Database settings to define custom settings for this zone processor

to use when connecting to the database, such as changing the server name to an IP address or

changing authentication to an explicit SQL account rather than integrated authentication. After

making changes, select the option for Use Customized DB Settings.


Retry Options - if no settings are made, the installer will use the same retry settings as currently

defined for this management console. Click the ellipses (...) to configure a different retry policy

for this zone processor.

8) Click Create.

9) Copy the new MSI file to the target machine and install it.

2.7.3 Zone Processor Support Files

When deploying a zone processor, it will be successful in managing Windows systems for password

changes not involving propagation.


Located in the SupplementalInstallers folder are additional helper files.

If you need have any of the following needs, you must install IntegrationComponents.msi on the

zone processor host:

• Password Propagation

• Help Desk Ticketing Integrations

• Event Sink notifications

• Email

Help desk integration support also requires certain file system and registry information be manually

copied from the management console host. See the admin guide for more information.

If you need have any of the following needs, you must install CrossPlatformSupportLibrary.msi on

the zone processor host:

• Connecting to anything with SSH or Telnet

• Connecting to other non-Windows platforms

57

This chapter lists some of the possible deployment strategies for Lieberman RED Identity

Management and will also describe some customer deployment scenarios. Included are descriptions

of bare minimum deployments through enterprise deployments.

Zone processor are always custom implementations and are configured to meet your specific

requirements. The implementations noted in this section are for reference only.

IN THIS CHAPTER

Deployment: Single Server No HA ........................................................... 58

Deployment: Multi-System No HA .......................................................... 59

Deployment: Multi-System Minimum HA ............................................... 59

Deployment: Multi-System Full HA ......................................................... 61

Deployment: Application Launching Minimum....................................... 62

Deployment: Application Launching Recommended .............................. 63

Customer Deployments ........................................................................... 64

Chapter 3 Deployment

Strategies

58 Deployment Strategies

3.1 DEPLOYMENT: SINGLE SERVER NO HA A bare minimum installation will use a single server. The single machine will host the database,

management console, website web service. If purchased, this same system could also host the

application launcher and session recording software. This system may be a virtual system or a

physical system. If this is a production system, it will have at least two CPU cores and 4GB of RAM or

better. Adding Application Launcher to this host will greatly increase CPU and RAM requirements.

Although not required, it is recommended to install the database in its own instance (rather than a

shared database instance) both for security and resource availability.

Backup is achieved by backing up the virtual machine or by backing up the database and encryption

key. Virtual Machine Backup is achieved using a solution appropriate to your Virtual Host. Database

backup is performed by configuring a backup job using SQL Management Studio.

This proposed solution provides minimum scalability and no high availability. This solution is

suitable to test, and small environments due to memory, storage, and high availability constraints.

The single server solution also poses the greatest security risk as the encryption key and the

encrypted data are hosted on the same server.

Deployment Strategies 59

3.2 DEPLOYMENT: MULTI-SYSTEM NO HA A recommended minimum deployment will include two systems: one for database and a second for

website and management console. If application launching is included, that is recommended to be

on a separate system. See Application Launching section towards the end of this document.

The database system will host the MS SQL database, preferably in its own instance, not shared with

other applications. This machine may be a physical system or a virtual system and will not be shared

with any other applications that utilize the system or database except for other Lieberman Software

solutions.

The management console, website, and web service may be hosted by a single virtual system. This

system should be allowed at least two CPU cores and 2GB of RAM. Hard drive space should provide

for multiple Gigabytes of free space for log file growth as required by the management console and

web application.

This proposed solution provides scalability to meet most medium to medium-large environments

that are generally well connected. Backup is achieved by backing up the virtual machine or by

backing up the database. Virtual Machine Backup is achieved using a solution appropriate to your

Virtual Host. Database backup is performed by configuring a backup job using SQL Management

Studio.

3.3 DEPLOYMENT: MULTI-SYSTEM MINIMUM HA Recommended medium deployments will include no less than three systems: At least two servers

for database HA, and one for the management console, website and web service. If application

launching is included, that is recommended to be on a separate system.


The solution database will utilize database availability groups, mirroring or database clustering to

provide for higher availability.

Availability groups, also known as always-on, was introduced with MS SQL 2012. It requires only two

database servers but can leverage more. Availability groups also offer a readable secondary server

which makes it very easy to work with reporting services tied to the non-modifiable copy of the

database. Availability groups also allows up to two synchronous replicas and two asynchronous

replicas to be simultaneously active. Availability groups is the recommended HA architecture for the

solution database.

Database mirroring is a feature introduced prior to MS SQL 2008. It requires the use of at least two

database servers. One DB is the primary DB and the other is a failover. Lieberman RED Identity

Management supports automatic and manual failover scenarios for database mirroring. At least two

database systems are required for manual failover and three for automatic failover. In a manual

failover, the database settings in the management console must be changed by hand. In an

automatic failover the SQL Native Client and the Witness server perform the fail-over. Mirroring

functionality was deprecated in SQL Server 2012.

Clustering may be used for the database in this deployment but will require the use of shared hard

drives and multiple network interfaces for each server.


3.4 DEPLOYMENT: MULTI-SYSTEM FULL HA Large deployments will contain five or more servers: two or more database servers, one or two

management console servers (licensing restrictions may apply), two or more password retrieval

website servers. If application launching is included, that is recommended to be on a separate

systems. Additional transcoder / media servers should also be placed on separate servers. See

Application Launching section towards the end of this document.

In the Full-HA server scenario, you will have at least two database servers, at least one management

console server, and at least two web servers.

There are multiple options for configuring the database the image above shows only one.

• The two database servers may be configured as an availability group without configuring the

database as a failover cluster. If using an availability group, multiple replicas may be made

available.

• The two database servers will be configured as a failover cluster. Additionally, you may wish to

mirror the clustered database to a single system or to another cluster of systems which will add

one or two more systems respectively.

The Lieberman RED Identity Management components will be pointed to the active node(s) in

either scenario.


The two web servers will be configured as a network load balanced cluster, using software NLB or a

hardware device. This provides high availability to the data source and high availability to access the

data (Stored passwords). This provides a constant access to stored passwords should up to two

servers fail (or more if mirroring to another cluster).

The variable is to deploy one or two management consoles. In order to deploy more than one

management console in a highly available solution, deploy a secondary console on a separate

machine (licensing restrictions may apply). Loss of the management console does not constitute

anything more than loss of the following abilities in a GUI:

• Create/Delete managed systems lists - can be done via PowerShell or web service.

• Create new password change jobs - can be done via PowerShell or web service.

• Scheduled jobs that run from the default deferred processor will not run; zone processor

operates independently on secondary systems and will continue to function.

In other words, the website and web service communicate directly to the database independent of

the management console and the converse is also true so disruption of one does not constitute

disruption in the other.

None of this is negates the need for a normal backup which should be done regularly.

3.5 DEPLOYMENT: APPLICATION LAUNCHING MINIMUM The following requirements are for launching applications on a separate bastion host where session

recording video transcoding will occur on a separate system (e.g. the web application server).

• Bastion host - remote desktop services host. 2GB RAM, 2 CPU cores or more. Refer to Microsoft

documentation for full remote desktop services sizing information.

.Net Framework v4.5.2

Additional requirements for launched applications

• Session Recorder / Media Server - 2GB RAM, 2CPU cores or more. Free disk space required will

depend on amount of stored recordings.


IIS


Microsoft Media Services (included in download)

The bastion host can also function as the video transcoder and media server, though this will impact

the performance of the host during video transcoding which will impact the user experience.

3.6 DEPLOYMENT: APPLICATION LAUNCHING RECOMMENDED If adding application launching and session recording the following hardware is also recommended:

• Bastion host - remote desktop services host. 6+GB RAM, 4-8 CPU cores or more (not including

hyper-threading). Installation could be in a farm if additional redundancy is required. Refer to

Microsoft documentation for full remote desktop services sizing information.


Additional requirements for launched applications

Multiple remote desktop services host configured as an RDS farm

• Session Recorder / Media Server - 4+GB RAM, 4-8CPU cores or more (not including

hyper-threading). Free disk space required will depend on amount of stored recordings.


IIS

Microsoft Media Services (included in download)

Storage for recorded videos could be on a DFS share

In the diagram below, use of Active Directory based DFS (distributed file system) is depicted as the

storage medium for raw and converted session recording files. DFS is not a requirement, but merely

a recommendation to add online redundancy for the storage of the recorded sessions. In this


scenario, the bastion hosts will record the raw sessions. They will be copied to the DFS share. The

media server transcode the files from the DFS share, then write the converted files back to the DFS

share, and then delete the original raw files. If a DFS share is not used, the bastion hosts will move

the raw files to the media server which will perform video transcoding services and provide local

storage. In either case, the media server will provide access to the recorded sessions via IIS and

Microsoft Media Services.

3.7 CUSTOMER DEPLOYMENTS This section describes some actual customer deployments.

Customer #1 - Cloud Services Provider

This customer manages over one million endpoints from a single distributed instance of Lieberman

RED Identity Management. The two primary management tasks include account elevation and local

password rotations.

Key points of this environment:


• Every day, several hundred systems are added and removed from production as capacity is

added or removed or simply due to system turnover resulting in the constant need for

management set updates to keep the information up to date.

• Every day, several thousand account elevations occur as support and IT staff require escalated

access to the target systems but cannot be granted persistent admin access to the systems.

• Every day, thousands of password rotations occur for existing systems as well as their

replacements.

The constant churn of systems initially caused delay for password change jobs and in turn for

account elevation jobs, as management sets needed constant updating.

The deployment:

• The database host configured has 32 CPU cores and 64GB of RAM.

• The database is configured in an availability group which is further replicated to another set of

SQL server hosts.

• There are four web application/web service hosts configured with a hardware load balancer.

• Each of two sites has 48 zone processors, some configured just for password management and

some configured just for account elevation.

• Additional zone processors were added to perform the continual refresh of the management

sets.

Reasoning:

In this scenario, the structure of the network is relatively flat. Zone processors were added to

improve job throughput. By adding more zone processors, more job queues are added which means

more jobs can be run at once thus reducing any latency and improving the user experience.

Customer #2 - Defense

This customer has 120,000+ systems to manage. The primary management task was password

rotations.


• This network contains over 120,000 endpoints.

• Local admin credentials on each endpoint must be rotated every week.

• Every month, there is approximately 18,000 password retrievals occurring which also add

approximately 18,000 additional password rotations per month following these retrievals.


The frequency required for password rotation meant human intervention was not only impractical,

but also impossible.

The deployment:

• The database hosts configured has 8 CPU cores and 16GB of RAM.

• The database is configured as an Active/Passive Cluster.

• There are two web application/web service hosts configured with a hardware load balancer.

• Four deferred processors were initially deployed to handle these password rotations. Zone

processors were not used as there was no need to further defined job affinity or management

set affinity.

Reasoning:

In this scenario, the network is relatively flat. More deferred processors were added to improve job

throughput. Zone processors were not used as there was no need to further defined job affinity or

management set affinity.

Customer #3 - Managed Services Provider

This MSP provides managed services for over 150 global customers. Previous to Lieberman RED

Identity Management, they asked their customers to create a large swath of named accounts for

the MSP staff so the MSP staff could manage the customer. This in turn required the customer to

support perform password resets for these named accounts if the support staff did not perform

their due diligence. Additionally, the MSP needed to manage privileged credentials on shared

customer resources, internal resources, and customer only resources.

Deploying Lieberman RED Identity Management allowed the customer to delete hundreds of

unnecessary accounts as shared accounts could be created that would have their password

managed and access audited by Lieberman RED Identity Management. This also eliminated the

need to the customers to perform password resets for the accounts required by the MSP.


• Over 150 global customers must be managed by a small group of support staff that rotate shifts

through the day.

• All customers must be managed through a single central service by the MSP.

• Overall password change volume was low, but frequency was high and based on shift changes.

The deployment:

• The database hosts configured has 8 CPU cores and 16GB of RAM.


• The database is configured as an Active/Passive Cluster.

• There are two web application/web service hosts configured with a hardware load balancer.

• Each customer, as well a a number of internal resources were placed under management of a

zone processor.

• Firewalls segregated web applications from the database.

• Firewalls segregated the zone processors in the customers environment from the central

database.

• Firewalls segregated the internal DMZ networks from the central database.

Reasoning:

Each customer, as well as some of the internal resources, represent untrusted networks for which

the firewalls do not allow inbound communication. Zone processors were deployed to each

customer to manage their specific resources (defined by management sets) and ensure the proper

support staff only had access to their assigned customers.

69

This section describes sizing for a variety of elements in Lieberman RED Identity Management

including database, host system, drive requirements and more.

IN THIS CHAPTER

Licensing .................................................................................................. 69

Database Host Sizing ............................................................................... 72

Management Console and Zone Processor Sizing................................... 76

Web App and Service Host Sizing ............................................................ 78

Application Launcher Sizing..................................................................... 79

Session Recording Sizing ......................................................................... 80

4.1 LICENSING Lieberman RED Identity Management requires a license to function. This license is tied to the

NetBIOS name of a host and is installed with the first console installed, referred to as the primary

management console. Additionally, licenses are required for each server, workstation and device.

When a commercial version of the product is purchased, a serial number (license key) will be issued

allowing management of a fixed number of systems and may enable a number of options.

When deploying Lieberman RED Identity Management, it will function without a license for 30 days

against 10 systems. After thirty days, the product will cease to function until a commercial license is

installed.

Following are the licensed items for Lieberman RED Identity Management:

• Support - While Lieberman RED Identity Management will function indefinitely once licensed,

the support period determines what versions you may upgrade to. You may upgrade to any

version released prior to the expiration of your support period.

• Console - You will receive a license for a single installation. This key will be installed on the

primary management console. After this license is installed, secondary management consoles,

Chapter 4 Sizing

70 Sizing

attached ot the same database, may be deployed without the need to input additional licenses

on those secondary consoles. If the machine name changes, a new license must be obtained.

• Endpoints - Your license will indicate a total number of licenses purchased. Licenses are

assigned to machine names automatically when the machine is managed by the management

console. You may manually release licenses from machines from the licensing dialog (Help |

Licensing). This will make those licenses available to new systems. If you are replacing a

machine using the same exact name, do not release the license to avoid a potential license

lockout situation. There is is no grace license count for overages. If you attempt to manage

machines that are not currently licensed, a new license must be available to assign to them or

the job will fail to run.

• Options - Lieberman RED Identity Management includes options, enabled by licensing. If you do

not have the menu items for the option, the license did not enable it. Available options include:

Zone Processing

Event Sinks

File Vault

Application Launching

Password Propagation

Account Pooling

See the admin guide for more information on using the management console and options. Contact

Lieberman Software for additional licensing needs.

When determining how many end point licenses to purchase, you will need an approximate count

of servers, workstations, and managed devices you intend to manage. It is irrelevant to this process

how many items are in a directory or on your network. It is recommended to then add 5-10% to that

number as there is no temporary overages are allowed for license count.

When planning your deployment, consider the infrastructure that Lieberman RED Identity

Management will be installed on. No additional licenses for that infrastructure is provided when you

purchase Lieberman RED Identity Management. This means you will need to provide licenses for

Windows, Microsoft SQL Server as well as Remote Desktop Services and the RDS clients when using

application launcher.

Following is an example to help describe the number of endpoint licenses required.

Example License Count

The system population and target account distribution is as follows:

Sizing 71

• 10 x ESX hosts

20 x local accounts (2 accounts x 10 hosts)

• 10 x IPMI

10 x local account (10 instances x 1 account)

• 40 x server guest

80 x local accounts (2 accounts x 40 hosts)

20 x database instances

o 80 x database accounts (20 instances x 4 accounts)

1 x Active Directory

o 15 x domain accounts

1 x Oracle Internet Directory

o 20 x LDAP accounts

5 x WebLogic

o 10 x accounts (5 instances x 2 accounts)

5 x ISA server

o 10 x local accounts (5 instances x 2 accounts)

• 40 x password lists

3,000 passwords

Totals:

• Total servers = 50 (10ESX hosts + 40 Server Guest OS)

• Total devices = 10

• Total accounts managed = 255

• Total accounts (passwords) unmanaged = 3000

Total Required Licenses:

• Total Server Licenses Required = 50

• Total Device Licenses Required = 10

Managed accounts and password lists do not consume licenses. Managers using the product do not

consume licenses. Only managed systems and devices are counted.

72 Sizing

4.2 DATABASE HOST SIZING The database is the single most important part of the Lieberman RED Identity Management

infrastructure. It contains all the data for the entire program and is the only piece of the product

where if it were to become unavailable would truly represent a production issue. Database sizing

covers not only the physical sizing of the database files but also the physical requirements of the

server itself.

Database CPU and RAM Resources

The database platform chosen has starting requirements to even turn on with respect to RAM, CPU

and so one. The starting off point for a production instance of a database which will host the

Lieberman RED Identity Management data store should have at least 2GB of RAM and two CPU

cores. This will be sufficient for a couple hundred managed systems, thousands of stored

passwords, and an otherwise basic installation which DOES NOT consist of any zone processors. The

recommended starting off point is 4GB of RAM and 4 CPU cores.

Proper sizing will involve base lining to determine the usage profile of the database: the database

involves large amounts of read and comparatively small amounts of write transactions following the

initial population of the database. The amount of data (number of systems, jobs, etc.) as well as the

number of zone processors will affect the requirements of the database.

The more systems data there is to read and write has an obvious effect on the need for more

database resources. However, the frequency at which these items are read and written, and the

amount of transactional data the server must service will affect the threading and queuing

resources required during any given transaction. Thus to offset his transactional requirement, an

increase in the available thread and queue capability will be required. This is in large part achieved

by adding more CPU and RAM.

An implementation with zone processors requires more database resources than those without. A

zone processor, just like a default deferred processor will query the database every N seconds to

check for work to do. N is equal to the sleep time value defined for the zone processor and has a

default value of 6 seconds. In other words, and also in the simplest case, a zone processor will check

the scheduling status of EVERY job in the database to determine which jobs are past due to run and

run the most out of date job. This information is calculated by running a query in the database every

N seconds per zone processor. Put another way, an implementation with 10 zone processors and

200 jobs will require the database to evaluate all 200 jobs, 10 times every 6 seconds. Then, if any

given (or multiple) zone processor(s) must run a job, they will be reading and writing to the

database while the other zone processors continue to query looking for work to do every 6 seconds.

Sizing 73

Each zone processor will require at least 512MB of RAM be added to the base line database server

RAM configuration. Each zone processor will tend to require 1/5th a CPU core.

EXAMPLE 1

Server Infrastructure Requirements without Zone Processors Environment Description:

• System count: 1,000

• Stored managed passwords: 2,000

• Propagation enabled: yes

• Number of base jobs: 20

• Base job frequency: monthly

• Number of re-randomization jobs per month: 200 (password recoveries)

• Total number of password changes per year: (20base x 12months) + (200 re-spin x 12months) =

2,640

• History enabled: yes

• Number of zones: 1 (default zone)

Recommended DB: 4 CPU cores, 4GB RAM

Factors:

• Small number of base jobs = low CPU, low ram

• Large number of recoveries resulting in re-randomization including propagation = add ram

• Large number of recoveries, year over year = add CPU cores in time

• Single zone (no zone processors) = low CPU, low RAM.

In example 1, although there were a large number of monthly password recoveries resulting in

subsequent re-randomizations of the target account overall CPU and RAM utilization will remain

low. The need for more CPU and RAM will be affected by total number of systems, total number of

jobs, and more zone processors.

EXAMPLE 2

Server Infrastructure Requirements with Zone Processors Environment Description:

• System count: 1,000

• Stored managed passwords: 2,000

74 Sizing

• Propagation enabled: yes

• Number of base jobs: 20

• Base job frequency: monthly

• Number of re-randomization jobs per month: 200 (password recoveries)

• Total number of password changes per year: (20base x 12months) + (200rerand x 12months) =

2,640

• History enabled: yes

• Number of zones: 10 (default zone)

Recommended DB: 4-8 CPU cores, 9-10GB RAM

Factors:

• Small number of base jobs = low CPU, low ram

• Large number of recoveries resulting in re-randomization including propagation = add ram

• Large number of recoveries, year over year = add CPU cores in time

• Multiple zone processors = add CPU, add RAM.

• Baseline = 4 CPUs

• ZP requirement = 10zp x 1/5th CPU = +2 cores

• Baseline = 4GB RAM

• ZP requirement = 10zp x 512MB = +5GB

Database Storage Sizing

Regarding the size of the database, there is nothing but variable after variable to contend with

when calculating the size of the DB such as:

• Number of systems

• Number of accounts

• Number of passwords

• Number of groups (system lists)

• Amount of recoveries and other web operations

• Number of delegations

• Number of password jobs

Sizing 75

• Stored password history

• Is propagation turned on or not

• Job failures

• Job logging

With the exception of the Secure File Store, Lieberman RED Identity Management is only storing

text into the DB fields as opposed to binary data. This means that what the input will be relatively

small in every sense of the word. Following are observed numbers from a Lieberman RED Identity

Management database running with SQL 2008 x64 Enterprise Edition.

INITIAL SIZING

• 4MB (.92MB Free) Default formatted DB, with one dynamic group with one active directory

query

MANAGED ITEMS

• System added to group (no information) = .0006MB Per system

• System information and account usage per system = .005MB per system

• System added to a job = .0006MB per system

• Stored Password with job settings and first time discovery information.045MB per new

password

• Job re-runs, stored passwords = .0017MB per password history

Based on the above number, a systems list with 1,000 systems in it changing one account on each of

those systems via one job, and further assuming that those accounts changed on the first try (no

retries or other failures) you would have an initial database that would be roughly:

4MB initial size + (.0006MB x 1000 Windows Systems) + (.005MB x 1000 Initial Discovery -

optional) + (.0006MB x 1000 systems in the job) + (.045MB x 1000 Password change job) =

55.2MB

If the optional discovery is not performed, which has no effect on jobs with propagation settings,

the size of the initial database becomes 55.2MB.

PASSWORD HISTORY

Password histories require approximately .0017MB (no job info stored with historic passwords).

1,000 password historical passwords, at 15 characters each, would be an additional 1.7MB.

After the initial password change job, there would be an additional 11 password change

jobs which would then record to password history.

76 Sizing

1.7MB x 11 pw changes = 18.7MB

LOGGING

Logging requirements will vary wildly based on operations performed vs success vs failure rates.

Based on this perfect example of all success and local password changes, logging would consume

approximately 20 MB of space over the course of the year. Logging tends to grow in a linear fashion

FIRST YEAR

After one year for 1000 Windows systems whose passwords change 12 times per year without

propagation, assuming everything else was relatively perfect, the size of the database would be:

55.2MB + 18.7 + 20 = 93.9MB

ANNUAL GROWTH

Assuming no other changes, this database will grow at the following rate:

1,000 systems x .0017 pw history x 12months + 1,000 systems x.0017 new password change jobs +

20MB logs = 42.1MB/yr

ACTUAL PLANNED SIZE

The size of the database will likely be much larger due to the factors mentioned at the beginning of

this section. In particular, job logging, web audit information, and account usage information will

impact the physical size of the database the most. Once the base measurement is determined using

the above math, for actual capacity planning triple the minimum size of the database:

93.9MB x 3 = 281.7MB for the first year.

42.1MB growth x 3 = 126.3MB projected actual growth per year.

4.3 MANAGEMENT CONSOLE AND ZONE PROCESSOR SIZING

CPU and RAM

The management console and zone processors consume a small amount of RAM and CPU cycles

when idle. At startup, the management console and scheduling service will consume approximately

15-20MB of RAM total and CPU utilization being 0% or close to it, with resources being allocated as

they run and perform work.

Both components are multi-threaded and can take advantage of as many CPU cores as is available

when performing work (e.g. password rotation, discovery, etc.). However, currently being a 32bit

application means no moe than 2GB of RAM will ever be available to each application.

Sizing 77

During an operation, CPU utilization for either process is capped at 95% of available CPU resources.

This is to ensure the system does not become unresponsive. Similarly, threading will be throttled

when total CPU resources reach 95%. In other words, if threads are dispatched and total CPU

utilization reaches 95%, no more threads will be launched until CPU utilization falls below that

threshold. When threads cannot be launched, total job performance will suffer. To help defeat this

condition add more CPU cores.

To help maintain RAM resources, plan your server's RAM capacity to include 2GB of RAM for the

host OS + RAM for other applications like anti-virus + 2GB of RAM for each Lieberman RED Identity

Management application component installed on the host.

To help maintain CPU resources, plan your server's RAM capacity to include 2 CPU cores for the host

OS + CPU requirements for other applications like anti-virus + 2 CPU cores for each Lieberman RED

Identity Management application component installed on the host.

Generally speaking, the minimum recommendation for a host server will be for 4 CPU cores and

4GB of RAM. During operations, more CPU cores will improve overall job processing performance

during multi-threaded operations.

The system also has a number of single threaded operations that occur where more CPU cores will

not help. Specifically:

• Console operations, such as changing management sets or opening the stored jobs dialog,

where the data for a dialog is read from the database and rendered on-screen, will not be

improved with more CPU cores. Rather, improving database to console performance will help

the initial load and ensuring a fast CPU and sufficient RAM on the host will improve the loading

of these dialogs.

• Individual system operations are single threaded. A job with 500 systems will dispatch 100

threads by default to manage 100 systems and the 400 will remain pending until there is at least

a single available thread. During these operations, there may be 50 operations to perform

against the host such as getting system information, reading service target propagation info and

performing the propagation. These operations will be performed in a single threaded linear

fashion against any particular host.

Logging

A number of logs are enabled by default for the following items:

• Management Console Operations - Logs every operation performed in the management

console.

78 Sizing

• Deferred Processor Service Log - Logs scheduling service activity such as launching and finishing

a job.

• Job Logs - Scheduled jobs create job log files named after each job ID which are appended to

with each successive job run.

Job Log Archiving is also enabled by default with a default setting of 1MB. When a component starts

(opens a handle to the specific log file), the size of the file is checked. If it exceeds the archiving

threshold, the log is moved to the log archival location and compressed and a new log file is

created. With this is mind, an active log can still exceed the 1MB threshold.

There are too many variables to provide an exact sizing recommendation for hard drive

requirements where logging is concerned. Most customers rarely exceed 4GB in total logging over

multiple years of activity.

4.4 WEB APP AND SERVICE HOST SIZING

CPU and RAM

The web application runs via IIS and leverages a COM+ application for database access and related

functionality. These COM applications (represented by dllhost.exe) consume a small amount of RAM

and CPU cycles when idle and shutdown automatically when not in use (per COM+ default settings).

At startup, the COM+ application will consume approximately 15-20MB of RAM total and CPU

utilization being 0% or close to it, with resources being allocated as they run and perform work.

Currently being a 32bit application means no moe than 2GB of RAM will ever be available to each

application.

To help maintain RAM resources, plan your server's RAM capacity to include 2GB of RAM for the

host OS + RAM for other applications like anti-virus + 2GB of RAM for each Lieberman RED Identity

Management application component installed on the host.

To help maintain CPU resources, plan your server's RAM capacity to include 2 CPU cores for the host

OS + CPU requirements for other applications like anti-virus + 2 CPU cores for each Lieberman RED

Identity Management application component installed on the host.

Generally speaking, the minimum recommendation for a host server will be for 4 CPU cores and

4GB of RAM.

Logging

One log is enabled by default for the web application or web service:

Sizing 79

• RouletteAppServiceSupport - Logs web service basic activity and errors.

• RouletteWebApplication - Logs web application basic activity and errors.

Job Log Archiving is also enabled by default with a default setting of 1MB. When a component starts

(opens a handle to the specific log file), the size of the file is checked. If it exceeds the archiving

threshold, the log is moved to the log archival location and compressed and a new log file is

created. With this is mind, an active log can still exceed the 1MB threshold.

There are too many variables to provide an exact sizing recommendation for hard drive

requirements where logging is concerned. Most customers rarely exceed 2GB in total logging over

multiple years of activity.

4.5 APPLICATION LAUNCHER SIZING The application launcher relies on Microsoft Remote Desktop Services (RDS) using RemoteApp to

stream applications to user's desktops.

To sum up Microsoft's stance on RDS host capacity: baseline and adjust as needed.

Following are some starting guidelines to RDS planning from various Microsoft resources:

• 2 Dual Core CPUs perform better then single Quad core processor.

• Recommended bandwidth for LAN of 30 users and WAN of 20 users. Bandwidth (b) = 100

megabits per second (Mbps) with Latency (l) Less than 5 milliseconds.

• On a Terminal Server 64 MB per user is the ideal memory (RAM) requirement for general

purpose use only + 2 GB for the operating system. For example, (100 users * 64MB) + 2GB = 8.4

GB.

• Applications used (i.e. SQL management studio, TOAD, etc..) will require more memory per user

to be added to this calculation over the 64MB base memory per user.

• 15 user sessions per CPU core is the recommended performance limit of an RDS host before

taking applications into account.

• CPU performance degrades if %processor time per core is constantly above 65%.

• Network should not have more than 5 hops, and latency should be under 100ms.

80 Sizing

4.6 SESSION RECORDING SIZING Application Launching ships with a free session recording component. Session recording runs on an

application launcher host and is triggered by launching applications configured for session

recording. This session recording component creates VCR like recordings of the start of the session

to the end of the session.

Sessions are recorded into a raw format. This raw file is shipped to the video transcoder. The video

transcoder converts the raw file into a playable format, such as WMV. The final file is moved to the

streaming media server. Note, these services could all be on the same host.

Using default settings, a recording at 1280x1024 in full color will consume about 300KB per

minute.

Once files are finally stored, they will be kept indefinitely until manually removed. There are no

automated data pruning processes.

81

A

AMAZON WEB SERVICES

CONSIDERATIONS • 32

APPLICATION LAUNCHER SIZING • 79

AS400 CONSIDERATIONS • 18

AZURE ACTIVE DIRECTORY


C

CISCO DEVICE CONSIDERATIONS • 16

CUSTOMER DEPLOYMENTS • 64

D

DATABASE CONSIDERATIONS • 20

DATABASE HOST SIZING • 72

DB2 CONSIDERATIONS • 25

DEPLOYING ZONE PROCESSORS • 51

DEPLOYMENT

APPLICATION LAUNCHING MINIMUM •

62

APPLICATION LAUNCHING

RECOMMENDED • 63

MULTI-SYSTEM FULL HA • 61

MULTI-SYSTEM MINIMUM HA • 59

MULTI-SYSTEM NO HA • 59

SINGLE SERVER NO HA • 58

DEPLOYMENT STRATEGIES • 57

F

FIREWALL CONSIDERATIONS • 40

H

HOW WILL THE INFRASTRUCTURE BE

DEPLOYED? • 38

I

IBM WEBSPHERE CONSIDERATIONS • 31

INTRODUCTION TO DEPLOYING

LIEBERMAN RED IDENTITY

MANAGEMENT • 5

IPMI DEVICE (LIGHTS OUT)


L

LDAP CONSIDERATIONS • 27

LICENSE AGREEMENT • 6

LICENSING • 69

LIMITED WARRANTY • 6

LINUX/UNIX CONSIDERATIONS • 14

Chapter 5 Index

82 Index

M

MANAGEMENT CONSOLE AND ZONE

PROCESSOR SIZING • 76

MCAFEE EPOLICY ORCHESTRATOR


MYSQL AND MARIADB CONSIDERATIONS •

23

O

ORACLE DATABASE CONSIDERATIONS • 22

ORACLE WEBLOGIC CONSIDERATIONS •

30

OS390 CONSIDERATIONS • 19

OTHER SSH & TELNET CONSIDERATIONS •

35

P

PLANNING FOR DEPLOYMENT • 9

POSTGRESQL DATABASE


R

RACKSPACE PUBLIC CLOUD


S

SALESFORCE CONSIDERATIONS • 33

SAP CONSIDERATIONS • 29

SESSION RECORDING SIZING • 80

SIZING • 69

SOFTLAYER CONSIDERATIONS • 34

SQL DATABASE CONSIDERATIONS • 21

SYBASE ASE CONSIDERATIONS • 23

T

TERADATA CONSIDERATIONS • 25

V

VMWARE ESX CONSIDERATIONS • 35

W

WEB APP AND SERVICE HOST SIZING • 78

WHAT ACCOUNTS WILL BE MANAGED? •

37

WHAT PLATFORMS WILL BE MANAGED? •

11

WHEN TO USE ZONE PROCESSORS • 44

WHERE ARE THE TARGET SYSTEMS

LOCATED? • 37

WILL HIGH AVAILABILITY BE EMPLOYED? •

38

WINDOWS CONSIDERATIONS • 11

X

XEROX PHASER PRINTER


Z

ZONE PROCESSOR SUPPORT FILES • 56

ZONE PROCESSOR USE CASE SCENARIOS •

45

Deployment & Sizing Strategies - BeyondTrust€¦ · deployment plan no longer meets the ever...

Documents

Transcript of Deployment & Sizing Strategies - BeyondTrust€¦ · deployment plan no longer meets the ever...