----- 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.85%29.aspx > [2] > https://social.msdn.microsoft.com/Forums/en-US/e1d600c8-60b7-4ed0-94cb-20ddd6c1a1c6/msadts-user-locking-password-policies?forum=os_windowsprotocols > [3] MS-ADTS 3.1.1.3.1.9 > https://msdn.microsoft.com/en-us/library/cc223253.aspx Pavel, this is great!
Thank you! -- / Alexander Bokovoy _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
