• Inok Systems

BMC Atrium SSO SSL Implementation and Best Practices – Part 1

User Rating:  / 0
PoorBest 

BMC Atrium Single Sign-On (Atrium SSO v9.x) is an authentication system that supports many authentication protocols and provides single sign-on and single sign-off for users of BMC products. BMC Atrium Single Sign-On allows users to present credentials only once for authentication and subsequently be automatically authenticated by every BMC product that is integrated into the system.

Atrium SSO will be installed with self-signed certificate however many organisation policy doesn’t allow to use a self-signed certificate. This blog details about the technical step by step procedure to implement a CA signed certificate with Atrium SSO. This also covers the authentication chaining configuration approach and recommendations.

Here I will be talking about the procedure for the implementation of Remedy Mid-Tier, MyIT, Analytics, Dashboard and Atrium SSO (v9.x) with SSL configurations. First step is generate certificate and configure tomcat for all applications.

Following Sequence can be followed:-

1.     Install AR Server, Mid-Tier and ITSM Applications.

2.     Install BMC Analytics, Dashboard, MyIT etc with default authentication.

3.     Install BMC Atrium SSO.

4.     Configure Atrium SSO, Mid-Tier, Analytics, Dashboard and MyIT etc with SSL (if required)

5.     Install Atrium SSO Integration with Mid-Tier, Analytics, Dashboard and MyIT etc

6.     Atrium SSO authentication chaining mode can be configured as follows,

 

a)     Kerberos

b)    LDAP

c)     ARS

Recommendation is to use UserId transformer in the Atrium SSO Realm configuration to avoid any user permission related issues in future. AD login ids are not case sensitive while Remedy login ids are case sensitive hence there are possibilities of having incorrect userid getting authenticated.

With the above configuration expected behaviours as follows:

User's browser will perform Kerberos authentication first (as it is the first one) and follow the sequence if case of any failure.

1.     When domain user enters the application URL from domain network and assumption browser configured for Kerberos. Then automatically login to the application and home page will be displayed according to the user access defined.

2.     If Kerberos failed then it will redirect to the Atrium SSO login page. Eg: user didn’t configure Firefox browser for Kerberos authentication then if the user defined in AD then login uses LDAP else it will check if defined in Remedy then login with Remedy password.

3.     In a Kerberos enabled environment if user access URL from Internet using IE then then it prompt for login credentials however you have to cancel the prompt then only Kerberos fail and redirect to Atrium SSO page. At this time Atrium SSO doesn't have any control on how browser behaves. In this case browser is asking user to login to the Domain. Once user cancels, control goes back to Atrium SSO and Atrium SSO is displaying login screen as Kerberos failed.

To be continued..

Random Blogpost

When a company is small with a small IT team of 3 people, it’s easy where all the tickets assigned can be communicated internally. But when it starts growing, assignment, responsibility and ownership becomes a big headache. Let say in a typical environment of a 200 staff IT company. We have the following teams: windows, DB, helpdesk, infra, network, app. And this is just the basic. Sub defined, we still have DB-oracle, DB-SQL, DB-MVS, DB-DWH…. And in 1 team, there’s 2-3 engineers handling the same job, so who should this ticket go to?!

Read more...