SYMPTOM
When using LDAP with alternative authentication modes in particular Windows and Trusted Users may notice that the Group filter does not take effect. In these instances users who do not fulfill the LDAP group filters requirements may be able to still login with LDAP and access the project list page. However, as they do not receive any additional privileges they are not expected to be able to use any other functionality in Strategy.
STEPS TO REPRODUCE
1. Create an Enviroment with LDAP authentication integrated with Windows
2. In the LDAP setting change a group filter that contains a criteria that wouldn't allow certain users to login
3. Attempt to authenticate with LDAP who searches Windows credentails as a user who is expected to be eliminated by the group filter.
4. The user will be able to see the project load page although the group filter should be not dissmissing the login.
CAUSE
Under Windows login, the authentication is done with Windows OS. Whether the Windows/ADS user account is existed or enables/disabled is handled by Windows login through Windows OS. Those are handed before the Windows user can login to MSTR products. Under Windows login, a MSTR user that is linked to the Windows/ADS user must be existed in the metadata. There is no auto-import Windows User into metadata during Windows login (There is no LDAP user import in this case).
The same is for other integrated authentication methods. When a trusted login is succeeded in IServer, the user is guaranteed to be existed and enabled in the ADS domain and is guaranteed to be linked to a MSTR user in the metadata.
The LDAP search filter for user in the IServer is to find the LDAP DN of the LDAP user that matches the LOGIN of the LDAP credential during LDAP login (not in this case). Under Windows login with LDAP integration, there is no LDAP credential (NO LDAP LOGIN) passed around as the LDAP credential is not provided.
ACTION
This issue was reviewed by our Technology team for feasibility and will not be scoped for a code fix in any upcoming Strategy release.
WORKAROUND
Should it be required to disallow some Windows/ADS users to be able to use MSTR product, it is suggested to not import those Windows/ADS users into the metadata? In this instance if there is NO MSTR user that is linked to the Windows/ADS user, that Windows/ADS user can not login to MSTR products using Windows login.
An alternative could be to disable those MSTR user accounts.
KB441009
