Idea ID: 2738873

Support for LDAP Groups and Synchronization

Status : Delivered
over 4 years ago

SBM currently lacks the ability to synchronize LDAP group membership with SBM group membership. For organizations like ours, this leads to great deal of unnecessary manual effort to maintain those users' group memberships. Ideally, SBM should automatically add/remove users from groups based on their existence in corresponding LDAP groups. Additionally, this would enable SBM to scale to its user management being externally managed by other tools which manage security via LDAP.

If you feel that these features would benefit your organization, please vote on this Idea. It would be great if you have the time to also leave a comment as well – especially if you have additional requirements which are not reflected here.



Here are our high level requirements (above and beyond existing SBM functionality).

  • Automatically (on demand and on a schedule) add and remove users from one or more SBM groups based on one or more LDAP groups

  • Must support groups where members are identified via member of attributes as well as member attributes (meaning both where LDAP has the members as attributes of the group as well as where the group membership is stored as attributes of the users).

  • Must have the ability to automatically manage the User Access level of users to support the highest common denominator of the groups they are in.

    • In other words, if a User has access level of None, and is automatically added to a Managed Administrator level group, then change the User to be of Managed Administrator access level. Conversely, if that user were then removed from that Managed Administrator group, then reduce their access level down to None (either because the user is in no more groups or because the groups they are in only have None access level).

  • Allow User import/update filter to include a means to use groups.

    • Currently, SBM only allows for User attributes to be used in the search filter. Here at Morgan Stanley, our directory is organized such that users are attributes of groups. Therefore, SBM cannot filter users by groups. Roughly speaking, this means that all users in the company have to be imported into SBM even though a subset of them have roles in the product.

    • This would probably be achieved by have a 2nd search filter designed to find the LDAP Groups against which to apply the existing User filter. A way to indicate whether members are properties of groups or group membership is properties of users would also be required. Lastly, the ability to specify the name of the attributes used (typical values include "member" and "memberof").

    • Similarly, this feature would also need to extend to the Delete user use cases such that users could be deleted when they are no longer in an LDAP group that matches the above group search filter.

  • SBM would also have to provide a means of mapping the SBM groups' names to LDAP Groups.

    • A default mapping of a naming attribute (to be selectable by an SBM Admin) and an SBM group name would be ideal. That way, any group matching the group search filter, could then be provisioned into SBM by matching the attribute to the SBM group name.

    • If there were also a LDAP filter section in the SBM Group definitions, then this default mapping could be overridden with a custom filter. This would extend the model to allow the LDAP sync to join specific LDAP groups (or user filters) together dynamically to populate a single SBM Group.

  • In the scenario where a group is configured to be mapped, but does not exist in SBM, the tool should have an option to control whether that group is automatically created. Conversely, if a group had been synced with LDAP but that group no longer matches the Group filter, then the group should be able to be automatically deleted.

    • This will probably require that Groups have an Imported/Updated from LDAP flag internally.

    • For parity with user operations, an option to delete groups matching a filter may be appropriate

  • If an SBM group is not synced, its members should be left unmanaged (membership will effectively be the responsibility of the SBM Administrator).

  • If a LDAP group contains another group as a member, that included group’s members should be considered members of the parent group and all recursively referenced users would be synced to the corresponding SBM group.

    • This is due in part because SBM groups currently do not allow groups to be members of other groups. If this were to change, the above requirement would likely not be required.

  • Process should allow for the use of a sample (template) user for initial imports, specific for each group

    • Currently Import Jobs allow for the specification of a user. That model could still be used if we could use one LDAP configuration per group. However, a more scalable implementation would be preferred (in order to minimize the number of separate LDAP configurations to maintain). Ideally, like Group Preferences, groups could have a template user for new users.

    • Keep in mind not all SBM groups may be synced with LDAP but may need to be part of template (Like a manually managed "All Users" group in addition to synced groups)

    • May need to reapply user template (or at least group preferences) on each sync (or maybe a flag to do it when template changes or manual user edits are detected/suspected)

      • This may lead to situations where the group preferences are hard to calculate when overlap is detected. Generally they should be unioned. But in cases were conflict could occur (like a home page report), a way to order the synchronization may be necessary (such as sync Group A, then Group B, then Group C, such that the result is predictable).

  • All changes made to users and groups shall be logged

    • The detail level would be configurable as it is today.

    • This would likely be an extension of the existing logging.

    • Internally, there may be some overlap between the Import logs in the TS_TRACEWORKS table and the TS_ADMINCHANGES table. Additionally, it should be auditable such that it can be determined how updates were made (such as via Web Admin, Web Services, or LDAP jobs) [in addition to the user that made the changes where applicable]

  • As SBM is an enterprise application, the implementation would need to support large enterprises reliably and efficiently. This includes supporting 80,000+ users, 200+ groups, high availability, distribute processing to additional load balanced or clustered servers, query LDAP efficiently for changes where possible, and options to throttle the process if it has the potential to affect the normal operation of the system.

  • If possible, better support the renaming of LDAP objects. For example, if a user's login id changes because of name change, it would be ideal if that would be detected as a rename instead of a "delete" and an "add". This would be limited likely by LDAP capabilities.

    • As an alternative, if two users could be easily merged manually, then this would be less of an issue.

