Page tree
Skip to end of metadata
Go to start of metadata

This page is no longer maintained and may contain obsolete information.

If you require, you can delegate CAST Engineering Dashboard/CAST Discovery Portal user authentication to Kerberos and user authorization to Microsoft Active Directory (LDAP). In other words:

  • let end-users login to the CAST Engineering Dashboard/Discovery Portal with their Windows user / password
  • let Active Directory decide the proxy user to use when an end-user enters the CAST Engineering Dashboard/Discovery Portal (e.g.: Active Directory decides if you are a VPAD, a CARCH etc. - these are the predefined CAST Engineering Dashboard/Discovery Portal users - see CAST-CED - Managing users and roles)

When deploying the CAST Engineering Dashboard (and the Discovery Portal) in a large organization, the integration with Active Directory (LDAP) and Kerberos means that:

  • the dashboard administrator no longer needs to define each single user in the CAST Engineering Dashboard/Discovery Portal
  • portal user no longer needs to memorize yet another login and password

As such:

  • as a portal user, you can use your corporate login and password to enter the CAST Engineering Dashboard/Discovery Portal
  • as a portal administrator, you can define the proxy user to use when a given user logs into the portal, with the ability to share this proxy user so that you only need to define a portal proxy user for each different access configuration (every corporate user that must share the same access configuration can share the same proxy user)

This integration also brings your CAST Engineering Dashboard/Discovery Portal implementation in line with your organization's password policy (complexity, frequency of change, etc.) as the CAST Engineering Dashboard/Discovery Portal now relies on your usual Windows authentication mechanisms.

Active Directory (LDAP) configuration

To assign a CAST Engineering Dashboard/CAST Discovery Portal proxy user to designated Active Directory users:

  • Select an Organizational Unit (OU) where you want to store the configuration
  • In this OU, create a group whose name complies with the following syntax: <proxy_user>.<dashboard_service> - e.g.: VPAD.CAST_CENTRAL
  • <proxy_user> refers to the CAST Engineering Dashboard/Discovery Portal users (see CAST-CED - Managing users and roles ) and <dashboard_service> refers to the name of your CAST Dashboard Service
  • these entries are likely to be case sensitive - please take care when entering the details
  • Assign Active Directory users to this group

CAST Engineering Dashboard/Discovery Portal configuration

To activate basic Active Directory (LDAP) integration with Kerberos authentication:

  • edit the Web deployment descriptor file in the CAST Engineering Dashboard application directory i.e.:
%CATALINA_HOME%\webapps\CAST-CED\WEB-INF\web.xml
  • set security.auth.kerberos and naming.ldap parameter values to true
  • update the security.auth.kerberos.realm parameter value to the Kerberos realm to use if the user does not enter it in the CAST Engineering Dashboard/Discovery Portal login screen. E.g.: INTERNAL.MYCOMPANY.COM
  • update the security.auth.kerberos.kdc parameter value with the name of the server that hosts your Key Distribution Center
  • update the security.auth.login.config parameter value with the path where you deployed the Web application or if you decided to store the login module configuration file in a different directory
  • update the security.auth.login.client parameter value
  • update the naming.ldap.url paramater value with the URL of your Active Directory (LDAP). E.g.:
ldap://host:389
  • update the naming.ldap.ou paramater value with the name of the OU you used in the previous paragraph. E.g.:
OU=TEST

Tips/Further information

  • All of the above parameters can be found in the following section of the web.xml file:
<!-- Security Parameters -->
  • Your Active Directory and Kerberos are likely to be case sensitive: use extra care when entering the configuration details
  • You can activate the integration with Kerberos alone. In this case, Kerberos will serve to authenticate the user trying to log in to the CAST Engineering Dashboard/Discovery Portal and the user name entered will be use to enter the CAST Engineering Dashboard/Discovery Portal (you will therefore need to declare your user in the CAST Engineering Dashboard. E.g.: USER@INTERNAL.MYCOMPANY.COM
  • You can activate the integration with Active Directory (LDAP) alone. In this case, the authentication is performed by Active Directory (LDAP) as the entered user name and password will be used to log in to the Active Directory.
  • Following any changes you make, save the web.xml file and then restart your application server so that the changes are taken into account.
  • You can find out more information about manual user authentication (i.e. not using Active Directory/Kerberos in the relevant sections below).

Example web.xml for LDAP configuration

The following text files contain specific examples for configuring Kerberos/Microsoft Active Directory (MSAD) authentication/authorization in different situations. Please ensure that you tailor them to your own environment:

Kerberos authentication alone, requires xxx@yyy.zzz.com user to be declared in the CAST Engineering Dashboard

web-kerberos.txt

Kerberos authentication and MSAD authorization

web-combined.txt

MSAD authentication alone, requires xxx@yyy.zzz.com user to be declared in the CAST Engineering Dashboard

web-msad.txt

Advanced LDAP configuration

The following additional parameters can also be configured to enhance the LDAP configuration:

Parameter

Value

Description

naming.ldap.useAccountName

[true]

Active Directory/LDAP search method

This option enables you to use the Microsoft Active Directory sAMAccountName attribute instead of the default UserPrincipalName in the LDAP search filter. Set to true if you need to use sAMAccountName otherwise, UserPrincipalName will be used.

sAMAccountName is required with Active Directory, but is not common to all LDAP directories. UserPrincipalName is more generic and other LDAP directories accept it.

naming.ldap.nogroup

[false]

Standalone Active Directory/LDAP authentication

When set to false this option checks that the user and password are valid against the Active Directory naming.ldap.service parameter.

naming.ldap.service

shared_group_suffix

Standalone Active Directory/LDAP authentication

Use this parameter value to override the name of the Dashboard Service when looking up for authorization groups.
The default behavior is to look up <proxy user>.<dashboard service> groups.

With this option, the portal will look up <proxy user>.<naming.ldap.service> groups. This can prove useful to :

- manage the authorization configuration for many Dashboard Service, by having them look up the same <proxy user>.<naming.ldap.service> groups.
- cope with corporate group naming constraints that would not allow for default <proxy user>.<dashboard service> groups. E.g.: for case sensitivity reasons.

naming.ldap.domain

[LDAP default user domain]

Standalone Active Directory/LDAP authentication

Use this option to set the default Active Directory user domain for authentication purposes. Similar to the Kerberos security.auth.kerberos.realm parameter.

naming.ldap.ssl

[false]

Active Directory SSL access for standalone Active Directory/LDAP authentication

Set to true to activate SSL encrypted communication during the authentication process.

naming.ldap.ssl.trustStore

[C:\\Java\\jre\\lib\\security\\cacerts]

Active Directory SSL access for standalone Active Directory/LDAP authentication

Defines the location of the SSL certificate store. Make sure you escape (using a back slash) any back slashes in the path.

security.auditTrail

false

Logging user activity
By default, this is set to false. When activated (true), various user activity is logged to a .CSV file (user creation/deletion/configuration update, successful and failed sign in and User proxy mapping).

One .CSV file is created per application server (i.e. data from multiple Dashboard/Portals on the same host will be logged in one file).

The .CSV file is stored in sub-folder of the cast.web.home directory - see the section CAST-CED - Configure the hard disk location for auto generated PDF reports for more information about this.

  • No labels