On Wed, Feb 10, 2016 at 11:38:34AM +0200, Alexander Bokovoy wrote:
> On Wed, 10 Feb 2016, Sumit Bose wrote:
> >On Wed, Feb 10, 2016 at 10:45:39AM +0200, Alexander Bokovoy wrote:
> >>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
> >http://www-01.ibm.com/support/docview.wss?uid=swg21290631 . 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.
> 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.
Interesting, so it is basically a best effort. If there server sends
sufficient information which we know and can handle we can tell the user
that his account is locked and that he has to try later. Otherwise he
will just see an authentication error. But I think this is fine and the
current version of the patch already behaves like this.
I'd like to have a
summary why we are depending on the debug string and
where logic of it being available/not available could be found to be
added to a commit message.
--
/ Alexander Bokovoy