Ability to remove/disable users after they leave the company

[brugidou]

I've been able to run the project that I would like to use as a replacement for the very old and unmaintained AD Connector we use today.

One key feature that I don't see (but it may exist!) was the ability to disable/remove any terminated employee from all our organizations. I tried to check the provided cron jobs but failed to run them (i'm running the docker compose setup for now, using AAD and a Github App).

How do you handle this internally?

[Shegox]

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.

[jeffwilcox]

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.

[jeffwilcox]

• 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.

[brugidou]

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.

[jeffwilcox]

@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.

[github-actions[bot]]

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.

[jeffwilcox]

Closing this issue for now;

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