Serverless LAPS using Azure function and Secret Key Vaults

Step 1 – deploy azure function app and configure

Create an azure function app:

Create the storage account and set plan type as default settings:

Monitoring defaults were accepted (change if required):

Azure function was then reviewed and created with the settings defined above.

Once the function app was created browse to the app:

Click Identity;

Enable system assigned and save:

system assigned managed identity enables Azure resources to authenticate to cloud services (e.g. Azure Key Vault) without storing credentials in code

Now click on TLS/SSL settings and ensure min TLS is set to 1.2 and https only has On:

Step 2 – deploy azure key vault and grant permissions

Create a key vault in Azure:

For testing i created in the same resource group as the function app

On ‘Access policy’ click the Option Add Access Policy:

Now set the Secret permissions to ‘Set’ and then select principal:

In the Select Principal add the function app created previously:

Then click Add once the function app has been selected

The account will now be added to the main Access Policy:

Networking was set with the default public endpoint:

Review and create the key vault:

Step 3 – Create and test azure function

Browse to the function app in Azure then select Functions in the menu and click Add:

Now select HTTP Trigger from the template options:

I left the template details as default and then Added the function:

Suggestion – name the template to KeyVaultSecret

Once added the http trigger will load:

Now open the Code + Test and remove all the code pre populated:

Copy the ps1 script from the following location:

SLAPS/Set-KeyVaultSecret.ps1 at master · jseerden/SLAPS · GitHub

Paste the code into the Http Trigger and replace the variable on line 8 to your key vault created earlier:

Original:

Updated variable:

Save the script

Next action is to test the script, click on Test/Run:

Browse to the following code:

SLAPS/New-LocalAdmin.ps1 at master · jseerden/SLAPS · GitHub

Copy and paste lines 46 to 52 from the script:

{	
	"keyName": "$env:COMPUTERNAME",
	"contentType": "Local Administrator Credentials",
	"tags": {
	"Username": "$userName"
	}
	}

For test purposes replace the values above with a test machine and a test username, example:

{	
	"keyName": "W10TEST-BFG",
	"contentType": "Local Administrator Credentials",
	"tags": {
	"Username": "localadmin"
	}
	}

Copy this test values and paste into the Input test run into the Http Trigger function:

Now run the test script input:

Should the input by valid then you will get an output of a password which would have been generated:

NOTE – it failed first time as the last bracket when copied and pasted did not work in the position it was, line 7 ending bracket had to be placed in the first available character space

As you can see from a couple of images above the spacing is now missing and this allowed the script to run.

Now the Test has completed browse back to Azure Key Vaults and select Secrets from the menu and the machine will now be present from the test run:

You can now browse into the machine and then the secret value will be present:

You can now view and copy the password.

Step 4 – Deploy script to Intune

Next action is to run the full script instead of the test selection, save the following script which will be deployed through Intune:

SLAPS/New-LocalAdmin.ps1 at master · jseerden/SLAPS · GitHub

REMEMBER TO CHANGE THE VARIABLES TO MATCH YOUR AZURE FUNCTIONS AND KEY VAULTS AS PER BELOW

Line 31 – change the admin name to your requirements

Line 34 – change the URI

To get the URI required browse to the function app and select ‘Get function URL’

Change the option to master under key:

For test purposes the script was just added into the powershell scripts within Intune but it’s advised to wrap up the script into a win32 application for better reporting.

Once deployed the script will succeed:

On the test device the local admins were previously set with the objects:

After the script had deployed the local admin account was created:

The machine was then available in the azure key vaults and the secret password was available:

NOTE: The script was deploying to the hostname of W10-BFG but failed to load the secret key, later this was found because the test run done earlier i used the same hostname and deleted the record therefore a historic record with that hostname was stored: