Office 365 deployment checklists

This topic provides checklists to help you make sure that you install and configure your Office 365 deployment correctly and with a minimum of issues.

With CyberArk Identity, administrators can deploy Office 365 so that installation of ADFS in not required. CyberArk handles the authentication and communication with Active Directory automatically. You can provide single sign-on (SSO) to users in Active Directory, LDAP, the CyberArk Cloud Directory, or any combination of those sources. After configuring Office 365 with CyberArk, users can access Office 365 from the user portal either from a web browser or a mobile device. Users can also use Outlook and Teams using their Office 365 credentials.

Deploy Office 365 with CyberArk Identity

We recommend performing the following steps in the order listed, and that at each deployment stage you test and verify that data is handled correctly before you move on to the next deployment stage. It is important to verify each section has been completed before attempting to federate any Office 365 tenant and provision user accounts.

Failure to perform and validate each of the below configuration tasks and object attribute cleanup steps may cause a significant negative effect on the deployment process.

Step 1: Prepare the Office 365 tenant

The Office 365 work or school account that you use for these procedures needs to be a member of the Office 365 Global admin role. This a requirement for Office 365 federation and may not be necessarily for all other Office 365 services. For more information about permissions in Office 365, see Permissions in Office 365.

Administrators must complete the Office 365 setup process to ensure the registered domain(s) display a status of "Setup Complete" in the Office 365 admin portal. CyberArk recommends the following best practices:

  • Use and register a test Office 365 domain for any POC or evaluation work before federating a production domain.
  • Create Office 365 administrator accounts using a unique name and domain suffix that does not match any Active Directory user accounts if the domain is to be federated.

    You need this administrator account to be outside of Active Directory in case you need to revert your Office 365 account back to user password authentication or if you need to make any configuration changes, such as changing your certificate or Issuer name. If you are already using ADFS with Office 365 at your organization, many of the below steps may have been previously completed such as enabling directory synchronization.

Use of Office 365 administrator accounts that match on-premise Active Directory users is not supported using CyberArk.

Steps to prepare your O365 tenant
Environment Prepare the Office 365 tenant Instruction

Office 365

Tenant Setup

Create an Office 365 administrator account that does not match any Active Directory-based account name. (example: admin@<company>.onmicrosoft.com)

Requirements and installation information

Ensure the Office 365 account license tier supports federation and directory synchronization.

Supported Office 365 account types

Ensure all Office 365 domain(s) are verified and display a status of "Setup Complete" in the Office 365 admin portal.

Prepare Office 365 for single sign-on

Set the default domain in the Office 365 admin portal to be <company>.onmicrosoft.com>.

Prepare Office 365 for single sign-on

Enable directory synchronization for provisioning.

Prepare Office 365 for single sign-on

Step 2: (Optional) Prepare Active Directory for Single Sign-On

This step is only required if Active Directory is your directory source.

We recommend planning your Office 365 communication to end users and ensuring that Active Directory is prepared for Single Sign-On before attempting to deploy or federate any Office 365 domain.

Be sure to prepare and validate user and group object attributes for:

  • displayName

  • mail

  • proxyAddresses

  • sAMAccountName

  • userPrincipalName (UPN)

Office 365 requires use of the UPN for user login.

All of these attributes should be unique across all domains you plan to use with Office 365.

Administrators should also ensure that all updates and service packs are applied to desktop applications such as Microsoft Office before Office 365 deployment. For Microsoft applications downloaded directly from the Office 365 tenant, these updates are downloaded automatically from Microsoft. DNS Autodiscover records will also need to be created for desktop applications such as Outlook to connect with Office 365.

Tasks to set up AD for SSO

Task

Instructions

Match the on-premises UPN attribute domain suffix with the Office domain to be federated.

More information from Microsoft

Match the on-premises UPN attribute with the proxyaddresses attribute for best user experience.

More information from Microsoft

Verify user and group object attributes for displayName, mail, proxyAddresses, sAMAccountName and userPrincipalName are unique across all domains in use with Office 365.

More information from Microsoft

Review best practices for synchronizing (migrating) users and mailboxes if planning to move mailboxes from Microsoft Exchange or other sources.

