[FEAT]: Disable a User account created by OnspringAzureADSyncer that does not exist in a group configured in OnspringActiveGroups

[RobertKlohr]

This feature request is dependent on #28 or a similar feature that would add a flag to each user account in Onspring created by OnspringAzureADSyncer.

When users are synced, if the user record was created by OnspringAzureADSyncer as determined by the presence of a field containing the Azure Object ID, and the account is no longer in one of the groups configured in the OnspringActiveGroups section of the configuration file, the user account is set to Inactive.

[StevanFreeborn]

So, this behavior is already in place today.

If a user is sync'd over from Azure to Onspring and there is a match in Onspring by the username mapping, but the user isn't found in one of the OnspringActiveGroups the user is set to Inactive.

Are you seeing different behavior? Or maybe I'm misunderstanding?

[StevanFreeborn]

Oh, now I think I get it what you're saying is in the case where a user was created in Onspring, but is no longer being synced from as Azure anymore because of whatever filters or active groups, you configured you still want the app to inactivate that user account on Onspring.

This way you can essentially From a particular group and Nager and it inactivates them and Onspring.

[RobertKlohr]

I think you have it now. A simplified use case would be:

1. A user is created in Onspring from this application.
2. Then the user is deleted from Azure.
3. On the next sync the application would set the user in Onspring to Inactive.

The only way I see to do this would be for the application to flag the account in Onspring as having been created by the application as there would be nothing in Azure to match it to at this point. I think using the Object ID could serve the dual purpose of being the flag, and the foreign key in Onspring that maps back to the original account in Azure.

Also matching on the username field could be problematic in edge cases where an account is created manually in Onspring with a username that matches a username in Azure. If this happens then obviously there will be a failure logged when we try to create the account during the sync because the username already exists, but what we don't want is for this local account to ever be set to Inactive by the application. That is why I think writing the Object ID to the record, say in a new field that we say is required as part of the setup, eliminates this problem.

[StevanFreeborn]

Okay so I'm following you here now.

Mandate object ids be mapped into Onspring.

Leverage that as a flag for inactivating orphaned azure user accounts.

But you are saying also to use that mapping to do the matching of Azure Users to Onspring users instead of the username field to prevent ever erroneously updating a non-Azure user in Onspring.

I think we can make that work.