Skip to main content

Cloud ConnectorsSetup

Table of Contents

Authentication

Manage User Accounts in Exabeam Cloud Connectors

By default, Exabeam Cloud Connectors ship with built-in users, roles, and passwords. Passwords are stored as clear-text.

As a best practice for security, we recommend using an external LDAP/AD for users, roles and passwords management. See Active Directory Authentication.

If AD/LDAP is not available, we recommend that you change the default clear-text based passwords with a more secure hashed passwords. See Replace the Default Clear-Text Passwords Mechanism with Hashed Passwords for Exabeam Cloud Connectors.

To manage user accounts using the built-in users and roles management, see:

Add or Remove a User

To add or remove users, you must have root-level access on the Exabeam Cloud Connectors machine.

  1. SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.

  2. SSH to your Exabeam Cloud Connectors machine.

  3. Locate the Exabeam conf files folder.

    sudo docker volume inspect --format='{{.Mountpoint}}' sk4_conf 

    For example /var/lib/docker/volume/sk4_conf/_data.

    If your Exabeam Cloud Connectors deployment is an OEM edition, you might find the the conf folder in a different location (for example /opt/[partner name]/data/sk4).

  4. Make a backup copy to the client-shiro.ini file in the conf folder:

    sudo cp <sk4 conf folder>/shiro/client-shiro.ini<sk4 conf folder>/shiro/client-shiro.ini.orig
  5. Edit the client-shiro.ini file. For example:

    sudo vi <sk4 conf folder>/shiro/client-shiro.ini
  6. To remove a user, delete the entry for the account including the username and password from the [USERS] section.

  7. To add a user, add a new row for each user that you want to allow access. Each row will contain the account name, the password, and the role. Refer to the following examples for the available password storage mechanisms (clear-text or hashed).

    • Clear-text password mechanism

      [USERS]
      sk4admin = s@mplePW4u$3r, sk4-admin <mynewuser>=<mynewpassword>, sk4-admin

      where <mynewuser> and <mynewpassword> are the username and password for the user.

    • Hashed password mechanism

      To generate a hashed password, see Generate a Hashed Password for the Exabeam Cloud Connectors Platform.

      [USERS]
      sk4admin =4f553c2977303e6727e4e6686fc16971cced06a2cc66, sk4-admin <mynewuser>=727e4e6686fc16971cced06a2cc6669a73d9f38942cf, sk4-admin

      where <mynewuser> and 727e4e6686fc16971cced06a2cc6669a73d9f38942cf are the username and password for the user.

  8. When done editing, save the changes and exit the editor.

  9. Restart the Exabeam Cloud Connectors service.

    sudo systemctl restart sk4compose

Reset a User's Password

To reset a user's password, you must have root-level access on the Exabeam Cloud Connectors machine.

  1. SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.

  2. Locate the Exabeam conf files folder.

    sudo docker volume inspect --format='{{.Mountpoint}}' sk4_conf

    For example, /var/lib/docker/volume/sk4_conf/_data.

    If your Exabeam Cloud Connectors deployment is an OEM edition, you might find the the conf folder in a different location (for example /opt/[partner name]/data/sk4).

  3. Create a backup copy of the client-shiro.ini file in the conf folder.

    sudo cp <sk4 conf folder>/shiro/client-shiro.ini <sk4 conf folder>/shiro/client-shiro.ini.ori
  4. Edit the client-shiro.ini file.

    sudo vi <sk4 conf folder>/shiro/client-shiro.ini
  5. Under the [USERS] section, locate the account for which you want to supply a new password. There are two password storage mechanisms available: clear-text or hashed.

    • Clear-text password mechanism

      [USERS]
      sk4adminuser = <newpassword>, sk4-admin
      

      Set the new password for the user account.

    • Hashed password mechanism

      To generate a hashed password, see Generate a Hashed Password for the Exabeam Cloud Connectors Platform.

      [USERS]
      sk4adminuser = 2977303e6727e4e6686fc16971cc, sk4-admin

      Set the new hashed password for the user account.

  6. When done editing, save the changes and exit the editor.

  7. Restart the Exabeam Cloud Connectors service.

    sudo systemctl restart sk4compose

