Jamf Pro and Google Secure LDAP

Integrate Jamf Pro with Google Cloud Identity Secure LDAP

Print Friendly, PDF & Email
UPDATE 18th of December: got it to work JamfCloud! See bottom of post.

Earlier this year Jamf announced support for the new Google Secure LDAP service. As I was too pre-occupied with macOS Mojave & Secure Tokens, I didn’t have the change to test it until now. 

But to break away from testing token related deployments, I decided to have a look at this new LDAP integration today.

Before I continue, I just want to highlight one important detail regarding the pre-reqs to integrate this feature in Jamf Pro.

If you look at the configuration guide for Google Secure LDAP, you'll see that it requires 'Certificate based Authentication'. Important to know, because the LDAP integration in Jamf Pro currently does not allow us to do so.

This means that, in case you do want to integrate Google Secure LDAP into Jamf Pro, whether you are hosting your own Jamf Pro server or using JamfCloud, you will need an additional proxy server. More about that below.

That said, let’s have a quick look at how to do things.

First of all we need to set up the LDAP app in G Suite or Google Cloud Identity:

In Google Admin, go to APPS – LDAP
Give your LDAP app a name and description…
and give the LDAP Client appropriate access level: entire domain or specific OU’s.

Important, for Jamf to be able to query group memberships, you must give it ‘Read group information’ privileges.
On the next screen you will be provided with the Google Cert which you’ll need for the Certificate Based Authentication. As said, more about that below.
I’ll come back to this screen below. In order to configure the LDAP integration in Jamf Pro, you’ll need to generate additional credentials under “access credentials”. 

Note: you will not be able to retrieve the password of the additional credentials after closing the popup. Hence, leave it like this for now, we’ll come back to it later.
You can already enable the app if you want.

Next we’ll need to sort out our certificate proxy. As said, Jamf Pro currently does not allow Certificate Based Authentication, but Google Secure LDAP requires it. This means we’ll need to run an additional service to make this magic happen. 

For this we use ‘stunnel‘, which will actually use the certificate we got from Google to authenticate to the LDAP service, and proxy this to Jamf. Download and install stunnel on the link above, or for example for Ubuntu, run ‘sudo apt-get install stunnel4’.

For his tutorial I installed it on Ubuntu 18.04, on the same machine as my Jamf Pro test server.

Note: When trying to install 'stunnel' I was unable to locate the package. Not sure why, but I had to fix my repository source file. (/etc/apt/sources.list).

Next, we need to configure ‘stunnel’ to connect to the Google LDAP service:

  • Navigate to the ‘stunnel’ directory and create a google-ldap.conf file (‘sudo nano /etc/stunnel/google-ldap.conf’)
  • Copy-paste the following into the file:
client = yes
accept =
connect = ldap.google.com:636
cert = 
key = 

Change the .crt and .key filename to match the filenames of the certificate/key file you downloaded from the Google Admin Portal, and specify the location. I uploaded the files to the ‘stunnel’ directory.

Note: port 1636 is actually free to choose. At least, for Windows/Ubuntu that is, for RHEL you'll have to choose something above the privileged 0-1023 ports.

Save your config file

Enable ‘stunnel’:  ‘sudo nano /etc/default/stunnel4′ and set ENABLED=1

Restart ‘stunnel’: ‘sudo /etc/init.d/stunnel4 restart’

Next, Jamf Pro!

Like always, for more exotic LDAP integrations we have to use the ‘manual configuration’. The idea here is to connect to the ‘stunnel’ LDAP proxy service which we just configured.

Server and port: and 1636 if you left it default and installed the proxy on the same server as Jamf Pro

DO NOT select SSL, as we are connecting locally to the proxy.

*** LDAP Server Account – SEE BELOW ***
Note: If you choose to run 'stunnel' on a separate server, you must configure your firewalls so that only the Jamf Pro server can access your stunnel server or for JamfCloud have a look at: permitting inbound/outbound traffic with JamfCloud. You can also configure 'stunnel' to listen with TLS.

I'll keep it at running 'stunnel' on the same server as Jamf Pro for now. I'll dive into securing it with TLS on a remote server later and update accordingly.

In order to configure the LDAP connection in Jamf Pro, we’ll need a “LDAP Server Account”. This brings us back to our Google Admin Portal, where I mentioned we had to create additional credentials.

Go back to your LDAP app in the Google Admin Console and click on ‘Authentication’. Next, ‘Generate New Credentials’. This will generate a username and password, which you can use in Jamf Pro as service account.

