Using your own app registration

For tenant admins.

By default your admins sign in through the shared app “AdminExplorer Portal” and Entra groups are read through “AdminExplorer Directory Sync”, each connected by one-click admin consent (see Microsoft Entra sign-in and Entra group targeting). If your organization prefers not to consent to multi-tenant apps, you can use one single-tenant app registration in your own directory for both. You own it completely: who may sign in, Conditional Access, sign-in logs and revocation.

The setting is under Settings, Sign-in and directory app (tenant admin).

No secret to keep safe

The portal authenticates to your app with a certificate. Its private key is created in, and never leaves, the portal’s key vault (not exportable, RSA 2048, valid for two years); the portal signs its sign-in assertions there. You only add the public certificate (.cer) to your app. A client secret is available as a fallback for organizations that cannot add certificates; it is stored only in the portal’s key vault and never shown again.

1. Create the certificate

Choose Create certificate, then Download certificate (.cer) (or note the thumbprint).

2. Run the setup script

As a Global Administrator or Cloud Application Administrator of your directory, run the setup script New-AdminExplorerCustomerApp.ps1 with that file (PowerShell 5.1 or 7 with the module Microsoft.Graph.Authentication; it signs in with Connect-MgGraph). Ask your provider for the script if you do not have it. Try it first with -WhatIf, which shows every change, makes none and connects with read permissions only:

.\New-AdminExplorerCustomerApp.ps1 -PortalUrl 'https://<portal host>' -CertificatePath '.\AdminExplorer-<thumbprint>.cer' -WhatIf
.\New-AdminExplorerCustomerApp.ps1 -PortalUrl 'https://<portal host>' -CertificatePath '.\AdminExplorer-<thumbprint>.cer'

The script creates the app registration:

single tenant, web redirect address https://<portal host>/auth/callback;
delegated openid, email and profile, and the read-only application permissions GroupMember.Read.All and User.Read.All, with admin consent;
the optional ID token claims email and xms_edov;
the public certificate added to its keys (existing keys are kept);
its enterprise application with Assignment required set to Yes.

It prints the application (client) id and the directory (tenant) id. Without -ClientId it always creates a new app and never takes over an existing one by name. With -ClientId (re-runs and renewal) it updates only that app, and only if it is single tenant; it stops when the app has other user owners unless you add -Force, and reports other certificates or secrets on it. It accepts only a public certificate file (never a .pfx), writes no secret to disk, and with -CreateSecret (fallback) prints a new secret once to paste into the portal. Keep yourself the only user owner of the app. You can also make the same settings by hand in the Entra admin center.

3. Validate

Enter both ids in the portal, optionally a sign-in link name, and choose Validate. The portal gets an app-only token with the certificate and reads users, groups and every group your policy uses; it shows each step, passed or failed. Nothing changes yet. Reserved link names (such as admin, support, microsoft, login and partner names) are refused.

Activation needs proof that an administrator of that directory approves it. A portal tenant admin who is also a Global Administrator, Privileged Role Administrator, Cloud Application Administrator or Application Administrator of the directory:

assigns themselves to the enterprise app in Entra;
chooses Sign in through the app as an Entra administrator;
chooses Activate, within 1 hour of that sign-in and within 24 hours of the validation.

Only then does the mode switch. That set-up sign-in can do nothing but activate; afterwards, sign in again through your organization’s sign-in.

In Entra, assign the people or groups who may sign in to the enterprise app (each also needs a role in the portal). Optionally add Conditional Access on it.

Signing in afterwards

On the sign-in page choose Use your organization’s sign-in and enter your work email. It finds tenants that have a sign-in link name (at most 5 lookups per minute per network address).
Or use your tenant’s link https://<portal host>/login/<name>.

While your own app is in use, roles in this tenant count only for sign-ins through it: email sign-in links and the shared “Sign in with Microsoft” no longer give access to this tenant. Such a sign-in uses only roles in this tenant, and the token must come from your directory and your app. Partner administrators are not affected. Your directory also becomes the tenant’s verified Microsoft Entra sign-in directory (the “require” option works as before) and its Directory Sync directory: group targeting reads through your app. A directory serves one portal tenant. Role changes take effect within 60 seconds.

Certificate renewal

60 days before the certificate expires the portal creates the next one and mails the tenant admins. Settings shows it with a one-line script command (with -ClientId, which only adds the new key). After you add it, choose Validate new certificate, or let the nightly check do it: the portal switches to the new certificate and deletes the old one. Reminders go out 30, 14 and 3 days before the credential expires (for a client secret, by the expiry date you entered).

Stop using your app

Stop using my app returns to the shared default apps. The portal deletes its certificates (or the stored secret), the sign-in link and the group memberships read through your app. Then delete the app registration, or its key, in your directory. While Require Microsoft Entra sign-in is on, the portal refuses to stop (turn “require” off first), so your users are never locked out. Deleted certificates stay recoverable in the key vault’s soft delete for 90 days, by your provider’s operators only, and are then gone.

AdminExplorer documentation, published by Circle of Bytes ApS. Customers sign in at portal.adminexplorer.circleofbytes.com.