How Can We Help?

Configuring Authentication

You are here:
< Back

Enterprise Tester supports the following authentication methods:

* SAML 2.0 is not configurable via the user interface and is incompatible with the other authentication methods. Please see the SAML 2.0 documentation for more details.

You can configure multiple authentication methods and set the priority of the configured methods. This means that if the primary authentication method fails, the secondary method is automatically employed, then the third and fourth.

For example, if you have configured the following authentication methods in the following order:

  1. LDAP
  2. Machine Source
  3. Enterprise Tester Database

If a user cannot be authenticated against LDAP (the primary authentication mode in our example), authentication will automatically be attempted against the next method in the priority list (Machine Source). If the secondary method fails, the third method will be used and so on until the user is successfully authenticated or all methods have been exhausted.

To access the authentication configuration screens you will require application administration permissions to Enterprise Tester. Navigate to the Admin tab. Expand the Configuration folder and double click on Authentication.

Here you can configure new authentication methods or update existing ones. You can also arrange the priority of the configured methods as well as test your configured methods.

By default, Enterprise Tester uses the Enterprise Tester Database as the authentication method.  This method does not require configuration.  

Currently the database method cannot be removed or disabled. 

Adding Methods

  • To add a method, click the ‘Add’ button then enter a name for the connection (Note: Currently editing of the connection name after creation is not supported) and select the method type.
  • Once you click ‘OK’, the list of methods will refresh to include the new method.
  • After creation the method is disabled, you must first configure the method, and then enable it, before it will be used.


Crowd Authentication method provides the ability to integrate with Atlassian Crowd installations (including single sign-on).

Currently Enterprise Tester supports Authentication with Crowd however does not support Synchronization with Crowd.

When using Crowd, users will still need to be created in Enterprise Tester with the option External User selected. Ensure that the username matches the username in Crowd.

Identifying the Application

To use Crowd with Enterprise Tester you must configure a new application in Crowd, which will represent Enterprise Tester – see the Crowd user guide for details. Once the Crowd application has been added via the Crowd console you should see it in the list of applications (by clicking the ‘Applications’ tab):

In this case, our application name is the lower case ‘enterprisetester’ and this is the value that should be used for the application name in the configuration screen.

Configuring the Method in Enterprise Tester

The Crowd authentication method has the following configuration screen:

Crowd ServerCrowd URLhttp://localhost:8095/crowd/services/SecurityServer
Application NameName of the application in Crowde.g. EnterpriseTester
PasswordPassword to access Crowde.g. Password
Convert Localhost to IPV6When enabled, the Crowd authentication method will automatically transform IPV4 loopback addresses and localhost host names to the equivalent IPV6 loopback address, when generating remote_address validation factor to be supplied to Crowd. It’s only necessary to enable this if you find validation is failing. Often this occurs when Enterprise Tester and Crowd are both running on the same server. 

Additional Information

Integrating Enterprise Tester with Crowd is straight forward. For more information on how the Enterprise Tester Crowd implementation works, please review the blog post Integrating Enterprise Tester with Crowd.


LDAP Authentication method provides a feature-rich authentication method suitable for use with LDAP Directories, including Active Directory.

Key Features:

  • Configuration setting to allow user creation on first successful login
  • Optional synchronization of Users, Groups and Group Memberships
  • Manual or Automatic synchronization of Users and Groups
  • Authentication only setting
  • Support for SSL and StartTLS
  • Deactivating users or user deletion

Enterprise Tester supports importing the following attributes into Enterprise Tester from LDAP:

1. First Name
2. Last Name
3. Email Address
4. Username
5. Phone Number

The LDAP Configuration has 2 components:

  1. General configuration to your LDAP server; and
  2. Synchronization set up.

General LDAP Setup

AD Explorer

AD Explorer is an open source tool that can assist with navigation of the Active Directory structure. It is useful in helping to generate the correct filter syntax settings described below. You can download the tool from the Microsoft Windows Sysinternal site.

Basic Configuration

