Compliance and Auditing

Topics

Audit Logging
Compliance Features
Reporting
Integration Examples
SOAR Platform Integration
HR System Integration

Audit Logging

Configuration:

Enable audit logging in ELS Console → Security → Audit Settings
Log categories: Authentication, Authorization, Configuration Changes

Log Locations:

/var/log/energylogserver/audit.log
/var/log/energylogserver/security.log

Retention Policy:

Default: 90 days
Configurable: 30-365 days

Compliance Features

GDPR Compliance: Data anonymization, user consent tracking
PCI DSS: Restricted access, audit trails
HIPAA: Encryption, access logging
SOX: Role segregation, audit reporting

Reporting

Generate Compliance Report: Navigate to Reports → Compliance Report → Generate

Audit Log Export:

curl -X GET "https://els-console:9200/api/v1/audit/export?start=2024-08-01&end=2024-08-25" \
  -H "Authorization: Bearer API_KEY" > audit_log_2024-08.csv

Integration Examples

SOAR Platform Integration

Automated User Provisioning:

import requests
import json

def provision_incident_responder(user_data, incident_id):
    """Provision temporary incident responder during security incident"""
    
    api_endpoint = "https://els-console:9200/api/v1/users"
    headers = {
        'Authorization': 'Bearer YOUR_API_KEY',
        'Content-Type': 'application/json'
    }
    
    payload = {
        'username': user_data['username'],
        'email': user_data['email'],
        'full_name': user_data['full_name'],
        'role': 'incident_responder',
        'department': 'security',
        'status': 'active',
        'temporary_access': True,
        'expiration_date': '2024-12-31T23:59:59Z',
        'justification': f'Emergency response for incident {incident_id}'
    }
    
    response = requests.post(api_endpoint, headers=headers, json=payload)
    return response.status_code == 201

HR System Integration

Automated Onboarding/Offboarding:

def sync_with_hr_system():
    """Synchronize user accounts with HR system"""
    
    # Fetch new employees from HR API
    new_employees = fetch_hr_new_employees()
    
    # Fetch terminated employees from HR API
    terminated_employees = fetch_hr_terminated_employees()
    
    # Create accounts for new employees
    for employee in new_employees:
        if employee['department'] == 'security':
            create_security_analyst_account(employee)
        else:
            create_viewer_account(employee)
    
    # Deactivate accounts for terminated employees
    for employee in terminated_employees:
        deactivate_user_account(employee['username'])

Authentication with Active Directory

The AD configuration should be done in the /etc/logserver/properties.yml file.

Below is a list of settings to be made in the properties.yml file (the commented section in the file for the AD settings to start working, this fragment should be uncommented):

ldaps:  
 - name: "example.com"  # domain that is configured 
   host: "127.0.0.1,127.0.0.2"  # list of server for this domain  
   #port: 389 # optional, default 389 for unencrypted session or 636 for encrypted sessions  
   ssl_enabled: false  # optional, default true 
   #ssl_trust_all_certs: true # optional, default false 
   #ssl.keystore.file: "path" # path to the truststore store 
   #ssl.keystore.password: "path" # password to the trusted certificate store 
   bind_dn: [admin@example.com] # account name administrator 
   bind_password: "password" # password for the administrator account 
   search_user_base_DN: "OU=lab,DC=example,DC=com" # search for the DN user tree database 
   #user_id_attribute: "uid # search for a user attribute optional, by default "uid" 
   #search_groups_base_DN: "OU=lab,DC=example,DC=com" # group database search. This is a catalog main, after which the groups will be sought. 
   #unique_member_attribute: "uniqueMember" # optional, default "uniqueMember" 
   connection_pool_size: 10 # optional, default 30 
   connection_timeout_in_sec: 10 # optional, default 1 
   request_timeout_in_sec: 10 # optional, default 1* 
   cache_ttl_in_sec: 60 # optional, default 0 - cache disabled 
   #authentication_only: true    # optional ignore role-mapping settings 
   #default_authentication_roles: [ "roleName1", "roleName2" ]      # roles asigned to new users authenticating using this LDAP server, used when authentication_only = true

