Merkai Walled Garden wildcards for the PC Entra

Hey Hassan, it sounds like you’re on the right track trying to walled-garden Microsoft’s authentication endpoints so that brand-new Azure AD-joined devices can reach Azure AD, change their password, install certs via SCEPMan, and only then get full internet access. The key is to allow all of the AAD/PKE endpoints that handle sign-in and password resets. Here’s what I’d recommend:

1. Identify the exact FQDNs and wildcards required From Microsoft’s own “Ruggedized network integration” guidance (used for Azure Stack Hub, but the list applies to any limited-internet scenario), you’ll need the following domains on your Meraki walled-garden list: • login.windows.net • login.microsoftonline.com • graph.windows.net • secure.aadcdn.microsoftonline-p.com • *.msftauth.net • *.msauth.net • *.msocdn.com Depending on your geo/tenant you may also need the gov/China/Germany endpoints (e.g. login.microsoftonline.us, login.chinacloudapi.cn, etc.), but start with the public ones above.
2. Use the correct wildcard placements According to the Azure Firewall FAQ on FQDN wildcards, asterisks only work on the left-most side for domains; you cannot do login.*.microsoftonline.com. Instead: • If you need all subdomains under msauth.net, use *.msauth.net • For specific hosts like login.microsoftonline.com, just list the full FQDN
3. Add these into your Meraki SSID’s walled-garden list In the Meraki dashboard under Wireless > SSID > Access Control > Splash page > Walled garden, add each entry exactly as above. Save and push the update.
4. Test connectivity before captive-portal auth On a device that has not yet logged into the portal, open a browser and try to hit https://login.microsoftonline.com. You should see the Azure AD sign-in page (or at least a redirect to your tenant). If that works, you know your walled garden entry is correct. Then proceed through the captive portal and confirm the same domains still resolve/route afterward.
5. Verify SCEPMan and device registration Once the password change is successful, the device should automatically pick up certificates via your SCEPMan policy. If it doesn’t, check the event logs on the client (Applications and Services → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider) to see if it’s trying to hit any additional domains.

Hope this helps you nail down the exact set of allowed hostnames so new users can change their password before full network access.

Follow-up questions if you’re still stuck:

• Which Meraki firmware version are you on? There have been some wildcard-parsing fixes in recent releases.

• Are you using a custom RADIUS/Captive-Portal combo or Microsoft Cloud Auth in Meraki?

• What error do end users see when they try to reach login.microsoftonline.com (timeout, DNS error, redirect loop)?

• Can you share a packet capture (DNS + HTTP) from a client that’s stuck?

Reference list

• Azure Stack Hub ruggedized network integration (firewall requirements): https://learn.microsoft.com/azure-stack/ruggedized/network-integration?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#firewall

• Azure Firewall FAQ (wildcard rules in app rules): https://learn.microsoft.com/azure/firewall/firewall-faq?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#how-do-wildcards-work-in-target-urls-and-target-fqdns-in-application-rules

• Wildcard applications in the Microsoft Entra application proxy (wildcard syntax reference): https://learn.microsoft.com/entra/identity/app-proxy/application-proxy-wildcard?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#prerequisites

Meraki walled garden rules must allow all required Microsoft endpoints for Microsoft Entra sign-in and password change flows; allowing only *.msauth.net and login.microsoftonline.com is not sufficient.

From the provided context, the only explicitly listed Microsoft cloud endpoints are for Microsoft 365 traffic and Microsoft Entra-related services. For a guest/Wi‑Fi walled garden that must allow Microsoft sign-in and password change, configure the Meraki walled garden (or equivalent allowlist) to permit at least:

1. Microsoft 365 / Microsoft cloud IP ranges (for sign-in and related services) Add the following IP ranges to the allowed list (as destinations that bypass the walled garden restrictions):
   • 132.245.0.0/16
   • 204.79.197.215/32
   • 150.171.32.0/22
   • 131.253.33.215/32
   • 23.103.160.0/20
   • 40.96.0.0/13
   • 52.96.0.0/14
   • 40.104.0.0/15
   • 13.107.128.0/22
   • 13.107.18.10/31
   • 13.107.6.152/31
   • 52.238.78.88/32
   • 104.47.0.0/17
   • 52.100.0.0/14
   • 40.107.0.0/16
   • 40.92.0.0/15
   • 150.171.40.0/22
   • 52.104.0.0/14
   • 104.146.128.0/17
   • 40.108.128.0/17
   • 13.107.136.0/22
   • 40.126.0.0/18
   • 20.231.128.0/19
   • 20.190.128.0/18
   • 20.20.32.0/19
   These are documented Microsoft 365 / Microsoft cloud IPs that must be reachable when Microsoft traffic is being forwarded or filtered.
2. Microsoft Entra / Global Secure Access FQDNs Ensure the walled garden allows at least the documented Microsoft Entra service FQDN suffix:
   • globalsecureaccess.microsoft.com (Meraki supports wildcards, so *.globalsecureaccess.microsoft.com or the base domain depending on configuration)
   In Meraki, this typically means adding that domain (or wildcard) to the allowed destinations so that DNS and HTTPS traffic to those hosts is not blocked or intercepted.
3. General guidance for the scenario
   • Confirm that DNS queries from the guest network can resolve Microsoft domains (no DNS blocking or redirection for these domains).
   • Make sure the walled garden rules are applied to both HTTP and HTTPS traffic.
   • After updating the allowlist, test with a freshly joined hybrid-joined PC on the guest Wi‑Fi and attempt to reach the Microsoft sign-in page and password change page.

If, after adding these documented IP ranges and FQDNs, sign-in still fails, verify on the Meraki side that:

• The rules are ordered correctly so that the allow rules for these IPs/domains are evaluated before any deny/captive-portal rules.
• There is no SSL inspection or proxy behavior that breaks Microsoft sign-in flows for these endpoints.

References:

• Security Service Edge (SSE) coexistence with Microsoft and Cisco Secure Access