NOTE: Copy the password before closing the pop-up!

Use the generated credentials in the ‘connection tab’ of Jamf Pro, with authentication set to ‘simple’. Next continue with the mappings:

For additional LDAP mappings: have a look here.

And the official Jamf Pro KB: here

That’s it! Enjoy Secure LDAP via Google Cloud Identity!

As said, I’ll have a look at enabling TLS to run ‘stunnel’ on a remote server in case you want to add some additional security. For instance when using it with JamfCloud. I’ll update ASAP.

UPDATE: How to do this with JamfCloud?

So, while installing this on-prem on the same server as the Jamf Pro server is quite straight forward, I had to do some additional testing to get it to work with JamfCloud. I’m not an ‘stunnel’ expert, so what would you expect 🙂

Anyway, this is how I did it. If there are any ‘stunnel’ experts around, please feel free to comment, correct or share any best practices!

Note: I'm not running my 'stunnel' processes in a chroot environment. I guess for this purpose it wouldn't really matter, correct me if I'm wrong!

I tweaked the config file for the google-ldap.conf file in order to create an additional tunnel. The idea is that JamfCloud will tunnel into the FQDN of my proxy server, which then tunnels it further via localhost to Google LDAP:

Additional to the extra tunnel, I added an SSL cert (and private key) to enforce SSL on the incoming connection from Jamf Cloud. The same cert is used in the Jamf Pro LDAPs connection.

In Jamf pro we enable SSL, upload the cert and configure server and port according to the FQDN of your proxy server. I am running the proxy on a virtual machine in my homelab. A bit funny to tunnel JamfCloud LDAP via an on-prem server to Google Cloud… but yeah, first of all the lack of ‘Certificate base authentication’ for LDAP in Jamf Pro is what it is. Secondly, a similar setup could easily be configured on any cloud hosted server.

That’s it! Google Secure LDAP in Jamf Cloud! Let me know if you have any advice, remarks or suggestions.

One thing I would add is limiting the communication inbound to the ‘stunnel’ proxy service to only those IP Addresses used by JamfCloud.

Maybe I’m missing some best practices on ‘stunnel’, like running it in chroot, but at least, it works!


Print Friendly, PDF & Email

