Keith Schroeder
asked on
Cannot logon because the logon method you are using is not allowed...
I noticed the other day that our company wide blast (every email address in the company) was listed as a security group and not a distribution group. I had an exchange "expert" here looking at a backup issue on my exchange server and asked him whether this was a problem. He told me that if that blast wasn't being used to apply security to shared folders, etc. that it could end up being a security risk. I had never seen it this particular group used for anything except communication. I went into AD and changed it over to a distribution group. Now all users that don't have local admin access to their computers get the "Cannot logon because the logon method you are using is not allowed..." message when logging into their machines. They can only log in again if I make them a local admin. Is there anything I can do globally in AD or elsewhere to rectify this situation without waiting for my users to complain and addressing each situation individually? It is a Windows Server 2016 running Exchange 2013
Amit
This looks more GPO issue. Check what all GPO applied on client machine.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
In terms of GPO, that same guy asked if we do any automatic drive mapping. We do map a shared drive via Group Policy when a computer is configured with an enterprise profile for the first time. Would this have any effect on this issue? Also, are there any drawbacks to flipping that blast back to a security group as it was before?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I don't think there will be any drawbacks to changing the group back to Security. The underlying SID should be the same, so the permissions will be in effect again.
It is what I would do, then go looking for how the group is used.
It is what I would do, then go looking for how the group is used.
ASKER
Rather than mess with GPO, I just made it a security group again. It wasn't hurting anything before the change Thanks again!
ASKER
I know I closed this question... but after changing the blast back to a security group, the issue is not resolved. not sure what to look for in GPO. any help would be greatly appreciated.
See my links. You can easily find out which gpo to modify if you use rsop.msc on such a client (as admin). Rsop will list the gpo name right in the section that is mentioned in my links. Then, locate that gpo in gpmc and change it, so that also the group domain user may logon locally.
ASKER
McKnife,
I found what you were talking about but I still have a couple of questions. Am I editing this on my primary domain controller or does it have to be done on every computer affected? Also, when I got to that policy on my DC, options to modify it were grayed out even though I am logged into the DC as the administrator. What could be causing that?
I found what you were talking about but I still have a couple of questions. Am I editing this on my primary domain controller or does it have to be done on every computer affected? Also, when I got to that policy on my DC, options to modify it were grayed out even though I am logged into the DC as the administrator. What could be causing that?
You need a crash course in GPO.
You should proceed like this:
As admin, open rsop.msc at a client and in the results navigate to where I mentioned: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment ->Allow logon locally
On the right hand side of that setting, you'll see a column "origin or GPO Name" which will list the GPO that contains the setting we are talking about. Equipped with that name, logon to a DC and open the group policy management console ("GPMC"). List the GPOs and edit that very GPO. In that section (again: GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment ->Allow logon locally) and add the group domain users.
It will apply after some time (background refresh: every 90 minutes).
Make sure, that policy does not apply to servers, as well, but only to clients.
"Also, when I got to that policy on my DC, options to modify it were grayed out even though I am logged into the DC as the administrator. What could be causing that?"
That means, you are looking at rsop, not at the GPMC. In rsop, only results are displayed, not editable.
You should proceed like this:
As admin, open rsop.msc at a client and in the results navigate to where I mentioned: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment ->Allow logon locally
On the right hand side of that setting, you'll see a column "origin or GPO Name" which will list the GPO that contains the setting we are talking about. Equipped with that name, logon to a DC and open the group policy management console ("GPMC"). List the GPOs and edit that very GPO. In that section (again: GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment ->Allow logon locally) and add the group domain users.
It will apply after some time (background refresh: every 90 minutes).
Make sure, that policy does not apply to servers, as well, but only to clients.
"Also, when I got to that policy on my DC, options to modify it were grayed out even though I am logged into the DC as the administrator. What could be causing that?"
That means, you are looking at rsop, not at the GPMC. In rsop, only results are displayed, not editable.
ASKER
Am I editing this on my primary domain controller only or does it have to be done on every computer affected?
No, just at one DC.
ASKER
Edited the "Log on Locally" GPO on my primary DC and still can't add a profile to a laptop without seeing "Cannot logon because the logon method you are using is not allowed..."
Please verify if the gpo got applied. Again use rsop.mac at the client.
ASKER
It just took a little while to replicate across the network. I am able to log in locally again. Thanks for your assistance and more importantly your patience with me.
Ok, let me finish this:
-you did not know whether or not to follow the consultant's advice - but you did.
-you did not know that the group was used within GPOs
->You need to document your settings and you need someone in the know. Without, this will not end good. Your workaround (making people local admins) ruined the security. If you undo it now, who knows what backdoors those people might have opened to restore administrative rights. Very easily done, once you are admin for 5 minutes.
--
Please try to answer the following questions:
-why was that setting (logon restricted to a certain group) in use at all? In other words: what is the default setting and why might someone felt it needed changing?
-is the status quo reached? Should it be reached?
-what was meant by my "Make sure, that policy does not apply to servers, as well, but only to clients" - why does it matter and how can you verify?
I am just trying to raise awareness :-) Modifying security settings on a large scale without the knowhow is dangerous and should be avoided. Using a forum to help you out might work, but we can only deal with the things that you notice and not with the errors you might have made while trying.
Many big security incidents are based on errors that happened while people kind of panicked, while people try desperately to find a timely solution at all costs.
-you did not know whether or not to follow the consultant's advice - but you did.
-you did not know that the group was used within GPOs
->You need to document your settings and you need someone in the know. Without, this will not end good. Your workaround (making people local admins) ruined the security. If you undo it now, who knows what backdoors those people might have opened to restore administrative rights. Very easily done, once you are admin for 5 minutes.
--
Please try to answer the following questions:
-why was that setting (logon restricted to a certain group) in use at all? In other words: what is the default setting and why might someone felt it needed changing?
-is the status quo reached? Should it be reached?
-what was meant by my "Make sure, that policy does not apply to servers, as well, but only to clients" - why does it matter and how can you verify?
I am just trying to raise awareness :-) Modifying security settings on a large scale without the knowhow is dangerous and should be avoided. Using a forum to help you out might work, but we can only deal with the things that you notice and not with the errors you might have made while trying.
Many big security incidents are based on errors that happened while people kind of panicked, while people try desperately to find a timely solution at all costs.