IBM Security Identity Governance and Intelligence Clustering and High Availability

Transcription

1 IBM Security Identity Governance and Intelligence Clustering and High Availability IBM SECURITY SUPPORT Luigi Lombardi: Gianluca Gargaro: Raffaele Sperandeo: Giuseppe Grammatico: Salvatore Matrone: July 14 th 2017

2 Goal of the Open Mic session Provide some guidelines about how to set up clustering and high availability in IBM Identity Governance and Intelligence, presenting a sample solution by Virtual Appliance, Front-end and back-end points of view. 2 IBM Security

3 Main Agenda What is going to be covered: Overview and Architecture Virtual Appliances setup and configuration Front-end: Web Load Balancer Back-end: DB2 Back-end: IBM Security Directory Server 3 IBM Security

4 Overview and Architecture

5 Section Agenda What is going to be covered in this section: Basic Architecture (5.2.x) How can users access IGI? Proposed solution 5 IBM Security

6 Basic architecture (IGI 5.2.X) users 6 IBM Security

7 Basic architecture (IGI 5.2.X) How can users access IGI? 7 IBM Security

8 Clustering and High Availability proposed solution IGI Front-end Load Balancer Web Seal Load Balancer IGI VA nodes IGI VA WebSphere Governance Identity Brokerage Onboard TDI IGI Back-end DB (HADR) DB DB HA Proxies Web Seal Reverse proxies IGI VA WebSphere Governance Adapter Store (Directory Server) Identity Brokerage ISDS Virtual IP Onboard TDI ISDS 8 IBM Security

9 Virtual Appliances setup and configuration

10 Section Agenda What is going to be covered in this section: Virtual Appliance Cluster Primary node configuration Member node configuration Cluster node configuration 10 IBM Security

11 Virtual Appliance Cluster IGI VA WebSphere Governance Identity Brokerage Primary Node Onboard TDI IGI VA WebSphere Governance Identity Brokerage Secondary Node Onboard TDI Member Nodes IGI VA WebSphere Governance Identity Brokerage Member Node Onboard TDI 11 IBM Security

12 Primary node configuration 12 IBM Security

13 Member node configuration 13 IBM Security

14 Cluster node configuration Cluster Configuration from Primary node Removing a node from the cluster Synchronizing a member node with a primary node Cluster Configuration from Member node Promoting the secondary node to the primary node Promoting a member node to the secondary node Reconnecting a node into the cluster Synchronizing a member node with a primary node 14 IBM Security

15 Front-end: Web Load Balancer

16 Section Agenda What is going to be covered in this section: WebSEAL Clustering Prepare WebSEAL for SSO to IGI Create an Ltpa Junction Create a FELB layer 4 server Verify failover using ISAM FELB 16 IBM Security

17 WebSEAL Clustering Group of Replicated WebSEALS sharing same object space generally with a Load Balance in front Improve Availabilty and performance Configuration changes performed on the Master WebSEAL. Define a mechanism for sharing session info ( failover cookie or DSC ) 17 IBM Security

18 Prepare WebSEAL for SSO to IGI (1/3) Via LMI edit WebSEAL Conf file Enable WebSocket support Create transformation rules for login and logout Detailed Information on IGI ISAM Integration Cookbook on developerworks 18 IBM Security

19 Prepare WebSEAL for SSO to IGI (2/3) IGI LMI console create an LTPA sso configuration Generate an LTPA key Export the LTPA key 19 IBM Security

20 Prepare WebSEAL for SSO to IGI (3/3) ISAM LMI console import LTPA key Add IGI CA Certificates into pdsrv.kdb 20 IBM Security

21 Create an LTPA junction Via LMI or command line Create transparent path /ideas junction point Use stateful junction Add LTPA support Add IGI servers 21 IBM Security

22 Create a FELB layer 4 server Create a Front End Load Balance Virtual Server Add WebSEAL Servers as Real Servers 22 IBM Security

23 Verify failover with FELB Swap active WebSeal between them WebSocket automatic reconnect 23 IBM Security

24 Back-end: DB2

25 Section Agenda What is going to be covered in this section: Introduction and Prerequisites of DB2 HADR Setting up DB2 HADR Enabling ACR Monitoring for automatic failover 25 IBM Security

26 Introduction Goal: minimize the impact of a single point of failure. Two identical DB2 servers, installed on separate systems. One acting as the primary database server, the other one as the standby. Data is replicated between them using the DB2 HADR fetaure, which allows automatic failover between two independent DB2 instances. 26 IBM Security