If we want to configure multiple domains, then in this configuration file we copy the # LDAP section below and configure it for the next domain.

Below is an example of how an entry for 2 domains should look like. (It is important to take the interpreter to read these values correctly).

ldaps:
  - name: "example1.com" #DOMAIN 1
    host: "127.0.0.1,127.0.0.2"
    bind_dn: "esauth@example1.com"
    bind_password: "password"
    search_user_base_DN: "cn=Users,DC=example1,DC=com"
    ssl_enabled: false
  - name: "example2.com" #DOMAIN 2
    host: "127.0.0.1,127.0.0.2"
    bind_dn: "esauth@example2.com"
    bind_password: "password"
    search_user_base_DN: "cn=Users,DC=example2,DC=com"
    ssl_enabled: false

After completing the LDAP section entry in the properties.yml file, save the changes and reload the module with the below command:

curl -sS -uUSER:PASSWORD localhost:9200/_logserver/auth/reload -XPOST

Example:

curl -sS -ulogserver:logserver localhost:9200/_logserver/auth/reload -XPOST

Configure SSL support for AD authentication

Open the certificate manager on the AD server.

Select the certificate and open it

Select the option of copying to a file in the Details tab

Click the Next button

Keep the setting as shown below and click Next

Keep the setting as shown below and click Next.

Give the name a certificate

After the certificate is exported, this certificate should be imported into a trusted certificate file that will be used by the Data Node plugin.

To import a certificate into a trusted certificate file, a tool called „keytool.exe” is located in the JDK installation directory.

Use the following command to import a certificate file:

 keytool -import -alias adding_certificate_keystore -file certificate.cer -keystore certificatestore

The values certificat.cer and certificationstore should be changed accordingly.

By doing this, he will ask you to set a password for the trusted certificate store. Remember this password, because it must be set in the configuration of the Data Node plugin. The following settings must be set in the properties.yml configuration for SSL:

 ssl.keystore.file: "<path to the trust certificate store>"
 ssl.keystore.password: "<password to the trust certificate store>"

Role mapping

In the /etc/logserver/properties.yml configuration file you can find a section for configuring role mapping:

# LDAP ROLE MAPPING FILE
# rolemapping.file.path: /etc/logserver/role-mappings.yml

This variable points to the file /etc/logserver/role-mappings.yml Below is the sample content for this file:

# admin - superuser group
admin:
  - "CN=Admins,CN=Builtin,DC=example,DC=com"

gui-access:
  - "CN=Admins,CN=Builtin,DC=example,DC=com"

Attention. The role you define in the role-mapping.yml file must be created in the EMCA_PROD_NAME.

How to the mapping mechanism work?
An AD user logs in to EMCA_PROD_NAME. In the application, there is a gui-access role, which through the file role-mapping.yml binds to the name of an AD group of which the user is a member. Additionally, this AD group binds to the EMCA_PROD_NAME admin role, which points to permission granted to the user in the application.

Similarly, the mechanism will work for any other role in the application. Important in this configuration is to add every AD group to gui-access which grants permission to log in and at least one more role which grants permission to some data.

The gui-access role is not visible in GUI, it’s only used to grant permission to log in.

If field authentication_only is true, user roles will not be mapped and they will be taken from the default_authentication_roles field. When the default_authentication_roles field is not added in properties.yaml, a user without a role will be created.

Below is a screenshot of the console on which are marked accounts that were created by users logging in from AD

If you map roles from several domains, for example, dev.example1.com, and dev.example2.com then in the User List we will see which user from which domain with which role logged in EMCA_PROD_NAME.

Password encryption

For security reasons, you can provide the encrypted password for Active Directory integration.
To do this use pass-encrypter.sh script that is located in the Utils directory in the installation folder.

