On (11/02/16 15:30), Alexander Bokovoy wrote:
> ----- Original Message -----
>> 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
> Pavel, this is great!
>
I like it too.
Sure.
It would be also godd to add links to the related code "data 775".
Did you miss: "... Where sub string 'data 775' implies that account is locked
(ERROR_ACCOUNT_LOCKED_OUT) [1]. ..." or you would like me to reword it?
>
> LS
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>