Multi-domain environment and Infrastructure Manager on Windows Server 2016

[dng2000]

Has anyone figured out any successful workarounds on getting Infrastructure Manager (JIM) on the same Windows Server to proxy to more than 1 domain for LDAP? According to Jamf support, it only supports 1 domain per JIM per server and I got 3 domains in my University's AD forest to deal with. I also created a feature request in https://www.jamf.com/jamf-nation/feature-requests/9333/feature-request-jamf-infrastructure-manager and hopefully you all can help with that by upvoting it.

[Anonymous]

Following and upvoted your FR.

I just had a conversation the other day with our Jamf team on this. We have a similar situation with multiple domains and single JIM instances on Windows 2019. We were not able to select the existing JIM to perform additional lookups (search base, etc).

This is definitely a shortcoming on the tool, as our previous MDM (on-prem) has the ability to have multiple LDAP configurations/search bases/domains, and I believe Jamf Pro could do this if you don't have a JIM.

Would be interested to see what your feedback on your FR or Jamf team provides, if I hear anything I will update.

[leslie]

Are they in the same forrest? Would querying the global catalog provide the needed attributes?

[Anonymous]

@leslie in our case it does not appear to be an option. Though our AD configuration domain is a single forest, single tree, with multiple child domains under the root.

Working with our Jamf team we tried a few different methods, including using the root domain as the search base, which did not work, but when we used a particular domain in the search base DC=domain1,DC=ad,DC=corpdomain,DC=com, it would pull records from that domain as expected. When using a directory tool for a more in-depth look at our config, seemed to confirm our findings that look ups don't appear to span.

After comparing to the previous MDM, LDAP also needed to be configured to use multiple search base configurations (though this mdm is not using an LDAP Proxy, that I am aware of).

[leslie]

@randy.andersen - well that's a bummer. Sorry if I'm asking the obvious, but you are querying port 3268 or 3269 (secure port).

[Anonymous]

@Leslie hm, that may be potentially the issue. Testing 3269 in ApacheDirectoryStudio at the root seems to pull records within the other domains (where as using 636 previously did not).
Our current firewall configuration is 8636 from JamfCloud to JIM, then 636 from JIM to AD/LDAPS. In JamfCloud the server/port for AD should be updated to 3269? And keep the LDAP Proxy/JIM port at 8636?

[leslie]

@randy.andersen Right, 3269 hits the global catalog whereas 636 only provides results from a single domain. Looks like you have the settings in Jamfcloud for LDAP server/port correct, leaving LDAP Proxy port as is.

[Anonymous]

thank you @leslie, and just to confirm visually, this is how it should appear in Jamf?

3269 should be opened all the way through? ie; jamfcloud > jim/dmz > internal ldap? and this should work with a JIM (even a single instance)?

@dng2000 my apologies for taking over your thread, hopefully this information might help your situation.

[dng2000]

@randy.andersen No worries and by all means because I'm in need of help with figuring out how to get LDAP in Jamf Cloud to work for my multi-domain environment. For my DC connection, I'm using 636 instead of 3269. So far, I only got 1 of my 3 domains mapped successfully for LDAPS.

[Anonymous]

@dng2000 do you have 3269 open? if so can you try that and map to your root? I'm curious if that will work as @leslie mentioned, once I get my firewall team on this I can test it out and report back.

[dng2000]

Not for JIMS so I have to work with my firewall team at my org tomorrow for help. However, I tested this on my on-prem sandbox environment (which I don't need JIM for) and it looks like that worked by mapping my DC to port 3269 and blank out all search bases I was able to search a few users from a few domains in my AD forest. Thanks @randy.andersen because your screenshot gave me that idea to play with. Now I still need to test that in my JIM when I get my firewall guys to help with that. :)

[dng2000]

And I just encountered a new problem. If I change my DC port to 3269 and blank out the search base for GC, my LDAP user-to-group mappings no longer work. So I haven't fully figured this out yet.

[Anonymous]

you'd probably need at least the root search base DC=corp,DC=com (usually what is after the realm/domains)

One tool you can use is ApacheDirectoryStudio, that has been helpful to pull mappings and testing searching with the particular ports.

[dng2000]

@randy.andersen Yes except the AD forest in my organization has dc=onename,dc=edu and dc=differentname,dc=org which is where it isn't helping for me. So I suspect even if I get this to work, I still need 2 JIM's - 1 for each root.

[dng2000]

@randy.andersen Did notice the ApacheDirectoryStudio suggestion 'til I reviewed this page again. Thanks again for the tip; will definitely try that tomorrow. :)

[leslie]

@randy.andersen - screen shot looked good.
@dng2000 - ya, with disjoint domains, think multiple JIMs is your solution.

[Anonymous]

Thank you @leslie, after getting our firewall changes done and testing, 3269 seems to have resolve our lookup issue. Hopefully this also helps you @dng2000 . I'll be interested to see how the multiple JIM set-up works out.

[dng2000]

@randy.andersen Were you using JIM when testing?

[dng2000]

@randy.andersen I forgot to mention that I still can't get LDAP group mappings to work, which I'm going to talk to my assigned Jamf support engineer about tomorrow. It works without JIM/LDP though. I fortunately still have my Jamf sandbox "on-prem" where I don't need to worry about network firewall rules so I'm sure it is still something with JIM/LDP.

[Anonymous]

@dng2000 Yes, JamfCloud 8636/AD serverport 3269 > JIM 636 > Internal LDAPS.

Are the corresponding firewall ports open inbound on your OS firewall rules of the JIM Server?

[dng2000]

Yup. I still couldn't get User Group Mapping to work, even for Universal groups, in my AD environment when connecting to my GC.

[leslie]

Recall not all LDAP attributes are replicated in the global catalog. For example I don't believe memberOf would be in the global catalog by default, it can however be added. Here's just a little info: Including Attributes in the Global Catalog

[konfio]

Could you solve this?