Installation of pass-encrypter

cp -pr /instalation_folder/logserver/pass-encrypter /usr/share/logserver/

Use pass-encrypter

/usr/share/logserver/utils/pass-encrypter/pass-encrypter.sh

Enter the string for encryption :
new_password
Encrypted string : MTU1MTEwMDcxMzQzMg==1GEG8KUOgyJko0PuT2C4uw==

Authentication with Radius

To use the Radius protocol, install the latest available version of EMCA_PROD_NAME.

Configuration

The default configuration file is located at /etc/logserver/properties.yml:

# Radius opts
#radius.host: "10.4.3.184"
#radius.secret: "querty1q2ww2q1"
#radius.port: 1812

Use appropriate secret based on config file in Radius server. The secret is configured on clients.conf in the Radius server.

In this case, since the plugin will try to do Radius auth, the client IP address should be the IP address where the Data Node is deployed.

Every user by default at present gets the admin role

Authentication with LDAP

To use OpenLDAP authorization, install or update EMCA_PROD_NAME too at least 7.0.2.

Configuration

The default configuration file is located at /etc/logserver/properties.yml:

ldap_groups_search - Enable Open LDAP authorization. The ldap_groups_search switch with true/false values.
search filter - you can define search_filter for each domain. When polling the LDAP / AD server, the placeholder is changed to the userId (everything before @domain) of the user who is trying to log in. Sample search_filter:
```
search_filter: "(&(objectClass=inetOrgPerson)(cn=%s))"
```
If no search_filter is given, the default will be used:
```
(&(&(objectCategory=Person)(objectClass=User))(samaccountname=%s))
```
max_connections - for each domain (must be> = 1), this is the maximum number of connections that will be created with the LDAP / AD server for a given domain. Initially, one connection is created, if necessary another, up to the maximum number of connections set. If max_connections is not given, the default value = 10 will be used.

ldap_groups_search - filter will be used to search groups on the AD / LDAP server to which the user is trying to log in. An example of groups_search_filter that works quite universally is:

groups_search_filter: "(|(uniqueMember=%s)(member=%s))"

Sample configuration:

licenseFilePath: /usr/share/logserver/

ldaps:
    
    - name: "dev.it.example.com"
      host: "192.168.0.1"
      port: 389                                                  # optional, default 389
      #ssl_enabled: false                                        # optional, default true
      #ssl_trust_all_certs: true                                 # optional, default false
      bind_dn: "Administrator@dev2.it.example.com"                     
      bind_password: "Buspa#mexaj1"                                 
      search_user_base_DN: "OU=lab,DC=dev,DC=it,DC=example,DC=pl"
      search_filter: "(&(objectClass=inetOrgperson)(cn=%s))"     # optional, default "(&(&(objectCategory=Person)(objectClass=User))(samaccountname=%s))"
      user_id_attribute: "uid"                                   # optional, default "uid"
      search_groups_base_DN: "OU=lab,DC=dev,DC=it,DC=example,DC=pl" # base DN, which will be used for searching user's groups in LDAP tree
      groups_search_filter: "(member=%s)"                        # optional, default (member=%s), if ldap_groups_search is set to true, this filter will be used for searching user's membership of LDAP groups
      ldap_groups_search: false                                  # optional, default false - user groups will be determined basing on user's memberOf attribute
      unique_member_attribute: "uniqueMember"                    # optional, default "uniqueMember"
      max_connections: 10                                        # optional, default 10
      connection_timeout_in_sec: 10                              # optional, default 1
      request_timeout_in_sec: 10                                 # optional, default 1
      cache_ttl_in_sec: 60                                       # optional, default 0 - cache disabled

When the password is longer than 20 characters, we recommend using our pass-encrypter, otherwise, the backslash must be escaped with another backslash. Endpoint role-mapping/_reload has been changed to _role-mapping/reload. This is a unification of API conventions, following Data Node conventions.

