SSO / Azure AD

Azure AD (now branded Microsoft Entra ID) is the most common identity provider for B2B SaaS — most corporate customers already use Microsoft 365. This article walks through registering ActiveManage as an Azure application and wiring it up as an authentication provider.

In the Azure Portal

1. Sign in to portal.azure.com as a Global Admin (or someone with App Registration permission).
2. Navigate to Azure Active Directory → App registrations → New registration.
3. Give the app a name (e.g. “ActiveManage Production”).
4. Set supported account types — usually “Single tenant” unless you serve other Microsoft tenants too.
5. Redirect URI: choose Web and enter https://yourdomain/auth/callback/azure.
6. Register, then note the Application (client) ID and Directory (tenant) ID.
7. Under Certificates & secrets, create a new client secret. Copy the value immediately — it's only shown once.
8. Under API permissions, add Microsoft Graph > User.Read (delegated) and grant admin consent.

In ActiveManage

1. Open Architect Panel → Authentication Methods → Add Provider and choose Azure AD.
2. Paste the client ID, tenant ID and client secret.
3. Map Azure AD attributes:
   • preferred_username → email
   • given_name → first name
   • family_name → last name
4. Optionally map Azure AD group membership to ActiveManage security groups.
5. Save and click Test — you'll be redirected to Microsoft, sign in, and bounced back with a success message.

Worked Examples

• Single-tenant SaaS: One Azure AD app, only your own staff sign in.
• Multi-tenant SaaS: One Azure AD app set to “Multi-tenant”; each customer admin consents to it once. Their staff sign in transparently afterwards.
• Group mapping: Azure group aad-admins maps to the platform's Administrators security group; aad-marketing maps to Marketing.

If your ActiveManage instance is multi-tenant (serving several customer organisations), each customer's Azure AD is a separate “tenant” in Microsoft terminology. This article covers managing those connections.

How Multi-Tenant Auth Works

Microsoft lets you register your app as accepting any Microsoft tenant. When a user from a new customer tries to sign in, Microsoft asks their admin to consent (a one-time approval). After consent, all users in that customer tenant can sign in to your app.

Viewing Connected Tenants

Open Architect Panel → Authentication Methods → Azure AD → Connected Tenants. The list shows every external Microsoft tenant whose admin has consented, with sign-in counts and last activity.

Mapping Customer Tenants to App Tenants

If your ActiveManage instance also has multi-tenancy (one application serving multiple customer accounts), you'll want to ensure that a user from Microsoft tenant X is dropped into ActiveManage tenant X — not into a default shared tenant. Map this via the Microsoft tenant ID in the tenant configuration.

Worked Examples

• Onboarding a new customer: Send them the consent URL. Their global admin clicks Approve. Your audit log shows the new tenant. Map it to their ActiveManage tenant ID.
• Customer offboarding: Revoke the consent in the connected tenants list. All Microsoft sign-ins from their tenant immediately fail.
• Sign-in failures: A customer's user can't sign in — check the tenant is still in the list, the consent is current, and Azure AD group claims still match your security group mapping.

Note: Microsoft tenants can be in “managed”, “federated” (with on-prem ADFS), or “B2B guest” modes. All work, but federated tenants may require an extra redirect dance. Test with one user from each new tenant before going live.