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 doch...@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.
--
/ Alexander Bokovoy
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
