Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Windows :: krnl21~1.htm

Windows 2000 SP2 and earlier kernel admin lockout



COMMAND

    kernel

SYSTEMS AFFECTED

    Windows 2000 SP2 and earlier

PROBLEM

    Eric  Domazlicky  posted   following.   Repeat   these  steps   to
    reproduce the bug:

        1. Log in as a local admin
        2. Check  your local  security policy  under "User  rights" to
           make sure  "Everyone" cannot  logon locally,  by default it
           can't.
        3. Rename the local administrators group to something  besides
           "Administrators"
        4. Reboot your machine
        5. Try to log in  as an administrator either Domain  or local.
           You  can't   because  your   local  policy   setting   says
           "Administrators"  may  logon  locally  but-  that  group no
           longer exists (since you renamed  it).  In other words  the
           local policy settings aren't  stored using SIDs, it's  just
           storing straight  group names  - very  lazy on  the part of
           Microsoft.   Also quite  annoying when  you find  you can't
           login to your machine because  you changed the name of  the
           Administrators group.

    Justin Silles shared another story.   He has one PC as a  Win2k DC
    with  active  directory  and  terminal  services  and  one  laptop
    running win2k.   While setting up  the security settings  (for the
    domain) he had set the administrators group to be the only one  to
    log  in  locally.   He  had  also  changed  the  name of the local
    administrator on the server and  various other settings.  After  a
    few moments he was no longer able to log on to my server  locally.
    He was not able to figure out the problem so heI figured he  could
    log on via  the Terminal Services  connection...still not able  to
    access it.

    After figuring that his client was acting up (laptop) he rebooted.
    This is  when things  went bad.   At the  laptop was  part of  the
    domain and it took on the new policy settings after the reboot  he
    was  now  locked  out  of  that  PC  as well.  The error is "Local
    security policy does not allow user to log in".  In an attempt  to
    get back into my server and  laptop he took a different PC  he had
    installed a fresh copy  of win2k Pro and  set it up on  my network
    to try and fix this problem.   During the install Justin added  it
    to the  domain, thus  taking on  the same  bad security  settings.
    After the final install process  the PC reboots as usual  and then
    locked me out  with the same  error.  He  reinstalled the OS  this
    time staying out of the domain.

    He  then  booted  and  mapped  to  the  admin share on the server,
    browsed  to  and  deleted  (see  MSKB  Q201227):   {xxxx-XXXX}   =
    Combination of letters  numbers (hex) there  will be two  of these
    and you have  to remove the  file from both  (numbered them 1  and
    2, but that has nothing to do with the numbers inside the {}):

        C:\WINNT\SYSVOL\DOMAIN\Policies\{xxxx-XXX1}\Machine\Microsoft\Windows NT\SecExit\GptTmpl.inf
        C:\WINNT\SYSVOL\DOMAIN\Policies\{xxxx-XXX2}\Machine\Microsoft\Windows NT\SecExit\GptTmpl.inf

    Within a  few seconds  the HD  activity lights  went nuts  (policy
    change was taking effect) and he was able to log into his  Server.
    Justin rebooted his laptop and regained access to that as well.

SOLUTION

    The only way to log on as an administrator to that workstation  is
    to get the NTrights.exe file from the W2k resource kit and run  it
    from a remote machine  to grant your renamed  Administrators group
    Log on locally rights.

    As for Justin's case there is two other ways to fix this
    1) log  in using  the win2k  recovery counsel  and delete the file
       then reboot  the server.   However this  requires you  to  take
       down the server.  The fix  above does not, since all access  to
       the server otherwise is still functional.
    2) If  you can  figure out  which setting  is in the "GptTmpl.inf"
       file, you can just delete that line (log on locally?) and  then
       the  server  would  be  fine  with all other important security
       settings still functional.


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH