On Wed, 10 Feb 2016, Alexander Bokovoy wrote:
>On Mon, 08 Feb 2016, Sumit Bose wrote:
>>On Mon, Feb 08, 2016 at 10:34:16AM +0100, Pavel Reichl wrote:
>>>
>>>
>>>On 02/05/2016 03:16 PM, Lukas Slebodnik wrote:
>>>>>
>>>>The ticket is about "SSSD should be about to display message to the
user when
>>>>the account in Active Directory is 'locked out'"
>>>>
>>>>If the string is not standardized among AD versions
>>>>than this ticket is NOT solved.
>>>
>>>So what do you propose? Rename ticket to contain version of tested
>>>AD? Or should we say user that although we have fix that would work
>>>for him it might not work for all AD versions so we won't provide it?
>>>
>>>Can we ask our QA to test on all AD version they can lay their hands on?
>>>
>>>>
>>>>>>Could you add link to msdn documentation where it is described
that this string
>>>>>>is guaranted to be returned in such case?
>>>>>
>>>>>It's not MSDN, but:
>>>>>
http://www-01.ibm.com/support/docview.wss?uid=swg21290631
>>>>I would prefer official documantation (msdn) in code ar at least in
>>>>commit message.
>>>
>>>We don't have any and it's possible it's not publicly
documented.
>>
>>The '755' in the message is a specific error code of some AD
>>calls which can be seen by the link Dan send. So I guess this will not
>>change.
>>
>>While I can make sense of some part of the remaining error string (yes,
>>it is just a string send with the LDAP bind response) I didn't found any
>>general description of the format and the components of the error string
>>on the MSFT sites.
>You should use error code 0x80090308, SEC_E_INVALID_TOKEN. The 80090308
>should be in the error string and this is what you have to compare
>against.
>
>https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd6c1a1c6/msadts-user-locking-password-policies?forum=os_windowsprotocols
>-----------------------------------------------------------------------
>Regarding the references in MS-ADTS on how account lockout policy is
>applied on Bind requests, I reported this as a document bug to the
>product team to request references being added.
>
>For LDAP errors returned by the server on a Simple Bind when the account
>is locked, the error is the same as if the Bind provided a wrong
>password. Windows Active Directory returns the LDAP error
>invalidCredentials.
>
>LDAP Bind Response error codes are documented in RFC2251 4.2.3..
>Examples of errors are operationsError , strongAuthRequired,
>inappropriateAuthentication, invalidCredentials, unavailable.
>
>RFC2251
>4.2.3. Bind Response
>- invalidCredentials: the wrong password was supplied or the SASL
> credentials could not be processed.
>The extended error information looks like this:
>-----------
>res = ldap_simple_bind_s(ld, 'contoso3\user1', <unavailable>); // v.3
>Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
>Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error,
data 775, v1db0
>Error 0x80090308 The token supplied to the function is invalid
>-----------
>
>MS-ERREF
>0x80090308 SEC_E_INVALID_TOKEN The token supplied to the function is
>invalid.
>
>The product team will be reflecting this in a future refresh of the
>MS-ADTS document.
>-----------------------------------------------------------------------
>
>>Alexander, do you think it would make sense to ask MSFT to enhance the
>>documentation of the LDAP error message format? And if yes, is sending
>>an email to dochelp(a)microsoft.com sufficient or this there a more
>>elaborate process?
>I'll check with Edgar on why this piece is still missing from MS-ADTS
>five years after. ;)
So I re-read MS-ADTS and section 3.1.1.3.1.9 "Error Message Strings"
has all the information:
-----------------------------------------------------------------------
When the server fails an LDAP operation with an error, and the server
has sufficient resources to compute a string value for the errorMessage
field of the LDAPResult, it includes a string in the errorMessage field
of the LDAPResult (see [RFC2251] section 4.1.10). The string contains
further information about the error.
The first eight characters of the errorMessage string are a 32-bit
integer, expressed in hexadecimal. Where protocol specifies the extended
error code "<unrestricted>" there is no restriction on the value of the
32-bit integer. It is recommended that implementations use a Windows
error code for the 32-bit integer in this case in order to improve
usability of the directory for clients. Where protocol specifies an
extended error code which is a Windows error code, the 32- bit integer
is the specified Windows error code. Any data after the eighth character
is strictly informational and used only for debugging. Conformant
implementations need not put any value beyond the eighth character of
the errorMessage field.
------------------------------------------------------------------------
So, my comment stands: check for "80090308" in the beginning of
errorMessage string.
Hi Alexander,
thank you for reaching out to MSFT for enhancing the docs. But I'm
afraid just checking for 80090308 is not sufficient as you can see from
. The value
behind the 'data' string is really important to find out the real reason
for the denial. The values themselve like (0x)701, (0x)773 or (0x)775
are documented as well (although I do not have the link at hand). But
since getting those values requires to parse the string it would be nice
to get some official details about the string.
bye,
Sumit
> --
> / Alexander Bokovoy