Best practices for synchronizing (migrating) users and mailboxes

Configure web browsers for silent authentication using IWA.

Configure browsers for silent authentication

Ensure all Office desktop applications have the latest Windows updates and service packs.

More information from Microsoft

Plan your end-user communications around production changes and how to get help.

More information from Microsoft

Step 3: Prepare the CyberArk tenant

Administrators that leverage CyberArk to provide Office 365 authentication and provisioning features must first register for a tenant and perform some initial configuration steps within the Identity Administration portal and install a connector within Active Directory.

After linking your source directory with CyberArk, it’s time to think about adding some roles to allow user access. By default, all users will have access to the User Portal but no applications will be visible unless the user belongs to at least one application role.

The Identity Administration portal roles are sets of user accounts and are similar in context to Active Directory groups. You use roles to assign applications, permissions, and policies to sets of users. Users can be members of multiple roles. CyberArk recommends creating role names that are easy to identify and include the application name and license type. As example, users that access Office 365 using an E3 license could belong to a role named “Office 365 Users – E3 License”.

You should configure one or more connectors within Active Directory to provide continuous up time for identity platform services. Install additional connectors for load balancing and failover. If the connector service is stopped or the host on which the connector is installed has a network failure and is unable to communicate with CyberArk Identity, user login will be impacted.

Tasks to prepare your tenant

Task

Instructions

Register for a CyberArk tenant and login to the Identity Administration portal.

Register

(Optional, if AD is your directory source) Download and install the connector on a Windows server 2016 and later.

Install the CyberArk Identity Connector

Create login suffix entries for all Active Directory and Office 365 domains in portal Settings.

Manage login suffixes

Enter a Corporate IP range in portal Settings.

Define Secure Zones

Create CyberArk Roles for Office 365 users by license type.

Create roles

Verify successful login to the User Portal using IWA.

Configure browsers for silent authentication

Step 4: Configure - Federation with Active Directory

CyberArk recommends performing federation changes during off-peak production hours whenever possible to avoid any interruptions to end users. It is critical to ensure user login to the CyberArk portal using IWA over HTTPS is working and that user communication has been completed prior to changing federation settings.

Before federating your Office 365 domain with CyberArk and changing its status from "Managed" to "Federated", make sure you have a clear understanding of how the federation change will appear to new users or users currently accessing Office 365 using OWA or Outlook.

Users attempting to log in directly to the Office 365 web portal will be redirected to the User Portal for authentication. If IWA using HTTPS is working correctly (or the user logs in manually), users will be authenticated and directed back to the Office 365 OWA interface. This is expected behavior and why validating successful login to the User Portal using IWA is extremely important to ensure a seamless user experience.

Outlook users may experience password prompts if DNS Autodiscover records for Office 365 have not been created in Active Directory or if the Windows Credential store on the local client falls out of sync with Active Directory. Ensuring Autodiscover records have been added prior to federation and clearing any saved credentials (as needed) for Outlook that may be out of sync with Active Directory will help minimize these issues.

If you decide to disable domain federation between Office 365 and CyberArk, there can be a delay from 1-4 hours within the Office 365 service before the domain status changes from “Federated” back to “Managed” status and is expected behavior per Microsoft.
Environment Configure CyberArk for Office 365 - Federation with Active Directory Instructions
the Identity Administration portal

App Setup - Federation

Add the Office 365 WS-Fed+Provisioning template from the CyberArk app catalog. Configure Office 365 for single sign-on
Enter and verify the Office 365 global administrator credentials. Configure Office 365 for single sign-on
Select the domain that you want to federate with CyberArk or take ownership of a domain that is already federated.
Configure User access by selecting Roles created for Office 365.
Configure authentication policy (optional).

Step 5: Configure for - User Provisioning

Administrators can use CyberArk to provision and license users, contacts and group objects without the need to install anything extra, such as the Microsoft Azure Directory Synchronization tool. In addition, CyberArk for Office 365 + Provisioning can synchronize and provision users from Active Directory, LDAP, and the CyberArk Cloud Directory. CyberArk provisioning does not replicate any AD password information into the cloud. AD-authentications that go through CyberArk are always performed within the domain environment via the CyberArk Identity Connector.

