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.