Problem

CG is LDAP connect and access to CG GUI is working just fine

COPILOT CONNEXION using a LDAP User does not work

Error messages:

CONNECT action for SERVICE:UI resource not allowed for user

ERROR L235 SystemUtil$2.print - java.lang.RuntimeException: SERV 0037 - Exception while checking password.

ERROR L235 SystemUtil$2.print - Caused by: com.axway.passport.sdk.common: Unable to get Assigned roles: GET https://mmy.test.uat.com:8081/api/parti... returned a response status of 500 Internal Server Error
2016-10-21 11:01:19.259 CEST [Thread-24653 ] ERROR L235 SystemUtil$2.print - at com.axway.nodes.passport.CGAutoles(CGAuthLDAPExit.java:170)
2016-10-21 11:01:19.259 CEST [Thread-24653 ] ERROR L235 SystemUtil$2.print - at com.axway.passport.services.amtion.AMSelectionServiceProvider.getUserRolesInExit(AMSelectionServiceProvider.java:610)

Resolution

In the use case above, the issue was related to the CG Identity Store configuration, more especially, to the parameter "User filter" in USER MAPPING section.

This parameter was filled with "(objectClass=person)" value meaning that all matching LDAP objects will be part of the local CFT cache.

When it returns a large number of objects, the cache will not be filled properly due to CFT timeouts.

It is recommended to not exceed 200 users returned by the filter to connect to Copilot when in a CG context

This limitation apply to current version (CG 1.1.2 / CFT 3.2.2) but will be enhanced in future versions.

The solution for the use case was to set a filter in regards of user's groups (memberOf=<DN du group>) after having verified, of course, that filter returns expected users from LDAP.

Recommendations:

• Keep the Identity Store a defined already, even with the user filter = "(objectClass=person)" for the LDAP connection with CG.
• Create a new Identy Store and a new external Organization dedicated for Copilot GUI users connection.
• Deploy that new Organization into the static CFT configuration (product access from Product List > Configuration > Access and Security/Access Management > Organisation)

Force flushing the CFT cache to ensure changes take effect immediately:

• Stop Transfer CFT and Copilot
• Delete cftam* file located in TransferCFT/runtime/data (you can backup that file first even though it will be automatically re-created)
• Start Tansfer CFT and Copilot

If the issue still exist, it is highly recommended to activate CFT traces:

Edit TransferCFT/runtime/profile file and add lines below:

Windows:
o set XTRACE_CFT_XPAM_LEVEL=5
o set XTRACE_XPAM_LEVEL=5
o set XTRACE_OUTPUT_FILENAME=%CFTDIRRUNTIME%\xpam.trc

LINUX:
o _EXPORT XTRACE_CFT_XPAM_LEVEL=5
o _EXPORT XTRACE_XPAM_LEVEL=5
o _EXPORT XTRACE_OUTPUT_FILENAME=$CFTDIRRUNTIME/xpam.trc

Z/os

o Variables are to be set in the member UPARM(CNFENV)

Same variables as for Windows or LINUX, Copilot and CFT are to be restarted.

Do not set the EXPORT XTRACE_OUTPUT_FILENAME variable, output default to the JOB or STC sysout.

Launch the profile and restart Copilot and Transfer CFT

AM traces will be located in TransferCFT/runtime/xpam.trc file.

This file will includes details sent from CG (PassPort) to the cache file:

- mapping between LDAP users and matching roles/rights, the user must be into that file when the Copilot connection is working, if not, it means that we are still facing an issue to fill-in the cache and you should get help from Support.