Issues with Provisioning New Users via M365 to Box – Email Confirmation Not Received
CompletedDescription of the Issue:
I’ve recently set up Single Sign-On (SSO) between Box and Microsoft 365 (M365) using Azure Entra (formerly Azure AD). While existing users who already have a Box password can successfully log in via SSO, I’m encountering issues when provisioning new users from M365 to Box.
Specifically, for newly provisioned users who have never created a password on the Box side, the system requests an email confirmation upon login. However, no confirmation email is received by the user’s M365 email account. I have checked message tracing in M365 and confirmed that the email was never sent from Box.
Steps to Reproduce:
- Configure SSO between M365 and Box using Azure Entra.
- Enable automatic user provisioning from M365 to Box.
- Provision a new user in M365 and add them to the Box group for automatic provisioning.
- Attempt to log in via SSO with the newly provisioned user.
- Box requests a confirmation code to be sent via email, but no email is received in the M365 mailbox (confirmed via message tracing).
Testing Details:
- Existing users who have previously created a password on Box do not face any issues when logging in via SSO.
- The issue is specific to newly provisioned users from M365 who have never set up a password on the Box side.
- No trace of the confirmation email can be found in the M365 message trace logs, indicating it was not sent from Box.
What Has Been Tried:
- Checked M365 message tracing and spam/junk folders: No confirmation email is received.
- Verified that the issue is only affecting new users who have not set a Box password.
- Found a similar issue reported in the Box community with no posted resolution.
- Test mode is off until this is resolved.
Thank you for your assistance.
Best regards,
Matthew Elliott
-
Rona ,
Is there any update on this issue? We are seeing the same problem.
Actually, if the email request is made twice, then a password message is sent to the mail address (once).
But, it makes no sense to require a box-specific password when SSO is required. We experienced the above issue in the SSO testing phase, but, wrongly assumed it would be fixed when SSO was required.
Please sign in to leave a comment.
Comments
2 comments