GBDI 4.1

GBDI Administration Guide

This Administration Guide is focused on administration procedures and tasks for GBDI, including user and role management and password changes.

Additional administration tasks are available via the Administration panel on the GBDI Home Page. (See GBDI Administration Panel.)

Creating and Managing Users and Roles

The user administrator creates and manages users/roles via either the Authorization Management (Users/Roles) page on the GBDI Home Page, or by using the mongo shell.

Note

The GBDI Home Page provides an interactive interface and is the preferred method for performing administration tasks. For an overview of the GBDI Home Page, see GBDI Application User Guide.

Performing Administration Tasks via the GBDI Home Page

To access the Authorization Management page, click the Users/Roles button (highlighted below) located in the Administration panel on the GBDI Home Page.

Launch_Users_Roles.png

Note

Only users with the UserAdmin role can access the Authorization Management page. The UserAdmin role is assigned to the user named secAdmin by default.

Three tabs comprise the Authorization Management page:

  • Users Management – Add and manage users. 

  • Roles Management – Add and manage roles.

  • DLS - Data Level Security – Advanced user setup and management based on data level security (DLS) rules.

Users Management

The Users Management tab contains a list of all current users, including pre-built user accounts (default users with predefined roles included with the GBDI installation).

Note

When creating new users, it is recommended to use an email address as the username to ensure functionality such as sign-on, notification, and reviewing and signing off on reports.

Adding Users via the GBDI Home Page

To add a user via the GBDI Home Page:

  1. On the Users Management tab, click the Add New User button (highlighted below).

    create_user1.png

     

  2. The Add New User window will pop up, as shown below.

    create_user2.png
  3. Enter the following details for the new user:

    • Username

    • Password

  4. (Optional) To create a user with default roles, select the Apply default roles checkbox. The default roles are:

    • SonarG application role

    • sonarGROUser role for admin database 

  5. Click Create User. The user will now appear in the list of users on the Users Management tab.

Adding Users via the Shell

Users and passwords can also be created via the administrator command line interface (CLI) / mongo shell. 

To add a user via the shell:

  1. After logging in with admin credentials, connect the mongo shell to Sonar:

    mongo <GBDI host>:27117/admin -uadmin -p
  2. Create the user with the sonarGUser database role:

    > db.createUser({user: "<username>", pwd: "<password>", roles: ["sonarGUser"]})
Managing Users via the GBDI Home Page

To manage user details via the GBDI Home Page:

Click the name of a user on the Users Management tab. The User panel (highlighted below) will open on the right side of the page; the user’s details can be managed / configured in the User panel.

User_Panel.png

In the User panel, you can perform the following actions:

Roles Management

The Roles Management tab contains a list of all roles, including the pre-built default roles with predefined grants included in the GBDI installation.

To manage role details:

Click a role on the Roles Management tab. The Role panel (highlighted below) will open on the right side of the page; the role’s details can be managed/configured in the Role panel.

Roles_Panel.png

In the Role panel, you can perform the following actions:

  • Remove a role

  • Add or remove a role from Global Roles

  • Manage the grants / permissions assigned to a role

  • Assign or remove a role from a user

Assigning Users / Roles via the GBDI Home Page

There are two ways to assign a role to a user (and vice versa) via the Authorization Management page:

  • Selecting from the drop-down menu

  • Using the Drag-and-Drop feature

To assign a role to a user via the drop-down menu:

  1. On the Roles Management tab, click the name of a role. The Role panel will open on the right side of the page.

  2. Under Users with this role, click the Users dropdown menu (highlighted below).

    role_users1.png
  3. From the dropdown list, select a user.

  4. Click the + button next to the dropdown menu to assign the role to the user.

To assign a Role to a User via Drag-and-Drop:

  1. On the Roles Management tab, click the name of a role. The Role panel will open on the right side of the page.

  2. Click the Users Management tab in the left panel of the page. This will reopen Users Management tab without closing the Role panel on the right side of the page. (To ensure the Role panel remains open, do not click anything inside the Users Management tab.)

  3. Hover the cursor over the Role panel (on the right side of the page). The drag me icon (highlighted below) will appear in the top left corner of the Role panel.

    role_users2.png
  4. Click and hold the drag me icon.

  5. In the Users Management tab, the Drag and Drop column will display the following message for each user in the list: “Drop here to add role” (highlighted below).

    role_users3.png
  6. While still holding the drag me icon (which will temporarily become a drop me icon), drag your cursor to a user's cell in the Drag and Drop column.

  7. Release the drop me icon onto the user's cell. The role is now assigned to the user.

