Sentinel One - NMM Provided Azure Runbook Improvement

Avatar
John Tokash

Some time ago I realized that the provided Azure Runbook for deploying Sentinel One works great, but does not do a great job of reporting if there was an error.   Because S1 needs to be deployed after imaging (not as part of the image itself) in a typical shared user pool that is image driven, this has the potential for the S1 agent to NOT be installed, and noone knows there was a failure in the deployment.    Ultimately - inside Nerdio, no check and balance to ensure every device is protected.

I recently came upon a scenario where there was a bad API token value in the install script, and the S1 deploy failed.   Because of the nature of the runbook, it still reports a successful azure runbook execution.   I made some tweaks (you might be able to do better) - but wanted to share for 1 - any partners who use this and recognize the concern, and 2 - maybe we can get NMM to update their provided script to better capture this failure?

Old execution statement:

Set-AzVMExtension -ResourceGroupName $AzureResourceGroupName -Location $AzureRegionName -VMName $AzureVMName -Name "SentinelOne.WindowsExtension" -Publisher "SentinelOne.WindowsExtension" -Type "WindowsExtension" -TypeHandlerVersion "1.0" -Settings $Settings -ProtectedSettings $ProtectedSettings


My execution statement:

try {
    Write-Output "Installing SentinelOne agent on VM $AzureVMName..."


    $installResult = Set-AzVMExtension `
        -ResourceGroupName $AzureResourceGroupName `
        -Location $AzureRegionName `
        -VMName $AzureVMName `
        -Name "SentinelOne.WindowsExtension" `
        -Publisher "SentinelOne.WindowsExtension" `
        -Type "WindowsExtension" `
        -TypeHandlerVersion "1.0" `
        -Settings $Settings `
        -ProtectedSettings $ProtectedSettings `
        -ErrorAction Stop


    Write-Output "SentinelOne extension installation initiated successfully."
}
catch {
    $errMsg = "Failed to install SentinelOne agent on VM $AzureVMName. Error: $($_.Exception.Message)"
    Write-Error $errMsg
    throw $errMsg
}

 

Ultimately - when the Azure Runbook executes and it is not successful in setting the Agent Extension, we get an error condition that can be associated to a notification action, that can be escalated to appropriate places during reimaging.     I am sure there are simpler/cleaner ways to do this in less lines, but the end result is the same.  

1

Comments (5 comments)

Sort by
0
Avatar
Dave Stephenson

Thanks for sharing, John Tokash !

I incorporated your improvements (as well as changing out some of the secure variables for inherited variables) into the original script and uploaded that new version to our NMM-Sales Engineering GitHub repo.

NMM-SE/Azure Runbooks/Install SentinelOne agent.ps1 at main · Get-Nerdio/NMM-SE

Unfortunately, I'm not able to test it because I don't have access to an S1 portal, but hopefully it can help out someone else who stumbles upon this thread.
If it does end-up working, we could pass it through to our Product department and possibly get it into the product.

 

1
Avatar
John Tokash

Dave Stephenson - Thank you sir!   And you thought of something that was on my to-do list, but never got around to it, and this would have been the perfect opportunity to include it :-)

It would be beneficial to inherit the Agent Version only, at least in my unique case.   We get customers who bring their own, or have it through another provider.   So we find ourselves with a unique API Token and Site Token.   I'd been meaning to copy and work that in there so that we can update the Agent Version one time (when ready) - and the API/Site Tokens stay unique to the particular account.   What I'd -really- love, is the ability to have an inherited variable, that could be overriden at the account level.   That isn't quite in the scope of this thread, but food for though. 

That said, I can test this out here in the next week or so and let you know my findings. 

0
Avatar
Dave Stephenson

Thanks, John!

I wasn't sure which variables should be “secure” (encrypted) vs. “inherited” (clear text).
I've got no problems switching Agent Version to be inherited and the rest being secure.
Maybe we can have some more partners chime-in on that, or wait for your testing, before I change the script?

As far as having “Secure Inherited Variables” go, there have been quite a few requests for that, but our product team has run into some technical roadblocks around getting it to work.
Hopefully, they're able to work through those and we can get the feature 🙏

0
Avatar
John Tokash

Touche` - I had forgotten about that adventure.    My interpretation is that the API Key and the Site Token is indeed at least somewhat sensitive (encrypted data).   The Site token tells it where to talk to, the API Token gives it access to a given console to do ‘the things’ - view and download the agent from the console repo.

One could make the case, as long as it is appropriately secured, that the inheritance/override capability is key to making the default scripted action (azure runbook) the most valuable.   Otherwise, I'll keep it at the account level. 

I could make a case for the same, with the Agent Version.   We may wish to update some customers to a newer version faster than others. 

Either way - regardless of what gets done with the variables, the big win on my end and likely for other partners is the failure getting caught, logged and opportunity for action to be taken to avoid a system that is supposed to have S1, not having S1. 

1
Avatar
John Tokash

I'm going to circle with a knowledge S1 resource and come back.  I know the API Token is one that needs to be secure (as it gives permission to the console) - but I don't know enough about the Site Token.

I also have an idea surrounding the variables, assuming I am not missing something, I be we could adjust the script to look for the presence of an account level variable, if it is there, use it.  If it is not there, or is null, use the variable from MSP level.

It doesn't solve the secure challenge, but where applicable, could solve the challenge of certain accounts need to be ‘special’, such as an older(or newer) version of the agent, or going to a different Site Token than the default.

The challenge with ideas, is finding the time to work them out to see if they hold water. 

Please sign in to leave a comment.