Appendix A - LDAP and LDAP Groups for Snare Central - User Information

Snare Central Server is capable of delegating user authentication and optionally group authorisation to an external LDAP or Active Directory server.

Configure LDAP

Authentication Mode

LDAP Web GUI authentication supports two operation modes:  user authentication only mode and user and group authentication mode. The mode is controlled by the  LDAP Groups  checkbox in the LDAP Setup section of the Configuration Wizard.

When LDAP Groups  is disabled, the GUI will redirect the authentication to the server and domain specified in the configuration. The user must still have an account on the Snare Server with the same name as the LDAP/AD user, in order to login, hence specifying DN is neither required nor allowed for users. The authentication will be carried out using the default username@DOMAIN (userPrincipalName) form.

When LDAP Groups is enabled, the GUI will not only authenticate the user, but will also confirm that the user belongs to one or more of the groups allowed to use the Snare Central Web GUI. This authentication is more flexible, and allows the DN to be specified. The Users DN  field, will be used to search for users under the specified OUs in order to bind and authenticate the user(s). At least two groups need to be available on the AD server, in order for this mode to work. This authentication mode is described in detail further in this document.

To configure LDAP authentication support, navigate to System | Administrative Tools | Configuration Wizard | LDAP Setup.

Trusted CA root Certificate subsection description:

This control allows you to install, update or remove trusted Root Certificates system wide. If you are required to authenticate users with LDAP/TLS or SASL/LDAP, you need to provide Snare Central with the CA root certificate of the authority that issued the LDAP server certificate.

If you are setting up a certificate authority for your organisation in order to build and use PEM certificates in-house, you need to make sure that Snare Central is configured to recognise and trust your CA.

It is also possible to load the certificate manually if required:

• Copy their PEM base64 encoded cert to the server either via SCP or open a vi session to a file and use cut and paste the base 64 encoded file
• mv testcert.pem /usr/local/share/ca-certificates/testcert.crt  - note the rename
• ​/usr/sbin/update-ca-certificates -v
• The refresh configuration wizard UI and it should show the new certificate loaded in the security tab in the configuration wizard.

LDAP Authentication subsection description:

• Enable LDAP - To enable LDAP select the checkbox. When enabled, all local Snare accounts will be temporarily disabled with the exception of the ADMINISTRATOR account, and all access to Snare will be authenticated and authorised from the LDAP server whether the user name exists as a Snare account or not.
• Protocol - Select from LDAP, LDAP/SSL, LDAP/TLS or SASL/TLS.  A CA root certificate is required for TLS, this will typically be from the Active Directory Domain internal certificate authority. 
• Server - The IP address or FQDN (Full Qualified Domain Name) of your LDAP/AD server. Please note that when using TLS, the administrator needs to make sure that the FQDN exactly aligns with the server name in the certificate, or authentication will fail.

• Domain - If specified, this Domain will be used for authentication. When the sAMAccountName option is enabled, the domain will be prepended to the to username using the DOMAIN\Username format. Otherwise, the Username@DOMAIN (User Principal Name) format will be used.

• Port - The LDAP server port.  Port 389 is the standard unencrypted port, however is used for TLS connections.
• Win Server 2012 R2 compatibility mode - Selecting this option will force a lower version of TLS. There is a known issue when trying to bind Snare Central to a MS Active Directory using LDAP/TLS on a Windows Server 2012 R2. OpenLDAP’s GnuTLS and Microsoft’s SChannel implementations are not compatible with TLS 1.2 negotiation during AD/LDAPS binding, therefore it’s necessary to disable TLS1.2 before attempting binding.
• Use SAM Account Name - If checked, this option instructs the LDAP authentication process to use the provided username as sAMAccounName rather than using it as a userPrincipalName (the default) in the initial login window of Snare Central. This means that when this option is selected the LDAP bind process will try to login a username using the DOMAIN\username format instead of the default username@DOMAIN form.
• LDAP Groups - Selecting this option, enables the authorisation of groups defined in the Active Directory server for Snare. Please note that when LDAP Groups option is enabled, all local accounts are temporarily disabled with the exception of the Administrator account. If enabled, any valid LDAP user that belongs to one or more of the Snare groups defined in the AD/LDAP server, will have access to Snare Central Web interface but will not be able to see any objectives until the correct access rights are granted to each objective.  This is set via the System | Administrative Tools | Manage Access Control configuration objective. 
• Super Group Name-  When LDAP Groups is enabled, a special group in the AD/LDAP server that will be used as the base for authentication is required. The default group name is Snare_Central however the user can change this default if required.
• Super Group DN- The complete distinguished name of the super group needs to be specified in this field.
• Users DN - When the users that need have access to the Snare Central server are distributed in different branches across the LDAP/AD hierarchy, the complete distinguished names of all the OU (Organizational Units or Containers) where the users reside must be specified for LDAP queries to work properly. If users are spread across different Organisational Units in your LDAP/AD server, add all the required User Distinguished Names in this list, one per line. All LDAP user queries will be sequentially executed in the order that they appear in this list.
• Test Authentication - This button is available to help verify that LDAP setup values are correct, verified by an overlay screen with a success or error message will be displayed to the user.

