COMMAND

    kernel

SYSTEMS AFFECTED

    Windows

PROBLEM

    Richard  Puckett  found  following.   He  has been working through
    this  with  MSFT  for  some  time  now.  Responses have been slow.
    Below is the issue as stated (with some cleanup) to MSFT.

    He  has  been  experiencing  an  odd  problem related to AD Object
    Security Settings and the way the "Change Password"  functionality
    works through the Windows NT Security Dialog Box.  A user who  has
    obvious explicit access to their own User object is denied  access
    to change their own password.

    When a User object has had Everyone - Change Password removed from
    it's effective permissions set, or is blocking inheritance of that
    specific  permission   with  SE_DACL_PROTECT   from  it's   parent
    container, a user  is unable to  change their password  using the,
    "Change Password"  dialog.   They receive  a message  stating that
    they do not have permisssion to change their own password.

    What  Richard  traced   this  to  is   an  issue  with   the   way
    authentication is occurring (or actually, not occurring) from  the
    SYSTEM Windows Station.   When a SAS  is initiated (CTRL  + ALT  +
    DEL), the Windows Station is switched from the Interactive Session
    of the authenticated User (WINSTA0) to the SYSTEM Windows Station.
    This is normal enough, except when a user attempts to change their
    password from  the SYSTEM  Windows Station,  it fails  because the
    "Change Password" dialog  is not using  the supplied User  context
    and  old  password  to  initiate  an  authenticated  bind  to  the
    Directory.   Thus,  the  DSBind  is  made  as SYSTEM, or basically
    anonymous/null,  which  translates  into  Everyone.   This  fails,
    obviously, with  the effective  or inherited  permissions for  the
    group Everyone removed  for the User  Object.  So  a User who  may
    have full  permissions to  their own  User object  is blocked from
    changing their password using the "Change Password" dialog.

    Question is,  why is  the DSBbind  used in  the "Change  Password"
    request not  being processed  with the  supplied User  credentials
    (Old Password and Domain\Username)?

SOLUTION

    The response was that the  bind was being made using  the Password
    Change  API  in  W2K,  which  utilizes  a  null  connection to the
    Directory.   In  order  for  it  to  function  properly there is a
    requirement  for  "Everyone  -  Change  Password"  to  be  on User
    Objects.  There is no workaround.