Generate a Hashed Password for the Exabeam Cloud Connectors Platform

If you are using the hash-based password mechanism for Exabeam Cloud Connectors, you create a SHA-256 hash value for an existing clear-text password. The Exabeam Cloud Connectors platform can then use the hash value as a user's password. To create the hash value, you must download and run the hasher program (version 1.8 or later).

  1. Download the shiro hasher jar from maven central repository, version 1.8.0-RC2: https://repo1.maven.org/maven2/org/apache/shiro/tools/shiro-tools-hasher/1.8.0/shiro-tools-hasher-1.8.0-cli.jar.

  2. Run the shiro command line hasher program.

    An util overview is available here: https://shiro.apache.org/command-line-hasher.html.

  3. In the same directory as the downloaded jar, run this command:

    java -jar shiro-tools-hasher-1.8.0-RC2-cli.jar -i 1024 -f hex -ngs -p
  4. Enter the clear-text password to hash and copy the hashed value you receive as output.

    Password to hash:
    Password to hash (confirm):

Replace the Default Clear-Text Passwords Mechanism with Hashed Passwords for Exabeam Cloud Connectors

By default, the Exabeam Cloud Connectors platform uses an authentication mechanism based on clear-text passwords. To change the authentication method to a more secure hash-based password, use the following workflow:

  1. Locate client-shiro.ini file and back it up.

    1. SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.

    2. Switch to the sudo user:

      sudo su -
    3. Run the following command .

      cd $(docker inspect sk4_conf -f '{{.Mountpoint}}')/shiro
    4. Copy client-shiro.ini for backup:

      cp client-shiro.ini client-shiro.ini.bak
  2. Edit the client-shiro.ini using your preferred editor and add the following lines under the [main] section:

    # for having hashed creds: https://shiro.apache.org/realm.html#Realm-HashingCredentials
    # generate a hax password via this tool: https://shiro.apache.org/command-line-hasher.html
    # and this command: java -jar shiro-tools-hasher-1.4.0-RC2-cli.jar -i 1024 -f hex -ngs -p
    credentialsMatcher = org.apache.shiro.authc.credential.HashedCredentialsMatcher
    credentialsMatcher.hashAlgorithmName = SHA-256
    credentialsMatcher.hashSalted = false
    credentialsMatcher.storedCredentialsHexEncoded = true
    credentialsMatcher.hashIterations = 1024
    iniRealm.credentialsMatcher = $credentialsMatcher
  3. Under the [users] section in the client-shiro.ini file replace each user's clear-text password with a hashed value.

    For more information on generating a hashed password, see Generate a Hashed Password for the Exabeam Cloud Connectors Platform.

Install and Renew an SSL Certificate on the Cloud Connector Platform

Use this procedure to swap the default HTTPS server certificate with the certificate that is signed by the customer's organization's certificate authority.

Note

