The Domain Server supports two primary security models: Native and LDAP.
Comparing the Native Security and LDAP Security Models
Native Security Overview
In the native security model, the users and groups, as well as the relationships between the two, are defined in the Domain Server itself. Native user credentials are stored in the Domain Server.
LDAP Security Overview
In the LDAP security model, users, groups, user credentials and group associations are managed or defined in the Microsoft Active Directory. Active Directory (AD) supports client communication via LDAP. The meshIQ platform allows importing the user and group definitions from AD to Domain Server, via LDAP connectivity.
What is required for LDAP security authentication?
One or more LDAP configurations must be defined at the Domain Server node.properties file, so that Domain Server can query the users or groups information existing on AD servers via LDAP. Refer to Chapter 2.4.2 from Administrators Guide for implementation.
How can we create AD users & groups in the meshIQ Platform?
- LDAP users can be defined manually or can be imported or can be created dynamically when user logs in. For auto-creation of users, see Automatically create LDAP users below.
- LDAP groups work in the same way as LDAP users, they can defined manually or can be imported or can be created automatically/dynamically when users login. For information on auto-creation of groups, see Can I add LDAP groups automatically to Domain Server?
What happens when a user logs in?
When a user (for instance 'bob') logs in via meshIQ Enterprise Manager or meshIQ Web UI interface (Manage or Track), the login request is sent to Domain Server. Once Domain Server receives the request, it first authenticates the user. After successful authentication, it inquires for the authorization information and shares the response back to the component that sent the login request. Description on how authentication & authorization is performed on each of the security model can be found below.
- Native users' : As these users exist on Domain Server, both authentication (validation of the user credentials) and authorization (getting the groups this user belongs to) is processed by Domain itself.
- LDAP users' : Domain Server passes the users credentials to AD via LDAP configuration for authentication. After authentication is successful, Domain Server again requests for the authorization information (group mappings for the user). Once response for authorization is received, it returns the information back to requester (Enterprise Manager or Manage or Track).
LDAP configuration options that affects login
Automatically create LDAP users
Instead of importing or creating LDAP users manually, you can have them created automatically at login by setting property server.domain.ldap.auto.create=true. This property would create user (if not created already) in Domain, when user logs in. In User Manager, such a user is marked as auto-generated (the Description field reads "Auto-generated LDAP account").
Use LDAP for user authentication only
By default, when an LDAP user is authenticated, the associated groups for that user are queried from LDAP so they can be assigned to the user. However, if you do not want to use LDAP groups, you can set up LDAP to do authentication only by configuring property server.domain.ldap.ldapserver.authenticateonly=true. In this case, as group mappings are not obtained from LDAP, LDAP users should be mapped to Native groups using Enterprise Manager.
Group matching (LDAP and Native groups)
As stated previously, when using LDAP security, Domain requests both authentication & authorization via LDAP and not just authentication. The option to perform authentication only via LDAP and ignore authorization is disabled by default. Group mappings are done by checking whether the groups obtained in the response received from LDAP exist on Domain or not. If user groups exist, then user is mapped to the groups. To understand, consider 'bob' is part of the LDAP groups APADMINS, TESTGROUP, DEVGROUP. Groups existing in the Domain are ADMINS, APADMINS and DEVGROUP. In this case, 'bob' would be part of APADMINS and DEVGROUP only and permissions are allocated based on the associated rights and privileges.
How does Manage login work?
Manage (previously known as Navigator) does not perform authentication or authorization of the user by itself. It forwards the user login request to Domain, collects the response from it and then checks for the permissions/roles allocated to the user, before logging them in. In other words, Domain sends Manage (Navigator) the user-group mapping information and Manage just checks whether the group exists, if exists, what permissions/roles are allocated.
Secure (Web Security Manager) Overview
User access control or RBAC is defined in Secure (previously known as WSM or Web Security Manager), at user group level. Secure provides the interface that allows Admins to define users, user groups, roles and other required aspects. It is important to note that
- For Manage, groups should be defined/created not only in Domain, but also in secure. A option to compare the groups between Domain & Secure is provided, which allows users to create missing groups in secure directly from this window. Article meshIQ Secure & Domain User Group Compare talks about this feature.
- If WGS is running with security option 4 or +au, users will be auto-created in secure. If WGS is not running with these security options, then users should also be created manually.
For additional information on secure and it's usage, refer to Secure documentation library.
Manage group matching example
For both manually defined and automatically generated users, mappings are only considered for groups defined in Secure. Continuing the example from Group matching (LDAP and AutoPilot groups) above, if Secure or WSM had PRODGROUP and DEVGROUP groups defined, 'bob' would be assigned to the 'DEVGROUP' with its associated rights and privileges. If a user who is not part of any groups logs in, he will be allowed to login (as authentication is successful), but he will not be allowed to connect to WGS or see any objects (as permissions/roles/access control is defined via groups).
How does Track login work?
Same as for Manage, Track (previously known as XRay) is not directly responsible for authorization or authentication. Track also reaches out to Domain and collect the response received. Track permission validation is also against groups, called as Teams in Track. Data in track are streamed to a repository. So, permissions are assigned to a team, defining the list of repositories, the members of this team can access and operations users can perform against this repository.
Additional resources
For additional general information, see:
2.4.2 Configuring Domain Server for LDAP in the Autopilot M6 Administration Guide
AutoPilot Authentication Basics
AutoPilot Authentication Groups
Can I add LDAP groups automatically to Domain Server?
How do you remove LDAP users that are not used?
For troubleshooting information, see:
How to troubleshoot Domain Server LDAP Security Integration
Error while trying to Import/load users from LDAP