Entra External ID in Edu

We’re all busy these days, but I doubt there’s anyone busier than a working parent with school-age kids. It’s hardly surprising then that the use of technology to link parents remotely with school systems has become increasingly common, enabling them to stay actively involved in their child’s education in the midst of their packed schedules. This began with straightforward tasks such as teacher communication and academic reporting, but as parental expectations for enhanced functionality and convenience grew, schools expanded their services, supported by a diverse array of back-end platforms. The convenience of these services often depends on handling sensitive financial and medical information and the responsibility for ensuring proper access, along with all other aspects of provisioning and support, typically rests with the overburdened IT teams in schools.

The Parent Trap

We have traditionally tackled this problem in one of three ways:

1. We use the same identity provider for parents that we’re already using for staff and student accounts, such as Microsoft Entra. This is likely well understood in our team and we can align the on- and off-boarding for parent accounts to our existing process and leverage the single sign-on integrations we’ve already built with other applications. However this approach is messy since we’d be more than doubling the number of users in the tenant and we could be introducing unintended security risks. Parent accounts need to be excluded from security policies such as Conditional Access and additional compliance tools such as Information Barriers may be needed to prevent unintended usage or inappropriate oversharing. Further, licensing models may limit their quantity, reduce their MFA protections and preclude monitoring for potential compromise.

2. We anchor parent identity in a single application such as a Learning Management System or School Information System. This is usually a quick win since parent access to academic information and teacher feedback is essential and many such systems have built-in parent access options so it’s easy to get this off the ground. The drawback is that having our parent body locked in to a single platform will hinder our ability to migrate to a more suitable one in future (and said incumbent vendor may know that they have us over a barrel and decide to hugely inflate their costs while cutting support and development - not that I still bear scars from this!). Additionally, a single application can’t usually provide access to other applications, so parents will likely end up with multiple accounts.

3. We use a separate identity provider solely for parents. There are education-specific options such as PIPS or we could use a generic IdP like Okta. This would whisk away most of our gripes; fewer security concerns with parent accounts in a separate system, simpler management with a single point of provisioning and access control, central logging and the convenience of single sign-on across multiple systems with one identity. This costs top dollar though; even the cheap options are thousands per year. The vendor lock-in also remains and with it the lack of control to do anything out of scope and the risk of changing price models and feature sets in future.

Many schools are either contemplating or are already in the process of moving from scenario 1 or 2 to scenario 3; it’s for them that I’ve written this blog in order to demonstrate that there is now a viable fourth option that preserves many of the same benefits without any recurring costs.

Azure 🐝🐝🌊

First, a little history. I stumbled across a service called Azure AD B2C back in 2019; it was (and still is sort of) Microsoft’s CIAM (customer identity and access management) solution. This would be used where, for example, you run a large electric utility and you need an identity service to process customer access to your web portal for viewing and payment of bills. In the context of a small school where we just want parent accounts for a couple of apps, B2C would be overkill. It’s also very limited in its out-of-the-box functionality, so the predominant education use case of needing to grant parents access to the same application as staff and students would require a custom authentication flow. Custom flows are, in the words of one Redditor, “the most painful thing I’ve had to do since my last root canal”. A Google search for ‘why is Azure B2C’ at the time would autocomplete with so complicated? Clearly there was a potential use case for parent access buried in there, but it was beyond the realms of practicality.

This changed last year when Microsoft announced the arrival of Entra External ID, specifically claiming it to be a less complex solution for the majority of use cases. I naturally wondered if that would include the same-application scenario and although that isn’t specifically mentioned on any documentation I’ve seen, I can confirm that it does. It is better, simpler and eminently achievable for most schools, especially considering it’s now in general availability and with full support.

The Secret Sync

So how do we get everyone access to the same app when they’re not all in the same tenant? Creating duplicate accounts would work but would defeat the purpose since we’d be doubling up on credentials and it’d be a disaster of a user experience. We need to provide a means for staff and students to use their existing credentials to access an app alongside parents, so we need to somehow get them into the External ID tenant. Helpfully there’s a feature called cross-tenant sync that does exactly this by automatically provisioning guest accounts in one tenant for users in another. While it’s designed for business-to-business collaboration between two Entra tenants and isn’t enabled or supported in External ID, we can work around this restriction and that opens the door to our solution, as you can see in this overview diagram:

Implementation

Before starting, it’s worth checking on the supported features list to see if there’s any blockers for you. MFA options are more limited in External ID tenants for example, though in a parent context we would be unlikely to need more than email or SMS methods anyway. SMS messages for MFA are chargeable, so that’s worth considering also.

The initial setup process is covered in the Microsoft documentation; my advice in this section assumes this has been completed.

Security Settings

You have just created a whole new tenant, so do not pass go until a backup admin and breakglass account are established in order to prevent loss of control at a future stage. It’s best to do this now, even if you’re just doing a demo or proof of concept since it’s easily forgotten once you get going. Popping into Entra and Users will show the user account from the primary (workforce) tenant that created it. Their identity type will be ‘ExternalAzureAD’ and they will have global admin rights. I’d add at least one other admin from your primary tenant as well as creating an in-tenant global admin. There’s no identity governance in the External ID tenant, so PIM isn’t an option here.

Head to Conditional Access next to be treated with a glorious blank slate where you can set up policies from scratch that only apply to your external users. Keep it simple, but I’d at least have a rule to require MFA and then enable an email OTP method for users. You may also want to consider adding a permit for only certain geographical locations and a block for high-risk users.

Branding

Customising the branding of the External ID tenant not only makes it look professional to parents but can differentiate it from your primary tenant to make it obvious which one you’re signing into at the logon page. My External ID tenant uses the same images, backgrounds and colouring but with a background set to partial instead of full and a different message in the footer (you’d probably want to do this anyway to add contact or support details for parents).

Sync Setup

Now create your parent users; for a test or to get things off the ground quickly, a bulk create with CSV upload works fine. Syncing our staff and students into the External ID tenant comes next; as I’ve already mentioned this is a crucial step so we can grant everyone SSO to the same application. You can see that if you try to access cross-tenant sync settings in the portal, you get the error “This feature is unavailable or doesn’t apply to the current tenant configuration”. To circumvent this limitation, just do it in Powershell – yes, it really is that simple. There’s multiple steps involved and they must all be completed for it to work, including automatic redemption of invitations.

Enterprise Apps

Enterprise Apps and their associated single sign-on settings are in preview in External ID (I know, I said it was in GA but actually this crucial feature isn’t quite yet) but work in exactly the same way as Entra, so creating an app and adding groups containing both external and internal users shouldn’t be a problem now they’re all in one place. However it’s important to bear in mind when transposing URLs for SSO endpoints into the destination application that these should all begin with https://«ExternalIdTenantName».ciamlogin.com rather than the traditional login.microsoftonline.com. Due to a bug, some settings (e.g. App Federation Metadata URL) are still displayed as the latter and must be manually amended or the SSO will fail. Hopefully this will be corrected during the preview.

Since we have two kinds of users in our External ID tenant, each with a different UPN structure, any apps that require authenticating both can’t use User.Userprincipalname as the unique user identifier. Switching to User.Mail is best, since it is in the same format for both (providing the application in use has email set as username).

Session Handling

When accessing an app published through External ID, members of the Entra (workforce) tenant must establish a new session token because their existing session tokens from their home tenant can’t be used to log in. This means that staff and students need to periodically reauthenticate. Since this uses the same credentials it’s not a big issue, and unless the default session length is changed they’ll only need to do this once every 90 days.

Closing thoughts

My school has deployed External ID successfully into production and I think it’s worthy of broader attention from the rest of the education community for three reasons:

1. It provides a dedicated IdP for parents without recurring costs (it’s free for up to 50,000 active monthly users, more than even the largest school would need for their parent base).
2. It shifts the locus of control in the school’s favour (for schools already using Entra it’s familiar and it’s entirely under school control).
3. It caters for common requirements without custom code or flows (it’s usable without needing to be an identity expert).

Ideally we want a parent to be able to use the same login for their child throughout their schooling so we should be thinking of their identity life cycle in decades rather than years. B2C is already 8 years old and Microsoft are clear that it’s staying, and External ID is just winding up so I fully expect it to be there a decade from now. There aren’t many other options I could say the same of.

Acknowledgements

Many thanks to Roald Schutte, my colleague at Rehoboth Christian College who kept the dream of External ID alive when I was in the trough of disillusionment; using Powershell to enable cross-tenant sync was his idea and our proof of concept was built on his persistence.

Thanks also to Al Martin at Compnow for seeing the value in this and not calling me a crazy person when I ranted at him about its potential in mid-2023 before anyone even knew what it was. I’m glad to have had Compnow’s involvement and they’re now in a good position to provide deployment support to schools.