• Retrieve Groups- When the LDAP Groups option is enabled, this button is also available and it must be used to grab the related group info in the LDAP/AD server as part of LDAP configuration. Simply enter a valid LDAP Username and LDAP Password to retrieve the valid groups that are set. Valid usernames formats are user, user@domain or domain\username.

  
  

  Local Groups

  When LDAP Groups option is disabled the user must still have an account on the Snare Central Server with the same name as the one in LDAP/AD server, in order to login.

LDAP/AD Server Configuration for LDAP Groups

LDAP Groups support delegates both authentication and group access control on the Snare Central user interface, to your selected LDAP/AD server and the "Manage Access Control" tool manages the permissions for those groups inside Snare server. Before LDAP Groups support can be enabled, the AD/LDAP server needs to meet the following conditions:

• First, a super group needs to be created in the AD/LDAP server. By default the super group name is “Snare_Central” and by default  it shall be defined under the default Users OU or container. However this can be changed if required. This super group is a requirement as Snare Central server will search within this super group for all other Snare Server groups. For example, if the domain of the LDAP/AD server is domain.co, the Distinguished Name for the Snare_Central group has to be exactly "CN=Users,DC=domain,DC=co". However if another name or the location of this super group needs to be different, the administrator can change these values by updating the Super Group Name field and the Super Group DN fields.

• Snare Central Server can retrieve any number of groups required as long as they are defined in the LDAP server and they are all members of the super group and the super group DN is provided. Starting from version 8.6, any sub group member of a group that is member of the super group will also have access to the Snare central UI effectively providing nested group capability under the super group.

• Any user account belonging to (member of) any of the above groups will be granted access to Snare but will not have permission to access any Objective or Report until permissions have been given to a group via the “Manage Access Control” tool (see corresponding section further down).

• Users belonging directly to (that are member of) the super group will not have access to the user interface as this group is for group membership only. So no user should be member of super group.

• All password complexity and password expiry verification will need to be carried out in the LDAP server.

• If users are distributed across the whole AD/LDAP hierarchy, it may be necessary to add the full DN (Distinguished Name) of the OUs (Organizational Units or Containers) where the users are located. Add each OU as a single line in the Users DN field of the LDAP Setup section.
• Once the super group and all sub groups are specified in the AD/LDAP server and the Super Group Name and Super Group DN fields updated in the LDAP Setup section in the Snare Central server, the administrator need to retrieve the group information using the Retrieve Groups button and providing a valid user and password.
• As a final step, once all the LDAP authentication has been successfully configured, it is required to grant access rights to the LDAP group(s) inside Snare Central with the "Manage Access Control" tool.

Example

In this example, the Snare Central server is configured to forward user and group authentication to an Active Directory server. There are five Snare related groups with different privileges (not including the Snare_Central super group as it can not have users associated with it). There are nine different users that are members of one or more of these groups.

Please note how the users are spread across different Organisational Units (OU) in the AD server. In this scenario, we need to specify to the Snare Central server where in the LDAP hierarchy the users can be found. To achieve this, the Users DN field needs to include a list with all the Distinguished Names of the containers where the users are located. When a user tries to login, an LDAP background query is triggered to find the groups for which the user is member of. A query is made for each of the Distinguished Names defined in the above list (and in the same order) until a match is found.

Please note that the Users DN field is only useful when the LDAP Groups option is enabled. 

Once the groups of the user are found, and if at least on of those groups is member of the Snare_Central super group, then the access is granted.

In the following image, please note how the users and group are defined in the Active Directory hierarchy and how this defines their respective DNs:

The DNs and the membership of all involved users and groups are as follows:

Snare_Central super group

dn: CN=Snare_Central,CN=Users,DC=snaresub1,DC=snare,DC=ia
member: CN=Security Analists,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Snare Web Reports,OU=Marketing,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Snare Administrators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Snare Analists,OU=Provisioning Area,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Snare Operators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

Groups:

Snare Administrators

dn: CN=Snare Administrators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Miles Davis,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Wolfgang A. Mozart,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Kevin Mitnick,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Generic Developer1,OU=Server Development,OU=Development Area,DC=snaresub1,DC=snare,DC=ia

Security Analists

dn: CN=Security Analists,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Kevin Mitnick,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

Snare Analists

dn: CN=Snare Analists,OU=Provisioning Area,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Tonny Hawk,OU=Users,OU=Provisioning Area,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Generic Visitor,OU=Guests,DC=snaresub1,DC=snare,DC=ia

Snare Operators

dn: CN=Snare Operators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Miles Davis,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Billie Holday,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=Generic Developer2,OU=Agent Development,OU=Development Area,DC=snaresub1,DC=snare,DC=ia

Snare Web Reports

dn: CN=Snare Web Reports,OU=Marketing,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
member: CN=David Gilmour,OU=Users,OU=Marketing,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

Users:

developer one

dn: CN=Generic Developer1,OU=Server Development,OU=Development Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Administrators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

developer_two

dn: CN=Generic Developer2,OU=Agent Development,OU=Development Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Operators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

KMitnick

dn: CN=Kevin Mitnick,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Security Analists,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Administrators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

wmozart

dn: CN=Wolfgang A. Mozart,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Administrators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

bholiday

dn: CN=Billie Holday,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Operators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

miles

dn: CN=Miles Davis,OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Administrators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Operators,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

thawk

dn: CN=Tonny Hawk,OU=Users,OU=Provisioning Area,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Analists,OU=Provisioning Area,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

DGilmour

dn: CN=David Gilmour,OU=Users,OU=Marketing,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Web Reports,OU=Marketing,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

visitor-one

dn: CN=Generic Visitor,OU=Guests,DC=snaresub1,DC=snare,DC=ia
memberOf: CN=Snare Analists,OU=Provisioning Area,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia

To allow all of the nine users to have access to the Snare Central server UI, the value of the Users DN field shall be like this:

OU=Server Development,OU=Development Area,DC=snaresub1,DC=snare,DC=ia
OU=Agent Development,OU=Development Area,DC=snaresub1,DC=snare,DC=ia
OU=Users,OU=Security Assurance,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
OU=Users,OU=Provisioning Area,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
OU=Users,OU=Marketing,OU=Operations Area,DC=snaresub1,DC=snare,DC=ia
OU=Guests,DC=snaresub1,DC=snare,DC=ia

It is also valid to omit the domain part of the DNs as follows:

OU=Server Development,OU=Development Area
OU=Agent Development,OU=Development Area
OU=Users,OU=Security Assurance,OU=Operations Area
OU=Users,OU=Provisioning Area,OU=Operations Area
OU=Users,OU=Marketing,OU=Operations Area
OU=Guests

If last DN in the list is omitted, the visitor-one user will not be granted access to Snare as the server will not be able to find the user in the query.

The final setup for this example will look like this in the Snare Central UI:

Testing your setup.

The LDAP Setup provides the capability to test the authorisation and the group retrieval mechanisms. In order to be able to use this tool, first the values of the Server, Domain and Port fields need to be saved. If group retrieval is to be tested, the "LDAP Groups for Snare Central" need also to be enabled and saved. Once these fields are stored, a user and a password can be provided to verify that the authentication is working correctly. A panel with the result of the test query will pop-up.

In the following image the account attributes of the Generic Developer1 user are shown. Notice that the User Principal Name (UPN) is highlighted in green and it has the form username@domain. Also please notice that the sAMAccountName (developer one) along with the NetBios Name are shown and together they form a NetBIOS logon Name (DOMAIN\username) and is highlighted in blue.

The LDAP Username field in the Test section, accepts the user name in both UPN and SAM formats. Following the Generic Developer1 example, the value for this field could be:

developer one@snaresub1.snare.ia or SNARESUB1\developer one

The LDAP Username field also accepts just the username alone without any domain. When used like this, its behaviour depends on the value of the Use SAM Account Name checkbox. When enabled the authorisation test is performed using the DOMAIN\username otherwise the username@domain is used.

Manage Access Control

The Manage Access Control interface provides an easy and flexible tool for changing Objectives Access Rights at the group level for both local groups or LDAP defined groups.

Every objective on the Snare Central can be individually secured so that only authorised staff have access to it. Access is granted at group level; therefore, an LDAP user must be attached to an LDAP group in order to view or change an objective. This also applies to local users and groups. Manage Access Control detects if Snare is in LDAP mode or not, and will change access rights for objectives accordingly.

Please note that most objectives under the "Administrative Tools" and "Data Management Tools" are restricted for Administrators group exclusively. This is because of the security risks and potential of harm to the Snare Central server involved. This means that most of such objectives cannot be accessed by LDAP users nor by local users that do not belong to the Administrators local group. This also means that the "Manage Access Control" interface cannot be used to assign permissions to these administrative objectives either. The complete list of the Administrators only objectives is the following.

One of two access rights levels can be granted:

• Access permissions. This provides a user with read to view the output of this objective, and also regenerate the objective.

• Change permissions. This provides a user with the ability to change the configuration settings for the objective as well as view and regenerate the function. 

A single, multiple or complete tree structures of existing objectives are able to be selected, to add or delete “Access” permissions (Read access) and/or “Control” permissions (Write access) to those objectives for a group or set of groups.

By selecting in the Objective name (or Objective directory) at the tree representation on the left (see image above) will select or deselect the objective(s). Once selected, one or more groups are required to be highlighted from the list provided and at least one access level to be checked in order to apply to selected objectives.

In addition, users who create, or clone an objective, are identified as the owner of the objective. Both the owner, and Snare Server ADMINISTRATOR have the ability to Delete the objective and Add new users to the objective.