Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I just spent the better part of this morning on a support call with a vendor where we eventually resolved our issue by manually adding the service account their application was using to the following Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/User Rights Assignment policies which were being set by a Domain GPO:

  • Back up files and directories
  • Log on as a batch job
  • Restore files and directories


After rebooting the server and getting the updated GPO our service account no longer generated the following Event 4625 - Logon Type 4 audit events when attempting to start the application:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          7/22/2013 9:27:04 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      server.constco.com
Description:
An account failed to log on.

Subject:
    Security ID:        SYSTEM
    Account Name:       server$
    Account Domain:     constco
    Logon ID:       0x3e7

Logon Type:         4

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       service-account
    Account Domain:     constco

Failure Information:
    Failure Reason:     The user has not been granted the requested logon type at this machine.
    Status:         0xc000015b
    Sub Status:     0x0



The vendor's documentation instructed us to add the service account to the Backup Operators and Power User Local Groups - which we did. Reading the Explain tab for each one of the required User Right Assignment policies indicates that the Backup Operators have those Rights by default (TechNet seems to confirm this). Incidentally, there's no mention of Power User being assigned those Rights that I can find so I'm not really sure why that was a requirement.


  • Why did we have to explicitly assign that service account those Rights (Back up files and directories, Log on as a batch job, Restore files and directories) when it already should of had them by virtue of being a member of the Backup Operators Local Group?

  • What is the relation between the User Rights Policies and the builtin Local Groups? Are User Rights Polices the constituent parts that make up the "meta"-rights of each builtin Local Groups? If so, where can I find which Rights belong to which bultin Local Groups?

  • As stated we resolved this issue by adding our service account to the Group Policy Object that is manually assigning a number of service accounts these specific Rights. I got the sense from the vendor's engineer that this GPO is interfering with the mapping of these constituent Rights to Local Groups. Is this hunch correct? Is assigning constituent User Rights this way a Bad Idea (TM)?

share|improve this question
add comment

1 Answer 1

up vote 1 down vote accepted

Members of local built-in groups (as well as domain groups) have whatever rights are assigned to the group. The default rights on a server for local built-in groups are set in the local security settings. To access the local security settings, click Start, type secpol.msc and hit enter. In the Local Security Policy editor, expand Local Policies, and click on User Rights Assignment. There you will see what groups/users are granted which rights.

The local User Rights Assignment settings can be overriden by domain group policy. If you create a domain group policy that grants certain groups/users a certain right, such as "Logon as a batch job", this will override the local policy for which users have that right.

From what you have written, here is what I am guessing happened: You had a GPO in your domain that granted certain users the rights that you mentioned. This policy did not grant these rights to local machine Backup Operators group. This policy overwrote the default policy on the server. Thus, adding the user to the Backup Operators group did not give them those rights because, due to the Domain GPO, the Backup Operators do not have them.

As to whether or not the vendor's solution is a good idea: I have found that it is usually easier to manage rights by using well-organized groups rather than granting them to individual accounts. This way, when you add a new user, you add the user to the logical groups to which he belongs, and he will immediately have all of the rights he needs rather than having to assign him each right one-by-one. That is what the Built-in groups were intended to do.

Instead of granting those three rights to an individual user, you could have granted the "Backup Operators" group those three rights in the GPO. Then adding the user to that group would have the intended effect.

I am curious why you would have a domain policy managing those rights in the first place. If the purpose was to grant certain users access to perform backup operations, it might have been a better idea to use the domain built-in Backup Operators group.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.