I added in Local Security Policy a non administrator account to Log on as a service. When I start/stop any service with credentials to this account (not as a Local system) everything works fine. However when I log in to this account and open Services I cannot manage any of them. Shouldn't I be able to manage services on this account if it has been added to log on as a service group?
Related
I'm trying to work around a problem with my Self-hosted Azure Pipeline agent. One of the workarounds listed here is to make the agent log on as myself, (instead of as the current, "Network Service" account it uses).
So I tried that. I went to the Services app, edited the "Azure Pipelines Agent" service and changed the user to be myself.
Windows then tells me that I'll need to stop the service and restart it. But when I do that, I get an error dialog with Error 1069: "The service did not start due to a logon failure"
I have tried to use both my Windows 10 Logon PIN (that I type to login when I sit down at the machine) as the password as well as my Azure AD password for our organization that lets me log on to all our resources. Neither one works.
I know I have the correct account. I don't have any other organization passwords that I know of. What am I doing wrong?
Change the logon user on DevOps agent services won't work.
If you'd like to run the agent with specific account, you need to uninstall the agent(config.cmd remove), then reconfigure the DevOps agent, type your account as below during the configuration.
You can validate the user account in DevOps pipeline with below task:
pool: self2
- script: whoami
I work in a team that uses Azure Service Fabric and I want to connect to an Azure SQL database using my Azure AD account instead of using a SQL username/password when running locally.
Service Fabric runs locally on a cluster and runs as the NT Authority\Network Service user. I believe that it's possible to change the user that it runs under, but when I tried it seemed to remove the ability to use Visual Studio to debug the app. It also required having the password in the config which is not ideal.
I'm trying to login to Azure AD with the AzureCli and the az login command and can do this easily with my local user azuread\chester.
A comment on github suggests that I should be able to run a powershell prompt as the network service and use az login to login with my account. When I tried this it failed with a generic error:
Does anyone know if it's possible to login to AzureAD with the NT Authority\Network Service user?
I know it's possible to use an Azure App Registration as a principal, but this method still involves a password and i'm trying to avoid passwords.
It is perfectly possible but, since it's a non-interactive account, the optimal choice is to login as an application. This, however, implies high level permissions so careful attention must be paid when consenting them. Also, it's possible to login as a user using the ROPC flow, however this one is not recommended due security and technical limitations.
Regarding az cli take a look at Sign in with a service principal.
I have a Windows 2019 container started with a valid CredentialSpec from a valid working gMSA account. It currently hosts a .NET 4.x application on IIS with Windows Authentication working just great. I can also execute nltest commands successfully and communicate to the domain controller.
I want to run a Job or Process as a domain user (MyDomain\UserABC). All of my attempts have failed:
Execute start-process with a credential object errors out with:
he security database on the server does not have a computer account for this workstation trust relationship.
Using a scheduled job as NT AUTHORITY\NetworkService fails to access the web because it is not using the gMSA credentials but the Network Service credentials.
Create a scheduled job with a Domain User results in the same error as above:
he security database on the server does not have a computer account for this workstation trust relationship.
Any other ideas?
Sounds like cached credentials. Maybe you can take a look on this link:
Site single Domain
I've got a VM running Windows 10 somewhere (with internet access). It is hooked up to Azure AD, and I can sign in with my domain credentials. Now I need to run a service as another user in Azure AD (it's actually a service account) since it's got all the correct permissions.
When I try to set it naively, I get an error about which says (approximately) that the domain is not in my list of locations.
Is there any way for me to do this?
I was installing the filebeat application and I noticed that I needed to run powershell as administrator in order to install them. When I checked the service using wmic service get name,startname,status it showed Local System. I'm wondering what this account is as this is neither the user account or the administrator account. Will this always be the case when I install services as administrator? What is the difference if I install it as a normal user and as administrator?
In any case, I've set this service to start automatically when windows start. Would this service start only when the user I used to install it logs in or will it start regardless of which user logs in?
OK, let's unpack that one by one, in no particular order:
Only a user with administrator rights can install a service.
Services that are configured to start automatically are started as soon as Windows is up and running; Windows does not wait until somebody logs in. It makes no difference to the service who the logged-on user is, or whether anybody is logged in at all, unless the service application itself has been explicitly programmed to check.
The program that installs the service decides what account the service uses to run. Windows doesn't care what user account was used to install the service, it doesn't even keep track.
If the program that installs the service wants it to use an ordinary user account, it must know the password for that account. There are various special accounts that a service can run in, these accounts do not require a password. One of these special accounts is Local System.
Local System is the highest-privilege service account in Windows; it has all the same rights as an administrator, and can do things an administrator can't. Local System is also the account that the user-mode part of Windows itself runs in, roughly equivalent to the UNIX root account except that it doesn't have a password.
Additional notes, for completeness:
One alternative to Local System is for the service to run as Local Service or as Network Service, which are non-administrative service accounts. The only difference between the two is that if the computer is joined to an Active Directory domain, the Network Service account has network access to other machines in the domain and the Local Service account does not.
It is also possible to configure a service to run in a special service account that is unique to that particular service. This is mostly useful if you want the service to have access to a particular file or folder, but do not want to give it administrator rights.
Nitpickers corner:
It is I believe technically possible to reconfigure Windows to allow non-administrators to install services, but this is not supported and would be a Very Bad Idea. If you did, though, it would still make no difference who installed the service. Windows doesn't record this information.