You must have root access to perform every step.

  1. Locate the sk4_conf directory in /opt/exabeam/data/sk4/conf.

    If you cannot find it in the /opt/exabeam/data/sk4/conf directory, run the following command to locate it:

    docker volume inspect sk4_conf
  2. Back up the sk4keystore.jks files that are stored in the sk4_conf volume.

  3. Copy your certificate to the sk4_conf volume located in step 1.

  4. (Optional) Create a new volume to map the sk4tomcat conf folder outside the container.

  5. Enter the Exabeam Cloud Connectors tomcat container.

    docker exec -ti $(docker container ls | grep sk4 | grep tomcat | cut -f1 -d" ") bash
  6. Navigate to the sk4conf directory inside the container.

    cd /usr/local/tomcat/sk4conf/
  7. Based on your certificate file format, perform the corresponding action:

    • pem format:

      Rename your certificate file to SF_certi.pem.

    • p7b format:

      Run the following command:

      openssl pkcs7 -inform der -print_certs -in <your-certificate-file>.p7b -out SF_cert.pem
    • crt format:

      Run the following command:

      openssl x509 -inform der -print_certs -in <your-certificate-file>.crt -out SF_cert.pem
  8. Merge your PEM certificate with the private key into p12:

    openssl pkcs12 -export -name skyformation -in SF_cert.pem -inkey app.key -out merged.p12

    Running this command provides the output Enter Export Password. The Export Password is a password for merged.p12. Enter a password for merged.p12. This password is required when you import p12 into the keystore.

    Note

    Note the skyformation alias.

  9. Remove the existing certificate:

    keytool -delete -alias skyformation -keystore sk4keystore.jks
  10. Import p12 into the keystore:

    keytool -importkeystore -srcstoretype pkcs12 -srckeystore merged.p12 -destkeystore sk4keystore.jks

    Running this command provides the following output: Importing keystore merged.p12 to sk4keystore.jks Enter keystore password: Enter source keystore password:

    The keystore password is the password for sk4keystore.jks. The Source Keystore password is the export password that we used for merged.p12.

    Note

    The default password for the keystore is changeit and must be equal to the alias password.

  11. If the certificate password is not changeit and the keystore password was left unchanged, change the password:

    keytool -keypasswd -alias skyformation -keypass <old-password> -new changeit -keystore sk4keystore.jks -storepass changeit
  12. (Optional) Change the password:

    1. Add your new password to the keystore.

      keytool -storepasswd -new <new-password> -keystore sk4keystore.jks -storepass changeit
    2. Open /usr/local/tomcat/conf/server.xml, and change the password from changeit to your new password.

      mceclip0.png
    3. Exit the container:

      exit
    4. Restart the Exabeam Cloud Connectors platform to take effect.

Create a New Volume to Map the Sk4tomcat Conf Folder

Each time the sk4tomcat container restarts, the server.xml is overridden by the default server.xml file from the docker image. Hence add a new volume and map the /conf folder that has server.xml file outside the container.

Note

If a docker compose override file - docker-compose.override.yml does not exist, create a new file. For more information see Create a Docker-Compose Override File.

To create a new volume:

  1. Edit the docker-compose.override.yml file as follows:

    version:
    '3'
    services:
      sk4tomcat:
        image:
    '498895000136.dkr.ecr.us-east-1.amazonaws.com/tomcat:<sk4-version>'
             
        volumes:
        - tomcatconf:/usr/local/tomcat/conf 
    volumes:
      tomcatconf:
  2. Edit the Exabeam cloud connector’s service file docker-compose execute command.

  3. In the etc/systemd/system/sk4compose.service file add a -f flag for the docker-compose.override.yml file:

    ExecStart=/usr/local/bin/docker-compose -f <path to docker-compose.yml> -f <path to docker-compose.yml.override.yml> up
    ExecStop=/usr/local/bin/docker-compose -f <path to docker-compose.yml> -f <path to docker-compose.override.yml> down

    Note

    The path for the docker-compose.yml and docker-compose.override.yml files is /opt/exabeam/data/sk4 for Exabeam deployment and /opt/sk4 for standalone deployments. This path is customizable during installation. Locate the exact path in the /etc/systemd/system/sk4compose.service file. The volume's name is displayed in the DIR_VOLNAME format. In this case the volume name is sk4_tomcatconf. DIR is the name of the directory in which the docker-compose.yml is persisted. By default the directory name is sk4. VOLNAME is the name of the volume as configured in the docker-compose.yml, in this case tomcatconf.

  4. To verify that systemd makes the updates, run the command sudo systemctl daemon-reloadsudo.

  5. Restart the machine and run the command sudo docker volume inspect sk4_tomcatconf.

  6. The following result appears that confirms that the updates are complete.

    [    {        "CreatedAt": "2020-02-10T10:25:05Z",        "Driver": "local",        "Labels": {            "com.docker.compose.project": "sk4",            "com.docker.compose.volume": "tomcatconf"        },        "Mountpoint": "/var/lib/docker/volumes/sk4_tomcatconf/_data",        "Name": "sk4_tomcatconf",        "Options": null,        "Scope": "local"    }]
  7. To see the tomcatconf in the list of volumes, run the following command.

    docker volume ls

Create a Docker-Compose.Override.yml File

