7

This article describes the (relatively laborious) steps you should go through to grant an Active Directory user the Log On As A Service right. However, if I install a service and manually specify my AD account's logon credentials (service properties | Log On), Windows tells me that 'The account [myaccount] has been granted the Log On As A Service right.' I can then run the service under my account credentials. However, on a subsequent reinstall of the service (or sometimes on reboot), the service is once again unable to start because of a login failure... until I go in and manually enter my credentials again, and the account is magically 'granted the Log On As A Service right.' After this, the service can once again start under my account's credentials.

What's going on here? Why do I apparently have the permission to grant this right to myself on-the-fly? If I can grant it on-the-fly, why doesn't it stay granted and I have to keep re-granting it? Bear in mind I'm not asking how to grant someone this right through Active Directory - I'm talking about the fact that this right appears to be 'auto-granted' by Windows upon your entering your credentials in the Log On window.

Jez
  • 1,333
  • 2
  • 11
  • 23

4 Answers4

8

It sounds like there is a group policy that defines the accounts that are granted Log on as a Service. Because you are an administrator you have permission to grant this privilege, but when the group policy re-applies the privilege will get removed. The next time the service stops it won't be able to start.

You should either change the scope / filtering of the policy so this machine is exempt from it or use the policy to grant the necessary privilege.

INFO FROM COMMENTS: To check if a group policy is applying the setting use the resultant set of policy wizard (rsop.msc)
If you want to apply this setting to many computers or can't remove an existing policy that defines this setting then use group policy to define it. There is a technet article that explains how to do this.
To check the current local security settings use secpol.msc - expand Local Policies then select User Rights Assignments. This will show the currently applied settings. If you have sufficient access and there is no group policy in effect then this will allow you to edit the current policy. If the add / remove buttons are diabled then a policy currently defines this setting.

If there is no policy in effect, then allowing windows to grant the user the right is perfectly fine and is just a convience feature provided by windows. As Jez discovered, if a policy IS in effect then it is pointless fighting it. Policy generally re-applies every few hours and will keep zapping any changes you have managed to make. (Although the service will carry on working until it stops for some other reason). Jez mentioned that he things a service is identified by a LUID generated at install time. I don't know if this is the case or not, but the Log On As A Service user right is not restricted to any particular service. So it won't make any difference WHAT service you want to log on as. One danger of letting windows assign the right for you is that you may forget to remove previous accounts and end up with a huge list of accounts that have the log on as a service privilege and no need for it.

So to answer Jez's comment a little more directly, if there is a policy in effect, there is no point finding ways round the disabled secpol.msc UI. The UI is disabled as a warning to you that any changes you manage to make will not be retained. In this case, editing the policy is the way forward, either to grant the privilege or to stop making that setting so that it can then be assigned locally.

EDIT: You seem to think that granting a domain user this priviege is somehow different to granting it to a local user. It isn't. If the PC/Server in question doesn't have any group policy applied then you open secpol.msc, go the privilege in question, double click, click add and then select the account you want. I've just tried this on a domain joined laptop and the add user dialog actually defaulted to the domain. If I wanted to pick a local group then I'd have to change the location.

If you double click the privilege then I assume you see the list and the add / remove buttons but the buttons are diasabled so you can't edit the list. This can't be becuase you are adding a domain account becuase you haven't yet selected whether to add a local or domain account.

I've run into exactly this problem at work, the service I was installing was only going on one PC so changing policy was not an option. We moved the PC in question to an OU where no policy applied, then I could grant the privilege without issue.

The reason you can grant the privilege the round-about way is that policy just disables the UI, it doesn't actually change the permissions you have. It does however re-apply itself periodically, which is why the setting gets overwritten.

