SyferLock Help Center

GridGuard Administration & Configuration Console Guide

1. Introduction

This documentation describes how to use the GridGuard Administration & Configuration Console (ACC) application provided with GridGuard Application. The ACC allows administrators to configure the GridGuard application via a web interface.

2. General Configuration

2.1. Accessing the ACC

Accessing the ACC

The ACC can be accessed through a browser from any machine on the network using the URL https://grid.company.com:8443/admin, where grid.company.com is the hostname of the GridGuard server.

You will be prompted to enter a username and password. The username by default is ‘gridadmin’. The password is the one specified during the setup of the GridGuard server. Once a good username and password is specified, a page similar to the one shown above will be displayed.

While loading the tool, a warning about an invalid SSL Certificate might be displayed. This is because the certificate that is installed on the GridGuard server by default is a self-signed certificate. This should be replaced with a valid certificate issued by a CA. For instructions on how to install a valid certificate, please refer to the GridGuard Installation Guide.

3. License & User Management

3.1. Current License Information

Current License Information

To view details of the currently installed license, navigate to section \L \ License & User Management > License Management > Current License Information

3.2. Purging Inactive Users

Purging Inactive Users

Periodically it might be necessary to purge inactive / invalid users who might no longer be using the system. To facilitate this process, the system provides an automated method to purge inactive users. To access this feature, navigate to section\L License & User Management > License Management > Purge Inactive Users

Inactive users are determined by using the following algorithm:

for each (realm) {
\L        for each (registered user) {
\L            if (user is not found in userStore associated realm) {
\L                Purge user
\L            }
\L        }
\L \   }

Depending on the number of registered users and the performance of the userStore, this process might run for a few minutes.

3.3. Importing / Updating Licenses

Importing / Updating Licenses

To import a new license into the system or update an existing license, navigate to section\L License & User Management > License Management > New License Information

Note: After new license is applied, the gridserver service must be restarted for the new license to take effect.

 

3.4. Notifications of License Expiration

Notifications of License Expiration

The license expiration notification section can be setup to send notification emails to a system administrator (or a distribution group) to notify them of an expiring GridGuard license or when the number of available licenses for new users falls below a certain threshold.

3.5. User Management

User Management

Users currently registered with the GridGuard system can be viewed by switching to the ‘User Management’ tab.

The tab shows you the total number of registered users in the system across all user stores. \L Note: If the same username is used in 2 separate user stores (e.g., Active Directory and a SQL Server database), it will count as 2 separate and distinct user licenses.

To unregister an existing user from the system,

Select the check mark next to the entry for the user(s)

Click the ‘Unregister Selected Users’ button

Unregistering a user does not delete the user from the target user store. It simply unregisters them from the GridGuard system. Once a user is unregistered, if they try to access the GridGuard system, if they are still an active user in the target user store, they will be able to re-register and access the system. If they are no longer an active user in the target user store, they will not be able to register to use the GridGuard system.

4. Configuring Encryption Keys

Configuring Encryption Keys

GridGuard encrypts and stores the sensitive user information in encrypted persistent data stores. All encryption is handled through the use of encryption keys: AES-128 or AES-256 keys for symmetric encryptions and RSA-2048 or RSA-4096 keys for asymmetric encryptions. The keys required for these encryptions can be generated through the ACC by using the ‘Encryption Keys’ option.

The ‘Encryption Keys In Use’ section lists the encryption keys currently being used to encrypt data.\L The ‘Generate New Encryption Keys’ section can be used to generate new keys.\L The ‘Import Encryption Keys’ section can be used to import a key that has previously been exported from another GridGuard server.

Symmetric keys are used to store encrypted information to the OpenLDAP server running on the GridGuard Virtual Appliance. Since all of the data is only written and read by the OpenLDAP server, and since the encrypted data is never accessed directly by any external process, a symmetric key meets all required encryption specifications.

When an encryption key is set as the nonce encryption key, all existing realms are also re-configured to use the key as the proxy cryptographic key.

