My system administrator made a gMSA for me to use with my work with containers. I am able to do the simple things with it (like test that it is working correctly).
But I cannot figure out how to use it for more than hosting and such.
How can I use the gMSA to make a call to a service that does Active Directory integration?
The specifics of my scenario are this:
I have a ProGet server that hosts a Chocolatey feed for me. It is setup to be integrated with Active Directory.
When I run a choco search command using my own machine, it works just fine.
when I run the same choco search command from the container it fails with an error: Not able to contact source 'http://MyLibrary/nuget/Chocolatey/'. Error was Expected an absolute, well formed http URL without a query or fragment.
If i run curl MyLibrary/nuget/Chocolatey I get a valid response, though the page content says access is denied. (So I know I can connect, but cannot authenticate.)
I have added my gMSA user to my proget Chocolatey feed
Related
We just upgraded from TFS 2017 to ADS 2020. The ADS runs in one domain and the build server runs in another. All appropriate cross-domain permissions are set up - these domains talk all of the time every day.
I had a service account created for the build server from the ADS domain for the ADS pipeline to run under (even thought the machine is on the other domain) and when we first tried this I got errors that the build didn't have access to write to the registry. This despite the service account (which again is on a different domain than the build server) is in the Administrators group on the build server. At some point that error went away, but now I get an error trying to run a PowerShell script from the build.
Just to summarize, Build Server on Domain1, ADS Server on Domain2, Service account running pipeline is on Domain2, but is part of the Administrators group on Build Server (Domain 1). Pipeline runs fine up until it tries to execute a PowerShell script and then gets an error saying the permissions aren't there to run a script.
Hope this all makes sense.
I have a whole bunch of GMSA used throughout my org. I'm able to see through AD what machines have permissions to install the GMSA but cannot find a way to see what machines have actually gone through the Install-ADServiceAccount step to actually have the GMSA installed.
An older post How can I see if a Groupmanaged Service Account is installed with Install-ADServiceaccount? suggests usingGet-ADServiceAccount and checking the HostComputers property but I only see this populated for MSA. For GMSA it's blank.
Any ideas on how I can get this without needing to connect to each machine and running Test-ADServiceAccount for each permitted GMSA? (especially given the whole PSRemoting and network access that causes problems) A WMI/CIM query I could run would be second to actually getting the data centrally from AD.
Thanks for any help.
We're trying to get our first containerized build running in Azure Devops Server.
The build runs fine in the container, but, unfortunately, it needs to access resources on another server. As such, I need this to be running as a domain user (GMSA account will work) so that it can authenticate the network share to access those resources.
I can't seem to find any documentation on running a containerized build as a specific user.
Can anyone point me to how to setup the yml for passing credentials, or gmsa account? That would be great.
Thanks in advance
Alright... so I figured it out.
First you have to create a credential spec
In powershell New-CredentialSpec -AccountName GMSAAccountName
Then add this in the yml file beneath the container declaration:
options: --security-opt "credentialspec=file://Domain_GMSAAccountName.json"
That was it... and now it works.
Have you tried using PAT(Personal Access Token) to run in agent build?
When setup asks for your authentication type, choose PAT. Then paste the PAT token you created into the command prompt window.
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops#permissions
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\" />
I have been maintaining an installation for a while but I am not really an expert. now I've been asked to come up with a solution for this:
Our software is always sold together with a computer as it has to be run in a very controlled environment. The installer needs administrative privileges to be executed. So far we had two different users, one with administrative rights and other one without. Our custumer service login as Administrator, install the software and restart the machine so that the user can access as a normal user.
Now we want the user to be able to install the software themselves but we don't want them to have access as an administrator because they can modify things it shouldn't be modified.
So, is there any way to programmatically raise the user privileges during the installation and afterwards lower them back? The installer is made using InstallShield but we use vbscript to check some pre-requisites.
Check out CPAU. It allows you to create an encrypted command that will run the installation as administrator.
EDIT: This is a more comprehensive list of like tools.
If you are looking for a toolkit to do this kind of thing, well, Microsofts MSI technology has this built in: Administrator access is required to install the initial MSI file, additional patches (MSPs I think) are digitally signed by the original MSI and are thus deemed safe - users can install them without requiring administrator elevation.
You can do the same thing: As part of your administrative install, install a service. The service can create a named pipe - that you explicitly give user ACLs to - or even just a socket or monitor a drop off folder that allows the user level code to communicate with the service code (running with SYSTEM or configured access). The service can then use its SERVICE or configured account level permissions to either impersonate an administrator, or do other tasks on the behalf of the user without EVER giving the user any kind of elevated permission - even temporarily.