The docker compose YAML file defines services, networks, and volumes. You can add configuration override for the existing docker-compose.yml file that has basic configuration, for preferred ports and volumes.

Locate the docker-compose.yml file in /opt/exabeam/data/sk4 for Exabeam deployment, or in /opt/sk4 for standalone deployments. The file is usually located at Exabeam Cloud Connector’s service file /etc/systemd/system/sk4compose.service.

To create a docker-compose.override.yml file:

  1. In the directory, add the service name and configurations you want to override or add. For example, if you change the ports of the sk4tomcat container, the docker-compose.yml file appears as follows:

    version: '3'services:  sk4tomcat:    ports:    - "8443:8443"

    The docker-compose.override.yml appears as follows:

    version: '3'services:  sk4tomcat:    ports:    - "8080:8080"
  2. To update the Exabeam cloud connector’s service file, in the etc/systemd/system/sk4compose.service file add a -f flag to the docker-compose.override.yml file.

    ExecStart=/usr/local/bin/docker-compose -f <path to docker-compose.yml> -f <path to docker-compose.yml.override.yml> up
    ExecStop=/usr/local/bin/docker-compose -f <path to docker-compose.yml> -f <path to docker-compose.override.yml> down

    Note

    Before editing the /etc/systemd/system/sk4compose.service file, stop the service. If a new docker-compose.override.yml file is added and /etc/systemd/system/sk4compose.service is updated, reload the systemd configuration (sudo systemctl daemon-reload) . Then start the service.

Add an SSL Certificate to the Cloud Connector Trusted Certificates Store Using a Script

  1. Create a script file on the machine that runs Exabeam Cloud Connector:

    #!/usr/bin/env bash
    
    # extracts ssl certificate from remote host. saves into a local file
    # receives host, port, target folder
    # creates a file ${host}.pem at execution location
    
    download_cert(){
      local _serverHost=$1
      local _serverPort=$2
      local _dstFolder=$3
      docker exec sk4tomcat openssl s_client -connect ${_serverHost}:${_serverPort} -servername ${_serverHost} 2>/dev/null | openssl x509 > ${_dstFolder}/${_serverHost}.pem
      echo ${_serverHost}.pem
    }
    
    import_cert_to_cacerts(){
      local _certFile=$1
      local _storeFile=$2
      docker exec sk4tomcat keytool -import -trustcacerts -keystore /usr/local/tomcat/sk4conf/${_storeFile} -noprompt -storepass changeit -alias "${_certFile}" -file /usr/local/tomcat/sk4conf/${_certFile}
    }
    
    # USE: script.sh my.server.com 443
    # maybe the folder is bound-mount
    confDir=$(sudo docker inspect sk4_conf -f '{{.Options.device}}')
    # and maybe not
    [ "${confDir}" == "<no value>" ] && confDir=$(sudo docker inspect sk4_conf -f '{{.Mountpoint}}')
    # download the cert. from the server to the conf dir.
    certFile=$(download_cert $1 $2 ${confDir})
    # import to cacerts
    import_cert_to_cacerts ${certFile} sk4cacerts
  2. Make the script executable:

    chmod +x import_cert.sh
  3. Run the script with the server full host and port:

    sudo ./import_cert.sh my.server.com 443
  4. Restart Exabeam Cloud Connectors to take effect.

Add an SSL Certificate to the Cloud Connector Trusted Certificates Store Manually

  1. On the machine that hosts the Exabeam Cloud Connectors, find out where the certificate store is:

    # maybe the folder is bound-mount 
    confDir=$(sudo docker inspect sk4_conf -f '{{.Options.device}}') 
    # and maybe not 
    [ "${confDir}" == "<no value>" ] && confDir=$(sudo docker inspect sk4_conf -f '{{.Mountpoint}}') 
  2. Download the certificate as x.509 file into the folder from step 1:

    Note

    Replace my.server.com and 443, with the values of your host and port.

    docker exec sk4tomcat openssl s_client -connect my.server.com:443 -servername my.server.com 2>/dev/null | openssl x509 > ${confDir}/my.server.com.pem
  3. Import the extracted certificate into the cacerts store:

    docker exec sk4tomcat keytool -import -trustcacerts -keystore /usr/local/tomcat/sk4conf/sk4cacerts -noprompt -storepass changeit -alias "my.server.com.pem" -file /usr/local/tomcat/sk4conf/my.server.com.pem
  4. Restart Exabeam Cloud Connectors to take effect.

