We are getting the following error when trying to log on to DeltaV with our operator accounts on our development system PRO stations: "Logon Failure: the user has not been granted the requested logon type at this computer." When attempting to log on to windows with these accounts we also get the following: "You cannot log on because the logon method you are using is not allowed on this computer."
These accounts are members of the domain just like all administrator accounts and are configured in DeltaV as a basic operator. We are able to log on successfully to the PROPLUS using these accounts both into windows and into DeltaV. We cannot on any of the PRO stations.
What could be causing this issue? Is there some sort of setting on each work station that grants log on rights to each account? Why would these accounts be able to log on to the PROPLUS but not the other workstations that are on the same domain?
Look at the event log for the machine and see if you can locate one of the events in the following article:
technet.microsoft.com/.../cc787567(v=ws.10).aspx
Then look for the logon type specified in the article. It should help you determine what logon type the operator does not have or is explicitly denied at those workstations.
Based on the fact that that they can log in to the domain controller proplus but not the domain members, I'm going to assume that the issue is due to either the pro stations cannot but must contact the domain controller for authentication or the pro stations are terminal sessions and you do not have the operators in the RDP users group (but they can log into the rpo plus console).
The basic operator role does lock down a lot of settings, but not interactive logon, as far as I know.
In reply to Youssef.El-Bahtimy:
Hi,
have you chosen the Domain as loging "place" from the dropdown list or are you trying to logon the local computer?
You need to download the stations to get the user list functioning properly.
Niklas Flykt
Klinkmann Oy
Key Account Manager safety products
[email protected]
In reply to Niklas Flykt:
I think Niklas is on the right track. In DeltaV Logon, you need to select the location of the user, if the user was assigned to a domain or computer. DeltaV uses that information to specify which account to use. You may have the same account name in different domains or computers and the DeltaV account (and associated privileges) are assigned to one of these. So the password validation will use the location\Username and seek authentication in that specific domain or computer.
At the windows level, you need to also use the correct domain/computer. In a DeltaV Domain, the user accounts are not created on the individual computers, unless you create them. If your logon is trying to authenticate at the computer, the account does not exist.
If the domain controller is not available to these other workstations, and these accounts have never been used on those computers, there is no cached account for the logon to use. However, I'm not sure what the error message would look like.
Youssef's suggestion to verify the logs will certainly clarify the issue on these computers. If it's not one of these logon location issues, check out the logs for more details.
Andre Dicaire
I am choosing the domain to log in to and made sure to download all of the workstations as well as the PROPLUS. The PRO stations are not terminal sessions.
I am finding the following errors in the security event log:
Event ID 4625 "An Account failed to log on." The logon type is 2 for interactive.
The security ID for the account which failed says "NULL_SID" so I am not sure what that means. I have little familiarity with the administrative side of things and our system admin left the company a few weeks ago. I notice that when I log on with my administrator account and it is successful the security ID is populated with my user information (domain/user name).
In reply to Steven Estes:
I also have seen that the operator log ons work on the 2 app stations in addition to the PROPLUS. Those 3 machines are all server 2008 machines whereas the PRO stations are windows 7 boxes. This leads me to believe that there is some sort of security issue with the windows 7 boxes vs the server 2008 boxes.
Open security policy editor on the Win 7 boxes (secpol.msc).
Under User Rights Assignment, see what is configured for the 'Allow log on Locally'.
It should be Default on workstations and servers:
Administrators Backup Operators Users
Also check the 'Deny Log on locally' setting. This should be blank (except maybe for Guests).
If you cannot edit these settings, then they are controlled by group policy and you will have to perform the same investigation at the domain controller using gpmc.msc. This is a whole other line of investigation, so we'll talk about that if you get there.
Your DeltaV users should be members of the Domain Users and Domain DeltaV groups. Domain Users should be member of the Users group on each Win 7 workstation.
Open compmgmt.msc on the workstation and verify the Users group contains the DOMAINNAME\Domain Users.
On th domain controller open dsa.msc and verify your deltav users are members of Domain Users and Domain DeltaV.
The Users group does contain Domain users and the DeltaV users in question are members of both Domain Users and Domain DeltaV.
I am unable to edit the settings described above from the workstation so they must be controlled by group policies.
One discrepancy is that I am seeing Administrators, Backup Operators, and Guests under "Allow Log on Locally" instead of Admins, backup operators, and users.
Out of curiosity I created a new basic configurator account (we just use administrators and basic operator) and am getting the same error on that account as well.
I think you may have stated the problem:
"One discrepancy is that I am seeing Administrators, Backup Operators, and Guests under "Allow Log on Locally" instead of Admins, backup operators, and users."
Notice that Users does not appear in the list. They will not be allowed interactive logon.
Now, go to your domain controller and determine which policy is controlling this setting, since you can't edit it on the domain member.
Run GPMC.msc. You can use the group policy modeling feature to determine which policies are inacted based on computer and/or user. The result should help you pinpoint which policies to focus on. Search each policy to determine which one(s) are writing the 'Allow Log On Locally' setting (which is a computer policy). You may have multiple policies fighting each other.
Thank you for your help on this issue.
I am a little confused by the wording of the "Allow Log on Locally" policy. Local log on to me means logging on to the workstation rather than the domain. I am assuming then that this "Allow Log on Locally" simply grants users the basic right of log on functionality(including logging on to the domain) rather than the right to log on to the local computer vs the domain. Is this correct?
Would this policy also be preventing these users from logging in to DeltaV?
Allow log on Locally: This logon right determines which users can interactively log on to this computer. Logons initiated by pressing CTRL+ALT+DEL sequence on the attached keyboard requires the user to have this logon right. Additionally this logon right may be required by some service or administrative applications that can log on users.
technet.microsoft.com/.../cc756809(v=ws.10).aspx
Controlling who can log into the computer or the domain at a computer is governed by the existence and proper membership/rights of the account at either the computer or domain, not only by the Allow Log on Locally policy. Domain accounts can (and should) be granted the right to log on locally provided they will require interactive sessions (as is the case for the DeltaV Pro station). The term 'locally' refers to the session type, not where the account is being authenticated. This is distinguished from the Remote Interactive logon type which means access via either a computer or domain account using a remote (RDP) session.
Arguably, Microsoft's terminology can be confusing. 'Allow log on locally' should probably read 'Allow log on interactive console' but I suspect it was originally named before terminal services, secondary logon, etc. existed, so there was only one kind of interactive logon.
Thank you for the explanation and all of your assistance. Adding the Users group seems to have fixed the problem.
I simply went in to the DeltaV workstations policy on the domain controller and added the Users group to the "Allow log on locally" setting. I did not find any other policies that were enabled and writing to this setting. I am guessing that our former employee who set the policies may have accidentally removed the Users group from this setting.