Note

You can also perform the reverse of the procedure described above, i.e. click and hold the user’s Drag and Drop column cell and drag and drop it into the Role panel. (When you click and hold the user’s Drag and Drop column cell, the Role panel will display a “Drop here to add user” message.)

To assign a User to a Role using Drag-and-Drop:

  1. On the Users Management tab, click a role. The User panel will open on the right side of the page.

  2. Click the Roles Management tab in the left panel of the page.

  3. Hover the cursor over the User panel (on the right side of the page). The drag me icon will appear in the top left corner of the User panel. 

  4. Click and hold the drag me icon.

  5. In the Roles Management tab, the Drag and Drop column will display the following message for each user in the list: “Drop here to add user”.

  6. Click and hold the drag me icon to the Drag and Drop column and drop it into the cell of the a role.

Application Roles

The following predefined application roles are listed in the Roles Management tab as part of the GBDI installation:

Role

Description

SonarCloudAdmin

Allows access to Cloud Sources Management and Cloud Storage Lifecycle Management.On the Cloud Sources Management page, users with this role can add, view and manage cloud sources such as AWS S3, Azure Event Hub, Google Pub/Sub, MongoDB Atlas and Splunk.

On the Cloud Storage Lifecycle Management page, users can manage retention and purge policies on local and cloud data. This includes determining when to transfer data from hot to cold storage, and when to fully purge data in compliance with privacy laws.

SonarCloudUser

Allows access to Cloud Sources Management.

On the Cloud Sources Management page, users with this role have read-only access to existing cloud sources. This role can view the details and current status of each cloud source.

SonarG

The default application role for standard users.

In a SonarG installation, this role allows access to Dashboards, JSON Studio, Playbooks, Reports, Scheduled Jobs, SonarK, and Workflows.

With this role, users can:

  • Create visualizations, graphs and timelions in SonarK

  • Build pipelines and analyze data

  • Create reports and dashboards

  • Manage scheduled and dispatched jobs

  • View and work on Workflow tickets

  • Manage and run playbook

In a SonarC installation, this role also allows access to Security 360 and Enrich.

  • Aggregate and analyze data from multiple collections

  • Create collection enrichments

SonarKibana

Allows access to SonarK.

In SonarK, users with this role have full access to Kibana objects and settings:

  • Index patterns

  • Visualizations

  • Dashboards

  • Timelions

  • Drill downs

SonarKibanaReadOnly

Allows access to SonarK.

In SonarK, users with this role have read-only access to Kibana objects and settings.

SystemAdmin

Allows access to Cloud Storage Lifecycle Management.On the Cloud Storage Lifecycle Management page, users can manage retention and purge policies on local and cloud data. This includes determining when to transfer data from hot to cold storage, and when to fully purge data in compliance with privacy laws.

UserAdmin

Users with this role will have access to the Users Management, Roles Management and DLS - Data Level Security tabs. This role controls user level permissions.

WorkflowManager

Allows access to Justify Workflows.In Justify Workflows, users with this role have full access to workflows, tickets, and permissions. Each workflow has its own set of permissions which cannot be configured from Users/Roles. In order to perform actions such as generating, viewing and transitioning a ticket, workflow permissions must be configured for active users, including the WorkflowManager.

WorkflowUser

Allows access to Justify Workflows. In Justify Workflows, users with this role have limited access to workflows and tickets. The following is a list of actions allowed by these users:

Note

Users with this role will also require workflow permissions.

  • Access "Table Board" and "Search Tickets" tabs

  • View, self-assign, work on, and transition tickets

jsonStudioAccess

In a SonarG installation, this role allows access to JSON Studio, Reports, Engines, and Scheduled Jobs. 

With this role, users can:

  • Build pipelines and analyze data

  • Create reports and dashboards

  • Manage scheduled and dispatched jobs

For SonarC installations, this role also allows access to Digital Trust:

  • Analyze data for instances of trusted entities

