On 02/10/2016 02:34 PM, Alexander Bokovoy wrote:
> On Wed, 10 Feb 2016, Pavel Reichl wrote:
>>
>>
>> On 02/10/2016 11:46 AM, Alexander Bokovoy wrote:
>>> On Wed, 10 Feb 2016, Pavel Reichl wrote:
>>>>
>>>>
>>>> On 02/10/2016 11:06 AM, Alexander Bokovoy wrote:
>>>>> On Wed, 10 Feb 2016, Pavel Reichl wrote:
>>>>>>>> since getting those values requires to parse the string
it would be
>>>>>>>> nice
>>>>>>>> to get some official details about the string.
>>>>>>> Well, the string content after DSID-<number> mark can
be completely
>>>>>>> missing while the hex of the code (80090308) will be there.
>>>>>>>
>>>>>>> The presence of "DSID-<number> ..." error
message is regulated by
>>>>>>> ulHideDSID character of the dsHeuristics attribute (MS-ADTS
>>>>>>> 6.1.1.2.4.1.2). So you can have Active Directory where
DSID-<number>
>>>>>>> string is completely missing but Win32 code for the error is
there.
>>>>>>>
>>>>>>
>>>>>> Alexander thanks for looking into this, but what we need is to
>>>>>> distinguish between reasons for invalid credentials.
>>>>>>
>>>>>> e.g.
>>>>>> Bind result: Invalid credentials(49), 80090308: LdapErr:
>>>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 773,
v23f0
>>>>>> Bind result: Invalid credentials(49), 80090308: LdapErr:
>>>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 775,
v23f0
>>>>> As I said, you should not rely on the information being available
to
>>>>> you
>>>>> as it might be disabled completely by the AD administrators in
>>>>> ndsHeuristics attribute.
>>>>>
>>>>> What are you going to do when ulHideDSID flag is set to 1?
>>>> The ticket is about providing extra info to user if account is locked.
>>>> If we can't decide, we return generic access denied and generic
>>>> message. Best afford attitude is fine here...IMO.
>>> That's fine but please add documentation about the behavior into the
>>> commit message so that we would have this discussion recorded somehow.
>>>
>>
>> OK, would this:
>>
>> """
>> This patch is best effort only as decision whether account is actually
>> locked is based on parsing error message returned by AD. The format and
>> content of this error message might be subject of change in future
>> releases and also can be modified by
>> AD administrators.
>> """
>>
>> appended to the commit message of the first patch work for you?
> Please refer to specific parts of MS-ADTS I've mentioned.
OK Alexander, would following work as commit message for you?
This patch is best effort only as decision whether account is actually locked
is based on parsing error message returned by AD. The format and content of
this error message might be subject of change in future releases and also
can be modified by AD
administrators.
If account is locked bind operation is expected to return following error
message:
-------------------------------------------------------------------------
Invalid credentials(49), 80090308: LdapErr: DSID-0C0903C5, comment:
AcceptSecurityContext error, data 775, v23f0
-------------------------------------------------------------------------
Where sub string 'data 775' implies that account is locked
(ERROR_ACCOUNT_LOCKED_OUT) [1]. However the 80090308 (error code 0x80090308,
SEC_E_INVALID_TOKEN) is the only guaranteed part of error string [2].
Error message is described in further detail as [3]:
-------------------------------------------------------------------------
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.
-------------------------------------------------------------------------
[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681386%28v=vs....
[2]
https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20...
[3] MS-ADTS 3.1.1.3.1.9
https://msdn.microsoft.com/en-us/library/cc223253.aspx