Microsoft Azure SCIM Provisioning

You can further enhance your OfficeRnD Hybrid Azure SSO with SCIM user provisioning. The Azure AD Provisioning Service provisions users to SaaS apps and other systems by connecting to a System for Cross-Domain Identity Management (SCIM) 2.0 user management API endpoint provided by the application vendor. This SCIM endpoint allows Azure AD to programmatically create and update users. In this article, you'll learn how to take advantage of this functionality when enabling SSO Authentication

Table of Contents

Important

  • We recommend managing and editing employees only in your Azure Active Directory.
  • OfficeRnD supports a Multi-team structure - one employee can be part of several teams. The first synced Azure group will be their Primary team. If they are part of other groups you decide to provision, they will be assigned to the person as Additional teams. mceclip0.png
  • If the employee record is synced from your Active directory, you cannot edit their Team in OfficeRnD. You can, however, switch their Primary and Additional team(s) here.
  • Please bear in mind that if an employee leaves the company and their profile is deleted from the Active Directory, they will not be deleted from OfficeRnD Hybrid but will be labeled as Former. If they had any bookings in the system, they will be kept as well. Any future bookings of the said employee must be canceled manually.

Enable SCIM

  1. Set up SSO with Microsoft Azure
  2. Navigate to Settings/Integrations and click Configure on your existing SSO Authentication integration.
  3. Check the Enable SCIM option

mceclip0.png

 

Azure Active Directory Set Up

  1. Open Azure Active Directory and select Enterprise applicationsmceclip1.png
  2. Click + New application then + Create your own application.mceclip2.png
  3. Choose “Integrate any other application you don't find in the gallery (Non-gallery)” and click Create.
  4. Click Provisioning on the left-hand side menu and click Get started.mceclip3.png
  5. Switch the Mode to Automatic and fill in the following fields:
    • Tenant URL - copy the value from SCIM Base URL found in your existing SSO Authentication. integration.
    • SCIMSecret - copy the value from SCIM Secret found in your existing OfficeRnD SSO Authentication integration.
  6. Test Connection - if the test is successful, there will be a green tick in the display name.
  7. Click Save.
  8. Navigate to Provisioning/Manage provisioning/Edit attribute mappings/Mappings and click Provision Azure Active Directory Users.mceclip0.png
  9. Change the one mapped to “external id” to source ObjectID.
  10. Change the one mapped to “active” to the expression Not([IsSoftDeleted]).
  11. Delete all irrelevant so that you are left only with the ones on the screenshot (More info on the attributes you can find at the bottom of this article):mceclip1.png
  12. Navigate back to Provisioning/Manage provisioning/Edit attribute mappings/Mappings and click Provision Azure Active Directory Groups
  13. Click show advanced settings and click Edit attribute list for customappsso.
  14. Go to the members row and in the column Reference Object Attribute remove the first checkbox “Group”
  15. Create a new attribute “description”, type “string” (More info on the attributes you can find at the bottom of this article). mceclip3.png
  16. Click Save.
  17. As an optional step, you can map the source description to the new description attribute.mceclip4.png
  18. Add your Active Directory Users and Groups.mceclip5.pngmceclip0.png
  19. Navigate to Provisioning and click Start Provisioning.

Which Azure Attributes Can be "customized" or Changed?

Every Azure AD is managed differently, with various fields per Group or User. Most of the attributes you are mapping for Groups and Users cannot be "customized" (changed) as they are vital for the integration. 

For those that can be changed - please make sure to only edit the source attributes. Source attributes are those on the left representing Azure fields. Target attributes are on the right, representing OfficeRnD mandatory fields.

User Mappings

  • userPrincipalName / userName - This field requires a unique email address. We do not recommend using a property different than userPrincipalName, unless you are certain that the field you'd like to use will always pass the user's email address. Difference in the email address in OfficeRnD and Azure results in an inability to log into our platform. Any changes here are at your own discretion.
  • Not({isSoftDeleted}) / active - No changes applicable here. Used to inform OfficeRnD if the user has been removed from provisioning and marks them as Former.
  • displayName / displayName - This attribute can be changed on the source side to another Azure field that you'd like to use. The value should remain as displayName on the target side. Provides information about the "name" of a user. 
  • objectId / externalId - No changes applicable here. Used to match users across both platforms to ensure no duplications are created on our end.

Group Mappings

  • displayName / displayName - This attribute can be changed on the source side to another Azure field that you'd like to use. The value should remain as displayName on the target side. Provides information about the "name" of a group. 
  • objectId / externalId - No changes applicable here. Used to match users across both platforms to ensure no duplications are created on our end.
  • members / members - No changes applicable here. Used to match users placed under the groups across both platforms to ensure no duplications are created on our end.
Was this article helpful?
2 out of 2 found this helpful

Comments

0 comments

Please sign in to leave a comment.