@Stephen Stahl,

Respectfully, I disagree. I believe the ticket that addresses your ask would be the linked issue: JSDSERVER-5072.

I agree that, as a JSM admin, I want to manage user groups that come from external directories as an organization, meaning that the users added/removed from our LDAP group will be reflected in the organization as soon as possible. HOWEVER, It is a requirement of my organization that we not expose our LDAP group names to our customers, as would be done in the solution provided by JSDSERVER-5072. It would also be supremely beneficial for us to be able to add, say, multiple LDAP user groups to a single JSM Organization. 

NOTE: The addition of multiple LDAP groups to a single JSM Organization would not be necessary if JSM better supported the use of nested LDAP user groups, but we are currently limited to using LDAP groups that contain our users directly instead of LDAP groups containing other LDAP groups which then contain our users.

As I understand the use of LDAP groups in JSM currently, a sync of users is already being regularly performed with JSM caching the data for its own use. What my organization wants from this suggestion is to be able to add those LDAP user groups (that are already synced with JSM) to an existing JSM Organization.

To be honest, I think the requirement of this ticket is not defined clearly enough. IMO the goal is not "adding a group to an organization". The goal should be: Groups can be treated as organization - wherever they come from, e.g. Active Directory, LDAP, internal directory, you name it.

I work in several instances where customers are stored in an external directory. The "customer-users" tend to be grouped into their own "organization" (=e.g. LDAP Groups) within that external directory anyway. Treating this specific group as "organization" within JSM would already solve so many problems... (e.g. sharing tickets among the users of an organization, without having to check if the user is actually present within that JSM orga...)

Currently whenever something changes within that "external directory", we have to trigger the whole CRUD-part of the user in the organizations with API methods. (This is technically OK, but requires a workaround for a feature that is overdue to be implemented...!)

So, to sum up my requirement in that case:

As JSM admin, I want to manage user groups that come from external (/internal) directories AS organization.

All users within that user groups will "automatically" become a member of that organization.
Whenever a user is added to the user group in the external (/internal) directory, the user will be added to the organization.
Whenever a user is removed from that user group, the user will be removed from the organization.

I don't think a "sync" between LDAP/AD and "ORGANIZATIONS" makes sense. (That would just add another layer of complexity with foreseeable problems here, with members of organizations not matching the user groups when something goes wrong...)

If you already have the exact data you want to work with from somewhere else: why not use it?