Using Atrium Single Sign-On with TrueSight

Transcription

1 FAQ Using Atrium Single Sign-On with TrueSight 4 th April 2016 Version 1.0

2 1 Table of Contents Contents 1 Table of Contents 2 2 Document Purpose Purpose Intended Audience Objectives Related Documentation TrueSight Strategy for SSO Atrium Single-Sign-On (ASSO) and TrueSight Background Remedy Single-Sign-On (RSSO) and TrueSight Background Current Deployment Strategy Migrating TrueSight to RSSO ASSO HA Using Local Authentication with TrueSight High-Availability Can I copy configurations from one ASSO to another server with a different hostname? Creation of Default Users and Groups for TSPS Disaster Recovery ASSO HA Using External LDAP Authentication with TrueSight High-Availability About Primary and Elder ASSO Nodes Best Practice - Monitoring ASSO Best Practice Configuration (Tuning) Changes to setenv.sh (Tomcat/bin directory) Changes to server.xml Best Practice ASSO Restart Procedure ASSO Restart Script Can I copy configurations from one ASSO to another server with a different hostname? Disaster Recovery ASSO Authentication Options with TrueSight 11 TrueSight supports external LDAP (Active Directory) only Additional Configurations items for successful implement with ASSO Load Balancer Is it possible to connect 2 TSPS to the same SSO Glossary 13 PAGE 2 OF 13

3 2 Document Purpose 2.1 Purpose The purpose of this is to provide answers to FAQ when there is a requirement to configure Atrium Single Sign-On (ASSO) with TrueSight (TS). The document applies to any component of the TS stack i.e. TSOM, TSCO, ITDA and AVM. The document also includes an outline of the TrueSight strategy for using Remedy Single Sign-On (RSSO) in the future. It should be used in conjunction with BMC Official documentation. In addition, previously ASSO could be deployed in Active/Active HA cluster. Unfortunately, BMC have noticed that when configured the product becomes unstable and as such now recommend an Active/Passive configuration as documented herein. 2.2 Intended Audience This document is intended for anyone interested in implementing TrueSight in an ASSO HA configuration or wishing to understand the future strategy of TrueSight relating to SSO. If customers have questions relating to the content then please log a BMC Support call. 2.3 Objectives The objective of this document is to demonstrate that TrueSight has a supported HA configuration when using ASSO. 2.4 Related Documentation Document Name Version TrueSight Operations Management 10.1, 10.5 & 10.7 Atrium Single Sign On and PAGE 3 OF 13

4 3 TrueSight Strategy for SSO 3.1 Atrium Single-Sign-On (ASSO) and TrueSight Background Currently TrueSight leverages ASSO to provide user management and single-sign-on. TrueSight is completely dependent on ASSO due to the fact that TrueSight does not include its own username store, but instead leverages the username store capabilities in ASSO. Additionally, although AtriumSSO supports SAML and 2-factor authentication, TrueSight did not include these additional capabilities. 3.2 Remedy Single-Sign-On (RSSO) and TrueSight Background RSSO is a next generation solution that all BMC products will begin leveraging for Single-Sign-On. RSSO was initially targeted for use by the Remedy solution. In order for TrueSight to leveraging RSSO, several additional capabilities were required to support the equivalency that was available in ASSO. These requirements are targeted for a summer release of RSSO. With that mid-year release, TrueSight will be able to deliver on the full support of RSSO in the release target for the fall of RSSO will allow TrueSight to expand on its current capabilities of RSSO features to include: SAML V2 support 2-Factor Authentication RSSO Active/Active High Availability Smaller footprint when compared to ASSO Multiple Deployment Scenarios o Standalone RSSO (TrueSight Only Use) o Shared RSSO (Shared across multiple BMC solutions) o Embedded RSSO (Part of the TrueSight Presentation Server) 3.3 Current Deployment Strategy For customers currently deploying TrueSight, AtriumSSO must be deployed to manage users and groups. ASSO cannot be configured with SAML (authentication through a federated single-sign-on) or Kerberos when used with TrueSight. For high-availability deployments ASSO must be configured in an active/passive or active/standby mode versus an active/active mode. 3.4 Migrating TrueSight to RSSO Once TrueSight provides support for RSSO in the fall 2017 release. Customers will need to migrate from ASSO to RSSO with that particular version of TrueSight. The plan is that TrueSight will only support RSSO with the fall 2017 release. Technical migration details are still under development, but the intent is to provide utilities to ease the migration. PAGE 4 OF 13

