Enable debug-level logging for relevant loggers shown in $STREAMBASE_HOME/ams/conf/logback.xml:
<logger name="com.tibco.ep.ams.auth.AMSActiveDirectoryRealm" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSAuthenticationFilter" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSJdbcRealm" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSLdapContextFactory" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSOpenIDConnectRealm" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSPasswordService" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSPermission" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSPersistenceRealm" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.AMSSimpleCredentialsMatcher" level="DEBUG"/> <logger name="com.tibco.ep.ams.auth.Authenticator" level="DEBUG"/> <logger name="com.tibco.ep.ams.conf.Configuration" level="DEBUG"/> <logger name="com.tibco.ep.ams.conf.ConfigurationWatcher" level="DEBUG"/> <logger name="com.tibco.ep.ams.conf.RoleToPrivilegeMappingsConfig" level="DEBUG"/>
With the above logging configuration, the resulting AMS server log will display the LDAP configuration (set in
AMS.conf):
2021-09-30 09:15:20.414 DEBUG (main) com.tibco.ep.ams.conf.Configuration:377 - Configuration from AMS.conf: ... Key: 'LDAPAuthenticationRealm.servers', value: 'SimpleConfigList([{"authenticationCredentials": {"password":"secret","userName":"uid=admin,ou=system"},"host":"localhost","portNumber":389, "principalRoot":"ou=system","principalSearch":"uid={0}","roleAttribute":"uniqueMember", "roleRoot":"ou=groups,ou=system","roleSearch":"distinguishedName={0}","secure":false}])'
The RoleToPrivilegeMappings configuration will also be displayed in additional lines in the AMS server debug log:
Key: 'RoleToPrivilegeMappings.privileges.Administrators', value: 'SimpleConfigList([{"privilege":"*"}])' Key: 'RoleToPrivilegeMappings.privileges.Developers', value: 'SimpleConfigList([{"privilege":"artifact:*"}])'
This line tells you that the AMS server's RoleToPrivilegeMappings have been seeded, and a key for each corresponding role name("Administrators" and "Developers") now exists in the AMS database.
The below screen capture shows the RoleToPrivilegeMappings section in the AMS.conf, which correlates to the highlighted lines in the AMS server log. In this case, the LDAP group "Administrators" is mapped to the AMS admin role (which includes all (*) permissions). In addition, the LDAP group "Developers" grants privileges with respect to artifacts only.
Refer to these and other DEBUG-level log entries to troubleshoot the common issues outlined below.
Case 1 - The AMS user cannot login, and receives a message in the AMS web ui saying "Authentication Failed. Please retry or contact the administrator." This can occur if:
- The username or password supplied by the user is incorrect.
- The selected principalRoot attribute is incorrect.
- The principalRoot value has a typo.
- The selected principalSearch attribute (or its binding) is incorrect.
- The principalSearch value has a typo.
- The roleRoot value has a typo.
- The selected roleAttribute attribute is incorrect.
Case 2 - The LDAP user cannot login, but no error message is seen in the AMS web ui (and the ui appears to hang). This can occur if:
- The selected principalSearch attribute is incorrect.
- The principalSearch value has a typo.
- The selected roleRoot attribute is incorrect.
- The selected roleAttribute attribute is incorrect.
Case 3 - The LDAP user can login to AMS, but cannot perform the expected actions (such as deploying/reading/writing artifacts in AMS). This can occur if:
- The group name(s) specified in the RoleToPrivilegeMappings do not exist in the LDAP system
- The selected principalRoot attribute is incorrect.
- The selected principalSearch attribute is incorrect.
- The selected roleRoot attribute is incorrect.
- The selected roleAttribute attribute is incorrect.
- The roleAttribute value has a typo.