LDAP ServerEnter LDAP Serve Name or IP Address123.123.1.234
PortPort number associated with the LDAP Server389
Protocol VersionVersion of LDAPVersion 2 (required for some older OpenLDAP installations) or Version 3 (Active Directory and new LDAP Directory implementations)
Authentication TypeAuthentication ProtocolAnonymous, Basic, Negotiate, NTLM, Digest, Sicily, Dpa, Msn, External or Kerberos
SSLEncryption ProtocolCheck if using SSL
StartTLSEncryption ProtocolCheck if using StartTLS
Base DNName of the root node in LDAP from which to search for userscn=users,dc=example,dc=com
Additional User DNPrepended to the Base DN to limit the scope when searching for users 
Additional Group DNPrepended to the Base DN to limit the scope when searching for groups 
Bind DNBind DN is the user and the node in LDAP where the user can be found (this is the user Enterprise Tester will authenticate to the LDAP directory as – they must have sufficient rights to query the LDAP directory)Either a value distinguished name such as “cn=user,cn=Users, dc=example,dc=com”, an username@domain e.g. “joebloggs@mycompany.local” or left blank for anonymous authentication.
Bind PasswordPassword for the Bind DN userPassword, or left blank for anonymous authentication.
Search AttributeThe attribute in LDAP holding the login nameuid (common for OpenLDAP) or sAMAccountName (Active Directory)


Enable PagingWhen enabled, users will be returned in multiple pages rather than a single list. This is useful when you have a large number of users configured in LDAP, and where a non-paged request will fail because the query returns more than the allowable maximum – this should always be enabled for Active Directory.True
User Page SizeSpecify the number of users to return per page. The default value is 100. This value should ideally be configured to be the same as the maximum number of results which can be returned from a single query to ensure the least number of round trips when querying LDAP.1000
Group Page SizeSpecify the number of groups to return per page. The default value is 100. This value should ideally be configured to be the same as the maximum number of results which can be returned from a single query to ensure the least number of round trips when querying LDAP.500

User Configuration

Object FilterFilter user for retrieving all users(&(objectCategory=Person)(sAMAccountName=*))
Search Filter TemplateFilter used for searching by name or partial name.(&(objectCategory=Person)(sAMAccountName={0}))
User Name AttributeUser Name Attributeuid (common for OpenLDAP) or sAMAccountName (Active Directory)
First Name AttributeFirst Name AttributegivenName
Last Name AttributeLast Name Attributesn
Email Attributemail
Telephone AttributePhone AttributetelephoneNumber

Group Configuration

