When Global Security is configured in WebSphere® Application Server and the LDAP to be used is a Microsoft Active Directory, you may get "access denied" problems although the user and password are correct.
In Microsoft Active Directory is an additional security feature named "Workstation Restriction".
For each user ID a list of workstations (hostnames) can be defined and the user ID now only can login on those machines.
In case of a user login to a WebSphere Application Server (e.g. the admin console), the user's workstation hostname is not passed to the Active Directory Server with the according LDAP request (neither is the WAS server's hostname). As a consequence the user is rejected eventhough user ID and password are correct. The third required parameter "userWorkstation" is just missing when WAS tries to authenticates against Active Directory.
The Workstation Restriction is a feature of earlier LAN Manager / NT Domain days and has not been adapted by other non-Microsoft LDAP implementations. Hence it cannot be passed as part of the LDAP search filter.
Diagnosing The Problem
A typical MSAD answer for a user which has a Workstation Restriction looks like this in the WAS logs or traces:
80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 531, v893
HEX: 0x531 - not permitted to logon from this workstation
Resolving The Problem
This problem is related to the configuration of Workstation Restrictions in Microsoft Active Directory. This problem does not happen when Workstation Restrictions is disabled on Active Directory.
If Workstation Restrictions can not be disabled, adding the hostname of the Active Directory to "userWorkstations" attribute for all users in Active Directory would be the possible solution.
However, consult with Microsoft Active Directory documentation and/or Microsoft Support to be sure there are no ill side effects due to this configuration.
Internal Use Only
For customer convenience, it might be worth raising a feature request to implement the userWorkstation functionality in the WAS LDAP module.
The "Resolving the problem" section was changed as an outcome of PMR 76243,999,760 on July 10, 2015.
15 June 2018