I’m running 5.0.14.
@Jesse.Peden - Thanks for answering this mostly I think (or maybe you did answer it fully, but I don’t understand) in the other thread. I wanted to start a new one as not to side track on that thread too much.
What are the best practices for working with service accounts that has write access to AD and Entra when the gMSA account can’t inherently read the secrets?
Do I need to create a Secrets reader apptoken that sits in the automation script as clear text?
Can I pass the roles on from the end user using the App to use that to retrieve the secret?
I’ve looked at the documentation, and I can’t figure out what the best option is when using a gMSA.
1 Like
The new “Integrated” mode in 5.0.15 may be just what you’re looking for, so you don’t need to authenticate internally.
Check out Module | PowerShell Universal for more details.
Will that work for pulling secrets too?
Can you assign the gMSA account roles?
This is something you set in appsettings.json, and would mean that you don’t need to worry about figuring out how to access the Secret variables or having a token in plain text at the top of your scripts. This, unless I misunderstood the description, would allow PSU to talk internally without the need for context or authentication, just like it did with 4.x
I can’t answer that other question.
1 Like
I’ll need to access secrets to connect to Entra. What is the best practice for that?
I’ve upgraded to 5.0.15 and turned on “integrated” “SecurityModel”. Rebooted the server.
In an Automation Script (Job) I’m running:
Invoke-RestMethod -Uri “https://PSUServer.domain.com/getuser/someusername” -Method Get
The endpoint has authentication turned on.
The script fails with a 401.
If I use an apptoken it works. Any ideas?
I’m also unable to test the endpoint directly under Endpoints. I get a Client Error 401. This worked in v4.
I can’t say for sure but, the option may be case-sensitive, in case you entered it as “integrated” rather than “Integrated”. I haven’t actually tested the new mode myself, so it may not work properly. @adam may need to step in to explain how the new mode works.
For your command, Invoke-RestMethod -Uri “[https://PSUServer.domain.com/getuser/someusername](https://psuserver.domain.com/getuser/someusername)” -Method Get, am I correct in understanding that you’re issuing this command outside of PSU (like on your laptop)? You’d still need to authenticate to that if you’ve got authentication enabled on that Endpoint (API). That has nothing to do with what this new mode is for. The new mode is for when PSU needs to talk to itself internally, such as to access Secret variables, or to access cmdlets internally, etc.
No, this is run in an script under the Automation tab. I’ve tried both with and without “-Method Get”, just to be clear.
The appsettings.json has “Integrated” for the security model, with the “I” capitalized.
Okay. Just to make sure I understand, you have a script in the Automation section of PSU that’s calling an Endpoint (API) also in PSU?
And, you’re saying that this command in the script isn’t able to invoke the API unless you include an app token in the header of your Invoke-RestMethod command?
If so, that is expected behavior due to you having Authentication enabled on the API.
If I got something wrong, please clarify.
You could also use something like this to get a set of PSCredentials from a GMSA account, then throw it at the -credential parameter.
Ryan2065/gMSACredentialModule
From the docs page:
Integrated Mode
Integrated mode uses the internal PowerShell Universal backchannel connection to communicate with the services via the Universal module. When using Integrated mode, call context is not provided to the services. This means that no authorization or authentication is performed. Integrated mode is useful in environments that do not require any security for internal API calls. It also bypasses the need to configure certificates or API URLs.
and
Integrated mode does not use the external API and communicates across the gRPC backchannel of PowerShell Universal. There is no need to configure API URLs, certificates or credentials.
I read the above as authentication isn’t used for internal API calls, i.e. you can set access roles on the APIs, but the API ignores the roles when the caller is internal, like a script (job).
Is that not how it works?
If it isn’t, how do I then secure my APIs but can still access them from a job without an access token, or is that not possible?
Thanks for the suggestion. The gMSA would have to be updated every 30 days when the password changes. Was hoping for a builtin way of getting to the secret with the roles I have assigned to the gMSA.
Thats supported, just include the module in the script and build the credential at runtime 
Given:
- gMSAs define who/what can get the always rotating creds (computer or
- PSU runs as gMSA service account (ie - gMsaPsu)
Setup:
Let’s say you run a script in PSU. It executes in context of gMsaPsu. This can retrieve gMsaPsuAdAction, you can use gMSACredentialModule to handle the call.
$cred = Get-GMSACredential -GMSAName 'gMsaPsuAdAction' -Domain $env:userdnsdomain
Invoke-GMSACommand -Credential $cred -ScriptBlock {
Add-AdGroupMemmber -Id $group -Members $member
}
Pretty much other methods of unattended action rely on a chain of trust and secrets cryptographically. The nice part here is all the secrets in this chain from machine account, psu service account, ad action is now rotated by AD automatically now.