Object FilterGroup Object Filter(&(objectCategory=Group)
Search Filter TemplateGroup Search Filter Template(&(objectCategory=Group)(cn={0}))
Name AttributeGroup Name Attributecn
Description AttributeGroup Description Attributedescription

Group Member Configuration

Group Member AttributeMembers attribute of groupmember
Group Members FilterMembers Attribute Filter(objectClass=user)

Once you have completed your configuration, select ‘Save’ at the bottom of the page.

When connecting to an OpenLDAP directory, group membership synchronisation has the following limitations

  1. The OpenLDAP schema must store members of a group using the full DN of a user rather than just the Uid value. E.g. Uid=Joe-Bloggs, OU = Users, OU = Department, DC = Corp, DC = Com.
  2. The Group Members Filter should be configured to identify the group object type(s) that will be searched, rather than the member object type. E.g. (objectClass=posixGroup)

Group Member Configuration Example for OpenLDAP

Group Member AttributeMembers attribute of groupmemberUid
Group Members FilterMembers Attribute Filter(objectClass=posixGroup)


The synchronization section allows you to set up the synchronization mode, the frequency of synchronization and any default groups you wish to have new users added to when being synchronized with Enterprise Tester.

ModeSelect the type of integration you would like with LDAPAuthentication only – LDAP is used to authenticate users onlySynchronization – Users, Groups and Group Memberships are automatically created in Enterprise TesterCreate User on Successful Authentication – New users are automatically created on first login if they are successfully authenticated in LDAP
ScheduleSynchronization FrequencyManual Synchronization, Every Hour, Every 2 Hours, Every 4 hours, Every 8 Hours and Every 24 Hours.
Synchronize UsersSelect to synchronize Users from LDAPCheck to synchronize users
Synchronize GroupsSelect to synchronize Groups from LDAPCheck to synchronize Groups
Synchronize Group MembersSelect to synchronize Groups from LDAPCheck to synchronize Group Members for each user

Default Groups

In the Default Group section you can configure all the groups you would like users to automatically be assigned to when they are created through synchronization with LDAP or through successful authentication on first login, this is in addition to any group memberships that user may have been automatically added if “Synchronize Group Members” is checked.

Unless you specify at least one default group (and assign that group view permissions for at least 1 project) any users created as a result of using the “Create User on Successful Authentication” option will be unable to use Enterprise Tester.

Additional References


The machine source is a flexible method supporting authenticating users against the following three sources of user information:

The machine source only works with Active Directory, and not other LDAP directories. Because of this fact it’s also a great deal easier to configure – if you wish to authenticate against the same domain as the server belongs to then no configuration is required what so ever!

Machine Source Authentication method provides a simple interface for accessing the local machine or Active Directory user and group information. This is useful for small AD deployments.

TypeThe type of users source, possible options are: Active Directory Domain, Active Directory LDS Store, or Local MachineLocal Machine
NameOptional name of the server (either as the source of “local” users, or the active directory domain controller)corp01
ContainerUse this only for Active Directory Domain or Active Directory LDS Store. This is the distinguished name of a container object for users/groups, this should be left blank for Local Machine,dc=mycompany,dc=com
User NameUsername to access the directory/machine (can normally be left blank).Administrator
PasswordPassword to access the directory/machine (can normally be left blank).********
Binding TypeThe authentication mode:Negotiate: The client is authenticated by using either Kerberos or NTLM. When the user name and password are not provided, the Account Management API binds to the object by using the security context of the calling thread, which is either the security context of the user account under which the application is running or of the client user account that the calling thread represents.Simple Bind: The client is authenticated by using the Basic authentication. Caution Communications may be sent over the Internet in clear text if the SecureSocketsLayer option is not specified with simple bind.Simple Bind
SealingThe data is encrypted by using Kerberos. This flag can only be used with the Negotiate context option and is not available with the simple bind option.Unchecked
Secure Socket LayerThe channel is encrypted by using the Secure Sockets Layer (SSL). Active Directory requires that the Certificate Services be installed to support SSL.Unchecked
Sever BindSpecify this flag when you use the domain context (Active Directory Domain type) if the application is binding to a specific server name.Checked
SigningThe integrity of the data is verified. This flag can only be used with the Negotiate context option and is not available with the simple bind option.Unchecked


You can configure automatic synchronization of users, groups and group memberships from Active Directory.

ModeSelect the type of integration you would like with the machine source.1. Authentication only –AD is used to authenticate users only
2. Synchronization – Users, Groups and Group Memberships are automatically created in Enterprise Tester
3. Create User on Successful Authentication – New users are automatically created on first login if they are successfully authenticated in LDAP
ScheduleSynchronization FrequencyManual Synchronization, Every Hour, Every 2 Hours, Every 4 hours, Every 8 Hours, Every 24 Hours
Synchronize UsersSelect to synchronize Users from the machine sourceCheck to synchronize users
Synchronize GroupsSelect to synchronize Groups from the machine sourceCheck to synchronize Groups
Synchronize Group MembersSelect to synchronize Groups from the machine sourceCheck to synchronize Group Members

SAML 2.0

Enterprise Tester with SAML 2.0 capable identity provider services

Enterprise Tester supports SAML 2.0 connections to an external Identity Provider (IdP).

While ET should work with most IdPs that support SAML 2.0, we currently only test with the following IdPs:

This article will cover the basics, from the Enterprise Tester side of the configuration, and then provide an example of setting up Okta with Enterprise Tester showing both Okta and Enterprise Tester configuration.


  • While a SAML 2.0 configuration is enabled, it will also be enforced when attempting to log into the application GUI. This means that local user accounts and passwords will no longer work for this purpose.
  • Enterprise Tester API requests do not support SAML 2.0. The existing API authentication methods will continue to work as normal whether SAML 2.0 is configured or not.
  • Enterprise Tester SAML 2.0 connections only handle authentication. User accounts, groups and permissions must be configured in Enterprise Tester separately.

SAML 2.0 Configuration Basics

Currently, a SAML 2.0 connection cannot be configured via the Enterprise Tester user interface; It must, instead, be configured via a configuration file located on the server Enterprise Tester is running on.  This is done by adding several key/value pairs to the appSettings section of the web.config file.  For more information about appSettings, please refer here.

To be able to configure several of the following properties, the IdP must be prepared first.  The process will differ in different IdPs, an example of configuring Okta is given further down in this article.

KeyPurposeDefault ValueExampleNotes
SAML.EnabledTo turn SAML support on or offfalse<add key=”SAML.Enable” value=”true”/>Required setting
SAML.ProviderUsed to switch between implementation styles of SAML 2.0n/a<add key=”SAML.Provider” value=”Microsoft” />Optional setting
This should usually be set to “Microsoft” but may need to be omitted all-together, depending on IdP
SAML.IssuerIDP Issuer URLn/a<add key=”SAML.Issuer” value=””/>Required setting
Requires IdP configuration first
SAML.IDPIDP SSO URLn/a<add key=””/>Required setting
Requires IdP configuration first
SAML.CertificateX.509 Certificaten/a<add key=”—–BEGIN CERTIFICATE—– certificate body —–END CERTIFICATE—–“/>Required setting
Should be entered as a single line and should include the begin and end certificate tags
Requires IdP configuration first
SAML.LogoutURL that a user will be redirected to if they choose to log out of Enterprise TesterEnterprise Tester Login URL<add key=”SAML.Logout” value=””/>Optional setting
If not configured, a user choosing the logout option will be automatically logged back in again provided there session is still active with the IdP.

Example of the configuration as it might appear in the web.config file alongside other settings

    <add key="site.root.url" value="" />
    <add key="Licensing.ServerKey.GenerationMode" value="Stable" />
    <add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />
    <add key="PathService.PackagePathSeparator" value="|" />
    <add key="aspnet:MaxHttpCollectionKeys" value="10000" />
    <add key="" value="FileSystemCas" />
    <add key="SAML.Enabled" value="True" />
    <add key="SAML.Provider" value="Microsoft"/>
    <add key="SAML.Issuer" value="" />
    <add key="SAML.IDP" value="" />
    <add key="SAML.Logout" value="" />

Example – Enterprise Tester with Okta

Okta is an enterprise-grade, identity management service, built for the cloud, but compatible with many on-premises applications. With Okta, IT can manage any employee’s access to any application or device. Okta runs in the cloud, on a secure, reliable, extensively audited platform, which integrates deeply with on-premises applications, directories, and identity management systems.

Configuring Okta

1) In Okta, create Enterprise Tester integration using SAML 2.0.

