1. Authentication task for authentication needs to be configured in Service Management platform, before configuring Secure Access component. If you don't want to configure authentication task first, you can do whole configuration directly in Secure Access.

• How to configure new provisioning task for authentication?

2. Login to Secure Access admin console
Select correct realm you are configuring this federation

3. Validate that configuration is stored correctly in Secure Access component

• Validation can be made in: https://{TENANT_NAME.com}/auth/ and use account main.admin (and appropriate password read from the tenant configuration).
  
   

4.  By selecting User Federation, a list of Authentication tasks should appear (if the list is empty, wait one minute, to transfer data from Service Management to Secure Access; if the list is still empty.

5. Selecting Edit from the particular task reveals details of LDAPS connection. It's worth checking if all the settings are in place in here, especially:

• Import Users: ON
• Edit Mode: READ_ONLY

6. After saving the connection, a Action menu reveals at the right upper corner, allowing admin to synchronize all Users from LDAP to Secure Access

7. Check if the AD_GroupMapper is in place. Select Mappers from the top bar of the User federation. Among the default ones, one (or more) group-ldap-mapper types should be visible here.

• If there is no AD_GroupMapper created automatically, user is able to create own one, with a click of blue Add mapper button.

Example of AD group mapper

8. After configuration is reviewed, Admin can try to Synchronize all users (mentioned in one of the previous screens). That should bring a message similar to

9. Synchronized users can be reviewed under Users section



10. Configuration should be done now and it is possible to test authentication

11. Next step is to configure user levels and roles: https://docs.efecte.com/configure-authentication/configure-esa-to-use-esm-roles 

Secure Access logs can be downloaded from Pro/IGA solutions Connectors tab, from Logs side menu. Then download under esa logs, keycloak.log file.

1. If Secure Access logs are showing some troubles related to SSL connection, like for example: 

2. If SSL is being used to connect ESA to Active Directory, ESA must be aware of the certificate which AD is presenting. That is a manual step and it requires:

• Ssh to host (if you don't have access to host, contact Matrix42)
• Ssh to Secure Access (ESA) container
• Go into /opt/esa (make sure there is a truststore.jks file) 
• In test environments, you can Issue the following command (if you don't have certificate file):
  
  
  • echo -n | openssl s_client -connect IP_OF_AD_SERVER:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > NAME_OF_THE_FILE_FOR_EXAMPLE_IP_OF_AD_SERVER.crt
  • But in production environments it is recommended to get root or intermediate certificate from Customer, those are usually longer valid than server level certificates.
• An example could be:
• echo -n | openssl s_client -connect 10.0.2.110:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > 10.0.2.110.crt
   

3. After you have certificate file, it needs to be imported into truststore.jks file

• keytool -importcert -file NAME_OF_CERT_FILE.crt -keystore truststore.jks -alias “ALIAS_OF_THE_CERTIFICATE”
• For example: keytool -importcert -file AD_certificate.crt -keystore truststore.jks -alias AD_certificate

4. Reboot Secure Access to take certificate into use

• Exit from esa docker to host, with command: exit
• After that process, ESA container needs to be restarted to apply new certificates, by running these commands on host(replace [TENANT] with your tenantname):
  docker stop [TENANT]-esa && run-image -e TENANT=[TENANT] esa