5.1.1.1.3 Sicily Authentication
Sicily is a combination of a package discovery mechanism and an authentication mechanism. Unlike SASL, Sicily includes package discovery in the authentication mechanism itself. The package discovery mechanism permits a client to discover the authentication protocols (also known as packages) that a DC supports. The authentication mechanism then permits a client to authenticate using one of those protocols. The authentication mechanism is independent of the package discovery mechanism in that a client can skip the package discovery mechanism entirely and proceed directly to the authentication mechanism (for example, if the client has some out-of-band knowledge of which authentication protocols the server supports).
Active Directory exposes and supports only the NTLM authentication protocol, as specified in [MS-NLMP], via Sicily.
The package discovery mechanism is performed by the client sending a BindRequest to the DC in which the name field of the BindRequest is empty and the authentication field contains the sicilyPackageDiscovery choice. The octet string contained in the sicilyPackageDiscovery choice is not used and is empty.
The DC responds to a sicilyPackageDiscovery by returning a SicilyBindResponse. A SicilyBindResponse is similar to an [RFC2251] BindResponse, but some of the fields differ. The SicilyBindResponse is defined as follows.
-
SicilyBindResponse ::= [APPLICATION 1] SEQUENCE { resultCode ENUMERATED { success (0), protocolError (2), adminLimitExceeded (11), inappropriateAuthentication (48), invalidCredentials (49), busy (51), unavailable (52), unwillingToPerform (53), other (80) }, serverCreds OCTET STRING, errorMessage LDAPString }
Note that resultCode is a subset of the enumeration present in LDAPResult. If the sicilyPackageDiscovery request is successful, the DC sets the resultCode to success in its SicilyBindResponse, and returns a string in serverCreds consisting of the semicolon-separated names of the authentication protocols it supports via the Sicily authentication mechanism. Active Directory supports NTLM, and returns the string "NTLM" in the package discovery response. The names of the authentication protocols are ordered in the server's preferred order, starting with the most-preferred authentication protocol. If the sicilyPackageDiscovery request is not successful, the DC returns an error in the resultCode field of the SicilyBindResponse. If the sicilyPackageDiscovery request fails because the DC does not support any authentication protocols via Sicily, the DC returns the error inappropriateAuthentication / ERROR_DS_INAPPROPRIATE_AUTH. The errorMessage field of the SicilyBindResponse can contain additional implementation-specific details indicating why the request failed.
Once the client has determined which authentication protocol it will use, it uses the Sicily authentication mechanism to authenticate the connection. The Sicily authentication mechanism consists of two requests, both of which take the form of an LDAP BindRequest. The first request is the sicilyNegotiate request. If successful, this is followed by the sicilyResponse request.
The authentication begins when the client sends the sicilyNegotiate request to the DC. This constitutes a BindRequest in which the name field is set to "NTLM" and the authentication field contains the sicilyNegotiate choice. The sicilyNegotiate choice contains an octet string consisting of binary data supplied by and dependent on the authentication protocol that is used, and which serves as a representation of the credentials with which the client wishes to authenticate the connection. If successful, the DC responds with a SicilyBindResponse in which the resultCode is set to success and the serverCreds contains binary data supplied by the authentication protocol on the server side. The client is expected to pass this binary data, whose content is authentication protocol–specific, to its implementation of the authentication package. If not successful, the DC returns an error in the resultCode field of the SicilyBindResponse, indicating that the sicilyNegotiate request was not successful. If the credentials supplied by the client are invalid, the DC returns the invalidCredentials / <unrestricted> error. If the client requests an authentication protocol that is not supported by the DC, it returns the inappropriateAuthentication / ERROR_DS_INAPPROPRIATE_AUTH error. The errorMessage field of the SicilyBindResponse can contain additional implementation-specific details indicating why the request failed.
If the sicilyNegotiate request is successful, the client then sends the sicilyResponse request to the DC by sending a BindRequest in which the name field is empty and the authentication field contains the sicilyResponse choice. The octet string in the sicilyResponse choice contains authentication protocol–specific data, generated in response to the data received in the serverCreds field of the SicilyBindResponse. The DC responds to this sicilyResponse request by sending a SicilyBindResponse. The serverCred field is not used in this response, and is empty. If successful, the DC sets the resultCode field to success, and the connection is now authenticated as the client-supplied credentials. If the bind fails, the DC sets resultCode to an error and the connection is not authenticated. As in the previous case, the DC uses the error invalidCredentials / <unrestricted> to indicate that the client presented incorrect credentials, and the error inappropriateAuthentication / ERROR_DS_INAPPROPRIATE_AUTH to indicate that the client requested an unsupported protocol. The errorMessage field of the SicilyBindResponse can contain additional implementation-specific details indicating why the request failed.
As with SASL, integrity verification or encryption can be negotiated as part of the Sicily authentication. The support for, and means of implementation of, such mechanisms is dependent on the particular authentication protocol used (for example, NTLM). As with SASL, such mechanisms cannot be used on a connection that is protected by SSL/TLS mechanisms, and once such a mechanism is in use, the connection cannot be rebound unless the LDAP_CAP_ACTIVE_DIRECTORY_LDAP_INTEG_OID capability is present in the supportedCapabilities attribute of the rootDSE of the DC.