Depending on options specified, the Domain Server runs a series of LDAP queries to authenticate a user and then to obtain the groups that user is assigned. For details on this logic, see Security integration with LDAP/active directory using the Domain Server. Active Directory is a very commonly used LDAP Server.
However, when this integration doesn't work, it can be challenging to determine why. The first thing that we recommend is reviewing the Domain Server logs as all LDAP requests are generated from it. Typical errors would be an invalid LDAP URL or bad credentials for the search user required to validate the user login information.
The next most common error is incorrect mapping of the LDAP configuration. Access to an LDAP browser to review the actual setup is required. Having your LDAP/Active Directory administrator on a screen sharing session is the optimal approach. Alternately, there are free tools, such as the Softerra LDAP Browser, that can be used to browse the configuration. These use the same credentials as used in the node.properties file so this also verified that connectivity. The key is to identify the LDAP configuration being used and which attributes identify the user and map the user to the groups. LDAP is very flexible and even with Active Directory, there is no single way to configure it. For example, sAMAccountName is typically the user attribute used to identify the login name and member is the attribute(s) in groups that points to the associated users. However, your environment may vary. For example, in some configurations, the groups point to the users and in others, the users point to the groups.
The corresponding attributes need to be specified in the Domain Server node.properties under the associated server.domain.ldap properties.
If after reviewing with the lDAP browser and verifying the attributes appear to be setup correctly and still not getting the results expected, the next option is to run a trace on the Domain Server to see the actual LDAP calls and responses being made.
First, add the following line to the <AutoPilot_HOME>/naming/node,properties file (the line may already be present and just commented out). This activates additional levels of trace from the Domain Server.
Second, edit the file <AutoPilot_HOME>/log4j.properties and add the following at the bottom. This ensure that the trace data written above is included in logging.
Next, in the same file, check the settings for the file appender. This is near the top of the file. Ensure that threshold for the file output is set to trace as well.
Save all changes and restart the domain server. Have the user(s) try to login. In the file <AutoPilot_HOME>/logs/log4j/DOMAIN_SERVER.log4j look for entries related to that user. In particular, look for Performing LDAP search trace entries.
As an example, this set of results would be returned when the group entries point to the user entries logging in as user1.
Performing LDAP search: search.base="CN=Users,DC=Domain,DC=MAIN", search.filter="(&(sAMAccountName=user1))", search.scope=2, members.attrs=
In this example, it is trying to find sAMAccountName with a value user1 in the base Users/Domain/Main. You can run this query in your ldap browser to see the results as well. Make changes until it works there and transfer the attributes back to node.properties.
Another query you will see is locating the groups associated with this user
Performing LDAP search: search.base="CN=Groups,DC=Domain,DC=MAIN", search.filter="(member=CN\=Fred Smith\,CN\=Users\,DC\=Domain\,DC\=main)", search.scope=2, members.attrs=[cn, cn]
In this case, it is searching Groups/Domain/Main for groups that have an associated match for Fred Smith, using the attributes from previous result set. This can also be put into the LDAP query tool to see the result. However, note the "\" which are escape characters added. These will need to be removed, since most query tools do not expect you to do them.
The next thing to look for in the log is the results from this query. It will show up as follows with 2 responses, one from the LDAP search and then matched up with the user.
LDAP query result: [Developers (Developers), Testers (Testers)]
LDAP user="user1", all LDAP groups=[Developers (Developers), Testers (Testers)]
This indicates that user1 is in the Developers and Testers groups in LDAP. These will now be compared to existing groups in the Domain Server and the respective product as described in the link earlier.
Note that if there are multiple LDAP instances are defined, these searches may be performed multiple times.
To deactivate the trace, the only required step is to comment out property com.nastel.nfc.security.trace in node.properties file. The other changes can be backed out, but are dormant unless this option is set.