Important Notice regarding Jamf Infrastructure Manager, LDAPS, and Jamf Pro 10.11

[doug_howell]

Just received this email from Jamf about forthcoming changes to LDAPS in 10.11. We have serious concerns about how this change would impact our Jamf Pro cloud instance:

Additionally, any LDAP server connections using LDAPS will require that the hostname of the LDAP server match the Common Name (CN) on the certificate that is uploaded to the Jamf Pro Server. A mismatch will prevent communication between the LDAP server and Jamf Pro Server.

Posting what I replied to Jamf with, hope others may face the same issue and also voice concerns back to Jamf (and upvote Feature Requests related to SAML and SCIM)!

Our internal domain that LDAPS binds against is a .local domain (over 20 years old AD!). This is not internet routable so there is no way for the hostname we give you on the Internet to match the common name. We can’t be the only ones that will face this issue! If you can match based on a SAN, we can probably make that work by adjusting our ADCS certificate template on our DCs that we expose to Jamf.

We fully support the security thinking behind this, but your efforts should go to doing a complete, proper SAML and SCIM implementation on your platform first, so we don’t need to use LDAPS at all over the Internet.

[sneil]

I think we're in a similar situation where our certificate and host name won't match either. Additionally this traffic is routed through our NetScaler as we don't allow direct access from the internet. I've opened a ticket with support as well. I'm awaiting more info back from support, especially the timeline for this upgrade.

[alexjdale]

I've never had to upload a certificate to the Jamf Pro server to use ldaps, just make sure the root cert is in the java keystore. What am I missing here?

[doug_howell]

I sense some security audit told them they should do this, and while it is admirable, it shows no understanding of typical customer infrastructure. This needs considerable advance notice, testing and acceptance on a per-customer basis.

It absolutely cannot be "You've been upgraded to 10.11! New feature: none of your admins and users can login; your entire subscription is useless!".

[doug_howell]

alexjdale,

They are saying the Common Name (CN) will have to match. So if you are pointing to mysecuredcproxy.mydomain.com and that is not the CN on the certificate that it connects to, the connection will fail. Taking CN to strictly mean CN, that means if its presenting mydc.mydomain.com that will fail, or mydc.mydomain.local that will fail, or if it is a proxy and you present myproxy.mydomain.com with a SAN of mysecurddcproxy.mydomain.com, that will also fail. A wildcard at your proxy would work I think (*.mydomain.com) as the wildcard is the CN.

[doug_howell]

Thinking further on this, a much better way to do this would be to give the customer the option on how to harden LDAPS. For example a rule builder to define how it validates:
- must be issued by my Root CA and match [regex].mydomain.local OR
- must be issued by a publicly trusted CA and match myproxyname.mydomain.com

(And the best way would be to implement SCIM and properly working SAML and advise everyone who can support those to move to those for provisioning and authentication instead of LDAPS!)

[tneubauer]

Do we know a date when the 10.11 upgrade will occur?

[doug_howell]

"Do we know a date when the 10.11 upgrade will occur?"
Excellent question. Totally absent from the email notice. Well, they did say "upcoming".

[Aaron_Kiemele · Accepted solution]

Strict SSL/TLS hostname validation ensures the integrity of your encrypted connections and prevents a variety of man-in-the-middle (MITM) attacks against Client-->Server communications in Jamf Pro. This will ensure that the common name (CN) or one of the subject alternative names (SAN) in the valid certificate matches the original string used to address the server endpoint. This method supports the use of wildcards.

For clarity, this change has two areas of impact:
· For those customers using Jamf Infrastructure Manager (JIM) as an LDAP proxy, we have updated the template for certificates to include a Subject Alternative Name (SAN), both to maintain compatibility with Java 1.8.0.181 and to allow for strict hostname validation for non-SSL connections through the LDAP proxy. Re-enrollment of the JIM is required in order to issue a new certificate containing the SAN field so it passes the enhanced strict hostname validation.
· For those customers who are not using an LDAP proxy, no changes will be enforced for currently configured connections. If you wish to edit an existing connection that does not meet the requirements for strict hostname validation, the system will require a new compliant certificate.

Jamf Cloud customers won’t be upgraded without first hearing from Jamf. Targeted outreach messages have already gone out, and our Customer Success organization is proactively coordinating with impacted customers to ensure future upgrades are successful.

Aaron Kiemele
CISO, Jamf

[doug_howell]

Aaron,

I appreciate the response on this. I agree with the reasons you are doing this. My reaction was because the initial customer communication did not mention SAN would be supported in addition to CN, nor did it mention the upgrade schedule and how that would be coordinated (usually we get an upgrade window given, this time we have to schedule it with our account rep).

[Chris]

I‘m still not entirely clear on this. I asked support specifically if a SAN is sufficient and was told it is not.

[hdsreid]

so the uploaded certificate is in LDAP configuration, correct?

I cannot get this to work for some reason but used to work on another server just fine. I have the Root AD CA uploaded and the DNS name cert but still can't get it to work. is there a way to even check if it is certificate related or if it is port related? big problem with my cloud instance is it makes it harder to check where it is failing

[mainelysteve]

@hdsreid The cert should be for the DC/GC that your jamfPro instance is using for lookups i.e. AD-DC1.something.local(.org.edu, etc.). Don't quote me on that but I don't think a non server specific root AD ca cert won't work.

The cert goes in the LDAP Servers section. Check Use SSL and upload the certificate.

[hdsreid]

@mainelysteve

trying to do this without putting real server names here so bare with me....
but main controller would be mainADCA.top.domain.com and jamf is trying to connect to specificController.top.domain.com
I have the certs for BOTH of these servers in the ldap config just in case, and cannot find a way to delete either of them if this is creating a conflict. specificController's cert was assigned from mainADCA and is on the chain.

[mainelysteve]

@hdsreid

You can either delete them under PKI Certificates or recreate your LDAP config. That's all I can see as available options considering the delete button next to those certs is oddly missing in that area.

[hdsreid]

@mainelysteve funny enough I cannot find them in the PKI settings, nor does deleting LDAP configs get rid of it. If I delete the LDAP config and create a new one, both of those certs are still there lol

[hdsreid]

Just wanna say I solved this and it was a stupid solution...Apparently Windows Firewall was enabled and blocking JIM communication. Now it works fine

[mainelysteve]

@hdsreid Great! Glad it's working. I've had a few of those duh moments throughout the years. Sometimes I'd even look at that "stupid stuff" first then decide it's not the problem then a day or two later find out it was the "stupid stuff" causing my problem.