Azure AD B2B Collaboration | Lessons learnt exploring the service

UPDATE 14 November 2015: Microsoft has responded to a question I have left in their blog post on B2B service and have clarified a few things:

• The likely reason why I am seeing an issue with using the self service reset option for the self service signup user is that the user I am using "does not have a valid email address". I haven't managed to test this out, but this makes sense as the email I used this test is not actually a proper email address but one implemented using an email forwarding service to forward any emails sent to that email address to my gmail.
• "If an invited user is in an unmanaged tenant (i.e. no global admin), then self service password reset is enabled for the user. If an invited user is in a managed tenant with a global admin, then self service password reset will only work if the admin has paid for the service in the tenant."

One new feature from Azure that I've been really excited about lately is the Azure Active Directory Business to Business Collaboration Service. I'm not going to go in depth on what this service is about here, as Azure already has good documentation on this service, but on a high level it provides you with the capability to share your organisation's resources with your partners in an easy and secure way.

The key advantage it provides include:

• Sharing organisations can secure partner access to their applications without having to manage the partner user's identity (and handle requests for password resets), or setup complex and expensive inter organisation federation. 
• Partner users can use their work credentials to access partner resources. This makes collaboration a lot easier.
• Sharing organisations can leverage the off-boarding process of their partner organisations to ensure partner users who leave the partner organisation can no longer access the partner's applications.
• Supports sharing applications with partners who do not currently leverage Azure Active Directory in their organisation through an easy email verified signup process e.g. the partner organisation currently uses Google Business Apps.

Lesson Learnt #1: Resetting the password of an email verified partner user does not require requires the partner organisation to perform a DNS takeover of their unmanaged tenant

Scenario: Sending an invite to a partner user whose organisation does not use Azure Active Directory as an identity provider, will provide the user with an easy and wizard based sign up process via their email. However, one thing I couldn't figure out was story around how that invited partner user can reset their password given that 

• Clicking on "can't access my account" on the login page doesn't work (makes sense given this feature is only available on paid versions of azure active directory) and I receive a wierd error message that will confuse end users.
• The sharing organisation cannot reset the user's password as they can not manage the identity of their partner's employees.
• The partner organisation cannot reset the user's password as they do not currently use azure active directory.

Observation: My conclusion from my research and experimentation is that in order for the partner user to reset their password, their organisation does not need will need to take over the unmanaged tenant via a DNS Domain Name Takeover.

Microsoft has clarified that self service password reset is available to users created via self service signup as long as they belong in an unmanaged tenant and the email used to create the user is a valid email address. It is still worth noting that the DNS Name takeover is still required if the partner organisation wants to manage their users.

During the process of trying to takeover the unmanaged tenant of my test partner user, I found out that you cannot sign up for an azure subscription whilst logged in as the test partner user created via the self service signup. Although I haven't tested this again, I believe the challenge I faced signing up to an azure subscription when signed in as the test partner user may also be due to Microsoft checking to see if the email address is a valid email address.

After several back and forth with Azure Support, I found out that I had to signup to an azure subscription separately or use an existing subscription, and perform the DNS takeover from that subscription.

Once you have signed up for a new Azure Subscription or logged in to an existing subscription, you will then then need to 

1. Navigate to the Active Directory Section
2. Click on an existing directory or create a new directory that you want to manage users for your domain name created via the azure's self service signup process
3. Click on the domains tab, and click the add button to start the domain addition process to take control of your organisation's unmanaged users. (You will need the assistance of your organisation's DNS domain name admin)

Overall I found the process of doing the DNS takeover pretty quick and straightforward.

Lesson Learnt #2: Inviting a partner relies on the email address having a custom domain

Scenario: The B2B Collaboration scenario is intended to cater for partner organisations of varying sizes. However it doesn't currently cater for partner organisations who do not have their own DNS Domain Name or use a consumer based cloud service that does not have their domain in their email. e.g. gmail.com, yahoo.com (although not common, these mom and pop type organisations do exist so I would be interested in how this scenario develops as the service hits general availability).

Observation: In my testing, I can confirm that attempts to send an invite to a gmail account will fail. However I did have some hope when I found a blog post from Andru where he indicated that you can add a CCEmail column at the end of your CSV file which will allow you to get around the current limitation of inviting users who do not currently use an email with a custom domain.

I haven't managed to get this working in my test scenario yet, but will update this post once I get it working. 

Closing

I really like where Microsoft is heading with this new B2B Collaboration service for Azure Active Directory. Having witnessed complex solutions built by organisations to handle sharing with partners, this will definitely make this scenario a whole lot easier for organisation.

Of course there are still limitations with the service (to be expected from a service at it's early stage and in Public Preview):

• No support for inviting via API or Powershell - this will be quite important if this will be leveraged by larger organisations 
• No support for partners with no custom domain - implementing this story will complete the b2b story as organisations may also need to share with organisations who are considered very small
• Managing password resets of self service signup users - this is perhaps one story or use case within this service that isn't as easy or seamless for the end user. Improved features to help them reset their password via software features or messaging will improve the user experience.

Have you experimented or used the B2B service? Please share some of your observations and lessons learnt in the comments below.