Asymmetric keys are used to encrypt data in external data stores like Active Directory (in a GridAdvanced configuration). The private keys cannot be exported from the GridGuard server. Only the public keys can be exported; and they should be loaded onto the external data store to encrypt the data. This will ensure that only GridGuard can decrypt the data that has been encrypted on the external data store.

It is very highly recommended from a security standpoint, to use separate keys for OpenLDAP and external data source encryption.

5. Service Management

Service Management

GridGuard services can be managed through the ‘Service Management’ option. The option allows the administrator to specify what services should be started on machine boot up, and also allows the administrator to start, stop & restart services.

6. System Management

The ‘System Management’ option provides system level functions for managing the GridGuard server including backups and restores, system monitoring and system startup/shutdown. The functions are detailed below.

6.1. Importing & Exporting Realm Configuration

Importing & Exporting Realm Configuration

Use the ‘Configuration Settings’ tab to export and import the realm configuration file (config.xml). This is the single file that contains all the Encryption key, Server, Store and Realm configuration.

When exporting config.xml, all encryption keys must also be separately downloaded. The encryption keys will need to be imported first into the target system, before the configuration file is imported.

6.2. ACC Authentication

ACC Authentication

The ‘ACC Authentication’ tab provides the ability to setup ACC authentication using an external LDAP or Active Directory Server.  The built-in authentication method using the gridadmin password will always be available; but this provides the ability to allow additional users to log into the ACC using their LDAP or Active Directory credentials.

6.3. SNMP Configuration

SNMP Configuration

The GridGuard system can be monitored via SNMP. The system currently only supports the SNMP v2c protocol.

6.4. System Shutdown & Restart

System Shutdown & Restart

Use this tab to shut down and restart the GridGuard system.

7. Cluster Management

This option allows for setup and configuration of a GridGuard in a cluster. Clustering allows for setup of multiple servers for load balancing, fail over and high availability scenarios. All LDAP data is synchronized across the servers and every server can be used to authenticate users.

While setting up a cluster, the basic process to follow is to

Designate one of the servers as a primary server

Shutdown slapd & slapd-proxy services on all nodes except the primary server

Launch ACC on the primary server and create a new cluster

To the primary server, add all the other servers as replication peers

On each of the other servers

Launch ACC and choose the option to join the cluster

Add each of the other servers as a replication peer

Start slapd & slapd-proxy services on the server

Once the servers have been setup in a cluster, all servers in the cluster will replicate LDAP data amongst themselves ensuring that all of the data is always synchronized with minimal latency.  All servers in the cluster are active and can process logins.

Note: When a server joins a cluster, all of the LDAP data on the server joining the cluster is deleted and refreshed with data from a server in the cluster.

If a server needs to be removed from the cluster, the process is as follows. It is important the follow the steps in the order listed below.

Launch ACC on each server in cluster replicating to the server to be removed and removing it from the list of replication peers

Launch ACC on the server to be removed and choose option to leave the cluster\L

The sections below provide details on creating, joining and leaving a cluster.

7.1. Creating a New Cluster

Creating a New Cluster

To create a new cluster, on the ‘Cluster Management’ tab, choose the option ‘Create new cluster’, provide a unique ‘Server Identifier’ and click the ‘Create new cluster’ button.

\L Then switch to the ‘Replication Peers’ tab and add new replication peers.

The list of replication peers is now updated to include the newly added peer.

Note: slapd & slapd-proxy service should be restarted after making any changes to cluster settings

7.2. Joining a Cluster

Joining a Cluster

To join a cluster, select the ‘Join an existing cluster’ option. On selection of the option, the preceding screen is displayed.

On clicking of the ‘Join an existing cluster’ button, the server will be joined to the cluster and the server specified as the remote host will be automatically added as a replication peer. To complete cluster setup, all other replication peers should now be added.

Note: Servers that are currently not part of the cluster, but are planned to be joined to the cluster, can be added as replication peers before they are joined to the cluster. When the server is eventually joined to the cluster, its replication peers will recognize it and start replicating to it.

7.3. Leaving a Cluster

Leaving a Cluster

To remove a server from a cluster, select the ‘Leave the cluster’ option