27 Prerequisites Following conditions must be met (refer to DB2 HADR system requirements page in Knowledge Center for details): The database names for the primary and standby databases must be the same. The instance names do not have to be the same. TCP/IP communications must be available between the primary and standby databases. The database server on primary and standby databases must be at same version, level and bit size (32 or 64 bits). The operating system for the hosts for the primary and standby databases must be at the same version and level. 27 IBM Security

28 Before to start (1/2) Installation of DB2 on both primary and secondary systems, according to mentioned prerequisites. Determine IP address and port number of each of the HADR databases. The general procedure, as per DB2 HADR setup, advises to take a backup of the primary and restore it to the standby. If preferred, set any configuration parameters recommended or required for HADR environments on the primary so that those settings will exsist on any standby you create. For example: enabling index re-creation behavior, and enabling a preferred logging method db2 update db cfg for <dbname> using LOGINDEXBUILD ON LOGARCHMETH <method> 28 IBM Security

29 Before to start (2/2) Specify the TCP/IP communication ports, adding on both system two lines to define the ports. For example: 29 IBM Security

30 Setting up DB2 HADR The DB2 HADR setup is achieved by setting various HADR configuration parameters. On both primary and standby databases, set the HADR local parameters (IP address and port): db2 update db cfg for <dbname> using HADR_LOCAL_HOST <IP address> db2 update db cfg for <dbname> using HADR_LOCAL_SVC <Port #> The level of synchronization between the primary and standby database is determined by the synchronization mode parameter (refer DB2 Knowlege Center documentation for details): db2 update db cfg <dbname> using HADR_SYNCMODE <syncmode> 30 IBM Security

31 Setting up DB2 HADR Linking primary to standby database Setting the remote HADR parameters to link the primary database system to the standby: db2 update db cfg for <dbname> using HADR_REMOTE_HOST <IP address of standby> db2 update db cfg for <dbname> using HADR_REMOTE_SVC <Port # of standby> db2 update db cfg for <dbname> using HADR_REMOTE_INST <instance name of standby> 31 IBM Security

32 Setting up DB2 HADR Linking standby to primary database Setting the remote HADR parameters to link the standby database system to the primary: db2 update db cfg for <dbname> using HADR_REMOTE_HOST <IP address of primary> db2 update db cfg for <dbname> using HADR_REMOTE_SVC <Port # of primary> db2 update db cfg for <dbname> using HADR_REMOTE_INST <instance name of primary> 32 IBM Security

33 Enabling Automatic Client Reroute (1/2) To transfer client application requests from a failed database server to a standby database server, the ACR (Automatic Client Reroute) will be configured with high availability disaster recovery. On the DB2 this is done using the Alternate Server command: l On the primary server: db2 update alternate server for database <dbname> using hostname <IP address of standby> port <Port # of standby> To ensure ACR can still be used in the event of a role switch, also the primary server can be configured as the alternate server for the standby: l On the standby server: db2 update alternate server for database <dbname> using hostname <IP address of primary> port <Port # of primary> 33 IBM Security

34 Enabling Automatic Client Reroute (2/2) On IGI Virtual Appliance, the ACR settings for DB2 is done in Configure > Database Server Configuration. In the DB2 ACR the Alternate server name and port number can be set, as well as other client reroute parameters. 34 IBM Security

35 Start HADR Start the standby system first: db2 start hadr on database <dbname> as standby Then start the primary system: db2 start hadr on database <dbname> as primary Verify that the HADR is set up properly on both systems by running the following command: db2pd db <dbname> -hadr 35 IBM Security

36 Failover testcase Takeover of standby DB when primary fails: - db2 takeover hadr on db IGI_DB by force 36 IBM Security

37 Back-end: IBM Security Directory Server

38 Section Agenda What is going to be covered in this section: Replication Info Replica Configuration ( Back-End Configuration ) IGI Integration for Target Administration 38 IBM Security

39 Replication Replication is a technique used by directory servers to improve performance, availability, and reliability. The replication process keeps the data in multiple directory servers synchronized. Replication provides three main benefits: Redundancy of information - Replicas back up the content of their supplier servers. Faster searches - Search requests can be spread among several different servers, instead of a single server. This improves the response time for the request completion. Security and content filtering - Replicas can contain subsets of the data in a supplier server. Simple replication: The basic relationship in replication is that of a Master Server and its Replica Server. The Master Server can contain a directory or a subtree of a directory. Cascading replication: Cascading replication is a topology that has multiple tiers of servers. Peer-to-peer replication: There can be several servers acting as master for directory information, with each master responsible for updating other master servers and replica servers. This is referred to as peer replication. Gateway replication: Gateway replication is a more complex adaption of peer-to-peer replication that extends replication capabilities across networks. 39

