Instead of using its own database to authenticate users, TEAMS-RDS can be configured to connect to a corporate active directory server to authenticate and authorize users.
NOTE – Active Directory support is available only on TEAMS-RDS version 12.x and later.
There are two ways of configuring TEAMS-RDS to support active directory authentication, depending on the version of TEAMS-RDS, or where TEAMS-RDS is installed:
- Choose method 1 if ANY of the is true:
- You have TEAMS-RDS version 12.x.
- TEAMS-RDS is installed on a Linux server.
- TEAMS-RDS is installed on a Windows server that is not part of the active directory domain.
- Choose method 2 if ALL of the following is true:
- You have TEAMS-RDS version 14.x, and
- TEAMS-RDS is installed on a Windows server that is part of the active directory domain.
Method 1. I have TEAMS-RDS version 12.x, or TEAMS-RDS is installed on Linux server, or on a Windows server that is not a member of the active directory domain
- Open the configuration file %RDS_HOME%/conf/rdsProperties.xml, and change the following property to “true”:
<entry key=”ldap.authentication”>true</entry>
- Provide the active directory information
<entry key=”ldap.domain”>mydomain.com</entry>
<entry key=”ldap.url”>ldap://ad.mydomain.com/</entry> - Provide the credentials of a user who is authorized to query user information:
<entry key=”ldap.username”>ad@company.com</entry>
<entry key=”ldap.password”>secret</entry> - Provide the active directory node that should be queried for user information
<entry key=”ldap.searchBase”>ou=service,dc=company,dc=com</entry>
- By default the attribute “userPrincipalName” is used as the “username” of the user. If needed, modify it:
<entry key=”ldap.subjectPrincipal”>userPrincipalName</entry>
- By default the attribute “memberOf” is queried for obtaining user roles. If needed, modify it:
<entry key=”ldap.userRoleSearch”>memberOf</entry>
- Restart Tomcat
Now users can use their corporate account to log in to TEAMS-RDS. They can enter their username in multiple ways, e.g., john.grisham, DOMAIN\john.grisham, or john.grisham@company.com.
Method 2. TEAMS-RDS server is installed on a Windows server that is a member of the domain
NOTE – This method is only supported on TEAMS-RDS version 14.0 and later. For TEAMS-RDS version 12.x, use method 1.
- Open the configuration file %RDS_HOME%/conf/rdsProperties.xml, and change the following property to “true”:
<entry key=”windows.authentication”>true</entry>
- Restart Tomcat.
Now the users can use their Active Directory credentials to log in to TEAMS-RDS. They can enter their username in multiple ways, e.g., john.grisham, DOMAIN\john.grisham, or john.grisham@company.com.
A user can also log in as another user, including the users created within TEAMS-RDS by TEAMS-RDS administrator, such as “mike”, frank”, etc.
Enabling single sign-on
The above setting still requires the user to enter their Windows credentials to log in to TEAMS-RDS. Since the user is already logged into his Windows computer, we may want the user to be automatically logged into TEAMS-RDS, without him having to enter his username/password again.
To enable this feature
- Open the configuration file %RDS_HOME%/conf/rdsProperties.xml, and change the following property to “true”:
<entry key=”windows.authentication.single_sign_on”>true</entry>
- Restart Tomcat.
Now, whenever the user visits TEAMS-RDS from his browser, he will be automatically logged in.
NOTE – If “single sign-on” is enabled, there are a few “gotchas”:
- The user will not be able to sign in as any other user, including the built in TEAMS-RDS users, such as “mike”, “frank”. He will always be logged in as himself.
- If the user logs into TEAMS-RDS from a colleague’s computer, he will be logged in as his colleague and not as himself!
- The user will not be able to logout at all!
Configure user roles
The user roles are obtained from the active directory “memberOf” attribute. These roles are unlikely to match the user roles expected by TEAMS-RDS. To map the Active Directory user roles to TEAMS-RDS roles, edit “%RDS_HOME%/roleMapping.xml”. The general format is:
For example, assume that we want to grant users who are members of “Technical Support Staff” and “Field Engineer” the TEAMS-RDS role of “Field Technician”:
Now, when a user who is a member of “Technical Support Staff” or “Field Engineer” logs into TEAMS-RDS, he will have the privileges of a Field Technician.
All the available TEAMS-RDS roles are specified in “%RDS_HOME%/roleMapping.xml”; edit the file to map TEAMS-RDS roles to the active directory memberOf attribute(s) for users.
TEAMATE Configuration
NOTE – The following feature is not available on TEAMATE version prior to 14.0.
TEAMATE is already configured to use Windows authentication AND to automatically log the user in. The configuration specified in “%RDS_HOME%/roleMapping.xml” as described above is not applicable for TEAMATE.
Since TEAMATE mainly operates in offline mode, it will use the user information that is cached by Windows.
When connecting to TEAMS-RDS for model/log synchronization via HTTP, the user will need to enter his Windows credential to log in to TEAMS-RDS to synchronize, even if TEAMS-RDS has been configured for “single sign-on”.
NOTE – If TEAMATE displays the Windows Security logon prompt, instead of automatically logging in the user, then the site http://127.0.0.1 needs to be added to the “Local intranet” site:
- From Internet Explorer, choose the Tools/Internet Options menu.
- Select the “Security” tab.
- Click the “Local Intranet” icon.
- Click the Sites button.
- Click “Advanced”.
- Add “http://127.0.0.1” to list of Websites