To complete the leave process, the server leaving the cluster should be removed from the list of ‘Replication Peers’ from all other servers in the cluster.

8. System Backup & Restore Capabilities

Administrators can take system backups & restore system from previously taken backups using the ‘Backups & Restores’ option.

8.1. System Backup / Restore

System Backup / Restore

8.2. Backup Encryption Setting

Backup Encryption Setting

This option can be used to change the passphrase used to encrypt backups.

IMPORTANT NOTE: When restoring a backup, the system will attempt to decrypt the backup file using this passphrase. So if the passphrase has been changed since the time the backup was taken, then the passphrase will need to be reset to the passphrase at the time the backup was taken, before the restore can be attempted.

8.3. Automated Backups

Automated Backups

This option can be used to schedule automated backups

9. Certificates

The ‘Certificates’ option allows for configuration of Certificate Authorities and import of certificates signed by trusted certificate authorities.

9.1. Manage Certificate Authorities

Use the ‘Manage CA’ option to install certificates for trusted Certificate Authorities and also view the list of currently installed trusted Certificate Authority Certificates.

9.2. Setup New Certificate Authority

Setup New Certificate Authority

9.3. Manage Certificate Authorities

Manage Certificate Authorities

This option displays the list of all currently installed Trusted Certificate Authorities. If the certificate you are installing is issued by a Certificate Authority that is not included in this list, you will need to import the certificate for the Trusted Certificate Authority using the ‘New Certificate Authority (CA) Setup’ process.

9.4. Manage Certificates

The GridGuard system allows you to install SSL certificates for 3 separate services:

  • GridGuard HTTPS Certificate – HTTPS requests to view web pages hosted on the server
  • Admin HTTPS Certificate – HTTPS requests to access the Administration & Configuration Console (ACC)
  • LDAPS Certificate – LDAP bind requests over SSL

Use the ‘Manage Certificates’ option to install a new certificate on the appliance or to update the existing certificate. The process for installing / updating certificates is the same for all 3 certificates. The instructions below apply to all three.

The process of installing of a new certificate involves the following steps:

  1. Generation of an encryption key
  2. Generating a CSR based on server and company information + the encryption key
  3. Provide CSR to a Certificate Authority (CA) and request an SSL Certificate
  4. Import SSL Certificate provided to you by the Certificate Authority.

To update certificates, follow steps 3 and 4 from above.

9.5. Encryption Keys

Encryption Keys

Allows administrators to generate keys, export current key or replace key with a newly imported one.

Note: Replacing the current key by re-generating the key or importing one will invalidate the existing CSR and installed certificate and will automatically install a self-signed certificate based on the new key.

9.6. Certificate Signing Requests (CSR)

Certificate Signing Requests (CSR)

Allows administrators to set CSR details and generate a CSR.

9.7. SSL Certificate

SSL Certificate

Allows administrators to import new SSL Certificates.

10. Password Validators

10.1. Adding a New Password Validator

Adding a New Password Validator

Complex rules can be enforced around passwords managed by the GridGuard system. This is accomplished by creating a password validator and associating the password validator with the realm.

A couple of important points to consider:

Only one password validator can be associated with a realm; though the same password validator can be associated with multiple realms.

In a 2 form configuration, password validator rules will only apply to the second form (i.e., password managed by GridGuard). The validation rules for the first form (typically Active Directory password) will have be enforced at the User store (Active Directory server) level.

To create a new password validator, right-click on ‘Password Validators’ and click ‘Add’.

10.2. Configuring a Password Validator

Configuring a Password Validator

11. Custom Keyboard Layouts

In addition to the standard keyboard layouts that are included in GridGuard, the system also allows administrators to define their own custom layouts. These layouts allow customers to define layouts with a different character set and also define how the symbols should be laid out.

11.1. Adding Custom Keyboard Layouts

Adding Custom Keyboard Layouts

To create a new custom keyboard layout, right-click on ‘Custom Keyboard Layouts’ and click ‘Add’.

11.2. Configuring Custom Keyboard Layouts