LDAP Authentication

To easily manage user access to Exabeam Cloud Connectors and improve the security of user information and credentials, it is highly recommended to use LDAP over the default authentication mechanism. After setting up the LDAP server as the authentication service provider for Exabeam Cloud Connectors, users will be prompted to enter their LDAP credentials to log in.

Prerequisites

  • Enable access between Exabeam Cloud Connectors and the LDAP server

  • Identify the LDAP server name and port number you will use to set up LDAP as the authentication service

  • Ensure each user for whom you want to grant access has an attribute

Configure LDAP Authentication

  1. SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.

  2. Enter the Exabeam Cloud Connectors tomcat container by running the command for your Cloud Connectors version:

    • For 2.3.x versions

      sudo docker container exec -it sk4_sk4_tomcat_1 bash
    • For 2.4.x versions

      sudo docker container exec -it sk4tomcat bash
  3. Make a backup of the following file:

    sudo cp sk4conf/shiro/client-shiro.ini sk4conf/shiro/client-shiro.ini.orig
  4. Edit the original file (%skyformation root%/tomcat/sk4conf/shiro/client-shiro.ini) to add the following code for the LDAP configuration:

    ldapRealm = com.skyformation.shiro.realms.SK4LdapRealm
    ldapRealm.bindByAttribute = %the user attribute to lookup for authentication%
    ldapRealm.contextFactory.url = ldaps://%ldap server address%:%LDAP server port with SSL%
    ldapRealm.membershipAttribute = %the user's attribute name to look for%
    ldapRealm.groupRolesMap = %"users attribute to lookup for each AuthN user to allow SkyFormation
    app access"%:sk4-admin
    // Optional - needed only in large scale LDAP deployments to avoid lengthy lookup
    ldapRealm.baseSearch = %base DN to start the users seach from% (Optional)
    // Only needed if anonymous LDAP search is not supported
    ldapRealm.contextFactory.systemUsername = %search user's DN for the LDAP search%
    ldapRealm.contextFactory.systemPassword = %search user's password for the LDAP search%
    securityManager.realms = $ldapRealm

    LDAP configuration lines example:

    ldapRealm = com.skyformation.shiro.realms.SK4LdapRealm     
    ldapRealm.bindByAttribute = uid     
    ldapRealm.contextFactory.url = ldap://ldapserver.mycorp.com:389     
    ldapRealm.membershipAttribute = ou     
    ldapRealm.groupRolesMap = "Product Development":sk4-admin      
    ldapRealm.baseSearch = ou=people,dc=mycorp,dc=com           
    ldapRealm.contextFactory.systemUsername = uid=ajensen,ou=people,dc=mycorp,dc=com     
    ldapRealm.contextFactory.systemPassword = secret          
    securityManager.realms = $ldapRealm                     
    () Remove the following lines        
    [users]        
    sk4admin = currentpasswordhere, sk4-admin
    
  5. To exit the tomcat container, press Ctrl+D.

  6. To support LDAPS (LDAP over SSL) if used above, Add an SSL Certificate to the Cloud Connector Trusted Certificates Store.

  7. Restart the Exabeam Cloud Connectors application.

    sudo service sk4compose restart

Active Directory Authentication

By default, the Exabeam Cloud Connectors platform uses a local authentication mechanism based on a local file that contains the relevant user, role, and credentials for each account. It is highly recommended to replace the default authentication mechanism with AD/LDAP based authentication. This provides an easy way to manage users that you permit to access Exabeam Cloud Connectors and improve the security of user information and credentials.

With Active Directory authentication, Exabeam Cloud Connectors will prompt the user for his or her userPrincipalName and password and validates these with the configured Active Directory server. Exabeam Cloud Connectors does not save the user credentials sent to Active Directory.

