AADConnect can block Azure AD B2B invitation

One of the approaches to work with externals of a business partner organization is to administrate full accounts for them in your on-prem Active Directory. With the arrival of Azure AD B2B capability, it is no longer required to have full accounts including password management for the externals; they can now be invited as 'guest' via the concept of "bring your own identity". However, for organizations that have a legacy of earlier external collaboration approach (note: does not necessarily have to be SharePoint based; it can also be for instance via SAP Portal, on-premisse webapplications, ....), an account provisioning conflict may arise.

Situation sketch:

• Externals of business partner are added as full accounts to your on-prem Active Directory
• Administrate in AD their own external company email as primary email address; as that is the mailbox they will typically use and monitor
• Utilize AADConnect to sync on-prem AD accounts to Office 365 / Azure AD
• Invite externals of same business partner as guest for Azure AD B2B; with their own external company email as identifier...

The result of this situation is error: BadRequest; The object is either sourced from an on prem directory or is undergoing migration

In general, Microsoft states that "duplicate identifying attributes are not allowed in a tenant with AAD Connect" (see Troubleshooting Errors during synchronization). The primary email-address is one of these: "For the proxyAddresses attribute only the value with SMTP:, that is the primary email address, is used for the evaluation". (source)

Approach to a more trusted Azure AD B2B invite handling

Simple approach to invite guest users is via the Azure AD admin portal. Disadvantage is that you have no control at all over the invite email that is being sent:

• It comes from the invites@microsoft.com mail origin instead of the inviting company
• It is sent on behalf of the account of Azure AD Admin (or other admin account that possesses the 'Guest inviter role'), iso an account of the actual business user at the inviting company
• The mail is in a standard format, without branded to the inviting company
• The mail includes a suspicious looking "Get Started" button
• The mail includes a "Click here to unsubscribe" link, which again looks suspicious as the receiver never subscribed to invites from Microsoft.com.

This results that - and in my opinion, in current days very understandable and justified - invited persons may not trust the invite email, suspect it is a phishing mail.

My first approach to improve on this is to invite the guest users via 'New-AzureADMSInvitation' PowerShell cmdlet, and make up the email text itself. However, you still have very little control over the mail setup: the only thing you can do it to specify the invite message. And this is limited to plain text, you cannot make a rich format including company logo. All of the above drawbacks still hold.

On questioning to Microsoft, their advice for now is to use the Azure AD B2B Invite API to make a company-customized invite experience. But this requires an Azure App to be designed, developed + deployed. Although sure would be fun to do, current I lack the time for that.

Therefore I decide for an approach in the middle. Still use the PowerShell cmdlet to create the guest accounts. But instead of direct sending the invite email, I let the PowerShell script make up a 'mailto:' specification that includes the guest user redeem-url. These specifications are exported per invited user via a .csv file. Next the Azure AD admin sends the .csv file to the responsible business user of the inviting company. And he or she can then direct from the received .csv file with the 'mailto:'specifications make up an invite mail in their own email outbox, make some final changes and additions (e.g. add personal mail signature; including items like company logo, contact details of the business user, ...); and next send out the mail. The invited guest then receives the mail from the mail domain of the inviting company, and of a person (s)he likely already is in contact with. As extra bonus I apply Office 365 email encryption, to give the invited user the trust that only he or she is able to read the invite mail.