Configuring Custom Keyboard Layouts

Given above are the different fields that need to be set to create a new keyboard layout.

12. Configuring Servers

Server references are used to reference any server with which the GridGuard Virtual Appliance needs to interface. These servers might be servers internal to the GridGuard Virtual Appliance like the MySQL or OpenLDAP servers or external servers like a customer’s Active Directory server. The realm uses these server references to determine how to authenticate users, where to store user information and log user activity. This flexibility allows customers the ability to swap out internal GridGuard Virtual Appliance components (like the MySQL database) with external components (like an MSSQL database hosted on the customer’s database farm) without affecting the core authentication functionality.

Based on the type of server chosen (DB or LDAP), different server type specific fields are displayed.

All other fields displayed are conditional based on the ‘Server Type’ selected.

12.1. Adding a New Server

Adding a New Server

12.2. Adding a New Database (DB)

Adding a New Database (DB)

Given above are sample values for Database (DB) type of server references for a database.

12.3. Adding a New Non-Active Directory LDAP Server

Adding a New Non-Active Directory LDAP Server

Sample values for a non-Active Directory LDAP server (LDAP type is set to LDAP) are given above.

12.4. Adding a New Active Directory LDAP Server

Adding a New Active Directory LDAP Server

Sample values for an Active Directory LDAP server (LDAP type is set to LDAP_AD) are given above.

13. Configuring Stores

There are multiple kinds of data store references that can be configured within GridGuard. The different types that can be configured are:

gridStore – The type of store used to store generated grids

historyStore – The type of store used to log user & administrator activity

sessionStore – The type of store used to store browser sessions

nonceStore – The type of store used to store nonces. This is used in ‘Token Auth’ configurations.

userStore – The type of store that contains the list of valid users.

userInfoStore – The type of store used to store GridPass information like the target position, GridPIN, etc.

Each of these stores can be stored in different storage types. The choice of storage will be dependent on customer requirements. For example, user sessions can be stored either in memory or in a database. If stored in memory, performance is better, but if the server reboots, then the session is lost. If stored in a database, the sessions are persistent and are valid after shutdowns, but performance will be slower.

13.1. Custom Stores and Java Interfaces Needed

Custom Stores and Java Interfaces Needed

The different ‘Storage Types’ supported are:

Memory – The data is stored in memory on the GridGuard server. This type of storage is not persistent and will be lost across server reboots.

Database – The data is stored to a JDBC supported database.

LDAP – The data is stored to an LDAP server. LDAP here also includes Active Directory servers.

Custom – The data is stored using a custom data store. This is only required when the storage type is not one of the 3 given above. This may be the case of a store like a Message Queuing system or a database store that does not support standard SQL operations. To implement a custom storage type, customers will need to implement their own Java classes that implement the relevant interface as given above.

For details on how to implement these custom interfaces and sample code, please contact SyferLock Support.

13.2. Adding a New Store

Adding a New Store

To create a new store, click the ‘[new]’ button, and then provide the store details. Based on the type of store and storage type selected, attributes specific to the storage type are displayed.

13.3. Configuring Grid, History, Session and Nonce Stores

Configuring Grid, History, Session and Nonce Stores

For gridStores, historyStores, sessionStores and nonceStores, only the storage type and server reference need to be specified; no additional information is necessary.

13.4. Configuring User and UserInfo Stores

Configuring User and UserInfo Stores

For the user store and user info store, if ‘LDAP’ is the chosen server type, then the Base DN for locating all users will also need to be specified as shown above.

14. Realms

A realm specifies the conditions that users must meet to sign in via a GridGuard appliance. It is a grouping of resources including:

Stores – Grid stores, History stores, Session stores, Nonce stores, User stores and User Info stores

Encryption keys – Keys used to encrypt and decrypt sensitive data

Process type – Type of security product or portal authentication is being performed for

Options –  Options defining the type of authentication to be performed and features available

Mail server info – for sending out GridKeys

SAML server information – for integrating GridGuard with portals via SAML 2.0 protocol

User Groups  - Groups of users authorized to access application via the GridGuard appliance

