We are planning to implement Local Administrator Password Solution, but the first thing I wondered was how inconvenient it would be for support engineers and helpdesk staff to retrieve LAPS account and password. Log into the Intune portal, navigate to the devices tab, search for the device, and dig through the properties to find the LAPS password — every single time they need an admin account. That had to be faster.

So (with some help of a good friend) I built the LAPS Portal: an Azure Web App with an Azure Function App as the backend, secured by two app registrations for authentication and Graph API calls. It runs at no extra cost and works on any device. Especially useful when you’re standing next to a device in the field and need the LAPS account and password right then and there — just open the portal on your phone, type the device name, and you’re done.

Here is exactly how you can set this up.

What You Will Build

• An App registration (backend) to call Microsoft Graph with the correct permissions.
• A Resource group for all your Azure resources.
• An Azure Function that queries Microsoft Graph for LAPS information with the App registration.
• A Log Analytics workspace so every lookup can be tracked by user.
• An Azure Web App that hosts a simple password and LAPS account lookup interface.
• An App Service Authentication so only authorized users can access the portal

You need an active Azure subscription with Owner permissions in order to realise the LAPS portal.

Step 1: Create the App Registration for the Backend

This app registration is used by the Azure Function to call Microsoft Graph.

Go to Entra ID → App registrations → + New registration

• Name: view laps data
• Supported account types: Single tenant
• Redirect URI (optional): leave as is.
• Click Register

Go to Certificates & secrets → + New client secret → Enter a description: LAPS-data-secret and set the Expires to: Recommended: 180 days → Add

Copy the Value and keep it save you will need it later in step 4.

Go to API permissions → + Add a permission → Microsoft Graph → Application permissions → Add:

• Device.Read.All
• DeviceLocalCredential.Read.All

Remove permissions User.Read. Click Grant admin consent for …

Click Yes.

Step 2: Create the Resource Group

Go to Resource groups → + Create

• Subscription: select your subscription
• Name: rg-laps-data-portal (the name you prefer)
• Region: West Europe (your desired region)
• Click Review + create → Create

Step 3: Create the Log Analytics Workspace

Go to Log Analytics workspaces → + Create

• Resource group: rg-laps-data-portal (the RG your create before)
• Name: law-laps-data-portal (name you prefer)
• Region: West Europe (your desired region)
• Click Review + create → Create

Once created, open Azure Cloud Shell

Choose PowerShell when asked.

Run the following script to retrieve the Workspace ID and Primary key:

$law = Get-AzOperationalInsightsWorkspace -ResourceGroupName "rg-laps-data-portal" -Name "law-laps-data-portal"; Write-Host "Workspace ID: $($law.CustomerId)"; Write-Host "Primary Key: $((Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "rg-laps-data-portal" -Name "law-laps-data-portal").PrimarySharedKey)"

Note both output values — you will need them in Step 4 for the Function App environment variables

Step 4: Create the Azure Function App

Go to Function App → +Create

• Select hosting option: Consumption (Windows) and Confirm.
• Resource group: rg-laps-data-portal (from step 2)
• Function App name: laps-Graph-portal (name you prefer)
• Runtime stack: PowerShell Core
• Version: 7.4
• Region: West Europe (your desired region)
• Click Review + create → Create

Click: Go to resource.

Settings → Environment variables → App settings → + add:

After adding the variables click: Apply → Confirm

Go to the Overview → Create in Azure portal.

Select: HTTP trigger → Next.

• Name: GetLapsPassword
• Authorization level: Function → Create

In Code + Test → replace the run.ps1 content with the content of the Function script from the GitHub repo and click Save.

Click Get Function URL → copy the URL including the function key, we will need this in step 7.

Step 5: Create the Web App

Go to App Services → Create → Web App

• Resource group: rg-laps-data-portal (from step 2)
• Name: laps-data-portal (name you prefer)
• Runtime stack: PHP 8.5
• OS: Linux
• Region: West Europe (your desired region)
• Linux plan: Create new: ASP-LAPS-data-portal → OK

• Pricing plan: Free F1 (free)
• Click Review + create → Create

Click go to resource.

Note/copy the URL from Default domain on the Overview page — you need this in the next step.

Step 6: Create the App Registration for the Frontend

This app registration is required before you can enable App Service Authentication in Step 8. You need the Web App URL from Step 5 to complete this step.

Go to Entra ID → App registrations → + New registration

• Name: LAPS-Portal-frontend (name your prefer)
• Supported account types: Single tenant only
• Click Register

Note the Application (client) ID — you will need this in Step 8

Go to Manage → Authentication (Preview) → + Add Redirect URI

Choose Web (not SPA)

• Enter Redirect URI: https://<default-domein-url-from-step-5>/.auth/login/aad/callback
• Check ID tokens

• Click Configure.

