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
Related
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.
When I running my Azure Devops build pipeline for a UWP app locally via a private Windows Agent, it complains that it cannot access C:\Program Files (x86)\Windows Kits\10\App Certification Kit\SupportedAPIs-x86.xml
The agent service is using the default suggested user NT AUTHORITY\NETWORK SERVICE.
So far I tried, without success:
to run the service with my (admin) credential (I'm using an hotmail account to log on my machine) but it doesn't want to (error 1355)
give `Everyone` `Read & Execute` rights on the folder the service is denied access to
I dont know if you're still having this issue but this is what worked for me. Anyone else that finds this can try this out.
I would recommend trying this out as a sanity check, but my issue was permissions.
If you run services.msc and find Azure Pipelines Agent then click
on the service to highlight it.
Right click, go to properties
Navigate to the Log On tab at the top
Change the username and password to a known domain admin account
Click ok and restart the service.
Now run your pipeline again and see if it can connect and publish your files. If it does then its a user/permissions issue.
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.
I'm trying to create a release definition in Visual Studio Online with the task "Deploy Azure App Service".
When I try to authorize for the subscriptions it gives this error message below.
Error(s):
Insufficient privileges to complete the operation. For troubleshooting refer to link.
The content of the link they provide doesn't seem to help me.
I already tried this using Azure Service Administrator account.
Why is this happening? What are the kind of permissions i need for doing this?
The user must be a member of Global Admin role in the directory.
On the other hand, you may configure it manually with this PowerShell script.
More information, you can refer to Automating Azure Resource Group deployment using a Service Principal in Visual Studio Online: Build/Release Management (Manual configuration section)
Download & run this PowerShell script in an Azure Powershell window to
generate required data for Service Principal based Azure service
connection. Running this script would prompt you for:
The name of your Azure Subscription name
A password that you would like to set for the Service Principal that is going to be created
Note: the script has been tested with Azure PowerShell version 1.0.2.
Once successful, the script would output the following details for the
Azure Service Endpoint.
Connection Name
Subscription Id
Subscription Name
Service Principal Client Id
Service Principal key
Tenant Id
I am new to TeamCity and currently installing it.
It was asking whether I want to be running the server under a "user account" or "the SYSTEM account" / running the agent under a "user account" or "the SYSTEM account".
I assumed that since my version control (clearcase) is configured to my employee id, I should select user account.
Is my assumption correct? When should either the SYSTEM account or a user account be used? What is the difference between them?
What you're talking about is allowing TeamCity to run as LocalSystem vs a specified user account (local or in ActiveDirectory). LocalSystem is highly privileged (see this article).
If you are interested in following the principle of least privelege, you should create a user account. If you're running TeamCity on your local workstation, LocalSystem is probably ok.
The same advice applies to the build agent.
The main difference for you as the user can be connection of the TeamCity to some remote repositories. I.e., you have an SSH authentication with keys configured in your user account, to access a git repository. From the user account you will be able to configure it almost out-of-box. But it will take time to configure authentication for system account.