5 4 ASSO HA Using Local Authentication with TrueSight 4.1 High-Availability Within ASSO, it is possible to create Users and Groups that are held locally within the internal database. Should you have a requirement for this configuration and require ASSO in HA, then BMC wish to state: Build two independent ASSO servers and manually keep the two in sync. For example, creating a User on ASSO Server1, then the same would be needed to undertaken on ASSO Server2. In the event of a failure then re-register TSPS to the active ASSO server using Command: tssh properties set bmc.sso.servername <new asso server> and the run the following command to apply the changes: tssh properties reload Can I copy configurations from one ASSO to another server with a different hostname? No, it is not possible to copy configuration data from one node to another if the host names are different. ASSO does not have a mechanism to import/export or copy from one stand-alone server to another. 4.2 Creation of Default Users and Groups for TSPS How does a customer manually create the default user/groups if they were not created during TSPS installation? Refer to BMC Support Knowledge Article and (How to re-create Out-Of-The-Box TrueSight users in Atrium Single Sign On) 4.3 Disaster Recovery If a customer requires a DR solution then ASSO as previously stated, there are no mechanisms to export or import configurations. Therefore, two independently deployed ASSO servers have to be synchronized with manual reconciliation. PAGE 5 OF 13

6 5 ASSO HA Using External LDAP Authentication with TrueSight ASSO can be deployed in a cluster for high availability but the configuration has to be deployed in a certain way. 5.1 High-Availability A customer can configure two ASSO and utilize a Load Balancer (LB) for connection to the TSPS when integrated with a customer supplied LDAP. The ASSO environment should be configured as though they Active/Active nodes, however the LB MUST be configured as shown below. The LB must be configured to connect to one ASSO at all times If the first ASSO fails, the LB should switch to the second ASSO in a controlled manner ASSO keeps the passive node in sync using inbuilt ASSO technology, therefore no manually synchronization activities are required. PAGE 6 OF 13

7 5.2 About Primary and Elder ASSO Nodes A customer can configure In an ASSO cluster, one member has the role of master or primary, the others are slaves. Only the primary node can answer requests authoritatively. In some cases the other nodes will forward their requests to the current primary node. The primary node selection process determines a so called elder node. This is the node that was started first in the cluster. Who the current elder node is in an ASSO cluster can be determined by looking at the ASSO HA page. For that you first have to log in to the ATSSO console and then go to the following URL (example): Configuration State Initialized True Derby DB Enabled True Apache MQ Enabled True Boot Time Time/Date Host atssoy1.example.com Site ID 01 Elder Site Id 01 Elder Boot Time Time/Date Records Processed Meta Messages 983 DB Messages 9085 Site ID Boot Time Host Last Update Received 01 Time/Date attsoy1.example.com Time/Date 02 Time/Date attsoy2.example.com Time/Date In this case, atssoy1.example.com has site ID 01, which is also the elder site id. Site ID 1 is typically assigned to the admin node, so both the admin node and the primary have the same site id. In an ideal configuration, we just have to make sure that atssoy1.example.com is reachable through the load balancer and atssoy2.example.com is not. PAGE 7 OF 13

8 5.2.1 Best Practice - Monitoring ASSO Sometimes you want to run a basic check to see if a node is alive. A simple and efficient check can be done by getting the output from following URL The above test is lightweight and can be ran on a relatively high frequency for basic health checking. For more detailed historical analysis, we have created alarm thresholds for certain parameters using PATROL. We have found those parameter to provide an accurate early warning indicator of a problem. SessionCreateRate => 70 CurrentThreadBusy => 650 CurrentThreadCount => 1500 Usually these parameter significantly increase before a service impacting event so you can set threshold that will raise a state change Best Practice Configuration (Tuning) Please note the following information is for environments with high user load, and may not be applicable for all installations. You can customize to suite your own requirements. During our testing our intention was to make sure that resources would never contribute to stability issues. Therefore, we oversized the ASSO nodes and increasing threads has contributed much to the improved stability. In some cases, the ASSO server would increase threadcounts very fast for only a short period of time. By setting this value to 3000, the system became a lot more stable. Example below: Linux OS : 12Gb memory / 4vCPU 3000 Threads Java Heap 4Gb min 6Gb max JMX Enabled for tomcat monitoring Max Sessions Per User : Changes to setenv.sh (Tomcat/bin directory) -Xms4096m \ -Xmx6144m \ -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=8086 \ -Dcom.sun.management.jmxremote.ssl=false \ -Dcom.sun.management.jmxremote.authenticate=false \ Changes to server.xml maxthreads="3000" scheme="https" secure="true" PAGE 8 OF 13

