Microsoft has step-by-step instructions here. Step 2: Set up Azure AD Application Proxy Use a web browser to login to your NDES server’s /certsrv/mscep_admin page to make sure you know your NDES URL and the service account you’ll use to login to retrieve dynamic challenge codes.
Jamf pro azure ad windows#
If you don’t yet have NDES setup, you can add the role to a Windows server. Your organization most likely has a PKI infrastructure and an NDES instance may already be up and running as a part of that. Step 1: Set up your AD Certificate Services and Microsoft NDES Better to use separate NDES servers for different things anyway so as not to put all your eggs in one basket. Most admins will probably just setup a separate Windows server+App Proxy to run the NDES role for Jamf Pro and other non-Intune SCEP clients. But messing with anything that’s even in the vicinity of an NDES that’s already supporting your production Intune seems like a bad idea. Or, you could run separate IIS instances in containers on the same server if you like doing things that way. That way, the Intune integration would use its customized setup on the 443 IIS app and Jamf Pro (and others) could use the default NDES setup running on port 8443. Or you could probably create a new IIS App that points to the NDES DLL directory and run it on an alternate port like 8443 giving it the same default auth setup used by NDES before you ran Intune’s NDESConnectorSetup.exe. We could probably figure out what MS is doing and setup an app proxy for Jamf Pro to match. One your run NDESConnectorSetup.exe on an NDES server, it alters the auth mechanism so that only traffic coming in from Intune will authenticate properly in IIS and any other client requests will get rejected. You might even be wondering if you couldn’t just use the same Azure app you just set up for Intune. You probably already did the same basic setup as what we’re about to describe here. If you’re already using Microsoft Intune/Endpoint Manager to deploy AD CS-sourced certs to your Windows clients, this will sound really familiar to you. In the case we’re talking about here, Jamf Pro is the client (the little blue person above) and NDES is the “Application”. This Microsoft diagram shows the basic traffic flow… Clients like Jamf Pro will connect to the cloud URL provided by the Azure Application Proxy Service and the internal Microsoft Application Proxy Connector will reach outbound to the Azure proxy to retrieve HTTP connections.
Jamf pro azure ad install#
Microsoft Azure AD Application Proxy can be used to solve this problem.Īzure AD App Proxy includes two components, a cloud-based Proxy to which clients will connect instead of your internal resource’s URL, and an “Application Proxy Connector” that you’ll install on an internal Windows server. This is a common issue for every app that an organization is moving to the cloud or implementing as SaaS but which requires connection to internal IT resources. But connections from the DMZ to internal networks should be avoided where possible, so it would be even better if the network connections were initiated outbound from the internal network. Since these servers typically run on internal networks, the network admin would need to create a route where they pass internet traffic through a reverse proxy or load balancer in their DMZ network zone. This can get more complicated when hosting Jamf Pro on Jamf Cloud because many will be reluctant to set up an internet-facing CA or SCEP server. Jamf Pro can deliver certificates to managed devices if you integrate it with a certificate authority. Read this Microsoft document that deals with this issue: Integrate with Azure AD Application Proxy on a Network Device Enrollment Service (NDES) server
Tldr: You may have SaaS or remote clients that need access to SCEP cert provisioning but your security team may not allow inbound connections from the DMZ to the internal network where your NDES Server is located.
0 kommentar(er)
