Microsoft Intune

Intune is the one MDM AgenShield connects to directly. Connect your Microsoft Entra tenant once, and every campaign afterwards deploys from the Frontegg Portal: no downloading profiles, no uploading packages, no keeping two systems in sync by hand.

​

Connected integration

You do four things once — register an app, hand over two IDs, upload a certificate, grant permissions — and from then on every campaign deploys with one click from the Frontegg Portal.

​

What AgenShield does on your behalf

Once connected, pushing a campaign creates and maintains these objects in your tenant: Your side of the deal is one thing: put devices or users in the group. You can do that from the Frontegg Portal or from Intune — both work.

​

Connect your tenant

Settings → Integrations → Connect Microsoft Intune. The wizard has four steps and takes about five minutes. AgenShield authenticates with a certificate it generates — you never create, paste, or rotate a client secret.

​

1. Register an app in Entra

In the Entra admin center: Entra ID → App registrations → New registration.

• Name it something recognisable, e.g. AgenShield.
• Keep the default account type — your organization only.
• Skip the redirect URI. It is not used.
• Select Register.

​

2. Give AgenShield the app’s identifiers

Back in the wizard, enter a name for the connection plus the two GUIDs from your new app registration’s overview page:

​

3. Upload the certificate

AgenShield generates a keypair, keeps the private key encrypted, and hands you the public half. Download it, then in your app registration go to Certificates & secrets → Certificates → Upload certificate and add the file. The wizard shows the SHA-1 thumbprint Entra will display after upload — compare the two to confirm you uploaded the right file to the right app.

​

4. Add permissions and grant consent

API permissions → Add a permission → Microsoft Graph → Application permissions. Required. The connection test probes each of these individually, so a failure tells you exactly which one is missing.

Optional permissions — three Frontegg Portal conveniences, each addable later

Each unlocks one specific feature and nothing else. To add one later, append the permission and re-run Grant admin consent — no reconnection needed.

Permission	Enables	If you skip it
Device.Read.All	Browsing your device directory from the Frontegg Portal	Add devices to the group from Intune or Entra instead
User.Read.All	Browsing your users from the Frontegg Portal	Manage user-group membership from Intune or Entra instead
DeviceManagementManagedDevices.Read.All	Rollout progress, and matching enrolled Macs to their Intune records	Pushes and offboarding still work; the rollout view reports the missing permission

Then select Grant admin consent for your organization, confirm, and Refresh — every row must read “Granted”. Finally, run the wizard’s connection test.

​

Push a campaign

From Devices (on the campaign) or Settings → Integrations, choose Push to Intune:

1. Pick the campaign.
2. Name the group — e.g. AgenShield — Engineering Macs.
3. Choose whether members will be devices or users.

AgenShield creates the group, materializes and assigns the campaign profile, and assigns the installer app. It runs in the background and usually completes in under a minute; the screen updates itself. Then add members. Nothing deploys until the group has members — Intune applies a profile only to members of the group it is assigned to.

​

One device, one campaign

A device or user may belong to only one AgenShield campaign group per connection. If you try to add one that is already in another campaign’s group, the whole request is refused and the conflicts are listed — moving a device between campaigns is a decision, not a side effect. Confirm, and AgenShield removes it from the other group first.

​

Track the rollout

With DeviceManagementManagedDevices.Read.All granted, the push view joins your group membership against Intune’s device inventory and against the Macs that actually enrolled: It also lists enrolled devices that are not in the group — usually machines that were installed by script before the MDM push existed.

​

Offboard a device

Use Offboard, not “remove from group”. Offboarding does both halves: it removes the member from the campaign group and adds it to the connection’s uninstall group, whose assigned script removes AgenShield at the next check-in. Re-onboarding later pulls it back out of the uninstall group automatically, so no device ever sits in both.

​

Keep it healthy

Two maintenance actions, both in Settings → Integrations: If someone edits or deletes an AgenShield object in Intune or Entra, Check setup reports it and Repair converges it back. Publishing a new release: the installer app is published once per connection and shared by every campaign group. After a new AgenShield release, re-publish it from the connection — every campaign picks up the new version without being re-pushed.

​

Manual upload

No tenant connection, no app registration. Push the two objects yourself.

​

1. The configuration profile

1. Devices → Manage devices → Configuration → Create → New policy.
2. Platform macOS, profile type Templates → Custom.
3. Name it, e.g. AgenShield, and upload deployment.mobileconfig.
4. Deployment channel: Device channel.
5. Assign it to your target device group.

​

2. The install command

1. Devices → macOS → Shell scripts → Add.
2. Upload a script containing the campaign’s install command:
   #!/bin/bash
   curl -fsSL 'https://<your-backend-url>/resources/campaigns/v1/<campaign-token>/install.sh' | bash
   
3. Run script as signed-in user: No.
4. Assign it to the same device group.

Paste the two-line command above rather than the full installer it downloads. The command is stable across campaign edits and AgenShield releases, so you set it once; and there is nothing long or non-plain-text for the script editor to round-trip. Intune retries a failed script on later check-ins, and the script exits non-zero if the device does not finish enrolling — so the run status reflects whether the device actually joined your fleet.

​

Choosing a profile

Both campaign profiles carry the macOS approvals. They differ only in whether they also carry the enrollment token, and that difference decides which installers each can be paired with. So: the install command pairs with either profile, and the package pairs only with agenshield.mobileconfig. Pairing the all-in-one profile with the install command is fine and slightly belt-and-braces: the command’s token is used, and the profile’s is the fallback if the command has not run yet. Pairing the package with deployment.mobileconfig is the one combination that does not work — the Mac gets every approval and never enrolls. What you must not do is deploy both profiles, or both installers, to the same Mac. If your tenant uses Multi-Admin Approval, the profile and the script may sit in pending approval before they deploy.

​

Next