40 Replication Info Simple Replica: Read/Write Read Only Read Only Read Only 40

41 Replication Info Cascading Replication: 41

42 Replication Info Peer to Peer Replication: 42

43 Replication Info Gateway Replication: 43

44 Replica Configuration To identify our servers in a simple way I changed the ibm-slapdserverid on both Servers into Peer1 and Peer2 in the ibmslapd.conf file. Add Credentials entries in ibmslapd.conf to permit binding across servers. ( User is cn=binduser and password is Passw0rd ) Credential entry for Peer1: dn: cn=master server, cn=configuration cn: master server ibm-slapdmasterdn: cn=binduser ibm-slapdmasterpw: Passw0rd ibm-slapdmasterreferral: ldap://<peer2_host>:<port> objectclass: ibm-slapdreplication Credential entry for Peer2: dn: cn=master server, cn=configuration cn: master server ibm-slapdmasterdn: cn=binduser ibm-slapdmasterpw: Passw0rd ibm-slapdmasterreferral: ldap://<peer1_host>:<port> objectclass: ibm-slapdreplication Restart Peer1 and Peer2 44

45 Replica Configuration ( Continue - Backend ) Building LDIF to complete the configuration: Replica Group: The first entry created under the replication context has objectless ibm-replicagroup and represents a collection of servers participating in replication: dn: ibm-replicagroup=default, o=ibm,c=us changetype: add objectclass: top objectclass: ibm-replicagroup ibm-replicagroup: default 45

46 Replica Configuration ( Continue - Backend ) Replica subentries: Below a replica group entry, one or more entries with objectless ibm-replicasubentry may be created; one for each server participating in replication. The replica subentry identifies the role the server plays in replication: master or read-only Subentry for Peer1: dn: ibm-replicaserverid=peer1,ibm-replicagroup=default, o=ibm,c=us changetype: add objectclass: top objectclass: ibm-replicasubentry ibm-replicaserverid: Peer1 ibm-replicationserverismaster: true cn: Peer1 description: Subentry for Peer1. 46

47 Replica Configuration ( Continue - Backend ) Subentry for Peer2: dn: ibm-replicaserverid=peer2,ibm-replicagroup=default, o=ibm,c=us changetype: add objectclass: top objectclass: ibm-replicasubentry ibm-replicaserverid: Peer2 ibm-replicationserverismaster: true cn: Peer2 description: Subentry for Peer2. Credentials: Identify the method and required information for binding. For simple bind, this includes the DN and password. The credential are stored in an entry the DN of which is specified in the replication agreement. Credentials used by peer1 to bind to peer2 and vice versa: dn: cn=replicabindcredentials, o=ibm,c=us changetype: add objectclass: ibm-replicationcredentialssimple cn: ReplicaBindCredentials replicabinddn: cn=binduser replicacredentials: Passw0rd description: Bind Credentials on Peer1 and Peer2 to bind to each other. 47

48 Replica Configuration ( Continue - Backend ) Replication agreements The agreement contains all the information needed to making a connection between servers and scheduling the replication. The number of agreements is dependent upon the number of servers relationship in the topology Replication agreement from the Peer1 and Peer2 dn: cn=peer2, ibm-replicaserverid=peer1,ibm-replicagroup=default,o=ibm,c=us changetype: add objectclass: top objectclass: ibm-replicationagreement cn: Peer2 ibm-replicaconsumerid: Peer2 ibm-replicaurl: ldap://igi-522-sds62-s2:389 ibm-replicacredentialsdn: cn=replicabindcredentials, o=ibm,c=us description: Replication agreement from Peer1 to Peer2. dn: cn=peer1, ibm-replicaserverid=peer2,ibm-replicagroup=default,o=ibm,c=us changetype: add objectclass: top objectclass: ibm-replicationagreement cn: Peer1 ibm-replicaconsumerid: Peer1 ibm-replicaurl: ldap://igi-522-sds64-s1:389 ibm-replicacredentialsdn: cn=replicabindcredentials, o=ibm,c=us description: Replication agreement from Peer2 to Peer1 48

49 IGI Integration for Target Administration 49

50 THANK YOU FOLLOW US ON: securityintelligence.com xforce.ibmcloud.com Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. Any statement of direction represents IBM's current intent, is subject to change or withdrawal, and represent only goals and objectives. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a lawful, comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM does not warrant that any systems, products or services are immune from, or will make your enterprise immune from, the malicious or illegal conduct of any party.