Integration with Active Directory, Active Directory Federation Services and FreeIPA

You can integrate KUMA with the Active Directory, Active Directory Federation Services, and FreeIPA services used in your organization.

You can configure a connection to the Active Directory catalog service over the LDAP protocol. This lets you use information from Active Directory in correlation rules for enrichment of events and alerts, and for analytics.

If you configure a connection to a domain controller server, you can use domain authorization. In this case, you can bind the domain groups of users to the KUMA role filters. The users belonging to these groups will be able to use their domain account credentials to log in to the KUMA web interface and will obtain access to application sections based on their assigned role.

It is recommended to create the groups of users in Actions Active Directory, Active Directory Federation Services, or FreeIPA in advance if you want to provide such groups with the capability for authorization using their domain account in the KUMA web interface. An email address must be indicated in the properties of a user account in Active Directory.

Connecting over LDAP

LDAP connections are created and managed under Settings → LDAP server in the KUMA web interface. The LDAP server integration by tenant section shows the tenants for which LDAP connections were created. Tenants can be created or deleted.

If you select a tenant, the LDAP server integration window opens to show a table containing existing LDAP connections. Connections can be created or edited. In this window, you can change the frequency of queries sent to LDAP servers and set the retention period for obsolete data.

After integration is enabled, information about Active Directory accounts becomes available in the alert window, the correlation events detailed view window, and the incidents window. If you click an account name in the Related users section of the window, the Account details window opens with the data imported from Active Directory.

Data from LDAP can also be used when enriching events in collectors and in analytics.

Imported Active Directory attributes

Enabling and disabling LDAP integration

You can enable or disable all LDAP connections of the tenant at the same time, or enable and disable an LDAP connection individually.

To enable or disable all LDAP connections of a tenant:

1. In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to enable or disable all LDAP connections.

   The LDAP server integration by tenant window opens.

2. Select or clear the Disabled check box.
3. Click Save.

To enable or disable a specific LDAP connection:

1. In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to enable or disable an LDAP connection.

   The LDAP server integration window opens.

2. Select the relevant connection and either select or clear the Disabled check box in the opened window.
3. Click Save.

Adding a tenant to the LDAP server integration list

To add a tenant to the list of tenants for integration with an LDAP server:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window opens.

2. Click the Add tenant button.

   The LDAP server integration window is displayed.

3. In the Tenant drop-down list, select the tenant that you need to add.
4. Click Save.

The selected tenant is added to the LDAP server integration list.

To delete a tenant from the list of tenants for integration with an LDAP server:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window is displayed.

2. Select the check box next to the tenant that you need to delete, and click Delete.
3. Confirm deletion of the tenant.

The selected tenant is deleted from the LDAP server integration list.

Creating an LDAP server connection

To create a new LDAP connection to Active Directory:

1. In the KUMA web interface, open Settings → LDAP server.
2. Select or create a tenant for which you want to create a LDAP connection.

   The LDAP server integration by tenant window opens.

3. Click the Add connection button.

   The Connection parameters window opens.

4. Add a secret containing the account credentials for connecting to the Active Directory server. To do so:
   1. If you previously added a secret, in the Secret drop-down list, select the existing secret (with the credentials type).

      The selected secret can be changed by clicking on the button.

   2. If you want to create a new secret, click the button.

      The Secret window opens.

   3. In the Name (required) field, enter the name of the secret containing 1 to 128 Unicode characters.
   4. In the User and Password (required) fields, enter the account credentials for connecting to the Active Directory server.

      You can enter the user name in one of the following formats: <user name>@<domain> or <domain><user name>.

   5. In the Description field, enter a description of up to 4,000 Unicode characters.
   6. Click the Save button.
5. In the Name (required) field, enter the unique name of the LDAP connection.

   The length of the string must be 1 to 128 Unicode characters.

6. In the URL (required) field, enter the address of the domain controller in the format <hostname or IP address of server>:<port>.

   In case of server availability issues, you can specify multiple servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.

7. If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the Type drop-down list:
   • startTLS.

     When the

     startTLS

     Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.

     Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.

     Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.

     method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.

     Make sure that port 389 is open. Otherwise, a connection with the domain controller will be impossible.

   • ssl.

     When using SSL, an encrypted connection is immediately established over port 636.

   • insecure.

   When using an encrypted connection, it is impossible to specify an IP address as a URL.