18 thoughts on “Jamf Pro and Google Secure LDAP”

  1. Do you have a more step by step guide for Jamf cloud? This completely falls apart for me when I try to run sudo /etc/init.d/stunnel4 restart with the cloud config in the google-ldap.conf file.


      1. I’m having issues launching stunnel after adding the configuration for Jamf Cloud to google-ldap.conf. The only other variable is that I ran a sudo apt get ugprade on my AWS ubuntu instance, but I’m not sure why that would have broken stunnel.

        1. Did some more testing and confirmed that stunnel breaks the moment I update the google-ldap.conf file to what is below.

          cert = /etc/stunnel/Jamf.crt
          key = /etc/stunnel/Jamf.key

          client = no
          accept = MYURL.jamfcloud.com:1636
          connect =

          client = yes
          accept =
          connect = ldap.google.com:636
          cert = /etc/stunnel/GoogleMYCOMPANY.crt
          key = /etc/stunnel/GoogleMYCOMPANY.key

          The error I receive is:

          systemctl status stunnel4.service
          ● stunnel4.service – LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons)
          Loaded: loaded (/etc/init.d/stunnel4; generated)
          Active: failed (Result: exit-code) since Wed 2019-02-13 17:28:54 UTC; 8s ago
          Docs: man:systemd-sysv-generator(8)
          Process: 3352 ExecStop=/etc/init.d/stunnel4 stop (code=exited, status=0/SUCCESS)
          Process: 3373 ExecStart=/etc/init.d/stunnel4 start (code=exited, status=1/FAILURE)

          [!] Error binding service [ldap_IN] to MY.IPADDRESS:1636
          [3373]: [ ] Unbinding service [ldap_IN]
          [3373]: [ ] Service [ldap_IN] closed
          [3373]: [ ] Unbinding service [ldap_OUT]
          [3373]: [ ] Service [ldap_OUT] closed
          [3373]: failed
          [3373]: You should check that you have specified the pid= in you configuration file
          [1]: stunnel4.service: Control process exited, code=exited status=1
          [1]: stunnel4.service: Failed with result ‘exit-code’.
          [1]: Failed to start LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons).

          1. What do you have as ACCEPT FQDN? That should be you public FQDN on which the connection from JamfCloud reaches you sTunnel machine. Properly configured with that hostname and port forwarding allowed.

  2. “Accept =“ below should not be your JamfCloud URL… nor internal IP. It needs to be the FQDN on which the service can bind and listen for incoming connections.

    client = no
    accept = MYURL.jamfcloud.com:1636
    connect =

    Needs to be:

    client = no
    accept = public-FQDN-sTunnel-server:1636
    connect =

    1. Thanks, updated the accept to my FQDN and stunnel is now running without outputting an error, but I’m still not able to get a successful test from Jamf Cloud.

      My new conf file is:

      cert = /etc/stunnel/Jamf.crt
      key = /etc/stunnel/Jamf.key

      client = no
      accept = ec2-MYFQDN.compute-1.amazonaws.com:1636
      connect =

      client = yes
      accept =
      connect = ldap.google.com:636
      cert = /etc/stunnel/Google.crt
      key = /etc/stunnel/Google.key

      I uploaded the cert that I created using the command below to my JamfCloud and have SSL enabled, but still no dice.

      sudo openssl req -new -x509 -days 365 -nodes -out /etc/stunnel/Jamf.crt -keyout /etc/stunnel/Jamf.key

      1. Try without SSL by removing the 3 lines above [LDAP] in and disable ssl in JamfCloud to isolate issue with SSL / cert. Apart from that, are the IP’s of JamfCloud whitelisted? If you open the FQDN for any inbound sources, can you telnet in FQDN port 1636? Finally, are you using the special Google credentials you have to create? And not just any account… also, when testing the connection in JamfCloud, and it fails, check in the Jamf Server logs (Jamf Settings). It will tell you what’s wrong.

        1. Whitelisting Jamfs IP’s did the trick.

          I actually did this earlier but tore the previous instance down for a clean install and never updated the security group for the new instance. Thanks so much!

          1. I’m trying to get this to work on my Jamf Cloud instance with both the config “Mike” posted and the one “TTG” outlined in the post.

            I have tried with/without SSL. I have confirmed Firewall rules are set. I am using FQDN in the “accept” portion of the ldap_IN block.

            I get the following error message:

            stunnel4[14780]: [!] Error binding service [ldap_IN] to :1636
            stunnel4[14780]: [ ] Unbinding service [ldap_IN]
            stunnel4[14780]: [ ] Service [ldap_IN] closed
            stunnel4[14780]: [ ] Unbinding service [ldap_OUT]
            stunnel4[14780]: [ ] Service [ldap_OUT] closed
            stunnel4[14780]: failed
            stunnel4[14780]: You should check that you have specified the pid= in you configuration file
            systemd[1]: stunnel4.service: Control process exited, code=exited status=1
            systemd[1]: stunnel4.service: Failed with result ‘exit-code’.
            systemd[1]: Failed to start LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons).

            Could either of you re-share your configs or provide any pointers to help with this?


          2. Hi Daniel! My config is exactly what I wrote in the blog. If you whitelisting of the 6 JamfCloud IP addresses or Firewall rules are 100% correct, what OS are you hosting the sTunnel on? And is the hostname of that device the FQDN you are putting in the config? It needs to be able to bind to that so you might have to put it in hostfile as well.

  3. Figured out the issue with PID after now running it in a chroot environment.

    Now I keep getting this error.

    Error binding service [ldap_IN] to :1636
    bind: Cannot assign requested address (99)

    Any ideas on what I can do to resolve this problem?

    1. Try to bind to the local IP address (replace the fqdn with the local IP addres of the sTunnel machine), and port forward 1636 on a Firewall level. I presume you sTunnel is behind NAT? In my config I used the FQDN and bound to that because I was actually using that machine for other Jamf related stuff.

      1. Thanks for the tips thus far. Using local IP helped that binding part. Also, instead of a port forward, I assigned that server it’s own Public IP address and added it to my external DNS, and did a 1:1 NAT on my Firewall from Public IP to internal IP.

        The thing I’m seeing now is that when testing within Jamf, when performing a look up within “User Mappings” — I’m getting No matches. Also “User Group Membership Mapping” does not seem to work, as it shows “Member – No” when I know a user is in fact in the group. Searching “User Group Mappings” appears to be ok.

        1. Do you have the exact same mapping as in my screenshot? Also, are you doing a search for the email address and not a short username?

Leave a Reply

Your email address will not be published. Required fields are marked *