In addition to general access control, the special database role jsonStudioAccess provides control over who may and edit queries using JSON Studio. To allow a user these abilities, add the jsonStudioAccess role on the admin database to a user. The database role is part of the default SonarGUser database role, but not part of the read-only SonarGROUser database role.

Global Roles

Any role marked as a Global role applies to all users by default;  it is unnecessary to assign Global roles to users. Setting and removing Global roles can be done via the Role panel.

Note

Some predefined roles included in the GBDI installation are set as Global roles by default. It is recommended that these roles are not removed until the system administrator is familiar with managing roles / grants in GBDI.

Database Roles

Database roles control the level of data access within a database. A user can have multiple database roles for the same database. These roles can be applied to a user through the Authorization Management page by first selecting a user. In the Database Roles section, provide a Database Name and then add a Database Role.

Many of the database roles are the same as their respective roles in MongoDB. (See https://docs.mongodb.com/v3.6/reference/built-in-roles/)

Note

Some roles listed in the above link may appear to be unavailable via the Authorization Management UI, but can be manually applied to users through the mongo shell.

GBDI also comes with several predefined database roles:

Role

Description

dlsAdmin

Provides access to system.dls collection, which is needed to apply Data Level Security filters.

dlsExcluded

Users with this role are unaffected by DLS rules.

jsonStudioAccess

Provides JSON Studio access to build and edit pipelines.

Added to sonarGUser role by default.

Exclusive to admin database.

sonarGROUser

Exclusive to admin database.

SonarGUser

Exclusive to admin database.

sonarSqlUser

Exclusive to admin database.

storageAdmin

Provides ability to manage purge and recompress schedules.

Passwords

Password Complexity

Passwords need to conform to password complexity configuration. Password complexity configuration is stored in web.xml as per the following parameters:

  • sonarg.pwdExpiration – Interval in months requiring a password change (default is 2)

  • sonarg.pwdComplexity – Required composition of password (default requires an uppercase letter, a lowercase letter, a digit and a special character)

  • sonarg.pwdLength – Minimum length (default is 8)

Changing Passwords

Users can change their own passwords via the GBDI Home Page.

The user administrator can change a user’s password via the Authorization Management page on the GBDI Home Page. (See Managing Users via the GBDI Home Page.)

Passwords can also be changed via the command line interface (CLI) / Mongo shell. (Using the GBDI Home Page is the preferred method.) To change a password via the CLI / Mongo shell, run the following command:

mongo localhost:27117/admin -u<your username> -p 

Next, run the following command in the Mongo shell:

> db.changeUserPassword("<username>", "<new password>") 

Resetting admin password

If you forget the admin password for SonarW, you will need to reset it:

  • Shut down SonarW (e.g. sudo service sonard stop)

  • Edit /etc/sonarw.conf and change to auth=false

  • Start SonarW (e.g. sudo service sonard start)

  • Login to SonarW with no password:

    ubuntu@ip-172-30-0-82:~$ mongo localhost:27117/admin 
    MongoDB shell version: 2.6.1 
    connecting to: localhost:27117/admin
  • Change the password:

    > db.changeUserPassword("admin", "<new password>");
  • Shut down SonarW (e.g. sudo service sonard stop)

  • Edit /etc/sonarw.conf and change to auth=true

  • Start SonarW (e.g. sudo service sonard start)

To reset/change the root password for SonarSQL you need to ssh to the GBDI host and run:

sudo sonarsql-setup setup

Restart the sonarsql service after making the changes.

Creating Users for SQL Access

Use a mysql client to login to SonarSQL using the SonarSQL root account you created when installing the software. When logged in as root, you can create new users in your MySQL client using:

CREATE USER '<user>' IDENTIFIED BY PASSWORD '<password>'

Unlocking secAdmin User

Any user, including secAdmin, will be locked upon entering an incorrect password at the GBDI login screen five times. While other users can be unlocked through the GBDI Home Page by a secAdmin user (via the Users/Roles button on the Administration panel on the GBDI Home Page), secAdmin itself must be unlocked through the mongo shell.

Locked users are specified in the locked_users collection in the admin database:

> use admin
> db.locked_users.find()

Deleting a user's document from this collection will unlock the user; to unlock secAdmin, run the following command in the mongo shell:

> db.locked_users.remove({"username":"secAdmin"})

Managing Role Grants

Each role is granted privilege to a specific set of dashboards, reports and pages in the GBDI Application. A role’s grants can be managed via the Authorization Management (Users/Roles) page in the GBDI Application.

Note

Changes made to a role’s grants will apply to all users with that role.

To manage a role’s grants:

On the Authorization Management page, click the Roles Management tab.

  1. To select a role, click its name. The Role panel will open on the right side of the page; the privileges currently assigned to the selected role are displayed under “Current grants.” 

  2. Click the Manage button (highlighted below).

    manage-button.png

    The Manage Role Grants panel will open, displaying a list of all grants alphabetically by category, as shown below. Checked boxes indicate current grants; unchecked boxes indicate privileges that haven't been granted to the role.

    grants-list.png
  3. Scroll through the list of grants, or use the search bar (highlighted below) to filter the list.

    search-grants-1.png
  4. Choose grants to be added or removed:

    • Use the checkboxes to select and/or deselect grants, or

    • Select “All Grants” to add every available grant to a role.

      Note

      Selecting "All Grants" assigns every grant to a role in perpetuity, including any grants added to the list at a later date.

  5. When finished adding or removing grants, click the Save button.

  6. The Manage Role Grants panel will close, and the updated list of the role’s current grants will appear in the Role panel.

Editing Grant Options

In the Manage Role Grants panel, grants that include a List icon (highlighted below) can be edited to change the options of the grant.

search-grants-2.png

For example, if a role is granted privilege to read index patterns in SonarK, you can edit the grant options to specify which index patterns can be accessed.

To edit grant options:

  1. Click the List icon beside a grant. The Edit Grant Options window will open, as shown below.

    search-grants-3.png
  2. Enter a new grant option and click the + icon to add it.

  3. Enter new options (adding them via the + icon), as needed.

  4. To delete an option from a grant, click the small x icon located beside the grant option.

  5. Click Ok to apply the options to the grant. (To cancel the current edit operation, click the large X in the top right corner of the Edit Grant Options window.)

Users Management Grant Options

Regex options are available for the Users Management grant (located under the Users, Roles and Access management category in the Manage Role Grants panel):

  • Use * for variable values.

  • Use +/- to include/exclude.

  • Options are prioritized by order.

For example, [ "-*admin*", "+*user*", "+test", "-*" ] will include or exclude users in following order:

  1. Users with admin in their names will be excluded,

  2. Users with user in their names will be included,

  3. User named test will be included, and

  4. All other users (i.e. with names that don't match the previous options) will be excluded.

Data Level Security (DLS)

The default GBDI setup is based on users and roles for security. Users may have custom privileges for each data set. More advanced setup is possible, using data level security (DLS) rules. DLS applies filters so that even though two users may have the same roles and access to the same data/report, each will receive different data based on the filtering policy. This is transparent (i.e. the user is not aware that the filter is being applied).

There are four default DLS modes supported out-of-the box in GBDI, accessible from the DLS - Data Level Security tab on the Authorization Management page:

  • None / Disabled – No DLS rules are applied. (This is the default.)

  • Based on Source – Map a user's access to data based on the collector.

  • Based on Server IP – Map a user's access to data based on the IP address related to the data source, e.g. the IP address of the database server being monitored.

  • Custom Rules – Map a user's access to data based on defined custom rule(s).

dls.png

Note

In SonarC, explicit rules need to be built depending on which data is sourced.

Applying DLS

When DLS is enabled, it can be applied to all users, or a specific set of users (DLS filtering). In the DLS - Data Level Security tab on the Authorization Management page (under Apply DLS to:), choose one of these options:

  • To apply DLS filtering to all users, select "All Users" and click Save.

  • To apply DLS to only a specific set of users, select "Named Users" and select users from the table.

Additionally, DLS rules can be created to provide more refined filtering with the DLS capabilities built into SonarW. Consult your GBDI account manager for details about building a DLS-based implementation.

Deploying DLS

When deploying GBDI using each of the three built-in DLS modes, you need to define what each user is able to see, using collections that need to be populated in GBDI. These collections can be populated through incoming CSV files, through dispatcher pulls from LDAP, through dispatcher pulls from an RDBMS, or through a push into GBDI using your own interface.

When implementing DLS based on source, a collection named dls_source needs to be populated in sonargd. Each document in this collection appears as shown below:

{"u" : "jane", "SonarG Source" : "gibm32" }

When implementing DLS based on IP, a collection named dls_ip needs to be populatedin sonargd. Each document in this collection appears as shown below:

{"u" : "jane", "Server_IP" : "10.10.1.2" }

When implementing DLS based on Custom Rules, a collection named system.dls needs to be populated in sonargd. Each document in this collection appears as shown below: 

{ "collection" : "name", "user" : "jane", "filter" : "{custom_expression1, custom_expression2, ...}" }

When implementing source-based DLS, the sonargd data collections are filtered as shown below:

"buff_usage",
"classifier",
"databases_discovered",
"datasources",
"discovered_instances",
"dm_extraction_log",
"exception",
"full_sql",
"grdm",
"grdmcomplete",
"grdmrec",
"installed_patches",
"instance" ,
"outliers_list",
"outliers_summary",
"policy_violations",
"session",
"stap_status",
"va"

SAGE data is not filtered in this case.

When implementing IP-based DLS:

  • The following data collections in sonargd are filtered as shown below:

    "databases_discovered",
    "exception",
    "full_sql",
    "instance" ,
    "outliers_list",
    "outliers_summary",
    "policy_violations",
    "session"
  • The following data collections in SAGE are filtered as shown below:

    "ae_dt" (signature)
    "ae_dt_queries" (query signatures)
    "ae_pr" (profile)
    "ae_pr_new" (profile by time)
    "db360" (DB 360 data)

When applying Custom Rules-based DLS, the “collection” field for each rule in system.dls needs to be defined.

Note

When using DLS, reports scheduled and delivered through the dispatcher propagate the user who scheduled the report (i.e. the dispatcher runs the reports on behalf of the user that scheduled the report and assumes that user's permissions). This is called the proxy user. This also means that in DLS environments, the user responsible for dispatching must have the setUser role (this is not assigned by default and needs to be added during the implementation).

Notice

Deleting a user with jobs already scheduled does not prevent the dispatcher from continuing to use that proxy user. If a DLS configuration is active for ALL users, these jobs will return results that are still filtered; if you specified that only named users are filtered, these jobs will now run unfiltered. If DNS is enabled, it is recommended that users not be deleted while they have jobs scheduled.

Synchronizing GBDI with LDAP

There are two synchronization options available between GBDI with Lightweight Directory Access Protocol (LDAP):

  • Synchronize Data between LDAP and a collection in SonarW

  • Synchronize users

The synchronization is handled by the SonarDispatcher.

Data synchronization:

  • The process will import new and update existing documents in the target collection.

  • In order to delete the “d=” variable must be set. The delete statement is executed independently from the LDAP query, therefore it cannot use any fields or values retrieved by it.

  • The delete is executed prior to any update to the collection.

Example: {“ou”: “sonar1”} (will delete all documents adhering to this condition)

Synchronizing users:

  • Removes any existing users if they no longer belong to any of the mapped groups.

  • Adds new users.

  • Updates existing users if they change group association.

Configuring the synchronization

Configure the LDAP information to be used:

  1. Edit the sonardispatcher.conf file (/opt/sonarfinder/sonarFinder/dispatcher.conf).

  2. Go to the [ldap] section and set the next variables:

    useradmin_username=
    useradmin_password=
    useradmin_uri=
    #(change CN, DC to match your LDAP settings)
    ldap_username=CN=Administrator,CN=Users,DC=sonar1,DC=local 
    #(change to match your LDAP settings)
    ldap_password= 
    #(change to the actual LDAP IP)
    ldap_address=192.168.1.0 
    #(change OU, DC to match  your LDAP settings)
    ldap_base=OU=jsonar-ou,DC=sonar1,DC=local 
    #(Change to match the required LDAP query)
    ldap_query=(objectClass=user) 
    
    # Support CN, sAMAccountName and userPrincipalName
    ldap_identify_field=
    max_query_cycles=1000000
    
    sonar_db=MyDB (Change to your target DB)
    sonar_coll=ldap_test (Change to your target Collection)
    #(Change to user with write permission to “sonar_db.sonar_coll”)
    sonar_username= 
    sonar_password=
    sonar_keyfile=
    sonar_authdb=admin (Change to the relevant authentication DB)
    # JSON query from Sonar
    q={"cn": "$$cn"}
    u={"cn": "$$cn", "manager": "$$manager"}
    d=
    upsert=true
    multi=true
    group_mapping=

Legend:

The following parameters are required only if Synchronizing users in GBDI based on LDAP groups. Leave these values empty if users are not being synchronized.

ldap_identify_field= one of: sAMAccountName, CN,  userPrincipalName
   (Note: this will be the username users will login with)

group_mapping - maping between LDAP groups and SonarW roles.
   Single Line Example:
     {"read_group": [{"db":"admin", "role":"sonarGROUser"}], "readwrite_group": 
     [{"db": "admin", "role":"sonarGUser"}]}

The mapping can includes multiple entries, each entry maps a single LDAP-group to one or more Sonar-roles. The syntax: “LDAP group name” : [{“db”: “db where the role is defined”, “role”: “Name of role”}, {“db”: “db where the role is defined”, “role”: “Name of role”}]

Base parameters: :

ldap_username - LDAP server user with query permissions
ldap_password - Password for authenticating against the LDAP server
ldap_address - IP address (or domain name) of the LDAP server
ldap_base - the “location/branch” on the LDAP server to query against
ldap_query - the query to run against the LDAP server w
max_query_cycles - max number of data retrieve cycles from LDAP 
# (each cycle brings 1 "page" of records as defined on the LDAP server, in most cases...  
# ...LDAPO servers are set to return 1,000 records per page).
sonar_db - DB in Sonar where the LDAP user info be saved 
sonar_col - the Collection within sonar_db where the LDAP user info be saved.
Note: sonar_db & sonar_col need to be created by the system admin 
sonar_username – user to be used for updating the data in sonar
sonar_password – Password for sonar_username
sonar_keyfile - can be used instead of password 
q - query to run against sonar_col to retrieve user data from previous runs
u - the update statement to be executed against the  sonar_col
d - Delete statement to be executed against the  sonar_col 
upsert - set to True, for updating existing users and inserting new users
multi - set to True, to ensure all records of each user are updated.

Syntax for queries: (q & u):

{“Key to query”: “$$Variable returned from LDAP query”}

Example: q={"cn": "$$cn"}

  1. Save and exit.

  2. Restart the sonardispatcher service.

You can add more than one section to the dispatcher.conf, and each could do a different task.

Example 1: Importing data from LDAP

The following configuration imports users’ information from LDAP and saves it to the ldap_users collection in the sonargd DB. The fields to be populated are: name, manager, first_name, last_name, email, groups, title. Data already in the collection will not be deleted.

[ldap]
useradmin_username=
useradmin_password=
useradmin_uri=
ldap_username=CN=Administrator,CN=Users,DC=sonar1,DC=local
ldap_password=ldapPassword
ldap_address=192.168.4.222
ldap_base=ou=jsonar-ou,dc=sonar1,dc=local
ldap_query=(objectClass=user)

# Support CN, sAMAccountName and userPrincipalName
ldap_identify_field=
max_query_cycles=1000000

sonar_db=sonargd
sonar_coll=ldap_users
sonar_username=User1
sonar_password=Password1
sonar_keyfile=
sonar_authdb=admin
# JSON query from Sonar
q={"name": "$$cn"}
u={"name":"$$cn", "manager":"$$manager","first_name": "$$givenName", "last_name": 
"$$sn", "email": "$$mail", "groups": "$$memberOf", "title": "$$title"}
# ensure the above is a single line
d=
upsert=true
multi=true
group_mapping=

Example 2: Synchronizing LDAP users

The following configuration imports users belonging to the readwrite_group, read_group and owners_group into the ldap_users collection in the sonargd DB. The fields to be populated are: CN and name. Users belonging to the groups: owners_group, read_group and readwrite_group will be granted access to GBDI based on the following mapping:

owners_group{"db": "admin", "role":"root"} & {"db": "admin", "role": "userAdmin"}

read_group{"db": "admin", "role":"sonarGROUser"}

readwrite_group{"db": "admin", "role":"sonarGUser"}

[ldap_users]
useradmin_username=User3
useradmin_password=Password3
useradmin_uri=
ldap_username=CN=Administrator,CN=Users,DC=sonar1,DC=local
ldap_password=ldapPassword
ldap_address=192.168.4.222
ldap_base=ou=jsonar-ou,dc=sonar1,dc=local
ldap_query=(&(objectClass=user)(|(memberof=CN=readwrite_group, OU=jsonar-ou,DC=sonar1,
DC=local)(memberof=CN=read_group, OU=jsonar-ou,DC=sonar1,DC=local)
(memberof=CN=owners_group, OU=jsonar-ou,DC=sonar1,DC=local)))
    #ensure the ldap_query is on a single line
# Support CN, sAMAccountName and userPrincipalName
ldap_identify_field=sAMAccountName
max_query_cycles=1000000

sonar_db=sonargd
sonar_coll=ldap_users
sonar_username=User2
sonar_password=Password2
sonar_keyfile=
sonar_authdb=admin

# JSON query from Sonar
q={"name": "$$cn"}
u={"CN":"$$cn", "name":"$$name"}
d=
upsert=true
multi=true
group_mapping={"CN=owners_group,ou=jsonar-ou,dc=sonar1,dc=local": [{"db": "admin",
"role":"root"}, {"db": "admin", "role": "userAdmin"}], "CN=read_group,ou=jsonar-ou,
dc=sonar1,dc=local": [{"db": "admin", "role":"sonarGROUser"}],  "CN=readwrite_group,
ou=jsonar-ou,dc=sonar1,dc=local": [{"db": "admin", "role":"sonarGUser"}]}
#ensure the group_mapping is on a single line

Note

You must specify the full ldap path to the group in the mapping.

Importing LDAP Users from a SonarW Collection

In instances where the GBDI server cannot query the LDAP source, LDAP users can be imported from a SonarW. In this scenario, users must first be exported to the SonarW collection by a separate process before being imported into the GBDI user management system.

As an example, the following is was provided and inserted into the collection:

"Login Name" : <Username>, 
"First Name" : <first name>, 
"Last Name" : <last name>,     
"EMAIL Address" : <email address>,     
"Role" : <ldap group>, 
"GBDI Source" : <sonarg source>

In this example, the configuration section for the LDAP import will contain the following fields:

[ldap_2]
sonar_username_convert_to_lowercase=True (Optional)
import_users_db=<database>
import_users_collection=<collection>
# JSON query from Sonar
group_mapping={"read_group": [{"db": "admin", "role":"sonarGROUser"}],"owner_group":[ {"db": "admin", "role": "sonarGROUser"},{"db":"admin", "role" : "readWrite"}]}
group_app_roles_mapping ={"read_group": ["sonarG","WorkflowManager"], "owner_group": ["sonarG", "userAdmin","WorkflowUser"]}

Save the dispatcher.conf file, restart the sonardispatcher service for the change to take effect, and then run a job that includes the LDAP target (under the Integration tab). In this example, the target is "ldap_2".

eMail Syncronization

When synchronizing LDAP users, the system will also import the email addresses of all LDAP users, and add them to the lmrm__users_email collection in the sonargd DB. The emails will be used to map users to email addresses.

Schedule synchronization

To schedule a synchronization, click the Schedules icon on the GBDI Home Page and schedule a new job.

Under the Main tab, set the job frequency as required and provide a name. Under the Integration tab, set the “LDAP Target” field to the “section” name, as defined in the configuration.

new_job.png

Encryption of Data-at-Rest

GBDI supports three encryption options:

  • When running in the cloud, you may use the cloud provider's encryption options.

  • Using Linux full-disk encryption.

  • Using GBDI's built-in encryption option.

When relying on encryption, you have three further options:

  • KMIP configuration

  • Manual key entry

  • One time key entry

Option (1) requires a KMIP-capable key-management solution. GBDI setup asks for all parameters and saves the information in pykmip.conf and in the sonard-setup-encryption config file.

Options (2) and (3) require the administrator to enter a key directly – option (2) every time the server is booted and option (3) only once. In option (3) setup saves the password locally so that GBDI may be used after a reboot without an operator. This is the simplest but least secure option, as the password persists on the computer hard drive.

For options (1) and (2), the user needs to run the sonard-setup-encryption script on every machine reboot and provide the password for the key generation or for the KMIP server access . Both these options are more secure than option (3).

Note that GBDI's data repository (SonarW) refuses to start if there’s a sonard-setup-encryption configuration and no encryption key on the system RAMDisk. In this case, a message is printed in the syslog.

For more information on setting up the keys for SonarW see http://sonarwdocs.jsonar.com/latest/encrypt.html