8. If you enabled TLS encryption at the previous step, add a TLS certificate. To do so:
   1. If you previously uploaded a certificate, select it from the Certificate drop-down list.

      If no certificate was previously added, the drop-down list shows No data.

   2. If you want to upload a new certificate, click the button on the right of the Certificate list.

      The Secret window opens.

   3. In the Name field, enter the name that will be displayed in the list of certificates after the certificate is added.
   4. Click the Upload certificate file button to add the file containing the Active Directory certificate. X.509 certificate public keys in Base64 are supported.
   5. If necessary, provide any relevant information about the certificate in the Description field.
   6. Click the Save button.

   The certificate will be uploaded and displayed in the Certificate list.

9. In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server.

   If multiple addresses are indicated in the URL field, KUMA will wait the specified number of seconds for a response from the first server. If no response is received during that time, the program will contact the next server, and so on. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.

10. In the Base DN field, enter the base distinguished name of the directory in which you need to run the search query.
11. In the Custom AD Account Attributes field, specify the additional attributes that you want to use to enrich events.

    Before configuring event enrichment using custom attributes, make sure that custom attributes are configured in AD.

    To enrich events with accounts using custom attributes:

    1. Add Custom AD Account Attributes in the LDAP connection settings.

       Standard imported attributes from AD cannot be added as custom attributes. For example, if you add the standard accountExpires attribute as a custom attribute, KUMA returns an error when saving the connection settings.

       The following account attributes can be requested from Active Directory:

       • accountExpires
       • badPasswordTime
       • cn
       • co
       • company
       • department
       • description
       • displayName
       • distinguishedName
       • division
       • employeeID
       • givenName
       • l
       • lastLogon
       • lastLogonTimestamp
       • Mail
       • mailNickname
       • managedObjects
       • manager
       • memberOf (this attribute can be used for search during correlation)
       • mobile
       • name
       • objectCategory
       • objectGUID (this attribute always requested from Active Directory even if a user doesn't specify it)
       • objectSID
       • physicalDeliveryOfficeName
       • pwdLastSet
       • sAMAccountName
       • sAMAccountType
       • sn
       • streetAddress
       • telephoneNumber
       • title
       • userAccountControl
       • UserPrincipalName
       • whenChanged
       • whenCreated

       After you add custom attributes in the LDAP connection settings, the LDAP attribute to receive drop-down list in the collector automatically includes the new attributes. Custom attributes are identified by a question mark next to the attribute name. If you added the same attribute for multiple domains, the attribute is listed only once in the drop-down list. You can view the domains by moving your cursor over the question mark. Domain names are displayed as links. If you click a link, the domain is automatically added to LDAP accounts mapping if it was not previously added.

       If you deleted a custom attribute in the LDAP connection settings, manually delete the row containing the attribute from the mapping table in the collector. Account attribute information in KUMA is updated each time you import accounts.  

    2. Import accounts.
    3. In the collector, in the LDAP mapping table, define the rules for mapping KUMA fields to LDAP attributes.
    4. Restart the collector.

       After the collector is restarted, KUMA begins enriching events with accounts.

        

12. Select the Disabled check box if you do not want to use this LDAP connection.

    This check box is cleared by default.

13. Click the Save button.

The LDAP connection to Active Directory will be created and displayed in the LDAP server integration window.

Account information from Active Directory will be requested immediately after the connection is saved, and then it will be updated at the specified frequency.

If you want to use multiple LDAP connections simultaneously for one tenant, you need to make sure that the domain controller address indicated in each of these connections is unique. Otherwise KUMA lets you enable only one of these connections. When checking the domain controller address, the program does not check whether the port is unique.

Creating a copy of an LDAP server connection

You can create an LDAP connection by copying an existing connection. In this case, all settings of the original connection are duplicated in the newly created connection.

To copy an LDAP connection:

1. In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to copy an LDAP connection.

   The LDAP server integration window opens.

2. Select the relevant connection.
3. In the opened Connection parameters window, click the Duplicate connection button.

   The New Connection window opens. The word copy will be added to the connection name.

4. If necessary, change the relevant settings.
5. Click the Save button.

The new connection is created.

If you want to use multiple LDAP connections simultaneously for one tenant, you need to make sure that the domain controller address indicated in each of these connections is unique. Otherwise KUMA lets you enable only one of these connections. When checking the domain controller address, the program does not check whether the port is unique.

Changing an LDAP server connection

To change an LDAP server connection:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window opens.

2. Select the tenant for which you want to change the LDAP server connection.

   The LDAP server integration window opens.

3. Click the LDAP server connection that you want to change.

   The window with the settings of the selected LDAP server connection opens.

4. Make the necessary changes to the settings.
5. Click the Save button.

The LDAP server connection is changed. Restart the KUMA services that use LDAP server data enrichment for the changes to take effect.

Changing the data update frequency

KUMA queries the LDAP server to update account data. This occurs:

• Immediately after creating a new connection.
• Immediately after changing the settings of an existing connection.
• According to a regular schedule every several hours. Every 12 hours by default.
• Whenever a user creates a task to update account data.

When querying LDAP servers, a task is created in the Task manager section of the KUMA web interface.

To change the schedule of KUMA queries to LDAP servers:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. In the Data refresh interval field, specify the required frequency in hours. The default value is 12.

The query schedule has been changed.

Changing the data storage period

Received user account data is stored in KUMA for 90 days by default if information about these accounts is no longer received from the Active Directory server. After this period, the data is deleted.

After KUMA account data is deleted, new and existing events are no longer enriched with this information. Account information will also be unavailable in alerts. If you want to view information about accounts throughout the entire period of alert storage, you must set the account data storage period to be longer than the alert storage period.

To change the storage period for the account data:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. In the Data storage time field, specify the number of days you need to store data received from the LDAP server.

The account data storage period is changed.

Starting account data update tasks

After a connection to an Active Directory server is created, tasks to obtain account data are created automatically. This occurs:

• Immediately after creating a new connection.
• Immediately after changing the settings of an existing connection.
• According to a regular schedule every several hours. Every 12 hours by default. The schedule can be changed.

Account data update tasks can be created manually. You can download data for all connections or for one connection of the required tenant.

To start an account data update task for all LDAP connections of a tenant:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. Click the Import accounts button.

A task to receive account data from the selected tenant is added to the Task manager section of the KUMA web interface.

To start an account data update task for one LDAP connection of a tenant:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. Select the relevant LDAP server connection.

   The Connection parameters window opens.

4. Click the Import accounts button.

A task to receive account data from the selected connection of the tenant is added to the Task manager section of the KUMA web interface.

Deleting an LDAP server connection

To delete LDAP connection to Active Directory:

1. In the KUMA web interface, open Settings → LDAP server and select the tenant that owns the relevant LDAP connection.

   The LDAP server integration window opens.

2. Click the LDAP connection that you want to delete and click the Delete button.
3. Confirm deletion of the connection.

The LDAP connection to Active Directory will be deleted.

Authentication using domain accounts

To enable users to perform authentication in the KUMA web interface using their own domain account credentials, perform the following configuration steps.

1. Enable domain authentication if it is disabled.

   Domain authorization is enabled by default, but a connection to the domain is not configured.

2. Configure a connection to the domain controller.

   The following connections are available:

   • Active Directory (AD)
   • Active Directory Federation Services (ADFS)
   • FreeIPA

   The AD and ADFS connection settings can be configured at the same time.

   You can connect to one domain only.

3. Add groups of user roles.

   You can specify a domain group for each KUMA role. After performing authentication using their domain accounts, the users from this group get access to the KUMA web interface in accordance with the specified role.

   The application checks whether the user group matches the specified filter according to the following order of roles in the KUMA web interface: operator → first line analyst → analyst → tenant administrator → general administrator. Upon the first match, the program assigns a role to the user and does not check any further. If a user matches two groups in the same tenant, the role with the least privileges will be used. If multiple groups are matched for different tenants, the user will be assigned the specified role in each tenant.

Special considerations for logging in after configuring domain authentication

For successful authentication, the following conditions must be met:

• FreeIPA: when logging into the system, the user must capitalize the domain name in the login. Example: user@FREEIPA.COM.
• AD/ADFS: when logging into the system, the user must specify UserPrincipalName in the login. Example: user@domain.ru.

If you complete all the configuration steps but the users are not able to use their domain accounts for authentication in the KUMA web interface, it is recommended to check the configuration for the following issues:

• An email address is not indicated in the properties of the user account in Active Directory. If this is the case, an error message is displayed during the user's first authentication attempt and a KUMA account is not created.
• There is already an existing local KUMA account with the email address indicated in the domain account properties. If this is the case, the error message is displayed when the user attempts to perform authentication with the domain account.
• Domain authorization is disabled in the KUMA settings.
• An error occurred when entering the group of roles.
• The domain user name contains a space.

Enabling and disabling domain authentication

Domain authorization is enabled by default, but a connection to the domain is not configured. If you want to temporarily suspend domain authentication after configuring a connection, you can disable it in the KUMA web interface without deleting the previously defined values of settings. If necessary, you can enable authentication again at any time.

To enable or disable domain authorization of users in the KUMA web interface:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select one of the options:
   • FreeIPA
   • AD/ADFS
3. Do one of the following:
   • To disable domain authentication, select the Disabled check box in the upper part of the workspace.
   • To enable domain authentication, clear the Disabled check box in the upper part of the workspace.
4. Click the Save button.

The selected settings are saved and applied.

Configuring connection between KUMA and FreeIPA

You can connect only to one FreeIPA domain. To do so, you must configure a connection to the domain controller.

To configure a connection to a FreeIPA domain controller:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select FreeIPA.
3. In the FreeIPA settings block, in the Base DN field, enter the DistinguishedName of the root record to search for access groups in the FreeIPA catalog service. Record format: dc=example,dc=com.
4. In the URL field, indicate the address of the domain controller in the format <hostname or IP address of server>:<port>.

   In case of server availability issues, you can specify up to three servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.

5. If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the TLS mode drop-down list:
   • startTLS.

     When the startTLS method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.

     Make sure that port 389 is open. Otherwise, a connection with the domain controller will be impossible.

   • ssl.

     When using SSL, an encrypted connection is immediately established over port 636.

   • insecure.

   When using an encrypted connection, it is impossible to specify an IP address as a URL.

6. If TLS encryption is enabled, the Secret field becomes required and you must specify a secret of the 'certificate' type in that field. If you previously uploaded a secret, select it from the Secret drop-down list. If necessary, click the button to create a new secret of the 'certificate' type and select the secret from the drop-down list.
7. In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server. The default value is 0.

   If multiple addresses are indicated in the URL field, KUMA waits for the specified number of seconds for a response from the first server. If no response is received during that time, the application contacts the next server. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.

8. In the Custom integration secret drop-down list, select a secret with the 'credentials' type.

   If you want to upload a new secret of the 'credentials' type, click the button on the right of the Custom integration secret drop-down list. This opens the Secret window; in that window, in the Name field, enter the name of the secret that will be displayed in the list after it is saved. In the User field, specify the DistinguishedName in the following format: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test. Enter the Password and click Save.

   The secret is uploaded and becomes available for selection in the Custom integration secret drop-down list.

9. If you want to configure domain authentication for a user with the KUMA general administrator role, use the General administrators group field to specify the DistinguishedName of the FreeIPA group containing the user.

   If the user belongs to several groups within the same tenant, the role with the least privileges is used.

   Filter input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

10. Click the Save button.

A connection with the FreeIPA domain controller is now configured.

You can also check the connection for the previously entered domain controller connection settings.

To check the connection to the domain controller:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select FreeIPA.
3. In the FreeIPA settings block, select the relevant secret in the User credentials field.

   If necessary, you can create a new secret by clicking the button or change the settings of an existing secret by clicking the button. If integration with FreeIPA is enabled, the secret selection is always reset when the page is loaded.

4. Click Test.

   After clicking the Test button, the system tests the connection with the domain and returns a notification with the test results. The system does not check if the users can log in or if the user group is configured correctly.

For domain authentication, add the groups for the KUMA user roles.

You can specify the groups only for the roles that require the configuration of domain authentication. You can leave the rest of the fields empty.

To add groups of user roles:

1. In the application web interface, select Settings → Domain authorization.
2. In the Role groups settings block, click the Add role groups button.
3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
4. In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
   • Operator.
   • First line analyst.
   • Analyst.
   • Administrator.

   Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

   You can specify only one domain group for each role. If you need to specify multiple groups, you must repeat steps 2–4 for each group while indicating the same tenant.

5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
6. Click the Save button.

The groups of user roles will be added. The defined settings will be applied the next time the user logs in to the KUMA web interface.

After the first authentication of the user, information about this user is displayed under Settings → Users. The Login and Password fields received from the domain cannot be edited. The user role will also be unavailable for editing. To edit a role, you will have to change the user role groups. Changes to a role are applied after the next authentication of the user. The user continues working under the current role until the current session expires.

If the user name or email address is changed in the domain account properties, these changes must be manually made in the KUMA account.

Configuring connection between KUMA and Active Directory

You can connect only to one Active Directory domain. To do so, you must configure a connection to the domain controller.

To configure a connection to an Active Directory domain controller:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select AD/ADFS.
3. In the Active Directory group of settings, in the Base DN field, enter the DistinguishedName of the root record to search for access groups in the Active Directory catalog service.
4. In the URL field, indicate the address of the domain controller in the format <hostname or IP address of server>:<port>.

   In case of server availability issues, you can specify multiple servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.

5. If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the TLS mode drop-down list:
   • startTLS.

     When the startTLS method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.

     Make sure that port 389 is open. Otherwise, a connection with the domain controller will be impossible.

   • ssl.

     When using SSL, an encrypted connection is immediately established over port 636.

   • insecure.

   When using an encrypted connection, it is impossible to specify an IP address as a URL.

6. If you enabled TLS encryption at the previous step, add a TLS certificate:
   • If you previously uploaded a certificate, select it from the Secret drop-down list.

     If no certificate was previously added, the drop-down list shows No data.

   • If you want to upload a new certificate, click the button on the right of the Secret list. In the opened window, in the Name field, enter the name that will be displayed in the list of certificates after the certificate is added. Add the file containing the Active Directory certificate (X.509 certificate public keys in Base64 are supported) by clicking the Upload certificate file button. Click the Save button.

     The certificate will be uploaded and displayed in the Secret list.

7. In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server.

   If multiple addresses are indicated in the URL field, KUMA waits for the specified number of seconds for a response from the first server. If no response is received during that time, the application contacts the next server. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.

8. To configure domain authentication for a user with the KUMA general administrator role, specify the DistinguishedName of the Active Directory group the user belongs to in the General administrators group field.

   If the user belongs to several groups within the same tenant, the role with the least privileges is used.

   Filter input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

9. Click the Save button.

A connection with the Active Directory domain controller is now configured.

You can also check the connection for the previously entered domain controller connection settings.

To check the connection to the domain controller:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select AD/ADFS.
3. In the Test connection settings block, select the relevant secret in the User credentials field.

   If necessary, you can create a new secret by clicking the button or change the settings of an existing secret by clicking the button.

   The following formats for specifying a user are available in the User field: UserPrincipalName and domain\user.

4. Click Test.

   After clicking the Test button, the system tests the connection with the domain and returns a notification with the test results. The system does not check if the users can log in or if the user group is configured correctly.

For domain authentication, add the groups for the KUMA user roles.

You can specify the groups only for the roles that require the configuration of domain authentication. You can leave the rest of the fields empty.

To add groups of user roles:

1. In the application web interface, select Settings → Domain authorization.
2. In the Role groups settings block, click the Add role groups button.
3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
4. In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
   • Operator.
   • First line analyst.
   • Analyst.
   • Administrator.

   Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

   You can specify only one domain group for each role. If you need to specify multiple groups, you must repeat steps 2–4 for each group while indicating the same tenant.

5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
6. Click the Save button.

The groups of user roles will be added. The defined settings will be applied the next time the user logs in to the KUMA web interface.

After the first authentication of the user, information about this user is displayed under Settings → Users. The Login and Password fields received from the domain cannot be edited. The user role will also be unavailable for editing. To edit a role, you will have to change the user role groups. Changes to a role are applied after the next authentication of the user. The user continues working under the current role until the current session expires.

If the user name or email address is changed in the domain account properties, these changes must be manually made in the KUMA account.

Configuring connection between KUMA and Active Directory Federation Services

To configure domain authentication in KUMA and ensure that users can log in to KUMA using their accounts without specifying a user name and password, first create a connection group and configure the rules in ADFS or make sure that the necessary connection groups and rules already exist.

After configuration, the Sign in via ADFS button appears on the KUMA login page.

The Sign in via ADFS button is hidden on the KUMA login page in the following conditions:

• The FreeIPA option is selected in the Authorization type drop-down list.
• The AD/ADFS option is selected in the Authorization type drop-down list and the settings for ADFS are not specified or the Disabled check box is selected for ADFS settings.

You can connect only to one ADFS domain. To do so, you must configure a connection to the domain controller.

To configure a connection to an ADFS domain controller:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select AD/ADFS.
3. In the Active Directory Federation Services settings block, in the Client ID field, enter the KUMA ID from the Client ID field in the ADFS.
4. In the Relying party identifier field, enter the KUMA ID from the Relying party identifiers field in the ADFS.
5. Enter the Connect Metadata URI from the Connect Metadata URI field. This parameter consists of the host where the ADFS resides (https://adfs.example.com), and the endpoint setting (/adfs/.well-known/openid-configuration).

   For example, https://adfs.example.com/adfs/.well-known/openid-configuration).

6. Enter the ADFS redirect URL from the Redirect URL field in the ADFS. The value of the Redirect URL field in the ADFS is defined when the Application group is configured. In the ADFS, you must indicate the KUMA FQDN and the </sso-callback> substring. In KUMA, the URL must be indicated without the substring, for example: https://kuma-example:7220/
7. If you want to configure domain authentication for a user with the KUMA general administrator role, use the General administrators group field to specify the DistinguishedName of the Active Directory Federation Services group containing the user.

   If the user belongs to several groups within the same tenant, the role with the least privileges is used.

   Filter input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

8. Click the Save button.

A connection with the Active Directory Federation Services domain controller is now configured.

For domain authentication, add the groups for the KUMA user roles.

You can specify the groups only for the roles that require the configuration of domain authentication. You can leave the rest of the fields empty.

To add groups of user roles:

1. In the application web interface, select Settings → Domain authorization.
2. In the Role groups settings block, click the Add role groups button.
3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
4. In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
   • Operator.
   • First line analyst.
   • Analyst.
   • Administrator.

   Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

   You can specify only one domain group for each role. If you need to specify multiple groups, you must repeat steps 2–4 for each group while indicating the same tenant.

5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
6. Click the Save button.

The groups of user roles will be added. The defined settings will be applied the next time the user logs in to the KUMA web interface.

After the first authentication of the user, information about this user is displayed under Settings → Users. The Login and Password fields received from the domain cannot be edited. The user role will also be unavailable for editing. To edit a role, you will have to change the user role groups. Changes to a role are applied after the next authentication of the user. The user continues working under the current role until the current session expires.

If the user name or email address is changed in the domain account properties, these changes must be manually made in the KUMA account.

Configuring connection in Active Directory Federation Services

This section provides instructions on how to create a new connection group and configure rules for the created connection group in Active Directory Federation Services (ADFS).

The ADFS role must already be configured on the server.

Creating a new connection group

1. In Server Manager, in the Tools menu, select ADFS Management.

   In ADFS, select the Application groups section and in the Actions section click Add Application Group.

2. In the Add Application Group Wizard window that opens, in the Welcome section Name field, specify the name of the new connection group. Example: new-application-group.

   In the Template field, in the Client-Server applications group, select Native application accessing a web API.

   Click Next to proceed to the next step of creating and configuring a connection group.

3. In the Native application section that opens, the Name and

    Client Identifier

   fields are filled in automatically.

   Specify the value of the Client Identifier field in KUMA, when configuring domain authentication.

   In the

    

   Redirect URI field, enter the URI for redirection from ADFS with the /sso-callback substring, and click Add. Example: https://adfs.example.com:7220/sso-callback

   Click Next to proceed to the next configuration step.

4. In the Configure Web API section that opens, in the

   Identifiers

   field add the trusted party ID and click Add. It can be any arbitrary value. Example: test-demo

   Specify the value of the Identifier field in KUMA, in the Relying party identifiers field, when configuring domain authentication.

   Click Next to proceed to the next configuration step.

5. In the Apply Access Control Policy section that opens, select the Permit everyone policy value.

   Click Next to proceed to the next configuration step.

6. In the Configure Application Permissions section that opens, the Client application field is filled in automatically.

   In the Permitted scopes field, select the check box for the allatclaims and openid options.

   Click Next to proceed to the next configuration step.

7. In the Summary section that opens, check the settings.

   If the settings are correct and you are ready to add a group, click Next.

A new group is added. You can proceed to configure the rules for the created group.

Adding rules for a connection group

1. In Server Manager, in the Tools menu, select ADFS Management.

   In ADFS, select the Application groups section and select the required connection group from the list. Example: new-application-group.

2. In the Application groups window, in the Actions section, click Properties.

   In the new-application-group Properties window that opens, in the Applications section, double-click new-application-group - Web API.

   In the new-application-group - Web API Properties window that opens, open the

   Issuance Transform Rules

   tab and click Add rule.

   In the Add Transform Claim Rule Wizard window that opens, in the Choose Rule Type section, select Send LDAP Attributes as Claims from the drop-down list.

   Click Next to proceed to the next configuration step.

3. In the Configure Claim Rule section, specify the rule name in the Claim rule name field. Example: rule-name-01.

   In the Attribute store drop-down list, select Active directory.

   In the Mapping of LDAP attributes to outgoing claim types field, map the following fields:

   LDAP Attribute	Outgoing Claim Type
   User-Principal-Name	UserPrincipalName
   Display-Name	displayName
   E-Mail-Addresses	Mail
   Is-Member-Of-DL	MemberOf

   Click Finish to complete the configuration.

4. Go to the new-application-group - Web API Properties window, open the

   Issuance Transform Rules

   tab and click Add rule. In the Add Transform Claim Rule Wizard window that opens, in the Choose Rule Type section, select Send claims using a custom rule from the drop-down list.

   Click Finish to continue the configuration.

5. In the Configure Claim Rule section, specify the rule name in the Claims rule name field. Example: rule-name-02.

   In the Custom rule field, specify the following settings: 

   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("ObjectGUID"), query = ";ObjectGUID;{0}", param = c.Value);

   Click Finish to complete the configuration.

6. The system proceeds to the new-application-group - Web API Properties window and the Issuance Transform Rules tab.

   To apply the rules, on the Issuance Transform Rules tab that opens, click Apply or OK.

The configuration of groups and rules in ADFS is completed. You can proceed to configure domain authentication in KUMA.

Troubleshooting the Access denied error

When you try to log in to KUMA using ADFS, the Access denied or Insufficient rights pop-up message may appear. The KUMA Core log shows the Data source certificate has been changed error.

This error indicates that the ADFS certificate is changed. To fix the error and resume domain authentication, update the certificate thumbprint saved in KUMA.

To update the certificate thumbprint on an Astra Linux or Oracle Linux host:

1. Contact Technical support to obtain the adfs_fingerprint_changer_tool binary file.
2. Place the received adfs_fingerprint_changer_tool binary file in any folder on the host with the KUMA Core. For example, /root/kuma-ansible-installer.
3. On the host with the KUMA Core, start the command line interpreter and use the cd command to go to the folder containing the adfs_fingerprint_changer_tool file.

   For example, you can enter the following command and press Enter:

   cd /root/kuma-ansible-installer

4. To grant the permissions to run a binary file and run the binary file, sequentially execute the following commands:

   chmod +x adfs_fingerprint_changer_tool

   ./adfs_fingerprint_changer_tool

To update the certificate thumbprint on a Kubernetes host:

1. Contact Technical support to obtain the adfs_fingerprint_changer_tool binary file.
2. Place the received adfs_fingerprint_changer_tool binary file in any folder on the computer of an administrator with access to the Kubernetes cluster and execute the following commands:

   k0s kubectl cp <path to adfs_fingerprint_changer_tool> $(k0s kubectl get pod -l app=core -n kuma -o name | cut -d/ -f2):/tmp/ -c mongodb -n kuma

   k0s kubectl exec $(k0s kubectl get pod -l app=core -n kuma -o name) -c mongodb -n kuma -- bash -c "chmod a+x /tmp/adfs_fingerprint_changer_tool && /tmp/adfs_fingerprint_changer_tool"

After you run the binary file, the certificate thumbprint is updated and the domain authentication by means of ADFS is again available.