You can configure authentication against Active Directory in Exabeam Cloud Connectors 2.1.21 and later releases. In Exabeam Cloud Connectors, you can also use the configuration in the app with 2.5.92 and later releases. Therefore to take advantage of these features, it is highly recommended you upgrade Exabeam Cloud Connectors to the latest release.

Prerequisites to Configure Active Directory

  • Make sure the Exabeam Cloud Connectors machine could communicate with the AD server

  • If you plan to use LDAPS (rather than LDAP) you must import the AD certificate to the Exabeam Cloud Connectors’s trust store. Note:

    Note

    If there are several servers behind the LDAPS URLs and multiple certificates are used, ensure that you add all of the certificates to the trust store.

  • Have ready the name and port number for your Active Directory server.

  • Ensure that each user for which you want to permit access to the Exabeam Cloud Connectors app belongs to the Active Directory group used to manage access.

Configure Active Directory Authentication

  1. SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.

  2. Change user to root.

    sudo su -
  3. To locate your sk4_conf volume, run the first command of the two below, if the result is <no value>, then run the second command of the two below to get the path.

    docker volume inspect --format='{{.Options.device}}' sk4_conf
    
    docker volume inspect --format='{{.Mountpoint}}' sk4_conf
  4. Backup your existing <sk4_conf_location>/shiro/client-shiro.ini file.

    cp <sk4_conf_location>/shiro/client-shiro.ini <sk4_conf_location>/shiro/client-shiro.ini.bak
  5. Delete the [users] section

    [users]sk4admin = CURRENT_PASSWORD_HERE, sk4-admin
  6. If anonymous AD search is supported or for keeping the system user’s password in /shiro/client-shiro.ini file in clear text please add the following lines to the file

    ldapRealm = org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm
    
    # ldap or ldaps
    ldapRealm.url = ldap://HOST_OR_IP:PORT
    
    # Optional - to allow [email protected] to authenticate with dan as the username. 
    ldapRealm.principalSuffix = @myorg.com
    
    # If white spaces exists int the AD group DN it must be put in double quotes  
    ldapRealm.groupRolesMap = "REPLACE_WITH_AD_GROUP":sk4-admin
    
    ldapRealm.searchBase = REPLACE_WITH_AD_BASE_SEARCH
    
    # systemUsername and systemPassword are only required if anonymous AD search is not supported
    # Existance of principalSuffix also applies to systemUsername 
    # So if [email protected] is the UPN for the system user and principalSuffix is @myorg.com then systemUsername should be sk4
    ldapRealm.systemUsername = REPLACE_WITH_SYSTEM_USER_UPN
    
    ldapRealm.systemPassword = REPLACE_WITH_SYSTEM_USER_PASSWORD
    securityManager.realms = $ldapRealm
  7. To encrypt the system user’s password in the client-shiro.ini file (if anonymous AD search is not supported) please do the following:

    1. Encrypt the system user’s password. By default, the SK4 root directory is either /opt/sk4 or /opt/exabeam/data/sk4.

      docker run --rm skyformation/troubleshoot-utils:latest encrypt-str REPLACE_WITH_PASSWORD `grep SKYFORMATION_ENC_KEY REPLACE_WITH_SK4_ROOT_DIR/docker-compose.yml |head -1 |sed's/.*SKYFORMATION_ENC_KEY=//'`
    2. Copy the encrypted password that is printed to the console.

    3. Add the following lines to the file.

      ldapRealm = com.skyformation.shiro.realms.SK4ActiveDirectoryRealm
      
      # ldap or ldaps
      ldapRealm.url = ldap://HOST_OR_IP:PORT
      
      # Optional - to allow [email protected] to authenticate with dan as the username. 
      ldapRealm.principalSuffix = @myorg.com
      
      # If white spaces exists int the AD group DN it must be put in double quotes  
      ldapRealm.groupRolesMap = "REPLACE_WITH_AD_GROUP":sk4-admin
      
      ldapRealm.searchBase = REPLACE_WITH_AD_BASE_SEARCH
      
      # Existance of principalSuffix also applies to the value you put here. 
      # So if [email protected] is the UPN for the system user, and principalSuffix is @myorg.com, systemUsername should be sk4
      ldapRealm.systemUsername = REPLACE_WITH_SYSTEM_USER_UPN
      
      ldapRealm.systemPassword = REPLACE_WITH_SYSTEM_USER_ENCRYPTED_PASSWORD
      ldapRealm.passwordEncrypted = true
      securityManager.realms = $ldapRealm
  8. Restart Exabeam Cloud Connectors tomcat microservice.

    docker container restart sk4tomcat

