AD Authentication tips
Avoid use DNS
In this example, senhasegura is configured to query DNS to resolve the LDAP address being balanced by the load balancer.
Despite the ease of configuration, users may not be able to log in to senhasegura if the DNS server is unavailable.
Sometimes the LDAP cluster member is unavailable for query, but the load balancer is not yet aware of this outage. In those cases, the user may receive an intermittent authentication attempt.
To avoid the cases described above, you can shorten the jumps and mitigate the risks present for DNS usage and a load balancer by registering all LDAP members with their IPs directly in senhasegura.
senhasegura will manage the sequence of inquiries. And if any member does not respond to the request, senhasegura will ask the next server.
Set a Provider by User
If the connection between senhasegura and the authentication provider is offline, it is good to configure senhasegura, so trusted users can authenticate locally. The administrator can do this for each user.
Check the config in provider by user
Check with the customer about what will be the order of servers so it does not affect usage by other applications.
AD authentication LDAP and Azure SSO
In cases where authentication is used with Azure SSO and user provisioning in senhasegura is done through integration with the local AD, which is also integrated with Azure.
There may be a need to login locally via authentication with AD if login via Azure SSO is unavailable.
To configure this type of scenario, the following items must be done:
Choose the Active Direcoty Provider used in Settings -> Authentication -> Active Directory -> Servers and select to edit.
Edit the following fields:
Account form: Defines how senhasegura will assemble the LDAP query based on the parameters provided. The Main account form will use the information from the Account filter format field to search for the user in LDAP and validate the authentication, ignoring other fields.
Account filter format: LDAP query used to query objects to validate their existence and later authenticate users. If left blank, there are two default query possibilities:
(&(objectClass=user)(sAMAccountName=%s)) if the Bind requires DN parameter is disabled;
(&(objectClass=posixAccount)(uid=%s)) if the Bind requires DN parameter is enabled;
The %s variable will be replaced by the username informed during an authentication or authentication test, and it is treated not to support special characters.