How to Automate Okta/Azure Provisioning for Multi-SaaS Clients

Multi-SaaS clients need centralized identity provisioning to reduce onboarding time, enforce consistency, and maintain access control. Okta and Entra ID (Azure AD) support SCIM and API-based provisioning to automate user lifecycle management across cloud applications. Automating this process reduces manual errors, speeds up provisioning, and enforces access policies from day one.

This guide explains step-by-step how to implement automated user provisioning in Azure and Okta.

Phases and methods to automate user provisioning for multi-SaaS clients

For MSPs, automated user provisioning removes manual, app-specific user creation, reduces the risk of human error and delays, and enforces consistent, role-based access across systems. Here’s how to automate Okta/Azure provisioning:

Phase 1: Build a role-based provisioning model

In this phase, you define a standardized structure where users are assigned roles, such as Sales, HR, or IT, determining the SaaS apps, permissions, and resources they receive.

📌 Prerequisites:

• Predefined user roles and application assignment policies
• Admin credentials for Entra ID (Azure AD) and/or Okta tenant environments
• Group-based access control is enabled in Okta/Entra ID (Azure AD)

Before automating, standardize access requirements by role or department:

1. Define user roles: List key roles within the organization.

Examples:

• • HR
  • Sales
  • Finance
  • IT

2. Map roles to SaaS applications: Identify which apps and permissions are required per role.

Examples:

• • Sales → Salesforce + Teams
  • HR → BambooHR + Outlook

3. Document access structure:

• • Define naming conventions.
  • Assign group memberships.
  • Set license assignment rules.

Use this structure as the foundation for automated provisioning logic in Azure or Okta.

Phase 2: Automate provisioning

In this phase, you implement automated provisioning workflows that create users, assign licenses, and apply role-based access to apps.

📌 Use Case: Automatically onboard new hires and provision them into SaaS applications.

Method A: Automate Entra ID (Azure AD) user and group provisioning

This method uses Entra ID (Azure AD) and PowerShell to automate user creation, license assignment, and group memberships that control app access.

📌 Prerequisites:

• Entra ID (Azure AD) Premium P1 or P2
• Admin access to Entra ID (Azure AD) and SaaS applications
• PowerShell 7+ (recommended)
• Microsoft Graph PowerShell SDK

Step-by-step:

1. Press Win + S, search for PowerShell, right-click it, and select Run as Administrator. (Read #1 in ⚠️ Things to look out for.)
2. Connect to Entra ID (Azure AD):

Connect-AzAccount

This command authenticates your session to the Azure environment.

3. Connect to Microsoft Graph:

Connect-MgGraph -Scopes "User.ReadWrite.All","Organization.Read.All","Group.ReadWrite.All"

💡 Include the required scopes when connecting to Microsoft Graph so later steps run without issues. Without these scopes, tasks like assigning licenses or adding users to groups may fail with authorization errors.

4. Create a user in Entra ID (Azure AD):

Before running the command, make sure the Az.Resources module is installed and imported.

💡 The New.AzADUser cmdlet isn’t included in the default module, without it, the step will fail with a CommandNotFoundException error.

Install-Module Az.Resources -Scope CurrentUser -Force
Import-Module Az.Resources

Then create a new user:

New-AzADUser -DisplayName "Jane Smith" -UserPrincipalName "[email protected]" -Password "P@ssw0rd123" -MailNickname "janesmith" -AccountEnabled $true

This command creates a new user object with login credentials in Entra ID (Azure AD).

💡 Note: This is the foundation of provisioning.

5. Assign Microsoft 365 license: (Read #3 in ⚠️ Things to look out for.)

After creating the new user and before assigning licenses, make sure the UsageLocation property is set for the user. For example:

Set-MgUser -UserId "[email protected]" -UsageLocation "US"

Then assign the license:

Set-MgUserLicense -UserId "[email protected]" -AddLicenses @{"SkuId"="ENTERPRISEPACK"}

⚠️ Important: Replace example values (e.g., “US”, [email protected]) with your tenant’s actual values.

6. Add user to a security group (for dynamic app assignment): (Read #2 in ⚠️ Things to look out for.)

Add-AzADGroupMember -GroupObjectId $groupId -MemberObjectId $userId

This command adds users to a group tied to provisioning rules or app assignments.

Schedule provisioning using PowerShell scripts and webhook triggers from client HR systems or PSA platforms.

Method B: Automate Okta provisioning using workflows and SCIM

This method automates provisioning across SaaS apps using Okta Lifestyle Management, SCIM integrations, and the Okta Workflows engine.

📌 Prerequisites:

• Okta Universal Directory
• Admin access to the Okta Admin Console
• Supported SaaS applications with SCIM or API connectors

Option 1: GUI-based automation with Okta Workflows

Choose this option if you prefer no-code, logic-based provisioning.

1. Trigger: New user created in Okta
2. Actions:
   • Assign user to groups (Read #2 in ⚠️ Things to look out for.)
   • Set profile attributes (Read #3 in ⚠️ Things to look out for.)
   • Push user to SCIM-supported apps (e.g., Zoom, Slack, Box)

Option 2: Programmatic provisioning using Okta API and CLI

Choose this option for DevOps-style or scripted provisioning flows.

1. Create a user via API:

curl -X POST"https://client.okta.com/api/v1/users?activate=true"\
-H"Authorization: SSWS yourApiToken"\
-H"Content-Type: application/json"\
-d '{
"profile": {
"firstName": "Jane",
"lastName":"Smith",
"email": "[email protected]",
 "login": "[email protected]"
},
"credentials": {
"password" : { "value": "P@ssword123" }
}
}'

⚠️ Important: Replace the placeholder values (client.okta.com, yourApiToken, Jane Smith, [email protected], P@ssword123) with your organization’s actual Okta domain, API token, user details, and secure password.

Afterward, use Okta SCIM provisioning to push the user into assigned applications and roles automatically.

Phase 3: Monitoring and validation

After the provisioning phase, verify that the provisioning scripts or agents executed correctly and completed without errors.

Option A: Track provisioning status with Registry and local logging

This option uses the local registry and .log files to validate whether scripts completed successfully.

📌 Prerequisites:

• Local admin rights
• Optional: RMM tool (e.g., NinjaOne) for remote checks

Step-by-step:

1. Press Win + R, type regedit, and click Enter to launch the Registry Editor.
2. Navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Org\Provisioning

3. Verify custom keys written by your script:
   • LastUserProvisioned (String) = “[email protected]“
   • LastProvisioningRun (String) = “2025-07-01T12:00Z”
   • AzureStatus (String) = “Success”
   • OktaStatus (String) = “Pending”

⚠️ Important: These values are shown as examples. Replace them with the actual user, timestamp, and provisioning status output from your environment.

4. Query values remotely using RMM or NinjaOne to confirm task completion and troubleshoot failures.

Option B: Use CMD and event logs to validate local agent activity

This option uses command-line tools and the Event Viewer to verify local provisioning activities.

📌 Prerequisites:

• Administrator access to CMD and Event Viewer
• Log files or audit logs from scripts

Step-by-step:

1. Press Win + S, type cmd, right-click Command Prompt, and select Run as Administrator.
2. List active sessions:

query user

3. Check provisioning script success via logs:

type C:\Logs\Provisioning\janesmith.log

⚠️ Important: The path and filename shown here are examples. Replace them with the actual log file path and username from your environment.

This command outputs the content of the local log file to the console, so you can check whether each provisioning step completed successfully.

4. Review the Windows event log for recent account changes:

wevtutil qe Security "/q:*[System[(EventID=4720)]]" /f:text /c:5

This shows the five most recent user account creation events.

These steps help confirm that local provisioning actions (e.g., profile prep, desktop configuration) were executed.

Phase 4: Enforce provisioning via Group Policy or Intune

This phase ensures new users receive a consistent and secure desktop experience.

📌 Use Cases: 

• Apply MFA and password policies to all new users
• Restrict local admin rights
• Automatically map drives, printers, and configure Teams login
• Enforce SSO configurations and trusted apps lists

📌 Prerequisites:

• AD or Entra ID joined devices
• Admin access to the Group Policy Management Console (GPMC) or Microsoft Intune

Step-by-step:

Option A: Group Policy (GPO)

1. Press Win + R, type gpmc.msc, and tap Enter to launch the GPMC.
2. Create a new GPO and link it to the relevant OU. (Read #4 in ⚠️ Things to look out for.)
3. Configure:
   • Password and account lockout policies
     • Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies
     • Set password complexity, minimum length, and lockout thresholds.
   • Deny local admin rights
     • Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups
     • Add the group Administrators and explicitly remove unauthorized users.
   • Startup scripts and drive mappings
     • Navigate to: Computer Configuration > Policies > Windows Settings > Scripts )Logon/Logoff) to add logon scripts.
     • Alternatively, navigate to: User Configuration > Preferences > Windows Settings > Drive Maps to configure shared drive mappings.
4. Force update: gpupdate /force

Option B: Microsoft Intune

1. Go to endpoint.microsoft.com.
2. Sign in with an admin account.
3. Navigate to Devices > Configuration > Create > New Policy.
   • Platform: Windows 10/11
   • Profile type: Settings Catalog
4. Configure:
   • Authentication, Passwords
   • Teams, Outlook, SSO, device restrictions
5. Assign the Entra ID (Azure AD) group and deploy. (Read #4 in ⚠️ Things to look out for.)

Ensure newly provisioned users receive their intended desktop experience automatically.

⚠️ Things to look out for

Additional considerations

Consider the following when automating Okta/Azure provisioning for multi-SaaS clients:

License pool checks

Use scripts to check license availability before provisioning. This prevents errors during onboarding and helps you stay within license limits. Use PowerShell with Microsoft Graph for Azure, or Okta Workflows for Okta environments.

Deprovisioning

Automate offboarding. Revoke access, disable accounts, and remove licenses across all connected platforms. Use Okta Lifecycle hooks or Workflows. For Entra ID (Azure AD), use PowerShell scripts or Graph API.

Audit logging

Log every provisioning action (create, update, delete). Include timestamp, action type, admin identity, and affected user. Keep logs secure and accessible. This supports compliance and helps with audits and troubleshooting.

Cross-tenant segmentation

Use consistent naming and tagging conventions. This simplifies management at scale and improves automation and reporting.

Troubleshooting common automated user provisioning issues

Here are common provisioning issues and how you can resolve them:

Provisioning delay

If user accounts don’t appear after creation, check your SCIM configuration and app assignments. Here’s what you can do:

• Check SCIM configuration:
  1. Navigate to Okta Admin Console > Applications > [App Name] > Provisioning.
  2. Confirm SCIM provisioning is enabled.
  3. Verify that Push New Users and Push Profile Updates are enabled.
• Confirm app assignments:
  1. Navigate to Applications > [App Name] > Assignments.
  2. Check if the user is assigned directly or through a group.
  3. Navigate to Directory > Group Rules and ensure the user matches the rule conditions.

PowerShell errors

A script may fail due to an incorrect module or an expired token. Here’s what to do:

• Confirm module version with:

Get-InstalledModule

• Re-authenticate using:

Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All"

• Verify token expiration:

(Get-MgContext).ExpirationTime

Registry values missing

If the expected registry keys are missing, confirm the script ran with administrator rights. Also, verify the registry path is correct:

HKEY_LOCAL_MACHINE\SOFTWARE\Org\Provisioning

Group not applied

If the user is not assigned to the correct group, check your membership rules and assignment logic. Here’s how:

• In Entra ID (Azure AD):
  1. Navigate to Entra ID Admin Center > Groups > [Group Name] > Dynamic Membership Rules.
  2. Click Validate Rules.
  3. Test the user and confirm that their attributes meet the rule.
• In Okta:
  1. Navigate to Directory > Group Rules.
  2. Check if the rule conditions match the user’s profile.
  3. Review logs for failed group assignment entries.

NinjaOne services to help with provisioning

NinjaOne enhances identity provisioning workflows by:

With NinjaOne, MSPs can enforce standard provisioning workflows and verify success across environments using consistent, scriptable logic.

Automate Okta and Azure provisioning for scalable user management

Automating user provisioning across Okta and Entra ID (Azure AD) helps MSPs streamline onboarding, enforce access control, and reduce operational overhead when managing multi-SaaS clients.

This guide provided a complete automation workflow. It covered setting up role-based access, running provisioning scripts, checking results using registry logs, and applying policies with Group Policy and Intune. Finally, it showed how NinjaOne supports deployment, tracking, and reporting across environments for consistent and centralized provisioning management.

Related topics:

• Device Provisioning
• SSO and SCIM Integration
• What is Zero Touch Provisioning (ZTP)?