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 | |
Kerberos authentication and MSAD authorization | |
MSAD authentication alone, requires xxx@yyy.zzz.com user to be declared in the CAST Engineering Dashboard |
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. 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. |
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 |