Admin Overview
The administration tab is divided into multiple sections covering a variety of administrative actions, as detailed below.
License Configuration
In this section, a new license file can be uploaded when provided by Heimdall, and the current settings and license use can be observed. In Demo mode, up to 4 LB servers can be used, and up to four VDBs with rules (optimizations) can be enabled for 30 days. The used count is only based on VDBs that have received traffic in the last 30 seconds, so will dynamically account for activity. If the used values surpass the allowed values, then a warning will be displayed on the console, but no restriction in features will be enforced. License handling is strictly advisory, i.e. while the system may complain about a license being invalid, it will not restrict what is done, to insure no outages occur as a result of licensing.
Note: When using an AWS paid-for instance, the proxy use on the instance will not count toward license use. Additionally, added paid-for instances can be reconfigured to be a pure proxy instance and will also not count to license use on another management server.
Log Management
Log Files Management
This section is provided to assist in managing log files and configuring data source used for logging. Core dumps are files that are generated by the operating system when a program terminates abnormally, such as by crashing or encountering an error. Heap dumps are files that contain a snapshot of the Java Virtual Machine (JVM) heap at a specific point in time. This functionality is removing all core files from /var/lib/systemd/coredump folder and also core files and heap dumps files from the project directory.
Log Database Management
By default, an embedded database supplied with Heimdall is used to store logs and statistics, however there is an option to select user configured data source (MySQL, PostgreSQL, Oracle and SQL Server supported). If Heimdall is unable to establish connection to selected source at any point it will fall back to using embedded one. User configured in selected data source has to have database root privileges.
Software Management
This section allows for management of the software. In the first dropdown, you can select a version of code to update to. Release is the normal release train of code, test versions are generally just before a new release, and development are the often daily updates that have completed regression testing. Customers will often be asked to update to the development build if they have encountered a problem and want to apply the fix for it. To apply a particular version, select the version in the dropdown, then click "Update via Repository". Please note, if you have independent proxies running (vla NLB or as a service), you will need to restart them independently as well. To check the version of code each proxy is running, please refer to the status tab.
Note: Any build pushed as a development build have passed all regression testing that any previous version has passed. What may not yet be complete are regression tests for the new changes, which often are developed in parallel with customer testing of the changes. This can result in frequent development builds, but allows for rapid test/fix/deploy cycles during customer POC processes. Once a POC is completed, we will work with customers to schedule a full release build for use in production that has completed full and updated regression testing.
You can also update the version of Heimdall by providing the url link to the zip file, complete this action using Update via URL button.
In the event that you want to update to a particular version of Heimdall that was provided to you as a zip file, you can use the third section for a manual update. Simply select the heimdall zip file, then update via File.
The next option is the Shutdown/Restart Heimdall button, which will not explicitly trigger a restart, but will rely on any restart mechanisms on the server to trigger the actual execution of the server after it terminates.
In the event you need to download the Heimdall driver (say to use as a jdbc driver) the next option "Download Heimdall Driver" can be used.
If you need to roll back to a previous version of the system, the quickest way is to use the "Rollback Version" button. Heimdall stores two versions of the system - the current and the previous - and you can swiftly switch between them.
Following is the release notes link, for the most current release notes.
Note, for command line manual update, please do the following:
1) copy the file into the install directory as heimdall-new.zip 2) cd to install directory 3) execute the following commands:
* sed -i "s/\s*\"modules\/.*\",*//g" config/heimdall.conf
* unzip -j heimdall-new.zip
4) kill and restart the heimdallserver.jar process: ps auxw | grep heimdallserver.jar root 4198 0.0 0.0 6100 624 pts/0 S+ 18:03 0:00 grep --color=auto heimdallserver.jar root 26005 30.8 4.0 9679444 638504 ? Sl 17:58 1:25 java -server -XX:+ExitOnOutOfMemoryError -jar /opt/heimdall/heimdallserver.jar
kill 26005
Alerts
This section provides a list of any alerts that have been dismissed with the check. Any alerts in this list will not be shown in the top of the GUI until cleared.
Login History
This provides the login times, account ID and source IP of the recentally recorded GUI logins.
Cache Drivers
This section allows a cache driver (specifically Hazelcast) to be uploaded for use by Heimdall instead of the built-in driver. This allows the driver to match what may exist in a customer's environment if our version causes a conflict.
Server Properties
These are properties that can control overall Management server behavior, and will be added to over time. Current properties supported.
- Disable Cert Validation: Disable TLS certificate validation for software downloads (Boolean)
- Enable Portal Mode: Value that indicates if after successful login central manager or portal mode will be used (Boolean)
- Minimum free disk space %: configured how much space needs to be free for any configuration saves to occur. Defaults to 1 for 1%. This helps prevent configuration loss if not enough space is available to successfully save the full configuration. (Double)
- Log Events To Console: For debugging or container use, log ALL events to the stdout console of management server (Boolean)
- Max Log Age: Sets the maximum age in days of log files and log records (Integer)
- Enables password validation: Validate new users password along with provided rules (Boolean)
- Proxy Host: If a proxy is needed to access the Internet for code update notifications and downloads, the host to use for this (String)
- Proxy Password: Proxy password for proxy authentication, no default (String)
- Proxy Port: The port defaults is 3128 (Integer)
- Proxy User: Proxy user for proxy authentication, no default (String)
- Redirect Config Fetches: Value that indicates if server should redirect all HTTP config requests to HTTPS Tomcat port (Boolean)
- Reserved Disk Space: Sets the amount of FREE memory to maintain on the log filesystem (Double)
- Verbose Debug Mode: On the server, enable verbose debug mode (Boolean)
Modules
Allows modules to be added or removed as needed. The fewer the modules, the faster a Heimdall node can startup. In particular cache modules that are unused should be deleted as some can add significant load time.
Password Policies
This section allows user to set up requirements that specific user password must meet to be accepted as a new one. Current rules supported:
- minimum/maximum of characters - minimum/maximum number of characters that password must contain (with minimum/maximum parameter tht defines the limit).
- digits requirement - rule defining that password must contain at least one digit
- special marks requirement - rule defining that password must contain at least one special mark
- uppercase character requirement - rule defining that password must contain at least one uppercase character
- custom regex matching - rule that provides a pattern parameter with the regular expression to which password must match
Config Management
This section allows editing startup /etc/heimdall.conf configuration file, which can be used to populate environmental variables or cloud environments. The user can set options described below.
| Option Name | Description | Default value |
|---|---|---|
hdRole |
proxy | |
hdHost |
Hostname of management server | heimdallmanager |
hdPort |
Port of the management server, generally 8087 or 8443 | 8087 |
secure |
If the proxy should use HTTPS to connect to the manager | false |
hdUser |
Login username for the management server, can be admin | admin |
hdPassword |
Login password for the management server | heimdall |
javaOptions |
Any arbitrary options desired to be set | -server -XX:+ExitOnOutOfMemoryError -XX:+IgnoreUnrecognizedVMOptions -XX:-MaxFDLimit -XX:+UnlockExperimentalVMOptions |
hdSecretKey |
In AWS, use this as the name of an "AWS Secret" to store the configuration, protecting included passwords from being written to disk. To use, proper permissions must be set on the IAM role. This option provides two major benefits. First is that all passwords are stored in AWS Secrets, in an encrypted format. Second is that redeployment of a management server can be done with a configuration pre-populated, so there is no need to backup and restore configurations to account for failures. Simply terminate the old instance and a new instance with the same user-data will be created with the same configuration as the original. |
LDAP (AD) Configuration (Proxy & Central Manager)
LDAP (AD) Authentication provides authentication with using of LDAP (AD) server. LDAP (AD) Authentication provides two modes of authentication:
- Bind + Search Mode - authentication is made by binding to server as admin and searching information about authenticated user;
- Simple Mode - authentication is made by binding to server as authenticated user.
Bind + Search Mode
To configure Bind + Search Mode, below options can be set.
| Ldap option | Required? | Description | Example value |
|---|---|---|---|
| LDAP(S) URL | yes | Specifies url of LDAP (AD) server | ldap://server.example.com:389 |
| LDAP Security Principal | yes | Specifies name of user used to search for authenticated user | CN=ro-admin,CN=Users,DC=example,DC=com |
| LDAP Search User Password | yes | Specifies password for user used to search for authenticated user | examplepassword123 |
| LDAP Search Domain | yes | Specifies LDAP (AD) search domain, the domain in which authenticated user's groups will be searched. | DC=example,DC=com |
| LDAP User Search Base | yes | Specified LDAP (AD) user search base in which authenticated user will be searched. | CN=Users,DC=example,DC=com |
| LDAP Name Attribute | yes | Specifies name attribute by which authenticated user | sAMAccountName |
| LDAP Group Name Attribute | no | Optional, specifies group's name attribute which should be read during extracting authenticated user's groups. If not provided, LDAP Name Attribute will be used instead. | CN |
| LDAP Group Filter | no | Optional, option used during searching for authenticated user. Setting this option limits the number of groups to search user into them, only to particular group inside server. Setting this option makes it required to extract at least one group to authenticate the user. | (DistinguishedName=CN=group1,CN=Users,DC=example,DC=com) |
| Use nested groups filter | - | Specifies if parent groups should be included, when searching for user's groups. | - |
| Ignore LDAP Cert | - | Specifies if TLS validation of LDAP server certificate should be performed | - |
By choosing option Simple Ldap Mode, you can switch to Simple Mode.
Advanced group filter
LDAP group filter is used to limit number of groups for look up for authenticated user. Example value describes filter limiting number of groups to only one particular group, but this option value is added as written, what enables writing more complex filters. Please look on below example.
Let's assume that we want our user be from groups group1 or group2. By knowing the syntax of search filter used in LDAP server we can set LDAP Group Filter as:
(|(DistinguishedName=CN=group1,CN=Users,DC=example,DC=com)(DistinguishedName=CN=group2,CN=Users,DC=example,DC=com))
Important: If there is an LDAP Group Filter specified at least one group has to be extracted to authenticate the user.
Simple Mode
Simple Mode is simpler mode than Bind + Search mode, because uses only one request (which is binding request) to LDAP (AD) server.
Simple Mode can be turned on by choosing Active Directory (LDAP) Auth Enabled checkbox, and then choosing Simple LDAP Mode checkbox.
Simple Mode requires to set below options to work properly.
| Ldap option | Required? | Description | Example value |
|---|---|---|---|
| LDAP(S) URL | yes | Specifies url of LDAP (AD) server | ldap://server.example.com:389 |
| LDAP Prefix | yes | Specifies prefix used in during bind authenticated user to LDAP (AD) server | CN= |
| LDAP Suffix | yes | Specifies suffix used in during bind authenticated user to LDAP (AD) server | ,CN=Users, DC=example, DC=com |
To understand working of this mode, should be known that send request is binding composed of three parts:
prefix + username + suffix. For given example values and user exampleuser, binding request would look like
CN=exampleuser,CN=Users, DC=example, DC=com.
Central Manager Information
If you want to authenticate CM user, in the Users tab you should create new user(-s) with the same name as in your active directory. During creating new user don't forget to mark the "Authenticate By Ldap" option.
LDAP Configuration Wizard
The LDAP Configuration Wizard is provided to simplify configuration process as much as possible. It's a walk-through tool preventing from going forward if provided configuration is not valid.
At the moment Wizard handles only Bind + Search Mode.
There is the list of information necessary to finalize the Wizard Configuration:
- LDAP(S) URL - Specifies URL of LDAP (AD) server
- Ignore LDAP Cert - Specifies if TLS validation of LDAP server certificate should be performed
- LDAP Security Principal - Specifies name of user used to search for authenticated user
- LDAP Search User Password - Specifies password for user used to search for authenticated user
- LDAP Search Domain - Specifies the domain in which authenticated user's groups will be searched
- LDAP User Search Base - Specifies user search base in which authenticated user will be searched
- LDAP Name Attribute - Specifies attribute which should be used to identify a user
- LDAP Group Name Attribute - Specifies attribute, which should be used to extract information about a group (Optional)
- LDAP Group Filter - Specifies group filter, which will be added during a search for a user's groups (Optional)
- Use nested groups filter - Specifies if parent groups should be included, when searching for user's groups
Service Account Validation
At the very beginning, the absolute basis of the correct and valid configuration:
- The fields above are required as the authentication is made by binding to server as admin and searching information about authenticated user.
- The grayed-out "Verify" button will remain gray until all visible fields are filled in.
- When all the fields are filled in, the button will turn green and when pressed, the connection to AD will be attempted.
- If it fails, a corresponding message with the reason for the error will be displayed.
- if it succeed, the next Wizard stage will be unlocked.
Users & Groups Search Details
The next step is necessary to properly look for information about the user being authenticated and the groups he belongs to + set whether nested groups should be searched for.
- In order to simplify configuration some of the fields can be filled using dropdowns (LDAP Search Domain and LDAP Search Base contains all possible options straight from LDAP Server).
- LDAP (Group) Name Attribute contains all attributes which are actually used among all configured users / groups with additional counter of how many users / groups actually contain particular attribute.
- Additional "Example users found" row will be shown after LDAP Name Attribute selection. This row is just a preview and has no affect on the final configuration, but what is important - these values will be treated as logins for users to authenticate.
- All of these fields can be customized after checking suitable checkbox on the right.
- When all the fields are filled in, the button will turn green and when pressed, the attempt to find Groups configured on the server will be performed.
LDAP Group Filter Creation
The last step of the Wizard is to select Groups of interest for the DB i.e. Groups which will be relevant to database roles. Based on the selected Group the LDAP Group Filter will be generated when you click "Generate Filter" button. If no group is selected then no filter will be provided and this is ok - LDAP Group Filter optional.
At this point your LDAP Configuration is complete and after saving it can be found under "Ldap Configuration".
Authentication Checker
Provided configuration can be verified with the last part of the LDAP Configuration Wizard - Authentication Checker. In case of successful authentication extracted groups will be listed, as long as LDAP Group Filter is specified.