By default, CyberArk will provision the userPrincipalName attribute for the Office 365 username. Microsoft recommends matching the UPN and proxyAddresses primary SMTP attribute to provide the best SSO user experience and prevent user confusion. CyberArk can be customized for environments where these attributes cannot be modified but these options should be used only by advanced users when best practices cannot be followed.

If you are using Microsoft Exchange in a hybrid configuration to provide on premise mailboxes and plan to migrate user data to Office 365, it is important to complete user mailbox migration before attempting to license the user object in Office 365 using CyberArk provisioning. Office 365 will not assign a license or a default SMTP address for any user object where an Exchange mailbox is still present, and migration has not completed. This Microsoft restriction helps prevent split-mailbox scenarios and is expected behavior.

The Hybrid Exchange Support option within the CyberArk provisioning settings is required for full extended user attribute sync and to provision non-user objects. CyberArk recommends enabling Hybrid support even if the Exchange server is not in use. Failure to enable this option may prevent specific user attributes (such as proxyAddresses) from provisioning with Office 365.

Please contact CyberArk Support if you are planning to provision users using a custom Source Anchor that does not use the local Active Directory user object Immutable ID.
Environment Configuring CyberArk for Office 365 - User provisioning Instructions
the Identity Administration portal

App Setup - Provisioning

Enable the provisioning option (Preview Mode is selected by default). Office 365 provisioning
Enable the "Hybrid Exchange Support" option (recommended even if not using Exchange in hybrid mode).
Determine if existing Office 365 accounts should be overwritten (merged) or retained.
Determine if existing Office 365 accounts should be overwritten (merged) or retained.
Assign Role and license mappings for Office 365.
Perform a full preview synchronization or test manual sync for specific user accounts and review the sync report for accuracy.
Configure deprovisioning rules based on current employee offboarding procedures. Deprovision users and other objects
Modify the advanced provisioning script if needed to link AD objects (Optional). Modify the provisioning script to link AD objects
Exclude AD objects from synchronizing if needed Exclude AD objects from synchronizing
Change provisioning mode from "Preview" to "Live Mode" when ready to enable production sync. Provision and license users to Office 365

Step 6: Verify setup and user communication

After completing the above setup and validation steps, the Office 365 domain should now be in a "Federated" status and user objects should be synchronized with the desired source directory. Users should be able to access Office 365 directly using the Microsoft Online portal, User Portal, desktop application, or mobile device.

Verify the following actions can be performed and communicate the planned changes to your users. Be sure to include user instructions for how to request assistance from your helpdesk.

Mobile device users will receive a login screen when launching the native, mobile Office 365 applications and is expected behavior.

O365 verification tasks

Environment

Verify Setup and user communication

Notes

Office 365 validation

Verify users and administrators can login to the Office 365 application and can access each tab in Office 365 from both inside and outside of the corporate LAN.

  • If a particular use cannot log in, verify that the login suffixes are configured correctly.
  • At each deployment step, you need to make sure that users can still log in successfully.

    Even if you verified this before, it’s important to verify it again.

  • To view your federation settings from the Office 365 Application Settings tab, select your federated domain and click Actions > View Federation Settings.

All users can log in with SP-initiated authentication directly to the Microsoft online portal and are redirected to CyberArkfor IWA login.

Active Directory Validation

Users on both PC and Mac computers can use Outlook and other Microsoft desktop applications without issue.

 

End-user communications have been sent.

More information from Microsoft

CyberArk for Office 365 desktop applications

Outlook works (Windows desktop)

If you have a hybrid Office 365 deployment, point the on-premise users to the on-premise Exchange server.

Online services such as Office online, CRM online and SharePoint work as expected.

 

 

 

Android and iOS clients work in the following scenarios

Mobile browser with OWA

User logs in to the user portal in a mobile browser and launches the web-based version of Office 365 (OWA) in the mobile browser.

CyberArk mobile application with OWA

User logs in to the native, mobile CyberArk application and then launches the web-based version of Office 365 in the mobile browser.