9 5.2.3 Best Practice ASSO Restart Procedure During our internal testing we created a procedure to ensure to make sure everything aligns well, the restart procedure is specific. We have been successful with a daily reboot of the machine. Although we are aware that a reboot may not be required and a process restart is all that is needed, we wanted to make sure that there is nothing else that would cause stability issues. Since the process is automated and the machine is dedicated, the difference between a reboot and a process restart was really a non-issue for our testing team, therefore you can decide what is best for your own implementation. The table below shows the various restart tasks. PRIMARY NODE SECONDARY NODE 1 Restart tomcat 2 Wait until tomcat is ready on secondary node 3 Enable secondary node in LB 4 Wait 60 seconds for LB to notice 5 Disable primary node in LB 6 Wait 5 mins for nodes to sync 7 Reboot 8 Wait until tomcat is ready on primary node 9 Enable primary node in LB 10 Wait 60 seconds for LB to notice 11 Disable secondary node in LB 12 Wait 5 mins for nodes to sync 13 Reboot PAGE 9 OF 13

10 ASSO Restart Script Note: The BoilerPlate script listed as part of the automated ASSO Restart Procedure is provided as a courtesy only. It will require in-house expertise to decide on its use and to customize it to suit the operating system you are running and as such, it is not supported by BMC. The provided restart script is designed to run on the secondary node. That way it can control the whole execution flow in the table above until the secondary node gets rebooted itself. The script requires perl and a couple of perl modules as you can at the top of the script. Depending on the deployed version of perl, installation of extra modules may or may not be required. The script will use OpenSSH to communicate across the nodes. It assumes root privileges (for rebooting). Therefore you should first check if you can ssh transparently between both nodes in the ATSSO cluster. ssh root@atssoy1.example.com should work from atssoy2.example.com and vice versa. To enable and disable a node in the load balancer (steps 3,5,9 and 11) we manipulate a file in the ASSO directory. } elsif ($command eq 'TOMCAT_DISABLE') { my $fname = $C->{SSOROOT}.$C->{STATUS}; my $cmd = '/bin/echo -n "OFF" > '.$fname; $output = runcmd($c, $target, $cmd); } elsif ($command eq 'TOMCAT_ENABLE') { my $fname = $C->{SSOROOT}.$C->{STATUS}; my $cmd = '/bin/echo -n "UP" > '.$fname; $output = runcmd($c, $target, $cmd); This code should be modified for your environment. As you can see, we write the words OFF or UP in a specific file (which is defined in the configuration at the top of the script) Can I copy configurations from one ASSO to another server with a different hostname? No, as previously stated, the same applies for this configuration. As the ASSO is integrated with a customers LDAP then there should be not requirement for manully intervention. 5.3 Disaster Recovery If a customer requires a DR solution then ASSO configured with LDAP then as previously stated, there are no mechanisms to export or import configurations and therefore two independently deployed ASSO servers have to be synchronized with manual reconciliation. PAGE 10 OF 13

11 6 ASSO Authentication Options with TrueSight TrueSight supports external LDAP (Active Directory) only All other authentications examples (Not limited to): SAML, RSA SecurID, CAC, Siteminder etc. will not work with TrueSight. PAGE 11 OF 13

12 7 Additional Configurations items for successful implement with ASSO The following detail some configurations that aid the implementation of ASSO within a TS implementation: Load Balancer a) Is a Layer 7 LB required for ASSO? There is no recommendation from BMC regarding this aspect of load balancing. The type does not matter with ASSO, as long as it can handle the active/passive load re-routing. b) The related load balancer must be configured for HTTPS communication. c) The load balancer should send traffic to only one node (e.g. Node 1). When Node 1 is down, the load balancer should send traffic to Node 2. d) SSL load balancing can be configured in two ways Passthrough or SSL Offloading. Passthrough is the best mechanism, as ASSO itself is installed in HTTPS mode. e) Particular attention should be paid to server certificates. The server certificate applied in a load balanced environment should use Subject Alternate Names (SAN), which allow you to specify additional host names that will be protected by a single SSL certificate. The SAN attribute should include the values of the load balancer and each of the node names used for ASSO Is it possible to connect 2 TSPS to the same SSO Yes, we can point multiple TSPS/TSCO/other servers pointing to same ASSO. Ensure that the ASSO that supporting infrastructure has the required resources. PAGE 12 OF 13

13 8 Glossary Clustering: Two or more operating systems, running shared applications, sharing the same disk array. Failover from one application node to another is automatic. Disaster Recovery: Two independent identical hardware systems or applications servers, running identical applications, with the second only available in the event of the first failing. Failover of a DR system requires manual intervention normally with DNS changes High Availability: two or more operating systems, applications or physical servers, running at the same time (but only one actively processing data), governed by a cluster-aware operating system or other mechanism (heartbeat). Fail-over from one application node to another is automatic. HA can be configured in Active/Active or Active/Passive. Load balancing: Two or more application or physical servers constantly running the same applications with their respective throughput monitored and adjusted by a load balancer. The users are unaware of the end applications (preventing them from having to log in to both systems); movement of requests from one application node to another is automatic. PAGE 13 OF 13