Configuring Single Sign On (SSO)

To configure SSO, the system should be accessible by domain name URL, not IP address or localhost.

Correct: https://loggui.com:5601/login
Wrong: https://localhost:5601/login, https://10.0.10.120:5601/login

The configuration description described below is based on:

AD Domain / Realm: example.com
AD IP Address: 192.168.3.111
GUI Url: loggui.com

To enable SSO on your system, follow the steps below.

Configuration steps

Create a User Account for Data Node auth plugin
In this step, a Kerberos Principal representing the Data Node auth plugin is created on the Active Directory. The principal name would be name@EXAMPLE.COM, while the EXAMPLE.COM is the administrative name of the realm.

Create a User in AD. Set “Account never expires” and enable support for Kerberos encryption as shown below.
Define the Service Principal Name (SPN) and Create a keytab file for it

Use the following command to create the keytab file identyfying the SPN:
```
  C:> ktpass -out c:\Users\Administrator\esauth.keytab -princ HTTP/loggui.com@EXAMPLE.COM -mapUser esauth -mapOp set -pass 'Sprint$123' -crypto ALL -pType KRB5_NT_PRINCIPAL
```
Details of the used switches:
- -out - path to the keytab file
- -mapUser - name of the previously created AD user. It might need to be preceded with pre-Windows 2000 logon if user cannot be found (e.g. EXAMPLE\esauth on the screenshot).
- -princ - service principal name. Must start with uppercase HTTP/ and must end with uppercase domain after the @ sign. Will be used later to configure principal.
- -pass - password that secures the keytab file itself (not connected user’s password!). Will be used later to configure principal’s password.
For more details about the ktpass tool, please refer to the official documentation: ktpass details.

The esauth.keytab file should be placed on your Data Node node - preferably /etc/logserver/ with read permissions for Data Node user:
```
chmod 640 /etc/logserver/esauth.keytab
chown user: /etc/logserver/esauth.keytab
```

Create a file named krb5Login.conf:

  com.sun.security.jgss.initiate {
      com.sun.security.auth.module.Krb5LoginModule required
      principal="HTTP/loggui.com@EXAMPLE.COM"
      useKeyTab=true
      keyTab=/etc/logserver/esauth.keytab
      storeKey=true
      debug=true;
    };
  com.sun.security.jgss.krb5.accept {
    com.sun.security.auth.module.Krb5LoginModule required
    principal="HTTP/loggui.com@EXAMPLE.COM"
    useKeyTab=true
    keyTab=/etc/logserver/esauth.keytab
    storeKey=true
    debug=true;
  };

The principal user and keyTab location should be changed as per the values created in Step 2. Make sure the domain is in UPPERCASE as shown above.
The krb5Login.conf file should be placed on your Data Node node, for instance, /etc/logserver/ with read permissions for the Data Node user:

sudo chmod 640 /etc/logserver/krb5Login.conf
sudo chown user: /etc/logserver/krb5Login.conf

Uncomment and edit JVM arguments, in /etc/logserver/jvm.options.d/single-sign-logon.options as shown below:
```
-Dsun.security.krb5.debug=false \
-Djava.security.krb5.realm=**EXAMPLE.COM** \
-Djava.security.krb5.kdc=**192.168.3.111** \
-Djava.security.auth.login.config=/etc/logserver/krb5Login.conf \
-Djavax.security.auth.useSubjectCredsOnly=false
```
Change the .krb5.realm and .krb5.kdc to the appropriate values. Realm is defined as used domain (must be in UPPERCASE) realm and .kdc is AD’s IP address. Those JVM arguments have to be set for the Logserver server.
Authentication options if authentication_only: true is set

If a user does not exist, Logserver will create the user without a role. Role in role-mapping.yml would be ignored and role gui-access from default_authentication_roles: ["gui-access"] will be assigned.

Add the following additional (sso.domain, service_principal_name, service_principal_name_password) settings for LDAP in properties.yml file:

sso.domain: "example.com"
ldaps:
 - name: "example.com"
     host: "IP_address"
     port: 389                                      # optional, default 389
     ssl_enabled: false                             # optional, default    true
     ssl_trust_all_certs: false                     # optional, default false
     bind_dn: "esauth@example.com"                  # optional, skip for anonymous bind
     bind_password: "password"                      # optional, skip for anonymous bind (AD admin's password)
     search_user_base_DN: "cn=Users,DC=example,DC=com"
     user_id_attribute: "uid"                       # optional, default "uid"
     unique_member_attribute: "uniqueMember"        # optional, default "uniqueMember"
     
     service_principal_name: "HTTP/loggui.com@EXAMPLE.COM" # principal name used while generating the keytab file
     service_principal_name_password: "Sprint$123" # -pass used during keytab creation

Note: At this moment, SSO works for only a single domain. So you have to mention for what domain SSO should work in the above property sso.domain - in this example it should be “example.com”.

After completing the LDAP section entry in the properties.yml file, save the changes and send a request for reload authentication data with the command:
```
curl -sS -u username:password localhost:9200/_logserver/auth/reload -XPOST
```
Enable the SSO feature in the logserver-gui.yml file:
```
login.sso_enabled: true
```
After that Logserver GUI has to be restarted with systemctl restart command

Client (Browser) Configuration

Internet Explorer configuration

Go to Internet Options from the Tools menu and click on Security Tab:
Select Local intranet, click on Site -> Advanced -> Provide correct URL -> Click Add:

After adding the site click close.
Click on the custom level and select the option as shown below:

Chrome configuration

For Chrome, the settings are taken from the IE browser.

Firefox Configuration

Update the following config:

KBC error codes

KDC error codes	Description
0	No error
1	Client entry is expired
2	Server entry is expired
3	Protocol version is not supported
4	Client key is encrypted in an old master key
5	Server key is encrypted in an old master key
6	Client is not defined in the security registry
7	Server is not defined in the security registry
8	Principal is not unique in the security registry
9	No key is available for the principal
10	Ticket is not eligible for postdating
11	Ticket is never valid
12	Request rejected due to KDC policy
13	Request option is not supported
14	Encryption type is not supported
15	Checksum type is not supported
16	Preauthentication type is not supported
17	Transited data type is not supported
18	Client account is revoked
19	Server account is revoked
20	TGT is revoked
21	Client account is not valid yet
22	Server account is not valid yet
23	Password is expired
24	Preauthentication failed
25	Preauthentication required
26	Supplied authentication ticket is not for the requested server
27	Server requires user-to-user protocol
31	Decryption integrity check failed
32	Ticket is expired
33	Ticket is not valid yet
34	Request is a replay of a previous request
35	Supplied authentication ticket is not for the current realm
36	Ticket and authenticator do not match
37	Clock skew is too great
38	Incorrect network address
39	Protocol version mismatch
40	Invalid message type
41	Message stream has been modified
42	Message is out of order
44	Key version is not available
45	Service key is not available
46	Mutual authentication failed
47	Incorrect message direction
48	Alternative authentication method required
49	Incorrect message sequence number
50	Inappropriate checksum type
60	Generic error detected
61	Field is too long
62	Client certificate is not acceptable
63	KDC certificate is not trusted or does not meet requirements
64	Certificate signature not valid
65	Client Diffie-Hellman key parameters not accepted
70	Client certificate could not be verified
71	Client certificate chain validation error occurred
72	Client certificate chain contains a revoked certificate
73	Revocation status for the certificate chain could not be determined
75	Kerberos client name does not match name bound to the client certificate
76	Kerberos KDC name does not match name bound to the KDC certificate
77	Key purpose restricts certificate usage
78	Certificate signature digest algorithm is not supported
79	PKAuthenticator is missing the required paChecksum
80	The signedData digest algorithm is not supported
81	The Public Key encryption delivery method is not supported