Grant admin consent to prevent permission prompts

To ensure no users in your tenant see a permissions consent prompt when opening the portal:

Go to Permissions → click Grant admin consent for <your tenant>

Click Yes.

Remove the permission:

Step 7: Deploy the Frontend

Go to App services → Open the web app your created in step 5 → Development Tools → Advanced Tools → Go → (opens Kudu)

Open File Manager → navigate to site/wwwroot

Drag and drop index.html and proxy.php from the GitHub repo into the file manager and delete hostingstart.html.

NOTE: Do not upload the files but drag and drop them, because then an upload glitch can happen as you can see below.

Correct upload:

Wrong upload:

proxy.php acts as a server-side proxy between the browser and the Azure Function. The real Function URL and key are stored as a Web App environment variable (FUNCTION_URL) and never exposed to the browser.

Add the FUNCTION_URL environment variable to the Web App

Go to the Web App (laps-data-portal) → Settings → Environment variables → App settings → + Add:

Click Apply → Apply → Confirm

You can now test the laps portal by browsing to the Default domain URL from step 4:

Enter an Intune devicename and click Retrieve to check the LAPS data.

Step 8: Enable App Service Authentication on the Web App

Now that the LAPS portal works we want to enable authentication before anyone can access the LAPS portal web app.

Go to the Web App (laps-data-portal) → Settings → Authentication → Add identity provider

Choose Microsoft

App registration type: Pick an existing app registration in this directory

Select LAPS-Portal-frontend from Step 6

Client secret expiration: 180 days

Unauthenticated requests: HTTP 302 found redirect:…

Click Add

All you tenant users are now automatically redirected to Microsoft login before they (all tenant users) can access the portal, which is a bit much.

Step 9: Restrict Access to Specific Users

To limit access to the LAPS Portal we can assign access to a specific Entra ID group with (IT support) members.

Go to Entra ID → Enterprise Applications → LAPS-Portal-frontend (From step 6)

Properties → set Assignment required to Yes → Save

Users and groups → Add user/group → assign your admin group

Now users NOT a member of the added group will see this when logging in the LAPS portal web app:

Optional: Enforce MFA and Session Timeout

To require MFA (Microsoft Authenticator) and automatically sign out users after 30 minutes of inactivity, configure a Conditional Access policy:

Go to Entra ID → Security → Protect → Conditional Access → + Create New policy

Name: LAPS Portal - Require MFA and Session

Users: select the group that has access to the portal (Step 9)

Target resources → Select resources → select LAPS-Portal-frontend

Grant → select Grant access → Require authentication strength → Select Multifactor authentication, click Select.

Session → Sign-in frequency → Periodic reauthentication → 1 Hour

Enable policy: On

Click Create.

Now user who sign in the LAPS Portal must complete a MFA step.

View the Audit Log

Every lookup is logged to Log Analytics with the user’s UPN, device name, IP address, and result. To query the log:

1. Go to your Log Analytics Workspace → Logs
2. Run this KQL query:

LAPSPortal_CL
| extend LocalTime = TimeGenerated + 2h
| project LocalTime, CallerUPN_s, DeviceName_s, AccountName_s, CallerIP_s, Result_s
| order by LocalTime desc

+ 2h converts UTC to Central European Summer Time (CEST). Use + 1h in winter (CET).

It can take up to 30 min. after the first retrieve from the portal before the log query returns data.

Save the query via Save → Save as query so you don’t have to retype it. You can also pin the results to your Azure dashboard via Pin to → Azure dashboard for quick daily access.

Conclusion

With just a few Azure resources and no custom authentication code, you now have a secure, mobile-friendly LAPS portal that any authorized helpdesk engineer or IT administrator can use from anywhere — whether they’re at their desk or standing next to a device in the field.

No more navigating through the Intune portal to find a LAPS password. Just open the portal, type the device name, and you’re done.

A few things to take away from this build:

• App Service Authentication secures the portal without writing any authentication code — Azure handles the entire login flow automatically.
• Store secrets as Function App environment variables, never hardcoded in scripts — this keeps sensitive credentials out of your source code and version control.
• Every lookup is logged with the caller’s UPN, device name, IP address, and result — giving you full accountability and a clear audit trail of who accessed what and when.
• Don’t forget to configure Conditional Access with MFA and a session timeout — this adds an important extra layer of security on top of the portal authentication.
• The first start/sign in to the LAPS portal can take a bit longer. When the Function App has been idle for a while, Azure deallocates the underlying infrastructure to save resources. The first request after a period of inactivity forces Azure to spin up the PowerShell runtime again, which takes 10–30 seconds.

The total Azure cost for normal internal use is effectively zero — the Function App runs on a Consumption plan and the Web App on a free F1 tier.

Flowchart

So I put all the created components and their relationships into a flowchart.