I have a .PXF file used to strongly name several of our .NET assemblies. VS2010/MSBUILD seems to expect this to be in the personal container for the user account running VS2010/MSBUILD. This is all just fine and dandy when working in an interactive user account, but when atempting an automated build via TFS 2010 on the build agent the account used by the build agent (by default) is NT-AUTHORITY/NetworkService.
Since I cannot log in an interacive session as NetworkService I cant just install the PFX from an interactive sessions shell.
So can anyone tell me how I install a PFX certificate in the personal cert store of the NetworkService account?
Answer Courtesey of Richard Reposed from serverfault
You need to open the Network Service certificate store, and add it.
To open the store:
From Start | Run: mmc.exe
File | Add/Remove Snapins and select Certificates then Add.
When prompted for the type of account select Service Account
Select local/remote computer as required
Select any service that's running as Network Service
("Remote Procedure Call (RPC)" run as Network Service by default)
Finish the wizard and OK to close the add/remove dialog.
On the applicable catrgory right click and select add tasks to find the import etc. operations.
Related
I have installed several application on a BizTalk 2020 server using BTDF 5.8 where I used to the application settings in the deployment to update any config for the BizTalk applications.
My own account is part of the SSO admin group and I use the in proc host account to install the apps into the BizTalk server. The proc host account is also part of the SSO admin group.
When I view the SSO using the admin or client utility no apps are shown. I also downloaded and run the BizTalk-Server-SSO-Application-Configuration-Tool. The tool also showed no current installed applications, but was able to add an application with it config.
But ideally I would like to view and edit current config as I am currently getting an error on a server with incorrect value.
Is there another tool to view and edit settings or am I missing something that must be enabled.
in the past, we used VSTS build agents, running with domain accounts on on-prem build machines. In such scenario, certificates could be stored into the domain accounts personal store (manually, by logging in once with this account). So a later build could get the certificates by thumbprint for signing e.g. a manifest.
Now, the agents run with "Network Service", because we no longer have a local domain (all moved to Azure AD). All works, except the retrieval of certificates from the store. I already used the mmc snap-in to connect to the service (VSTSAgent), and installed certificates to this personal store, but still the build fails with "Error MSB3323: Unable to find manifest signing certificate in the certificate store.".
If I log-on to the machine and run from within VS, all works well, but of course here I am using a different account (with a different personal store), but this at least tells me that solution & projects are fine. And the pipelines are OK as well, because they still work OK on the "old" build-machines that use a domain account.
So, if anyone has an idea or can point me to some information on how to use the VSTSAgent running as "Network Service" together with signing (from the certificate store), that highly appreciated.
Many thanks, Sebastian
Windows Server 2016, ADFS, Certification Authority
I tried to create duplicate web server template, but it says that it's not an accessible. see below snap.
Now, My client is not technical, he provide me an account with most of the access, account is not an administrator, but I can assign many access to my self using AD Administrative service.
My only question is which access DO I need to provide to this account for creating duplicate web server certificate template?
In a multi-domain environment, I have had the same issue, if I did not select a domain controller in the root domain, respectively in the domain that hosts the CA. In my case, another domain was chosen by the console, because my computer for remote administration is in another domain (child domain).
Try the following:
Open "Certificate Template Console"
Right-click "Certificate Templates" in the left pane
Click "Connect to another writable domain controller ..."
Change the domain
click "Ok"
Try to duplicate once again. :)
I know this is an old thread, but thought I might add a fix that could help others. The account you use to login to the CA server should have Enterprise admin rights and should also be a member of local IIS_IUSRS group. If you have verified both, just logout and login to the box again and you should be able to duplicate a template.
I've checked that the TeamCity user has access to the network share in question.
All packages from the public NuGet feed are found correctly while packages available on the network share are not.
We use the network share when building via Visual Studio with the exact same path without a problem.
I've tried using "file://ratchet/NuGetRepository" but that doesn't make a difference.
TeamCity log entries and screenshot of the build step configuration shown below:
NuGet command: E:\BuildAgent01\plugins\nuget-agent\bin\JetBrains.TeamCity.NuGetRunner.exe E:\BuildAgent01\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe restore E:\BuildAgent01\work\95323b7041b60513\MySolution.sln -Source https://nuget.org/api/v2/ -Source \\ratchet\NuGetRepository\
Was able to solve this by specifying the fully qualified name of the network share, e.g. \\ratchet.hq.local\NuGetRepository.
Since the accepted answer did not provide a solution for my setup, I'd like to post what did allow TeamCity to access my network share.
First, a very important note: TeamCity Build Agent may either run as a Windows service or directly in command prompt. For my machine, this had the following consequences:
When run as a Windows service, the build agent was logged in as LocalSystem. For our network share, my machine's credentials were not given permissions.
Note: while this SO thread indicates that the network share can be configured to allow the machine's LocalSystem account to have permission, this was NOT an option for me.
When run in command prompt, the build agent will use the security context of whoever runs it (for me, it was my domain user). Again, for our network share, all domain users are given permissions.
The quick solution was to simply run the build agent in command prompt and call it a day; however, I did really want to run the build agent as a Windows service, since I think it is a cleaner approach.
Here's my solution:
First, I needed to grant my domain user the privilege to log on as a service. This is needed to run the service with my domain user's security context. I navigated to User Rights Assignment within Local Security Policy:
Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment
Next, I added my domain user to the Log on as a servcie setting. For this, I made sure to include the domain with my user name.
Now that my domain user's security context can be used when starting a service, I navigated to Services (services.msc), located TeamCity Build Agent, and edit its properties:
Now, when relaunching the TeamCity Build Agent Windows service, it would be able to access the network share since it was using the security context of my domain user. I can now access the Nuget repository on our shared drive and keep the build agent running in the background.
You can include the package sources in NuGet.targets file. Just find the commented lines and add your path.
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="\\ratchet\NuGetRepository\" />
My build agents are not starting after I change the properties credentials to the domain account from the network service. I done this because the network service account cannot write to my drop folder.
Each time I add the network service to the drop folder share, it appears then disappears.
http://msdn.microsoft.com/en-us/library/bb778394.aspx I followed this but some steps are different, i have xp and it doesn't show the share tab so i go through security tab
So I guess I'm asking two questions here;
Agents are not starting after changing credentials.
Network service not able to write to the drop folder.
Thanks in advance
Yes, Network Service won't have permissions to write to a drop location. That's pretty standard. You need to be using a domain account.
The TFS Build Service will need to run as a domain user so it can write to the drop location.
The domain account for the build agent will need to be in the TFS Project Collection group for build service accounts (internal to TFS). I can't remember what it's actually called but you need to be a collection administrator to update it.
The domain account will also need some login as batch/service permissions but that should be done automatically when you reconfigure the service. Do you use the TFS Admin console to reconfigure the agent or did you just set the credentials on the service? (You should use the TFS Admin console).