2) In Okta the SAML General Settings need to contain the following.

  • Single Sign URL – this must be your Enterprise Tester instance e.g https://enterprisetester/authentication/SAML2.rails
  • Audience URI – this is A9CC4713-F3D5-4321-9C19-14A58E117364

3) Make sure you record IDP information when selecting the “View Setup Instructions”.

Configuring Enterprise Tester to use Okta

Add the following keys to the appSettings section in the Enterprise Tester web.config file.  Note: Values used within these appsettings will be available after completing the Okta configuration above.

1) Enable SAML Support

<add key="SAML.Enabled" value="true" />

2) IDP Issuer

<add key="SAML.Issuer"value="<IDP Issuer>"/>


<add key="SAML.IDP"value="<IDP SSO URL>"/>

4) X.509 Certificate

<add key="SAML.Certificate"value="<X.509 Certificate>"/>

5) Specify logout url

Do not add an Enterprise Tester URL here or users will be automatically logged back into Enterprise Tester.The Okta applications page is a suggested url that could be added.

<add key="SAML.Logout"value="https://your_selected_logout_page"/>

SHA-256 XML Signature Support

SAML 2.0 uses the SHA-256 encyrption protocol if this is not enabled on your server you will need to do the following.

On the Enterprise Tester server:

  1. Download CLR Security Update
  2. Download GACUTIL from here:
  3. Extract Security.Cryptography.dll assembly
  4. Add Security.Cryptography.dll toGAC full path... gacutil.exe /i Security.Cryptography.dll
  5. View Security.Cryptography.dll assembly gacutil.exe /l Security.Cryptography
  6. Update machine.config in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config. Insert the following code block after <system.web> section in <configuration> 
       <cryptoClass RSASHA256SignatureDescription="Security.Cryptography.RSAPKCS1SHA256SignatureDescription, Security.Cryptography, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
     <nameEntry name=""class="RSASHA256SignatureDescription"/>

Diagnosing Authentication

Diagnosing authentication issues can be difficult – there are a number of possible issues that can occur:

  • Incorrectly configured authentication method
  • Authentication methods are disabled
  • Servers etc. that methods rely on cannot be contacted
  • Username does not exist
  • Username exists in directory, but does not exist in Enterprise Tester
  • Password is incorrect

On the authentication methods toolbar select Test Authentication:

You can then check your authentication method from the screen.

Enter a username and password, then click “Run Test” button which will then attempt to authenticate the user against all enabled authentication methods.

  • Overall success is reported via two fields “Success” and “User Exists”.  Both these must be true for the user to be able to log into Enterprise Tester successfully.
  • By clicking the plus icon next to a row you can see authentication details
Table of Contents