COMMAND

    kernel

SYSTEMS AFFECTED

    WTS 4.0 on WinNT 4.0 sp4

PROBLEM

    'mRm3n4c3' encountered what is believed to be a bug in NT security
    when using Windows  Terminal Server 4.0  on NT 4.00.1381  (Service
    Pack 4).  The problem occured in an environment with 2 WTS servers
    using Metaframe  and running  a Loadbalancing  service, two  file/
    print servers also  running Oracle databases  and one name  server
    set  to  be  PDC.   The  users  homedirectories containing WTS/ NT
    profiles are located on the PDC.  There is another NT file/  print
    server running also exchange 5.0...  It is this server that is set
    to be BDC.

    If you log  on to the  WTS and type  the wrong password  more than
    three times, the your account gets locked out. BUT, if you  choose
    to continu trying  anyway, and after  some time manage  to type in
    the  correct  password,  the  WTS  will  let  you  log  on  as  an
    'anonymous user'  account, using  either a  locally stored profile
    or a default profile.  This  because the PDC denies access to  the
    homedir.  The funny thing is, you have no access to the PDC, which
    only  replies  with  'your  account  is  locked  out', but the WTS
    ignores  this  and  lets  you  browse  the network, map up locally
    shared drives/ catalogues, run  command.com / cmd.exe or  regedit/
    regedt32 (not determined what kind  of access th user has  at this
    point, but more than he/ she should anyways...).  Now, the user in
    this example was set up like this in usermgr:

        Homedir path \\nt40pdc\usernameshare$
        No terminal homedir
        Allow logon, no timeouts.

    This  means  two  severe  problems:   If  the  users  profile   is
    unavailable for some  reason, the user  is logged on  anyway.  The
    'account locked out' function does not work on WTS

SOLUTION

    This behaviour may seems like  bug to many, but according  to Bill
    Stout it  appears to  be working  like it  should.  The 'Anonymous
    User'  accounts  are  local  guest  accounts on the Citrix server.
    If you logon using  only username/password, the correct  behaviour
    is for  NT to  scan the  local users  for the  username, then  the
    domain.   A  failed  logon  using  username/password  only   would
    traditionally use the 'guest' account.  Extract from Q103390:

    "If the Domain specified in the SMB is NULL [None specified] then

        The Advanced Server will treat this a local network logon.  It
            will check for a matching account in its own SAM Database.
        If  it finds a matching account then
            The SMB password is compared to the SAM Database password.
            If  the password matches then
                The Command Completed Successfully.
            If  the password does NOT match then
                The User is prompted for a password.
                    It is retested as above.
                System error 1326 has occurred.  Logon failure: unknown
                user name or bad password.
        End
        If  it does NOT find the account in the local SAM Database then
            The Advanced Server will Simultaneously ask another Advanced
                Server in each Domain that it Trusts if it has account that
                matches the SMB account.
    
        If  no Trusted Domains respond to request to identify the
            account then
            Guest permissions are tested on the Original Advanced Server -
                not the Trusted server.
            If  the Guest account is Enabled
                The Command Completed Successfully.
            If  the Guest account is Disabled
                System error 1326 has occurred.  Logon failure:
                unknown user name or bad password.
        End
    "