Multiple tenant and invitation APIs

[cblomart]

Hello,

When working with multiple tenants, the invitations process and api can generate confusion.

If Sharepoint is linked with one tenant:

• multiple result on lookup: invited users and native users in their tenant.
• inviting a user from another tenant does not work until the user is properly invited.
• previous question is valid on inviting a group (role)

What would you think of the proposition to:

• integrate azure ad invatitation api (users and groups).
• detect correlation between guest accounts (shadow users from primary tennant) and primary account in another tennant (configured in azurecp). So that only the primary account is shown.

thanks for the usefull tool!

Cédric

[Yvand]

Hello, thank you for your feedback, and sorry but I think I don't understand what you propose.
I didn't know the AAD invitation API so I found and read this.
Can you make your point more explicit?
Do you propose that AzureCP replaces the site invitation process of SharePoint (and not only the people picker lookup)?

[cblomart]

We are trying out AzureCP for our solution.

Basicaly, we want to user AzureAD for sharepoint on permises and leverage B2B as well as MSA (i.e: hotmail).

We spotted few points that we would like to be able to handle:
1/Invitation
Authorization does work correctly for the different kind of users. but every user needs an account in azure ad, right. In B2B a guest would have a shadow account.
So users needs to be first invited into azure ad before rights can be set to them in sharepoint. We are debating the use of an invitation portal that would allow to invite extern people. A example page does exist for that (https://github.com/Azure/active-directory-dotnet-graphapi-b2bportal-web if i am right).
We can't avoid feeling that there should be a more sharepoint integrated solution to that.
2/Groups
We wouldn't want to recreate groups from B2B tennants to provide access so we want to use claims enrichments to collect groups from the original tenant of B2B users (provided they are in an AzureAD).
To allow management from sharepoint we decided to configure extra azuread in azurecp thus allowing picking of extra groups.
3/People Picker
So we end up with a "main" azure ad which handles user authentication as well as B2B and MSA. But in people picker both the shadow account and the real account shows up. As discussed in another issue, B2B does work with a claims modification on ADFS level (from #ext to normal upn). But this modification might not be welcome for MSA accounts.
In the end we tought possible to filter out "shadow" accounts from B2B users and only use the information form their native tenant if provided by an azure ad (i.e. main tenant emailaddress match another known tenant upn).

So:

• invitation process: we may have to look in another direction
• shadow accounts: we d'like to correlate shadow account and account from other known tenants to detect shadows and hide them.

[Yvand]

hello,
thank you for the detailed description, it makes much more sense now.
Technically speaking what you describe sounds possible, but it's a big work to do.
To be honest, I have other priorities and I don't think I'm going to invest time to implement this. The most important change I'd like to make is to rely on Microsoft Graph instead of the old Azure Active Directory Graph Client Library (as described here), but even that I don't know if/when I'll have time to do.

With that said, if you have the resources and the time, you could try to implement this on your own. I think it is possible by just inheriting AzureCP, if I create an overridable method (in AzureCP class) that is called after all AAD users/groups were found, so you can add/remove the ones you want.

What do you think?

[cblomart]

Knowing where to implement a function to filter search results would great. Would you have some pointers for the invite process?

[cblomart]

Could a simple patch doing the following be suffisient?

• when listing users
  • if user is of type guest
    • if signinname is in a registered tenant domain
      • do not add to people picker

[cblomart]

Hello,

We installed a test sharepoint and dev tools (vs2013) to look further at customisation.
On compilation we get these errors and warning:

C:\Users\<user>\Documents\AzureCP\AzureCP\AzureCP.cs(911,37): error CS1985: Cannot await in the body of a catch clause

C:\Users\<user>\Documents\AzureCP\AzureCP\AuthenticationHelper.cs(17,42): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.

I can get rid of the error by moving the "tryAgain" flag in the begin of the method and the "if (firstAttempt && tryAgain)" to the end of the method.

For the warning, i didn't realy get the explanation (yet).

[Yvand]

Hello, can you try to sync the latest commit in dev branch and start from it?
I pushed an update this afternoon and, apart from a lot of optimizations, code is also easier to understand.

With that said, I can't explain the errors you mention, compilation should succeed...

[cblomart]

Compiles correctly from dev branch without signature.
If signature is enabled (with self cert), visual studio complains that Nito.AsyncEx is not strong named.