Solved

Getting error the signin method you're trying to use isn't allowed.

Posted on 2016-07-19
8
1,079 Views
Last Modified: 2016-07-27
I am helping a friend out sort out through his computer server and desktop computers.    His company has Windows Server 2012 Essentials.  
I added a user and added him to the domain user's group.  I basically copied an existing user and his group membership to the new user I created.  When I tried to logon to his about using the following format "Domain name\user name.  I received the following error

Getting error the signin method you're trying to use isn't allowed.

When I go back and login as the user he was login in as  domain name\existinguser he can log in just fine.

I tried logging him on another computer, and get the same message.   Seems as is the computer name is somehow tied to a particular domain user.  

How can I fix this problem?
0
Comment
Question by:MomForLife
  • 5
  • 3
8 Comments
 
LVL 16

Expert Comment

by:Spike99
ID: 41721189
It sounds like the logon method isn't allowed. Is this a local log on? (meaning they are sitting down at the PC and trying to log on directly & not remotely)

There is a security setting in local security policy that can block local logon.  By default, authenticated users & administrators can log on locally to client PCs.  But, if someone changed local security policy, that might be what's blocking it.

To get into local security policy, you can run "secpol.msc" at a command prompt (or click on Start and type that in the search box).
Then, browse to Security Settings > Local Policies > User Rights Assignment.
Check the settings for the "Allow log on locally" policy.  By default, Administrators and Users have rights to log on to client PCs:
Local Security Policy Console
There is a similar setting in group policy.  In the group policy console (GPMC.msc), that setting would be in this policy:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
But, at the domain level, that GPO is normally only changed to allow administrators to log on to domain controllers locally.
1
 

Author Comment

by:MomForLife
ID: 41723150
Thanks Alicia.  I used gpedit on the local user computer not the DC. and  this setting was grayed out, and has the settings applied by a group policy on our Domain server.  I can disjoin the domain and use a workgroup and of course I can now edit the local policy and of course has no reference to the Domain policy.  

Do you have any idea, why anyone would do this?  It has caused problems, because only those users listed on the DC group policy can logon to the local computer (not the DC) .  To get around this I have to add AD users to the local admin group on the local computer.
0
 
LVL 16

Accepted Solution

by:
Spike99 earned 500 total points
ID: 41723519
I don't know why someone would do that: it's definitely not normal.

This page describes things pretty well:
https://4sysops.com/archives/deny-and-allow-workstation-logons-with-group-policy/

By default, every user in AD automatically gets added to Domain Users. Domain Users is, once again by default, included in the local Users group on workstations when the workstations get added to AD. That means that unless you take action on either the user account or the computer configuration, any user account in your AD environment can log into any computer whether you want them to or not.

It makes sense to restrict a regular user's right to log on to servers & domain controllers.  But, I don't see any reason to restrict a user's right to log on to a PC (access to apps or data on a PC can be controlled without preventing users from logging on).

Rather than having individual users listed in the GPO to grant them local log on rights, I think it would make more sense to create an AD group. That would make controlling local logon a lot easier: just add any new AD user to the group & they can log on without having to edit group policy or granting local admin rights.
0
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 

Author Comment

by:MomForLife
ID: 41723627
So if i go i to the default policy on the domain controller and  disable this policy it should go with the default settings-  Administrators users etc.  - correct?  I thought this  was only used for local access to domain server not local computer users on workstations
0
 

Author Comment

by:MomForLife
ID: 41723896
Ok.  I am totally baffled.  I am going to give  description of our setup in regards to the policies on the domain server.

There are 4 policies.  The default domain policy, default domain controller policy, wse policy, map drive policy

The default domain policy takes precedence over all  of them, since it has the lowest number of 1. All are enabled and inherited. None are enforced.  

The default domain policy has the following users  on "allow logon locally"   buildin\remote desktop users, ourdomain\user1, ourdomain\user2, cadet\administrator, buildin\administrators

I have go into this particular policy and removed "define these policy settings."   I have then  executed
a "gpupdate /force" on the user's computer.  Logged in with a permitted account, executed a gpedit and  and looked up "allow logon locally".  The users are still there and it is still grayed out.  Therefore only those specific accounts can logon to that user computer.

PUlling my hair out. What is wrong?
0
 

Author Comment

by:MomForLife
ID: 41725455
Okay.  Don't understand why this happened, may someone can explain.  After removing the users that had been add to the domain policy on the server under "allow logon locally".  I did a gpudate /force on the workstation (not on the server), it still showed the users under the local policy for the workstation and of course it was grayed out, and I was not able to logon to any other user other than those specified in the policy.  

Today I went in and everything is now working as it should.  I have logged on to other computers and the local policy is now as it should be and I can now login as any ad user on any computer.  

Why did it take so long for the server to update, even though I did a gpupdate /force?

Thanks in advance for your input.
0
 
LVL 16

Expert Comment

by:Spike99
ID: 41729387
Usually, after you run "gpupdate /force" it will prompt you to reboot or log off if needed to fully apply policies. That's because some policies can't be updated until the next reboot or until the next logon.  Did it prompt you to reboot or log off?
0
 

Author Comment

by:MomForLife
ID: 41730398
To Alicia W.  - no never prompted me for  a reboot or log off.
0

Featured Post

Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Monitor input from a computer is usually nothing special.  In this instance it prevented anyone from using the computer.  This was a preconfiguration that didn't work.
A quick guide on how to use Group Policy to create a custom power plan and set it active on Windows 7.
This Micro Tutorial will give you a basic overview of Windows DVD Burner through its features and interface. This will be demonstrated using Windows 7 operating system.
This Micro Tutorial will give you a introduction in two parts how to utilize Windows Live Movie Maker to its maximum capability. This will be demonstrated using Windows Live Movie Maker on Windows 7 operating system.

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question