Skip to main content

Description 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:


  1. Configure SSO between M365 and Box using Azure Entra.

  2. Enable automatic user provisioning from M365 to Box.

  3. Provision a new user in M365 and add them to the Box group for automatic provisioning.

  4. Attempt to log in via SSO with the newly provisioned user.

  5. 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

360497915707 ,


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.


 


 


 


 

Reply


Terms & ConditionsCookie settings