When configured for Direct Authentication to Active Directory, the SAS^® Metadata Server attempts to form a qualified account with which to authenticate with Active Directory. For SAS 9.2, the Metadata Server supports User–Principal–Name (UPN) as well as the NT–style domain. The first authentication attempt will be with a UPN form. If that fails authentication, the Metadata Server attempts using the NT–style domain form. If that fails, the Metadata Server makes a third attempt using an unqualified form of the logon_name.

If an invalid password is provided by the client user, then the Active Directory account might be locked. This is typical when the Lockout–Threshold in Active Directory is set for four or fewer invalid logon attempts. This is due to the multiple authentication attempts the Metadata Server makes.

For example, when the client logs in as:

the Metadata Server attempts to authenticate (bind) using the following forms of the logon_name:

1. Attempt: logon_name@WinDomain
2. Attempt: WinDomain\logon_name
3. Attempt: logon_name
4. Attempt: logon_name (unreported in the Audit.Authentication logging, but used for error reporting)

Active Directory does not currently provide an invalid password return. Therefore the Metadata Server can not determine why the bind was unsuccessful. The current action is to attempt a bind using each of the forms of the logon_name described above. A SAS option to restrict this behavior might become available in a future release.

One circumvention is to use LDAP as the authentication provider method. You can still connect to your Active Directory server, though using the generic LDAP calls rather than Active Directory–specific calls. The LDAP method uses two connections: The first uses the LDAP_PRIV_DN user to look up the Distinguished Name for the authenticating user. The second connection is a bind on the found user's Distinguished Name.

A second circumvention is to modify the client login to be:

In this case, the SAS Metadata Server strips the trailing @WinDomain as the ADIR indicator, and passes the name as logon_name@WinDomain. The Metadata Server recognizes that the resulting name is qualified and does not attempt any form changes for bind attempts. An incorrect password in this case produces only two bind requests, one logged as you see in the example below, and a second which is used for error reporting but is not logged:

Example results from Audit.Authentication logger:

- Create Authenticated Token
- User/Pass authentication for user logon_name@WinDomain@WinDomain
- Found matching WinDomain: WinDomain
- Calling auth provider...
- Entering ADIR provider for user logon_name@WinDomain
- Bind failed as user logon_name@WinDomain
- Provider failed: 80bfd012
- New client connection (7) rejected from server port 8561 for user logon_name@WinDomain@WinDomain.
- Client connection 7 closed.

If the double WinDomain specification is confusing, you can change the AUTHPD value to be a more generic name that does not relate to a domain at your site, such as sas.

Then log in from a client application with either of the two forms:

A third circumvention is to increase the login attempts lockout to 5 or more. This allows for a single bad password attempt to pass its 4 bind requests without locking the account.

Operating System and Release Information