Administrator Groups – Groups of users authorized to administer the GridGuard application

Every instance of an application that needs to be integrated with GridGuard should be configured via a separate realm. You can have any number of realms per GridGuard server. So the same GridGuard server can authenticate users to a Juniper appliance, an Outlook Web Access portal and a custom built web portal, all based on different criteria and authentication mechanisms.

Given below are explanations of the various tabs that need to be configured while setting up a GridGuard realm. This is a general description of the fields and properties that is applicable to all integrations. For details on settings that are specific to an appliance, refer to the appliance specific setup guides.

14.1. Adding a New Realm

Adding a New Realm

To add a new realm, right-click on ‘Realms’ and choose the ‘Add’ option.

14.2. General Tab

General Tab

On the ‘General Tab’, the above attributes can be set.

14.3. Options Tab

Options Tab

On the ‘Options Tab’, the above attributes can be set.

14.4. Cryptographic Options Tab

Cryptographic Options Tab

On the ‘Cryptographic Options Tab’, the above attributes can be set.

14.5. Fields Tab

Fields Tab

The fields on this page are used to define the name of the html elements in the login form that will reference the username and password fields. These fields are usually device / application specific. In a single form mode, only a single username and password field will be displayed; in 2Form, 2 sets of username and password fields will be shown.

If Grid2Form authentication is selected, there will be 2 instances of username and password that will need to be specified.

14.6. User Groups Tab

User Groups Tab

This tab is used to specify groups of users who are authorized to access the target application through GridGuard and also the group of users who will be classified as Administrators. These are groups that will be defined in the user store that is associated with the realm; so typically these are Active Directory Groups.

14.7. URLs Tab

URLs Tab

The URLs tab is used to specify key URLs that will be accessed during the login process. A description of the various URLs is given above.

14.8. Additional Options Tab

Additional Options Tab

The additional options tab is used to specify SMTP server and SAML server settings. SMTP server settings are used to send out GridKey information in emails. The SAML server information is required when GridGuard is used as a SAML 2.0 IDP. Details of the fields are given above.

14.9. Stores Tab

Stores Tab

This is the tab used to specify the various stores that will be used to reference. These store configurations are specific to the realm, even though the stores themselves can be used for multiple realms. For example, the history store might reference a MySQL database; multiple realms can use the same MySQL database as the history store. What this will mean is that history for multiple stores will get written out to the same database. So most times, determining what stores to access for what information is implementation specific and up to the customer to decide.  All stores referenced here must be setup as stores under the ‘Stores’ node as described in Section 13, ‘Configuring Stores’ section of this document.

A description of the various stores and what they are used for is given above.

14.10. Advanced Tab

Advanced Tab

15. GridRadius Setup

GridRadius Setup

This allows for configuration of the GridGuard RADIUS server, If the server is being setup to support the RADIUS protocol. Typically RADIUS support is required for GridSoftToken and GridApplet implementations.

The figure above shows the RADIUS setup screen.

Note: When RADIUS support is required, ensure that the ‘radiusd’ service is running and also setup to start on boot. This can be controlled through the ‘Service Management’ option.

16. LDAP Configuration

Provides administrators the ability to configure the GridGuard LDAP server. It provides the ability to add new whitelisted users, change the Root DN password, setup LDAP proxies, and manage LDAP Organizational Units (OUs).

16.1. General LDAP Configuration

General LDAP Configuration

16.2. LDAP Proxy Configuration

LDAP Proxy Configuration

This option allows administrators to configure the GridGuard server as an proxy to another LDAP or Active Directory Server.

16.3. LDAP Proxy OU Management

LDAP Proxy OU Management

This option allows administrators to add and delete User OUs as necessary.

17. Logging

This option can be used to view system log files, control logging levels and setup external syslog servers to which GridGuard logs can be written out to.

17.1. Log Configuration

Log Configuration

This option allows for setting of the logging levels and also to setup external sys log servers.

17.2. Log Viewer

Log Viewer

The log viewer option allows administrators to view local system logs for troubleshooting.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk