Let’s get this this blog started with one very popular add on for Jamf Cloud: ‘JIM’, or Jamf Infrastructure Manager.
Note: while JIM can also be used for more complex on-premise Jamf Pro installations, I’ll focus this post on Jamf Cloud only. The setup for on-premise servers should however be similar, taking some network considerations into account.
Before forcing you to read my point of view on JIM, I’d like to share a link to THE video you must watch to understand all the details on how this tools works. Laurent, one of the Jamf Profesional Services Engineers, presented an awesome keynote on JIM during JNUC 2017! Have a look at the end of this post for the link.
However, while not trying to re-invent the wheel, here are my highlights on the installation and configuration of LDAP integration in Jamf Pro.
Many companies or educational institutions use Active Directory, or another LDAP, to manage their end users. And while binding macs to AD is a complete different discussion, ‘to bind or not to bind’ will most likely be one of my future posts, LDAP integration in Jamf Pro remains a very nice thing to have.
Integrating LDAP into Jamf Pro allows you to assign devices to users, auto configure user settings based on AD attributes, authenticate users in Self Service, provision Jamf Pro accounts for admin users and enrollment purposes, etc…
For this integration to work however, the Jamf Pro server needs to be able to query the LDAP server. For on-premise Jamf Pro installations, this is most likely going to be a straight forward exercise, as both servers are likely to be on the same internal network. But for Jamf Cloud instances, there is some additional configuration needed. Opening up the internal LDAP server to the world, is most likely not going to amuse your network security team, but still, Jamf Cloud needs acces from outside your network, through the firewall, inbound to the LDAP server. One way or the other…
So before you’ll be able to configure the LDAP integration in Jamf (Settings —> LDAP Servers) there is some extra work to do.
To make this work, in a secure way, we have 2 options:
- Whitelist the published IP adresses used by Jamf Cloud (outbound from Jamf Cloud and inbound to your LDAP server)
- Use the Jamf Infratructure Manager (or ‘JIM’), preferably in combination with whitelisting of the IP addresses as well.
The first option is quite straight forward. Just have a look at the Jamf article below, and identify the IP addresses for your region of Jamf Cloud. The only thing you’ll need to do is to whitelist connections through your firewall for those IP addresses, on the relevant LDAP port (389 for LDAP, and 636 for LDAPs), INBOUND to your internal LDAP server.
Note: the published IP addresses in the article above, are only used OUTBOUND from Jamf Cloud. For LDAP purposes, this should be enough to configure your firewall, but if, for any other reason, you need to whitelist the communication outbound your network, but INBOUND to Jamf Cloud, those IP addresses won’t work. As Jamf Cloud uses a load balancer for inbound connections, you will have to whitelist *.jamfcloud.com outbound your network if needed. Jim also needs to be able to contact *.jamfcloud.com on port 443 to receive settings. NOTE: * = your instance name, for instance: mycompany.jamfcloud.com.
Whitelisting the published IP addresses should give you a level of security which eliminates the risk of rogue attempts to connect to your LDAP server, originating from unknown sources. But while this might be sufficient for many environments, chances are that this is not sufficient to please your network security team, and/or comply with internal company policies.
Hence the second option: Jamf Infrastructure Manager.
Jamf Infrastructure Manager, aka ‘JIM’ in the Jamf community, is a LDAP PROXY tool, provided by Jamf. The idea behind the tool is to install it on a server (Windows or Linux, see requirements below), located in your DMZ.
Installing JIM enrolls the server in Jamf Pro (yes, the only Windows/Linux computer you can enroll in Jamf Pro 🙂 ), and makes the JIM server check in on a regular basis into to the Jamf server… waiting/asking for instructions. Once you have a JIM server enrolled in Jamf, you can configure the LDAP integration in Jamf Pro to use JIM as a proxy to your LDAP. Doing so, each time you search for an LDAP user (when assigning devices in the inventory, authentication during enrollment, Self Service Login, etc…) Jamf Pro will contact JIM over a port you can choose, and ask JIM to query the LDAP server.
The fact that I mentioned “over a port you can choose” is very important to understand how JIM works. See diagram below:
The idea behind adding JIM to the LDAP setup, is the fact that you can limit the inbound connection into your LDAP server, to 1 known source: the JIM server. This allows you to strictly limit the “external” connection to your LDAP to the one and only known source: the JIM server (a server under your control, in your DMZ). This either over port 389 or 636 (with SSL).
Additionally you choose a port which Jamf Cloud will use to contact JIM. This port can be anything you want, as long as it is above 1024, and if preferred you can limit the connection from Jamf Cloud to the JIM server even more by whitelisting the IP adresses discussed above.
Note: The preferred port to use for JIM is either 8389 for LDAP, or 8636 for LDAPs.
Note: A common source of confusion, when troubleshooting JIM installations, is the fact that the JIM server does not start to listen on the “chosen port” right after completing the JIM installation. This is however expected behavior, as installing JIM only enrolls it in Jamf Pro and makes it check in with the Jamf server to ask for instructions. By default every 30 seconds.
On the above screenshot you see the enrolled JIM server in Jamf Pro. As you can see, there is no mention of any port. JIM is only checking in with Jamf Pro on a, be default, 30 seconds cycle.
It’s only after completing the LDAP integration in Jamf Pro (see below), selecting the JIM server as proxy, and adding the “chosen port” to the configuration, that Jamf wil inform JIM what port it should listen on! To complete the setup, JIM needs to check in once after saving the LDAP setting in Jamf Pro (default 30 seconds).
In the above screenshot you see the LDAP integration in Jamf Cloud configured for LDAPs, with the JIM communication over port 8636. This tells the enrolled JIM server to listen for inbound LDAP queries on port 8636, and JIM will communicate with the Active Directory over the standard 636 LDAPs port.
See below for the links to the tech articles on how to install JIM (including system requirements) and configure the LDAP integration in Jamf Pro, as well as the JNUC 2017 video!
There are however a few important things I’d like to highlight:
- JIM needs a fully qualified domain name (FQDN), publicly resolvable to the public IP address of your DMZ
- JIM does not like to be behind NAT and needs to be able to resolve it’s FQDN back to itself, being it’s own (local) IP address.
- Don’t forget to allow inbound connection from Jamf Cloud (see whitelisting IP addresses) to you JIM server on the chosen port (8389/8636) both on a your network firewall and the OS firewall (Windows). As well as allow the connection from JIM to your LDAP on 389/636
This means that if JIM is behind NAT, the easiest way to fix this is by adding an entry in the hosts file of the JIM server, pointing it’s local IP address to the FQDN used by JIM, or use a split DNS setup (where externally the JIM FQDN resolves to the public DMZ IP address, but internally, via the internal DNS server/configuration the JIM resolves to the internal/local IP address).
Note: while tweaking the hosts files is the easiest way to solve the NAT issue, using a split DNS is the preferred way to go. In general hosts file changes should be avoided, and adding an A record or CNAME to the internal DNS server should be straight forward enough to do. Just saying that if split DNS is not possible, for whatever reason, tweaking the hosts file is the the only option left to fix JIM’s dislove of NAT.
For Ubuntu you can find the hosts file at: /etc/hosts
For Windows c:\windows\system32\drivers\etc\host:
Furthermore, JIM needs a Jamf Pro user account to connect to Jamf. For this it’s highly recommended not to use your default, or any other, Jamf Pro admin account. Instead, create a custom account with the following privileges: create+update for Infrastructure Manager Instance and update for LDAP Servers:
Final note: You can only install one Infrastructure Manager instance per computer, but you can enroll as many JIM servers into Jamf Pro as your organisation requires.
Oh yes, where to find the JIM installer? Right, always handy: go to Jamf Nation, login with your institutional Jamf Nation account and go to “My Assets”:
The Jamf Infrastructure Manager Installer requires a computer with the following:
- One of the following operating systems:
- Ubuntu 14.04 LTS Server (64-bit) or Ubuntu 16.04 LTS Server (64-bit)
- Red Hat Enterprise Linux (RHEL) 7.0, 7.1, or 7.2
- Windows Server 2008 R2 (64-bit), Windows Server 2012 (64-bit), or Windows Server 2012 R2 (64-bit)
- A 64-bit capable Intel processor
- 2 GB of RAM
- 300 MB of disk space available
- Java 1.8 (For more information, see the Installing Java and MySQL Knowledge Base article.)
- THE video the watch: JNUC 2017: Jamf Infrastructure Manager
- Jamf Infrastructure Manager Overview
- Jamf Infrastructure Manager Guide (pdf)
- Integrating with LDAP Directory Services
- Permitting Inbound/Outbound Traffic with Jamf Cloud
- Configuring Jamf Pro to Use LDAP over SSL
That’s all folks! As long as your network (firewall, ports, DMZ, …) is configured as discussed, integrating Jamf Cloud with LDAP via JIM should be a walk in the park! If not, it’s always the network!
Don’t hesitate to contact me of you have any questions, suggestions or corrections regarding this post.
Upcoming posts will for sure include some additional LDAP discussions, but don’t hesitate to suggest any topic I should cover!