Ability to remove/disable users after they leave the company about opensource-management-portal HOT 7 CLOSED

What we/I do is to leverage the /unlink API endpoint. We have an external script, which gets the list of all users from the opensource-portal daily, checks them against our internal user directory, and then if they are not found in our internal user directory unlinks them. Unlinking causes the portal to remove them from all organizations and that works quite well.

The advantage of the external script (vs. e.g. something built-in) is in my opinion that we can manage some special cases and special user directories.

from opensource-management-portal.

@brugidou that's a good point... way too many things are deeply coupled right now. We once had a version working with GSuite and other tech to prove it could be decoupled, but it's not pretty. Open to ideas to abstract out or fix some of that.

I doubt it's really required, but might be used to find e-mail address details or managers or something.

Internally we have another job that helps us find the manager for a former employee, or look it up in a cache of last-known-manager, for example... probably worth us removing from the generic implementation.

from opensource-management-portal.

We have something very similar... let me see if the script is part of the open source files or not. Some of the more company-specific things are quite hacky.

We use two approaches:

1. Most-aggressive, we have a company-specific Azure Data Explorer / Kusto query that provides us a very strong confidence that someone has left the company. An hourly job uses this data joined with the link data to then use the 'external' unlink API to remove those users.
2. A cronjob compares all linked users with the Microsoft Graph, and if the entries by AAD ID 404 a few times consecutively, we remove them.

My bet is #2 is also a little hacky... we had a few instances years ago where we aggressively unlinked users.

from opensource-management-portal.

• So operations.terminateLinkAndMemberships is what we tend to use to remove users internally. https://github.com/microsoft/opensource-portal/blob/main/business/operations/index.ts#L451
• The exposed api/people/unlink API is what we use to connect to that. https://github.com/microsoft/opensource-portal/blob/main/api/people/unlink.ts
• Here is a script from our project that is not in the open source project, but should be... it's just a brute force walk to identify 404'ing linked users. I found another version which has a scary-looking set of calls into terminateLinkAndMemberships. I've shared that script here just now: https://gist.github.com/jeffwilcox/3eb652cb088ceaebb6a62fe8ebcb5f7e

I think given that I think we definitely use #1 as the primary approach.

We also use SAML single sign-on for our GitHub orgs in the enterprise, and so have some additional protections in place, since former employees will not be able to SAML in.

Open to ideas to make this more robust or usable.

from opensource-management-portal.

Hey, thanks for all your answers! it seems that the refreshUsernames job also calls terminateLinkAndMemberships I may try it but it will require me to get the Microsoft Graph provider to work.

from opensource-management-portal.

This issue has been identified as stale because it has gone 30 days with no activity.
The issue will be closed in 10 days. If this is incorrect, simply comment on the issue, or remove the stale label.

from opensource-management-portal.

Closing this issue for now;

While strongly coupled to Microsoft graph, the refreshUsernames job + terminateLinkAndMemberships is our recommendation for the time being.

from opensource-management-portal.