pipTheGeek
  • 1,152
  • 5
  • 7
  • So how do you change the policy? Just because you have the permission to temporarily grant the Log On As A Service right doesn't mean you have the permission to log on to your AD server through Terminal Services, something you presumably need to do? It seems mad that you can temporarily grant this right, but not permanently. – Jez Jun 10 '11 at 17:37
  • @Jez Group policy trumps local policy in all things. By default, management of that setting is not handled by GPO; someone setting group policy decided that their domain setting should override local settings, so it does. Same with terminal services; if someone takes that away in group policy, it will be gone, no matter what you think the local settings "need" to be. – Shane Madden Jun 10 '11 at 21:50
  • @Shane Except that 'Log on as a service' on this domain is 'Not Defined', so actually the local setting isn't being trumped by a domain setting. I don't understand why the right being granted locally doesn't stick in this circumstance. – Jez Jun 10 '11 at 22:33
  • @Jez Are you looking at the Resultant Set of Policy? There can be more GPOs than just the default applying. – Shane Madden Jun 10 '11 at 22:38
  • @Shane How does one look at the resultant set of policy, as opposed to one particular group policy? – Jez Jun 12 '11 at 07:51
  • 1
    @Jez Start->Run->`rsop.msc` – Shane Madden Jun 12 '11 at 19:44
  • @Shane OK. Yep, Log On As A Service is still Not Defined in the RSOP. – Jez Jun 12 '11 at 20:03
  • @Jez Try to follow the first set of steps in the article you linked to in your question. In the fourth step, if there is a GPO affecting this, you will not be able to click the Add User or Group button because it will be disabled. If not, use this window to add the credentials you're using for the service. What results do you get for trying this? – Paul Kroon Jun 13 '11 at 11:57
  • @Paul That section of my Local Policies is indeed locked, because this is an Active Directory user account. – Jez Jun 13 '11 at 13:54
  • @Jez If that button is disabled, it should be because there is some GPO affecting it. You can test this by stopping any GPOs from applying to this server (if that's possible for you). After you ensure all GPOs aren't being applied anymore, check to see if you can alter this local policy. Another option you have is to see what users/groups are listed as having that user right. Perhaps there is some network service AD group that has the right, and you can just add the AD account to this group to pick up the permission. – Paul Kroon Jun 13 '11 at 14:39
  • @Jez - the only reason the local policy settings will be locked are because a group policy is in effect. It won't be anything to do with the type of account you are trying to add. – pipTheGeek Jun 14 '11 at 20:57
  • @pipTheGeek I've accepted your answer, but I'd appreciate if you could edit it to: emphasize the `secpol.msc` command - I found this very useful and it shows the current local security policy (at least in Windows 7) which applies to your current login, as a result of all the AD security policies being applied. Also could you add that it seems that services may have a UID generated for them in the registry and reinstallation *may* change this, requiring the right for the user to run the service to be re-assigned via the Log On window. – Jez Jun 17 '11 at 08:32
  • @pipTheGeek I say *may*, because this has mysteriously stopped happening for no obvious reason on my box now. When I reinstall the service, it does continue to login OK. Anyhow, you say that `secpol.msc` on the local box merely disables the GUI allowing you to assign new accounts the Log on as a service permission? It'd be useful if you could point people in your answer to some software or method in Windows to assign this permission without using `secpol.msc`, or being assigned it by the AD controller. Thanks to everyone for their answers on this question, it's been very informative! – Jez Jun 17 '11 at 08:35
  • @pipTheGeek Also forgot to mention, your answer might want to also mention the `rsop.msc` command, which is also useful here. – Jez Jun 17 '11 at 08:38
  • @Jez - thanks. How's that? – pipTheGeek Jun 19 '11 at 09:27
  • @pipTheGeek Looks good, but I'm not sure I agree with the whole "don't fight what's in `secpol`" thing. If Windows really wanted you to stop you fighting it, it wouldn't have the 'grant Log on as a service right on-the-fly' thing built right in and applying automatically, would it? – Jez Jun 19 '11 at 09:38
  • @Jez, yes, it would. Applying it automatically is a convenience that they simply forgot (or didn't think important) to make unavailable when a group policy is applied. Policy still wins, as I said in the text, the policy will keep getting re-applied; normally every couple of hours. – pipTheGeek Jun 20 '11 at 06:24
  • @pipTheGeek It just seems like a mess, though. What's the point in having a policy that says "don't let this user log on as a service" if Windows can and does do just that on request? And what's the point in nullifying that user's right? It's the worst of both worlds; not true 'security' against the user logging on as a service, but inconvenient for the user who has to keep granting themselves the right, as well. Whatsmore I don't think this is new to Windows 7; it's been happening since XP. It's hard to believe Microsoft didn't notice it... something about it seems to be by design. – Jez Jun 20 '11 at 07:08
  • @Jez, Group policy isn't about permissions, it is about pushing common configuration settings out to a number of clients easily. The permissions needed to edit the privilege assignment is to be a member of local administrators, which you have; otherwise you wouldn't be able to edit the privilege assignment or install software. – pipTheGeek Jun 20 '11 at 20:39
  • @pipTheGeek But there's a 'security settings' section of group policy; you're saying that's not about permissions? You can define which users are allowed to have the Log on as a service permission, in group policy. – Jez Jun 20 '11 at 21:11
  • @Jez :) yes, there is. I know what I mean and how I fit this discrepency in my head. I'm not sure I can explain it fully. I think, policy is for sending configuration settings, those settings may themselves be secuity related, even permissions, but the fact that they are being set by group policy doesn't make them more "stuck". If you have permissions to edit one of these settings then you can. However, if useful / practical, then MS will disable relevent UI to prevent an administrator from being confused by disappearing settings. Maybe you should ask Microsoft why it works as it does? – pipTheGeek Jun 21 '11 at 16:48
3

That article is describing ADAM (Active Directory Application Mode), which is quite different than your stock-standard Active Directory installation... Just worth considering.

Opinion time - I also believe that when you install (or reinstall) a service, it generates a UID for it in the registry. Some of it's settings are probably tied to that, including authentication.

Heglund
  • 61
  • 3
  • Right, but Windows seems to be saying that the user account itself has had the Log On As A Service right 'granted'. If that right has been granted to the account, shouldn't it stay granted? – Jez Jun 13 '11 at 08:13
1

Lets get this straight -

  1. You have a service running under your user account (in services.msc it displays your user account next to this service)
  2. To get this working in the first place you gave your account Log On As A Service rights
  3. Following a reboot or reinstall of the service, the service fails to start with a login failure error
  4. To fix this, you simply re-enter your credentials in the service configuration and start it

This implies that there is a problem with your saved credentials, NOT with you periodically losing the login as a service right.

First off, I would recommend creating a new user account to run this service under rather than using your credentials, set the password on the account to never expire and grant the account logon as a service rights. Best practice is to always use a dedicated account for software running as a service rather than re-purposing user accounts

Then see if you get the problem again, and if you do, try to work out exactly what was done to cause this to fail, i.e. Do you need to re-enter the credentials every time the server is restarted ?

Also, why are you reinstalling the service periodically ? Is there some other problem with this software ?

Jon Reeves
  • 438
  • 2
  • 7
  • **"set the password on the account to never expire and grant the account logon as a service rights."** How do I grant the rights? – Jez Jun 13 '11 at 13:49
0

This does not appear to be a right issue. Any chance your password is changing between restarts of this service? If so, you'll need to change reset it in the service settings. Better to create a service account where the password doesn't change

uSlackr
  • 6,337
  • 21
  • 36
  • No, the password isn't changing. The login failure (until I re-enter credentials in the Log On tab) occurs whenever I reinstall the service. – Jez Jun 10 '11 at 16:26
  • Log on as a service is a local right and would need to be assigned on every machine the service is loaded on. – uSlackr Jun 10 '11 at 18:34