COMMAND

    EFS

SYSTEMS AFFECTED

    Win 2000

PROBLEM

    Brandon Lay found following.  If a user encrypts Autoexec.bat on a
    Windows 2000  NTFS system  volume, no  user will  be able to logon
    locally or access resources shared on this computer remotely,  not
    even Administrator.

    Windows 2000 NTFS  volumes support the  Encrypting File System  as
    built-in functionality.   This is  a certificate-based  encrypting
    system.  Any  user  that  can  be  authenticated  and  has   Write
    permission  to  a  file,  such  as  Autoexec.bat  (default is Full
    Control) can  potentially encrypt  the file  by right-clicking  in
    Explorer, selecting Properties,  clicking on the  Advanced button,
    and selecting Encrypt Contents to Secure Data.  This functionality
    should be  seriously considered,  as files  encrypted by  one user
    cannot be shared with any other user (by default).  Regardless  of
    permissions or ownership, if you  encrypt a file, no one  else can
    "open" the file.   Of course, because  of this functionality,  one
    would  think  you  couldn't  encrypt  system  files.  Well, if you
    attempt  to  encrypt  the  Winnt  folder  or the system boot files
    (NTLDR,  NTDETECT.COM,  BOOT.INI),  you  will  be denied access to
    encrypt it.  This is good.

    However, there is no such  protection on Autoexec.bat.  Once  this
    had been done  to Autoexec.bat, the  next user to  attempt a local
    logon  will  see  the  dialog  box  with the message "Loading your
    personal settings..." and the system just sits there waiting.   My
    assumption  is  that  Autoexec.bat   is  parsed  for   environment
    variables on every logon.   Since the file has been  encrypted, it
    can't be  accessed unless  the user  who encrypted  it presents  a
    certificate.   The certificate  is stored  in the  user's profile.
    Catch 22.   The user's  profile hasn't  actually been  loaded yet,
    preventing access to the key certificate that may (as in the  case
    of the user who did the deed) decrypt the file.  Thus Autoexec.bat
    can't be read and somehow  prevents the system from continuing  to
    load the  user's profile.   So not  only does  this prevent  other
    users from  logging on,  but also  the user  who encrypted it, and
    any Recovery Agents (such as the Administrator account).

    Here is a summary of observances:
    1. After encrypting  Autoexec.bat and logging  off, you can't  log
       on, system hangs.
    2. If  you think  you will  remotely access  \\computername\c$ and
       decrypt it, forget  it. You can  connect, which takes  a while,
       but then the connection no longer responds.  In otherwords, you
       eventually see  the contents  of C$  in a  window, but it won't
       respond to any action.  This is odd, since onw would thought to
       understood  the   authentication  process,   that  access    to
       Autoexec.bat would cause remote connectivity problems.
    3. You  cannot  fix  in  any  of the following ways (all  tested):
       Through  remote  access,  safe  mode,  safe  mode  with command
       prompt.   We  are  going  to  assume  that the Emergency Repair
       process would do nothing for you, but this was not tested  yet,
       so don't quote.

    To Reproduce:
    =============
    Logon  locally  to  any  current  release  version of Win2k - Pro,
    Server, Advanced Server have been tested - with NTFS 5.0.  Log  on
    using any user account (local or domain) and encrypt  Autoexec.bat
    using the method described above. Log off, and attempt to log on.

    To Repair:
    ==========
    Boot to  the Recovery  Console (refer  to article  Q229716 for the
    How-To),   log   on   to   your   Win2k   installation  using  the
    "administrator" password (must be THE Administrator account),  use
    the  CD  command  to  go  to  the  root  of  the drive, and delete
    Autoexec.bat.  Before deleting it, you can verify it is  encrypted
    by using the DIR command which shows all attributes for files  and
    folders.   On  Autoexec.bat,  you  will  notice  the "e" attribute
    appears.   Now if  you installed  the Winnt  folder on a different
    volume  than  your  active,  or  system,  volume, you will need to
    change drive letters and then delete the file.

SOLUTION

    Numerous people pointed out how a good secure configuration  would
    prevent  this  problem  from  occurring  (by preventing users from
    being able  to modify  an AUTOEXEC.BAT  if present,  or preventing
    them from  creating one  through carefully  thought out  directory
    rights).  The most interesting so far came from Martin Holden  who
    referred to this KB article;

        http://www.microsoft.com/technet/support/kb.asp?ID=185590

    wherein the key ParseAutoexec can  be found.  The key  may prevent
    the use of the AUTOEXEC.BAT file. The KB states;

      "When this value is 1, the environment variables declared in the
      Autoexec.bat file are included in the user's environment"

    The  Possible  Preventative  Solutions  (until  this  is hopefully
    fixed - Pick One):

        * Set  the  NTFS  Read  permission for Authenticated Users  on
          Autoexec.bat.  If you can't  write to it, you can't  encrypt
          it.  Remove any other permissions inherited or assigned.
        * Disable EFS on stand-alone Win2K machines.  To do this refer
          to Microsoft article Q243035.
        * Disable EFS domain-wide.  Refer to Microsoft article Q222022

    BTW, deleting the file (since apparently we don't need to have it,
    but  if  it's  there  we  need  to  read  it!)  doesn't give you a
    preventative solution.  As a  user could just create a  file named
    Autoexec.bat on you System partition and then encrypt it.