› User connectivity › Active Directory resources › Integrate Transact with Active Directory

Integrate Transact with Active Directory

To integrate Transact with Active Directory, you need to modify the following property files:

  • server.xml

  • user-connectivity.properties

  • application.properties

Before modifying these files, you need the following:

  • An understanding of how Active Directory works, including the difference between domain controllers, organizational units, groups, and users.

  • The directory structure used to organize users.

  • The users in the directory.

  • Passwords for each user to be authenticated.

  • Information about where users and groups exist in Active Directory.

  • How users are mapped with respective groups.

Using an Active Directory tool like JXplorer can help you examine the Active Directory structure and identify the users, groups, domain controllers, and organization units that you want to assign to Transact.

Roles in Transact

Users and groups that are used in Transact are assigned to the one of the following roles:

  • Super Admin: Has full access to Transact, including System Configuration.
  • Administrator: Has access to all Transact screens except System Configuration.
  • Operator: Has specific access to non-administrator tasks, such as the batch list, validation, and review.

When configuring Transact components to use Active Directory, you need to consider which users and groups should be assigned to these roles.

Configuring Transact components

Server.xml

The server.xml file defines information about Active Directory. The configuration in this file helps to authenticate the users with Active Directory.

  • className: This must be set to org.apache.catalina.realm.JNDIRealm. This refers to JNDIRealm class in Tomcat.

  • connectionURL: Define the URL of the Active Directory server in this format: ldap://<IP,DNS,FQDN>:<PORT> where the Active Directory port needs to be 3268 (also called the Global Catalog Port) or 3269 (if Active Directory is configured with SSL).

  • connectionName: Define the Distinguished Name of any user who exists in Active Directory. For example, CN=aj,OU=USERS,OU=EPHESOFT,DC=ephesoft,DC=com means that the user with the name aj exists in OU called USERS which is under ephesoft sub-domain and com root-domain. You can also define the connectionName here using a naming convention like aj@ephesoft.com.

  • connectionPassword: Provide the password for the user defined in connectionName.

  • userBase: The relative path under which all the users' information will be located. This attribute defines where to look for a user. For example, you can search for users directly under our sub-domain. Therefore, it will look for the user under the sub-domain as well as in all the Organizational Units.

  • userSearch: This is the pattern specifying the Active Directory search filter to use after substitution of the username. Possible values are "(sAMAccountName={0})" or "cn={0}". If you are using sAMAccountName, it will look for the value in sAMAccountName property of Active Directory. If you use cn={0}, it will look for the value in the cn property in Active Directory.

  • roleBase: The relative path under which all the roles information will be located. This attribute defines where to look for a role corresponding to a user. In the example above, you are searching for all roles and groups under sub-domain "ephesoft" as well as in all Organizational Units.

  • roleName: The attribute in a role entry containing the name of that role. In the example above, the value of the cn attribute in Active Directory will be checked.

  • roleSearch: The LDAP search filter for selecting role entries. It optionally includes pattern replacements "{0}" for the Distinguished Name. In the example above, the member property of the user in Active Directory will be looked up.

  • userSubtree: The search scope. Set to true to search the entire sub tree rooted at the userBase

  • roleSubtree: The search scope. Set to true to search the entire sub tree rooted at the roleBase.

user-connectivity.properties

The user-connectivity.properties file configures authorization. This file defines the limitations on the groups and roles to be fetched from the Active Directory. Set the following properties:

  • user.connectivity_url: Specify the URL of the Active Directory server. It is of the form of ldap://<IP,DNS,FQDN>:<PORT> where the port in case of Active Directory needs to be 3268 (also called Global Catalog Port) or 3269 (if Active Directory is configured with SSL).

  • user.connectivity_domain_component_name: Specify sub-domain information. If there is more than one sub-domain, like com.ephesoft.support, use this convention: user.connectivity_domain_component_name=support,dc=ephesoft.

  • user.connectivity_domain_component_organization: Specify the root level domain name.

  • user.connection: Set this property to 1 to use AD.

  • user.ldap_user_base: This is an LDAP-related property. You do not need to define any value for this property if you are using Active Directory.

  • user.ldap_group_base: This is an LDAP-related property. You do not need to define any value for this property if you are using Active Directory.

  • user.connectivity_groupSearchAttributeFilter: This is usually set to the value cn. This property will look at the cn property in Active Directory and accordingly will pick the Group / Role name defined in this property.

  • user.connectivity_userSearchAttributeFilter: Usually set to the value cn or sAMAccountName. This property will look at the cn or sAMAccountName property from Active Directory. This needs to be set according to the value set in the userSearch property in server.xml.

  • user.msactivedirectory_context_path: Define the relative path where the groups exist. If groups exist in more than one OU, separate them using double semicolon (;;).

  • user.msactivedirectory_group_search_filter: Define the pattern to only pick the groups which match this pattern. If the name of Super Admin group does not match the pattern, add the name of the group here.

    Example: (|(cn=EphesoftSupport*)(cn=Ephesoft-SystemAdministrator)). This pattern picks all groups starting with EphesoftSupport and followed by anything. If there is a Super Admin group that does not match this pattern, this example adds Ephesoft-SystemAdministrator separately in this filter.

The user.msactivedirectory_context_path and user.msactivedirectory_group_search_filter properties can be used together as well to further limit the GROUPS

application.properties

The application.properties file sets Super Admin group details. The following properties need to be set:

  • user.super_admin: Assigns groups to Super Admin rights.

  • update_super_admin_group: Must be changed to true.

Access to specific screen and batch classes

Use Access Manager to control the specific rights to users in Transact. To use Access Manager, you must have Super Admin rights.

In Access Manager, you can select which screens different groups can access. Select the checkbox for that screen to enable access, or clear the checkbox to deny access.

You can also use Batch Class Management to specify which roles can access a batch class. Use the Roles column in the Batch Class Management screen to provide access control at the batch class and batch instance level. If you assign a group to a batch class, only users in that group can view that batch class and associated batch instances. For more information, see Batch Instance Management.