- Deployment
- Authentication
- Manage User Accounts in Exabeam Cloud Connectors
- Generate a Hashed Password for the Exabeam Cloud Connectors Platform
- Replace the Default Clear-Text Passwords Mechanism with Hashed Passwords for Exabeam Cloud Connectors
- Install and Renew an SSL Certificate on the Cloud Connector Platform
- Add an SSL Certificate to the Cloud Connector Trusted Certificates Store Using a Script
- Add an SSL Certificate to the Cloud Connector Trusted Certificates Store Manually
- LDAP Authentication
- Active Directory Authentication
- Disable Sync Users and Groups Configuration
- Log Forwarding
- Docker Management
- High Availability
- Monitoring
- Security
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.
SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.
SSH to your Exabeam Cloud Connectors machine.
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
).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.origEdit the
client-shiro.ini
file. For example:sudo vi
<sk4 conf folder>
/shiro/client-shiro.iniTo remove a user, delete the entry for the account including the username and password from the [USERS] section.
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-adminwhere
and<mynewuser>
are the username and password for the user.<mynewpassword>
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-adminwhere
and<mynewuser>
727e4e6686fc16971cced06a2cc6669a73d9f38942cf
are the username and password for the user.
When done editing, save the changes and exit the editor.
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.
SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.
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
).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.oriEdit the client-shiro.ini file.
sudo vi
<sk4 conf folder>
/shiro/client-shiro.iniUnder 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-adminSet 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.
When done editing, save the changes and exit the editor.
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).
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.
Run the shiro command line hasher program.
An util overview is available here: https://shiro.apache.org/command-line-hasher.html.
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
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:
Locate client-shiro.ini file and back it up.
SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.
Switch to the sudo user:
sudo su -
Run the following command .
cd $(docker inspect sk4_conf -f '{{.Mountpoint}}')/shiro
Copy client-shiro.ini for backup:
cp client-shiro.ini client-shiro.ini.bak
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
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.
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
Back up the
sk4keystore.jks
files that are stored in the sk4_conf volume.Copy your certificate to the
sk4_conf
volume located in step 1.(Optional) Create a new volume to map the sk4tomcat conf folder outside the container.
Enter the Exabeam Cloud Connectors tomcat container.
docker exec -ti $(docker container ls | grep sk4 | grep tomcat | cut -f1 -d" ") bash
Navigate to the
sk4conf
directory inside the container.cd /usr/local/tomcat/sk4conf/
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
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 formerged.p12
. Enter a password formerged.p12
. This password is required when you import p12 into the keystore.Note
Note the skyformation alias.
Remove the existing certificate:
keytool -delete -alias skyformation -keystore sk4keystore.jks
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.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
(Optional) Change the password:
Add your new password to the keystore.
keytool -storepasswd -new <new-password> -keystore sk4keystore.jks -storepass changeit
Open
/usr/local/tomcat/conf/server.xml
, and change the password fromchangeit
to your new password.Exit the container:
exit
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:
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:
Edit the Exabeam cloud connector’s service file docker-compose execute command.
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.To verify that systemd makes the updates, run the command
sudo systemctl daemon-reloadsudo
.Restart the machine and run the command
sudo docker volume inspect sk4_tomcatconf
.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" }]
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:
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"
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
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
Make the script executable:
chmod +x import_cert.sh
Run the script with the server full host and port:
sudo ./import_cert.sh my.server.com 443
Restart Exabeam Cloud Connectors to take effect.
Add an SSL Certificate to the Cloud Connector Trusted Certificates Store Manually
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}}')
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
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
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
SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.
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
Make a backup of the following file:
sudo cp sk4conf/shiro/client-shiro.ini sk4conf/shiro/client-shiro.ini.orig
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
To exit the tomcat container, press Ctrl+D.
To support LDAPS (LDAP over SSL) if used above, Add an SSL Certificate to the Cloud Connector Trusted Certificates Store.
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
SSH into the Linux machine that hosts the Exabeam Cloud Connectors app with an account that has root-level permissions.
Change user to root.
sudo su -
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
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
Delete the
[users]
section[users]sk4admin = CURRENT_PASSWORD_HERE, sk4-admin
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
To encrypt the system user’s password in the
client-shiro.ini
file (if anonymous AD search is not supported) please do the following: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=//'`
Copy the encrypted password that is printed to the console.
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
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:
Log in to the Exabeam Cloud Connector platform with your registered credentials.
Click Accounts.
Click the name of the connector that you want to edit.
Click Advanced.
In the Account Connector Configuration section, search for the account-settings field.
Next to the account-settings field, change the value of both is-persona-sync-supported and is-groups-sync-supported to false.
Click Save.