Troubleshooting Active Directory Authentication

To troubleshoot your Active Directory authentication setup, refer to the following considerations and tips:

  • In an INI file every property (name and value pair) is contained in a section (the section name appears on a line by itself, in square brackets). All relevant configuration must be in the main section

  • Enter the group name without quotes.

  • Username, both the ldapRealm.systemUsername in the ini file and the one being used in the login form must be the User Principal Name (UPN).

  • If you have defined ldapRealm.principalSuffix please verify ALL users that should access the application share the same suffix. This should also be applied for the ldapRealm.systemUsername you are using. If you have more than one unique suffix, you should not define a ldapRealm.principalSuffix and set the full UPN for the ldapRealm.systemUsername and use your full UPN to authenticate.

  • In the ldapRealm.groupRolesMap field - the Active Directory group must be described by its full DN. If the DN contains white characters, it should be wrapped in double quotes.

  • Please verify that indeed the user trying to authenticate has the active directory group set in the ldapRealm.groupRolesMap field as one of the values in the user's memberOf attribute

  • Please verify that all users that should access the application and the ldapRealm.systemUsername you are using are indeed under the ldapRealm.searchBase in the LDAP tree.

  • Default [users] section must be removed from the ini file.

Sample client-shiro-ini File

[main]

sk4Authc = com.skyformation.shiro.filter.SK4FormAuthenticationFilter

sk4Authc.loginUrl = /login.html
sk4Authc.successUrl = /index.html

cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
cacheManager.cacheManagerConfigFile = classpath:ehcache.xml
securityManager.cacheManager = $cacheManager

sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
sessionManager.sessionDAO = $sessionDAO

securityManager.sessionMode = native

cookie = org.apache.shiro.web.servlet.SimpleCookie
cookie.name = SSOcookie
cookie.path = /
sessionManager.sessionIdCookie = $cookie

securityManager.sessionManager = $sessionManager

ldapRealm = com.skyformation.shiro.realms.SK4ActiveDirectoryRealm
ldapRealm.url = ldap://ad.exabeam:389
ldapRealm.principalSuffix = @exabeam.com
ldapRealm.groupRolesMap = "CN=SK4,DC=Groups,DC=exabeam,DC=com":sk4-admin
ldapRealm.searchBase = DC=exabeam,DC=com
ldapRealm.systemUsername = sk4
ldapRealm.systemPassword = gATNJ0RQzDzWPSHg/kJ1Jg==
ldapRealm.passwordEncrypted = true  
securityManager.realms = $ldapRealm

[urls]
/login.html = sk4Authc
/index.html = sk4Authc, roles[sk4-admin]
/onboard.html = sk4Authc, roles[sk4-admin]
/logout = logout
/ = sk4Authc, roles[sk4-admin]
/** = anon

Disable Sync Users and Groups Configuration

Some cloud services require admin permissions to be granted to the Exabeam cloud connector only for retrieving the user and group information and not for other logs. By default, Exabeam grants users and groups sync and admin permission to cloud services. If you do not want to assign admin permission to the Exabeam cloud connector, edit the configuration settings to disable the retrieval of users and groups for a specific cloud service.

To edit the configuration to disable users and groups sync:

  1. Log in to the Exabeam Cloud Connector platform with your registered credentials.

  2. Click Accounts.

  3. Click the name of the connector that you want to edit.

  4. Click Advanced.

  5. In the Account Connector Configuration section, search for the account-settings field.

  6. Next to the account-settings field, change the value of both is-persona-sync-supported and is-groups-sync-supported to false.

  7. Click Save.