CyberArk mobile application with Office 365 mobile applications

  • User logs in to the native, mobile CyberArk application and then launches a native, mobile Office 365 application.

  • When your Office 365 account is federated, the user gets a sign in screen when launching the native, mobile Office3 365 application. There are different applications for different devices.

Mobile mail:

User adds their work account to their mobile device for email or email and calendar and contacts.

 

Additional tasks

This section covers optional tasks that might be appropriate for your Office 365 deployment.

Add a bookmark application that opens SharePoint Online directly

If you want your users to have an application in their user portal that they can click to go directly to SharePoint, you can add a generic bookmark application to provide that access without requiring users to sign-in again.

The following procedure uses the Firefox web browser; you can use similar tools in Chrome or other browsers.
  1. Install an HTTP header trace add-on in Firefox, such as Live HTTP Headers or SAML tracer.
  2. Open the HTTP header trace Firefox add-on.
  3. Make sure that you’re not currently logged in to either Office 365 or your SharePoint site.

    You’ll need to capture some of the SAML token info that gets passed during login.

  4. Go to your custom SharePoint domain, which has the format of mydomain.sharepoint.com.

    You’ll be redirected to the user portal.

  5. Log in to the user portal.

    Then you’ll be redirected back to your SharePoint domain.

  6. In the HTTP header trace Firefox add-on, look for the GET command that has an URL that starts with “https://cloud.Idaptive.com/run?appkey=Office+365&customerid=”

    If there are multiple URLs that look similar, pick one that has the cbcxt and also the wctx in it.

    For example:

    https://cloud.Idaptive.com/my?appkey=Office+365&customerid=AB123&cbcxt=&popupui=&vv=&username=
    adele.smith%40Idaptive.com&mkt=&lc=1033&wfresh=&wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=wa%3dwsignin1%252E0%26rpsnv%3d3%26ct%3d1393546930%26rver%3d6%252E1%252E6206%252E0%26wp%3dMBI%26wreply%3dhttps%253A%252F%252FIdaptive%252Esharepoint%252Ecom%252F%255Fforms%252Fdefault%252Easpx%26lc%3d1033%26id%3d500046%26%26bk%3d1393546930%26LoginOptions%3d3
  7. Copy the entire URL and paste it into a plain text editor.
  8. In the text editor, remove everything in the URL from the “cbcxt=” up to “wfresh=&” just before “wa=wsignin1.0”.

    Using the example above you'll end up with

    https://cloud.Idaptive.com/run?appkey=Office+365&customerid=AB123&wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1%252E0%26rpsnv%3D2%26ct%3D1391061064%26rver%3D6%252E1%252E6206%252E0%26wp%3DMBI%26wreply%3Dhttps%253A%252F%252FIdaptive%252Esharepoint%252Ecom%252F%255Fforms%252Fdefault%252Easpx%26lc%3D1033%26id%3D500046%26%26bk%3D1391061066%26LoginOptions%3D3
  9. In the Identity Administration portal, add a Generic Bookmark application with the above URL, and deploy the application to all users.

    Remember to give the application a custom name so that you know that it links to SharePoint.
  10. In the user portal, click the newly created application to open SharePoint in a new window.

Remove and update the password that Outlook

When users change Active Directory passwords, connection issues in Microsoft Outlook are possible on Windows systems. This can happen if the user had the desktop applications save the login credentials; the stale credentials remain stored with the previous password.

  1. In Windows, go to Windows > Control Panel, then and click Credential Manager.
  2. If you see any credentials for Outlook, open the credential to expand its information, and click Remove from Vault.
  3. Restart the computer.

    Upon restart, the user logs in to the computer with her current and correct password. Microsoft desktop applications renew their use of the user’s credentials to the correct and current password.

Troubleshooting

To diagnose any issues with your Office 365 deployment that is related to authentication, configuration, policy restrictions or provisioning, see Office 365 troubleshooting workflow.

After completing the above setup and validation steps, the Office 365 domain should now be in a "Federated" status and user objects should be synchronized with the desired source directory. Users should be able to access Office 365 directly using the Microsoft Online portal, User Portal, desktop application, or mobile device.