Specifically Okta LDAP.

Okta has a native LDAP interface that can be very useful for products that require it. Like say .. Jamf Pro.

LDAPS is one of those protocols that was handy when it was first invented but has seriously outlived it’s usefulness in today’s cloud first world. Leaving that aside, there are times when you have to make Jamf work nicely with it.

Sadly Okta rate limits the heck out of it and Jamf is particularly “noisy”. As a result with much discussion on the mac admins slack and some experimentation, I decided to compile what should be the definitive okta settings guide for Jamf Pro. At least definitive as of September 2021.

(Hello the Future! This might be horribly inaccurate by the time you read this!)

I’ve run out our Jamf Pro config and censored the relevant parts for security. You should be able to match the settings with what’s normally displayed in the Jamf Pro GUI.

==========================================================================================
LDAP Servers
==========================================================================================
	Name ................................. ** name of ldap setting **
	Hostname                               okta name here.ldap.okta.com
	Port ................................. 636
	LDAP Proxy Server                      false
	SSL .................................. true
	Open Timeout                           15
	Connection Timeout ................... 60
	Wildcard Searches                      false
	----------------------------------------------------------------------------------
	Authentication                         simple
	Distingushed Name .................... uid=account email here,dc=okta name here,dc=okta,dc=com
	----------------------------------------------------------------------------------
	User Object Class Limitation           all
	User Object Class(es) ................ inetOrgPerson
	User Search Base                       ou=users,dc=okta name here,dc=okta,dc=com
	User Search Scope .................... First Level Only

	----------------------------------------------------------------------------------
	User Group Object Class Limitation     all
	User Group Object Class(es) .......... groupofUniqueNames
	User Group Search Base                 ou=groups,dc=okta name here,dc=okta,dc=com
	User Group Search Scope .............. First Level Only

	----------------------------------------------------------------------------------
	Membership Location                    Group Object
	Member User Mapping .................. UniqueMember
	Use distinguished name                 true
	Use LDAP Compare ..................... false
==========================================================================================

Fill in the blanks section:

• Name
  • This is the Jamf name of your LDAP settings
• okta name here
  • This is the name of your Okta tenant. It’s usually your company name.
• Distinguished Name
  • Replace the “account email here” with the email of an Okta account allowed to access LDAPS services.

The rest is pretty simple to follow. Most notable things are to change the search scope to “First Level Only” from “All Subtrees”, which will cut down on the search times considerably. Disabling wildcard searches improves reliability at the cost of having to do explicit searches. Finally the use of the “UniqueMember” setting in members of groups.

For the longest time I was not specifying the OU in the search bases for users or groups with the end result that any LDAP query was expanding into areas it didn’t need to.

Was this profitable? Well I hopefully don’t need to worry about this again! Was this fun? I’ll let you draw your own conclusions on that.