" class="nav-category">Demo Walkthroughs
  • Leadership
  • This widget could not be displayed.
  • IT Topics
  • This widget could not be displayed.
  • This widget could not be displayed.
  • ">Repo
    This widget could not be displayed.
  • This widget could not be displayed.
  • ">MSPs
    This widget could not be displayed.
  • Community News
  • cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    Feature request: enhance LDAP-as-a-service to support macOS OpenDirectory mappings

    jlgtx
    Novitiate II

    Right now, it's possible to configure JC LDAP to support basic authentication on macOS clients, without installing the JC agent at all. But it doesn't properly support groups, e.g. the OS can't determine a user's group membership, and I'm sure there are other "gotchas" in trying to utilize JC LDAP for macOS authentication & authorization, things like network home directories etc. It would be great to be able to fully utilize JC LDAP in this way, because it would give us a way to manage macOS clients without having to mirror JC users/groups to the local machines.

    5 REPLIES 5

    TomBridge
    Rising Star II
    Rising Star II

    Hey @jlgtx - tell me more about what you're trying to do here? I'm a little confused why the agent wouldn't be the right approach to managing identity.

    jlgtx
    Novitiate II

    The JC agent does its thing by creating local users, groups, etc. -- writing to the local directory service & storage. That's not always desirable.

    Case 1: We have network home directories, group storage, shared applications. We don't want or need local accounts on devices, we just need authentication & authorization, to give a user access to the resources on the network. Thin clients are a bit passé, I know, but there are valid uses, especially when we have an SSO engine.

    Case 2: We have a database server that can use macOS directory services for authentication & authorization. It uses user accounts for authentication, and user or group for authorization -- and it's much more convenient to manage group permissions in the databases, because that ultimately enables us to control database authorization via JC. We don't want local user accounts or home directories on this server, as we don't want to allow local logins.

    Thanks so much for the context! I would strongly recommend filling out a feature request from the Support tab on the Admin Console.

    For Case 2, I would imagine that they support other authentication methods, like LDAP, OIDC or SAML, and that would be the better way to tie into JumpCloud. 

    OIDC just gets user-level authentication, which would require managing user-level authorization in the database itself vs. in JC. OAuth2 would get us group-level authorization, but then I'd have to come up with all the particulars for a custom OAuth2 connection...or, I could just set the database to use macOS directory services, which are easier to tie to JC, and be done with it.

    Now, if there were a set of instructions on configuring an OAuth2 connection to JC from FileMaker Server...

    While I don't have a Filemaker Server to test with yet, I did find these instructions: https://help.claris.com/en/server-help/content/config-auth-oauth.html