Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 878
  • Last Modified:

Completely locked out of server with "the local policy of this system does not allow you to logon interactively"

Somehow in manipulating the group policies we managed to lock ourselves out.  We can connect to the network at another workstation and see the server, but we can't logon to the server at all.  Is there a way other than re-installing the operating system to get in?
Randy Rich
Randy Rich
1 Solution
As far as I know you can't prevent the administrator account regardless of the group policy setting. You should be able to log in with the local administrator account on the machine (ie You should logon to the machine not the domain).

This issue occurs because the server does not have the relevant users added to the Group Policy Object for the "Log on Locally" user right.   To modify the Group Policy Object for the domain controller, go to Administrative Tools>Domain Controller Security Policy>Security Settings>Local Policies>User Rights Assignment>Policy>Log on Locally>Add>Browse, click the appropriate group, and then click Add. After modifying the Group Policy, type  secedit /refreshpolicy machine_policy /enforce  at a command prompt, press ENTER, and then press ENTER.
Randy RichPresidentAuthor Commented:
Yeah, I wouldn't have thought you could, but I've read where others have been locked out the same way.  Anyway, I can't log in as administator.  I've tried loggin in as administrator at the server itself and also using a remote desktop connection.  Both give the same message.

I have another computer that I can connect to the server with.  Is there any way that I can connect remotely to the Domain Controller Security Policy?  
Here's a trick that might work:

Configure a policy that will allow you to access the machine.  Apply that policy at the Site level (as opposed to the Domain level) using AD Sites & Services.  Set "No Override" on this new Site policy.  Since Site policies are processed before Domain policies, if your site policy has No Override selected, it should take precedence over the Domain policies.

Or, a simpler trick.  Install the adminpak tools on your workstation, and modify the group policies from there.  If you have an XP workstation (or 2003), use the Group Policy Management Console:


Once you've modified your policy, you'll need to wait for a bit for it to be applied to the users/machines in question.  Or, if you don't want to wait, you can use the psexec tool to run the secedit /refreshpolicy machine_policy /enforce (might as well do user_policy while you're at it, too) on the DC remotely.

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Is it possible that the true adminsitrator account was renamed? We've done that here for security reasons - we even setup a dummy account called administrator so we could watch and see if it ever gets locked out.
Randy RichPresidentAuthor Commented:

Ok, I've installed the GPMC.  Before I open it, at the dos prompt I type net user \\myservername\administrator mypassword /user:myservername\administrator to log onto the server.  Then when I launch the GPMC I get a message that says "To manage group policy you must logon to the computer with a domain user account" but it launches the GPMC anyway.  The only entry there is on the left side tree is "Group Policy Management".  I right click that and select "Add Forest" and enter my domain name.  Then it replys "No mapping between account names and security IDs was done".  What am I doing wrong?


I've been using this Administrator accouint for some time.  If someone changed the name it was before my time.
Nirmal SharmaSolution ArchitectCommented:
1. Goto another computer.
2. Goto Start > Run > type "mmc.exe" (without quotes)
3. Goto File Menu > Add Remove Snap-in > select Local Security Policy > select on Another computer.
4. Edit the policy for remote computer and change the logon rights: -

User Rights Assignment
     Log on locally

Add Administrator account here.

Now try to log on locally using Administrator account.

Let me know.

Randy RichPresidentAuthor Commented:
I don't see the Local Security Policy snap-in in the list of available choices.  I do see one named Security Policy which I'm able to add and connect to the server.  It has 2 sections.  User configuration and Computer configuration.  I don't see anything in there about logging on.

I have another one named Security Policy Management.  When I try to add that snap-in, I get the message: "To manage Group Policy, you must log on to the computer with a domain user account."  I'm logged onto the workstation with the workstations administrator account. So I tried to log onto the server using a net use command  (net user \\servername\\ipc$ password /user:servername\administrator), but I still get the same message.

Randy RichPresidentAuthor Commented:
Here's what I did to fix the problem:

1.  Download the Windows Server 2003 Administration Tools Pack at http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&DisplayLang=en which gave me the Active Directory Users and Computers MMC plug-in.  I did that because the XP Professional workststation didn't have that tool.

2.  Then from Start->All Programs->Administrative Tools->Active Directory User and Computers I modified the group policy to reverse what I did to mess it up in the first place.   I was able to move the server from the new OU that I created back to the domain controller and remove the new OU.

The big thing was being able to access that server from another workstation.  

I think you should probably request a points refund, as my answer doesn't seem to have applied to your case.

Another note, it's probably not a good idea to move DCs out of the Domain Controllers OU.  The Default Domain Controllers policy should have Block Inheritance applied, and sets security for domain controllers properly.  Also, you can use the Default Domain Controllers policy to enable auditing types like Audit Account Logon Events (is that the domain account one, or is it Audit Logon Events?  I always forget) in one place.
Randy RichPresidentAuthor Commented:
Actually what you suggested is exactly what helped me to fix the problem.  Once I installed the admin pack I was able to then connect to the server remotely and fix the problem.

I will never move the dc from the domain controller's ou again.  I was suprised that the administrator password couldn't get in however.  I thought that account had full rights no matter what happened.

Thanks for your help.

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now