Lightweight Directory Access Protocol (LDAP) is an application protocol used for accessing a user directory in a network.
The LDAP security components of Moogsoft AIOps are configured in the file called security.conf. You will also need information from your LDAP SME.
|LDAP Critical Step||Description|
The LDAP URL connection string
|ex. "URL": "ldap://LDAPServerName:389"|
Identify the User in the LDAP Tree that will have read only rights to search for end users of the tool
|userDnLookupUser and userDnLookupPassword|
|The Distinguished Name is the unique path to any object in the active directory|
|The attribute for the username|
"userBaseDn" : "dc=corp,dc=standard,dc=com"
|Have the LDAP SME test this password and ensure the password is valid. Most service accounts have disabled the ability to logon which makes it challenging to properly test the password.|
groupBaseDn": "OU=Groups,OU=SFG Users,DC=corp,DC=standard,DC=com"
|Note: This is can be different than the location of the userDnLookupUser|
|What to do|
Edit the Security.conf with all data provided by the LDAP SME as well as your Moogsoft roles
Ldapsearch Utility - It is highly recommended to use this tool as part of your LDAP configuration steps. The tool will enable you to test the existence location of the user being used to search LDAP for Moogsoft end users
ldapsearch -h LDAPServerName -u CN=LDAP-Moogsoft_User,OU=Accounts,OU=Users,DC=corp,DC=company,DC=com -x -W -b CN=LDAP-Moogsoft_DEV,OU=Groups,OU=Users,DC=corp,DC=company,DC=com
service moogfarmd stop/start
|After any change to the Security.conf file|
service apache-tomcat stop/start
|After any change to the Security.conf file|
Role Map ie.."Moogsoft Super User": "Super User"
|This is just an example map as many roles as needed to properly configure AIOps|
Role Map ie.."Moogsoft Operators": "Operator"
|This is just an example map as many roles as needed to properly configure AIOps to map to your groups or teams|
Testing and Validation
|What to do|
The use of the ldapsearch utility will enable you to validate that your configuration settings and user settings are correct
You must engage the LDAP SME for validation of users and configuration settings
Using both ldapsearch and the LDAP SME are the key to a successful LDAP integration
When everything is configured you must stop and restart both moogfarmd and apache-tomcat
The two key logs to check once testing the configuration begins are:
This file allows different authentication and authorization sources to be defined. Each authentication/authorization source is called a Realm and there are three types:
|DB||A moogsoft database|
|LDAP||An external LDAP server|
By default all the Realms within this file are commented out which means the default Moogsoft DB will be used. Edits to this file will require a restart of apache-tomcat for the changes to take effect. If any realms are defined in this file, the default DB Realm will not be used. This leads to the following configuration options:
|1||All realms commented out will mean the moogsoft db is used. Only local db users will be able to log into the system|
|2||One or more LDAP realms (but not DB realm). Only LDAP users will be able to log into the system|
|3||One or more LDAP realms plus a DB realm (there can only be one db realm). Both LDAP users and local db users will be able to log into the system|
If a user is defined in more than one Realm (with or without the same password) they will be authenticated and the login will succeed as long as at least one of the Realms authentication's succeeds.
Depending upon the type of Realm there may be additional configuration items required. The DB Realm does not require additional items but the LDAP one does. If both types are used, the DB Realm must come first in the file. All Realms are defined as follows (the name can be any you choose):
DB typeAn example DB type is given below:
The type of Realm (authentication/authorisation source). This can be either ‘DB’ or ‘LDAP’.
A url as follows:
The IP should be the IP address of the LDAP server and the port will typically be 389 (LDAP) and 636 (LDAPS).
By default port 389 is non-SSL, but SSL can be enabled, by upgrading the connection to secure with Start TLS - see Start TLS.
Note that Start TLS is recommended way to get secure connection with SSL, instead of using LDAPS.
If using LDAPS SSL then you will need to import the certificate into JAVA_HOME:
The above link has a section on client requirements:
Run the following commands as Root
Enter the following:
Check for the cacerts file in:
If this file exists, make a copy of it in the same directory and name it: jssecacerts
This is because if both cacerts and jssecacerts exist, jssecacerts will be used exclusively (so it is best to include the default certificates in jssecacerts by copying it).
Run the keytool command:
- Java's default cacerts password is "changeit" (for the keytool)
- If you encounter problems after importing the certificate then check:
- That you are importing to the correct JVM (The JVM that is running tomcat).
- Check to see if there is a certificate chain that needs importing as sometimes the whole chain needs to be imported.
The ‘Start TLS Extension’ is not currently supported (i.e. using ldap:// rather than ldaps:// for a TLS connection):
If predefinedUser is true then the user account information must exist in the local DB (as well as the LDAP server). To provision pre-existing users the stored procedure create_remote_user should be used e.g.
If predefinedUser is false then the LDAP information will be used to create/update the user account (and the local DB user does not need to exist before logging in).
userDnResolution and resolutionType
A block of config that determines the mechanism used for obtaining the user DN that will be used in the LDAP bind. Within the userDnResolution block resolutionType is mandatory and should have one of two possible values (direct or lookup). Whatever the value there must also be a config block of the same name e.g.
If resolutionType is direct then a user DN will be ‘built’ using the config fields usernameAttribute and userDnPostFix.
Example (“resolutionType” : direct):
If resolutionType is lookup then a user DN will be searched for in the LDAP server using the usernameAttribute as a filter and userBaseDn as a base to find the DN. The filter used for the user DN search is a combination (using AND) of userBaseSearchFilter and the usernameAttribute. If the user DN search returned more than one match then the login attempt would fail.
The actual user DN search will either use a specific userDnLookupUser or the systemUser (so at least one of these need to be configured).
Example (“resolutionType” : lookup):
Depending on the value for userDnLookup this key field is used to either build or search for the user DN that is used in the LDAP bind. See userDnResolution section for more details.
Used in conjunction with the usernameAttribute to build the user DN (Distinguished Name) that is used for authentication. See userDnResolution section for more details.
When resolutionType is ‘lookup’ this field will be used to determine the base subtree of the LDAP structure of which to do the user DN search.
userDnLookupUser and userDnLookupPassword
When resolutionType is ‘direct’ the userDnLookupUser and userDnLookupPassword if defined will be used to search for the user DN (based on the entered username). If these fields are not defined then the LDAP module will attempt to use the systemUser and systemPassword instead.
If the userDnLookupPassword is not defined (or is empty) the LDAP module will attempt an unauthenticated user bind (Special configuration would be needed in the LDAP server to allow this)
If you want to encrypt your passwords using the Moog Encryptor, comment out the
userDnLookupUser and uncomment
An LDAP filter that is used for searching for user attributes. This filter will be passed with the user DN as base to find all user attributes. If not specified this will be given the following default value:
The original version of attributeMap had the attributes swapped around so that the LDAP attribute was on the left and the DB column name was on the right. This had serious limitations in that it means an LDAP attribute could only map to a single DB column. Since it is useful to have a single LDAP attribute map to multiple DB columns this was swapped around
systemUser and systemPassword
With the LDAP protocol, the system will send two bind and two search requests. If no system user is configured then the user bind (used for authentication) will be re-used for the LDAP group search also.
A DB (Distinguished Name) for the part of the LDAP structure that contains the user groups. This will be used in conjunction with the the memberAttribute to find any LDAP groups the user belongs to. These groups are then mapped to a local role using the roleMap.
The member attribute is used to build a group filter to find groups.
This is the name of the LDAP attribute (for the LDAP group) that identifies the group name. This group name will then be used by the roleMap.
The left hand side of the above mapping is the LDAP group and the right hand side is the Moogsoft role name (as defined in the roles table). The LDAP group names (as defined by the groupNameAttribute e.g. CN) will be mapped to a role using this configuration.
Users who are not members of any of the mapped LDAP groups will not be able to log in.
Optional Boolean argument. If set to true, and the group name cannot be found in the teamMap (see above) or the roleMap (see above) it will assign the user to a team with the same name as the LDAP group.
Optional Boolean argument. If set to true, and AIOps cannot find an existing team with the wanted name (either in the teamMap or when useGroupName is set) it will create a new team. Please note, this team will be created without services, situations filter or alerts filter. This will need to be done using the UI or graze.
SSL can be enabled for non-SSL connections (by default on port 389), by upgrading the connection to be secure with SSL using Start TLS.
This can be achieved by enabling "ssl" configuration section for LDAP Realms. Once enabled, Express or Custom mode can be used.
In Express mode, none of the certificates or keys needs to be specified. Secure connection will be created, even thought the certificate is not validated.
In Custom mode, the provided certificates and keys needs to be valid and match the LDAP Server certificate.
Additional client authentication can be provided with both client_cert_file and cient_key_file specified, where the client_key_file needs to be issued by this same CA as the server_cert_file.
Note that client authentication needs to be explicitly enabled in LDAP Server schema.
(Optional) Specifies with SSL Protocol to use.
With JRE 8, it can be any of those "TLSv1.2", "TLSv1.1", "TLSv1", "SSLv3".
By default that is "TLSv1.2".
The location of SSL certificate, key files:
Relative pathing can be used, i.e. '.' to mean current directory, '../server.pem' or '../../server.pem' etc.
If neither relative nor absolute (using '/') path is used then $MOOGSOFT_HOME is prepended to it.
i.e. "config/server.pem" becomes "$MOOGSOFT_HOME/config/server.pem"
Path to the LDAP server certificate file.
Path to the Client certificate file.
Path to the Client private key file. The provided key needs to be in PKCS#8 format.