Supplemental Requirements

In order to better support the use cases above, here are additional requirements:

  • Do not delete via LDAP unless imported or updated via LDAP

    • Currently if two SBM servers use different authentication options (such as one with LDAP and one with Internal) OR one server with LDAP first then Internal, you cannot use the feature that deletes users who do not match the specified filter within an Update from LDAP job without deletion of user accounts not backed by LDAP.

    • When LDAP Update job is run on accounts that were manually established, if they match the user search filter, set a Imported/Updated from LDAP flag true so that they can be managed by LDAP synchronization thereafter. This will better support preexisting accounts prior to the introduction of this new feature. A similar flag already exists on TS_MEMBERS and would probably need to be honored by these new features to allow manual overrides if desired. This flag on the users, memberships, and groups may need to be visible and able to be selected as a filter to aid in management of exceptions and initial conversion to the use of these sync features.

    • While not an issue for us, if two SBM servers sharing one database used two different LDAP configurations, a configuration id may also have to be associated with the users, groups, and members in order to properly manage the system.

  • Ability to generate ALF events to correspond to each resulting operation

    • As each customer's onboarding and off boarding process may involve more than just user management (such as reassignment of work), the tool should emit ALF events with enough information about the change so that onboarding and off boarding activities can be automated via custom orchestrations.

    • This also implies that ALF events would need to be raised regardless of the source of the change (LDAP sync, Web Admin, or Web Services) and that source would need to be part of the event.

  • Enable user values in User/Multi User fields to be distinguished by more than just their Full Name (as this is not always unique in LDAP).

    • Alternatively, LDAP attribute map could be made to support a value display format approach allowing the selection of multiple attributes or even a value display format defined logically at the User table or higher in the tool (like Contact cards).

  • Enable the search on User/Multi-User fields to include ability to search on other user attributes.

    • Potentially, those visible in Contact cards would be a safe default. Otherwise, the list of searchable fields would need to be controlled by an SBM Administrator

  • The tool should allow for attributes in LDAP to be mapped to User and/or Resource attributes such that org chart information is traceable within SBM. In other words, it is not sufficient to map a manager's name or LDAP DN to a Manager field – it should manifest in the tool as a reference to the corresponding User field where possible. This would then set the stage for being able to notify a user's manager in an escalation or further automate onboarding and off boarding activities. This could be aided by saving a DN attribute in the user objects.

  • With increased LDAP capabilities, the number of users defined in SBM also tends to grow. This increases the size of the Global Process app. This increases the time needed to create snapshots and promote them. It would be ideal to optimize this to run faster, or be able to either exclude user data from snapshots and/or at treat it like Notifications and only include users referenced by other entities. For us, it takes an hour to create the Global Process App snapshot, and we do not use Contact records for users.

  • Kerberized Access for connection to LDAP

    • The product should allow the credentials of the application pool or Windows service running the SBM application to be used to perform the connection to LDAP directory. In this way, an SBM Application Administrator does not need to know the password, it is more secure, and more scalable to password changes.

  • Ability to cancel running synchronization tasks.

Additional features to consider

Here are additional features that we considered but don’t currently need. They are included in case other customers have a need for these features.

  • Some customers may not have LDAP groups usable to manage groups in SBM – but they may have other LDAP user attributes (such as Department) that do correlate to an SBM Group.

    • SBM partially supports this use case when first creating users. However, it does not currently support it when group membership is defined by member properties of groups nor maintenance of those users' group membership after creation.

  • Some customers may have a need to sync logically to an LDAP directory rather than physically. To achieve this, SBM would need to support the processing of LDAP LDIF files. This may be in a fashion similar to Excel import or a way that can be scheduled as a recurring job.

  • It may be desirable to notify users of changes made via the LDAP sync. The user affected could be notified as well as admins may want a summary of changes.

    • Notifying a user that they have been deleted may need to be a configurable option as it may not be desired or appropriate in certain use cases. For example, it may fail to send an email to a user if the user is no longer able to receive email.

  • Extend these LDAP use cases to Contact records and/or Resources where applicable.


  • All I can say that no customer "including us" is willing to buy or even consider Micro Focus ID solution to compliment a basic functionality of the tool. David comments will make us to revisit the Serena Tools and its utilization in our organization and may eventually let us sunset the product.
  • All I can say that no customer "including us" is willing to buy or even consider Micro Focus ID solution to compliment a basic functionality of the tool. David comments will make us to revisit the Serena Tools and its utilization in our organization and may eventually let us sunset the product.
No Data