What a long title – again!

In early 2018, the Microsoft Technology Center (MTC) in Minneapolis completed several rapid prototype sprints with customers in health care who had a few common challenges around shared workstations and easy user access to Office 365.  In March of 2019 we revisited the topic, this time involving key industry software partner Imprivata.  This post is an update to the original test (http://www.officeflashfriday.com/2018/03/office-flash-friday-topic-show-m365o365windows-10-and-shared-use-workstations-in-health-care/) and includes both an OFF demo show episode as well as the technical overview below.

As a recap, we are attempting to address the following core challenges identified with customers when implementing Microsoft Modern Workplace solutions:

• Many health care orgs use a “Modern Shared Clinical Workstation” model and manage login/logout to apps within that tool using smartcard/tap solutions
• These locations use only a single Windows Profile – users don’t use the traditional Windows login UI
• On these stations users may have web-only Office access but want to use the “full” Teams client for collaboration
• Users need a fast and secure login experience that ensures no “cross-over” access between sessions on the shared workstation

So, that’s the goal, and hopefully you all find this content useful.  Our sincere thanks go out to the Imprivata team, and in particular Steve Furtsenau, for their support and participation.  You guys were great to work with, and we appreciate the dedication you showed helping our mutual customers.  Ditto to Randall Irwin, Technical Specialist from Microsoft, who went above and beyond herding all the cats.

Now, here is the overview video and the companion technical content (below the video).  While this isn’t comprehensive to all scenarios, we found this approach to be a good starting point for organizations facing this challenge.  This isn’t meant to be authoritative, but rather to provide guidance and information that might help our customers.

As always, feedback most welcome 🙂

– Doug Splinter, Director – Microsoft Technology Center, Minneapolis

Click on the image above to watch the overview

TECHNICAL SOLUTION OVERVIEW:  “SHARED ID WORK STATION” SCENARIOS FOR WINDOWS 10 AND OFFICE 365 WITH IMPRIVATA

The following document outlines research done around improving both user and IT management experiences for Windows-based access to Office 365 services in mixed client access/license scenarios commonly found in health care provider organizations.

The target audience is IT departments, Microsoft Partners, and technical teams tasked with enabling Office 365 services in these environments.  The content assumes customers are familiar with Microsoft Office 365 capabilities and have knowledge of Windows PC management, Imprivata OneSign, and related technologies.

During testing we found there were several areas where issues were experienced that impacted usability and/or access to Microsoft Teams and Microsoft Office Web Applications in common health care provider shared workstation environments.  These areas were as follows:

• Poor user experience when signing in/out of Office 365 services in common health care provider shared workstation scenarios; users entering credentials mutliple times
• Users with both selective app access (Microsoft Teams) and/or browser-only access to services encountered issues getting quickly signed in via methods such as proximity cards

The goal is to review customer feedback/issues in each of these areas, and then document approaches developed during rapid prototype test work.

Clinical Shared Use Workstation Scenario Review

Many clinics hospitals have the concept of a Modern Shared Clinical Workstation (MSCW) in use to support locations where users simply ‘walk up’ to machines that are already unlocked or authenticated at the Windows OS level.  These PCs are usually constantly signed with local Active Directory Domain Services (ADDS) accounts that represent the location (ex: CareStationMSPB1-1222) of the machine as opposed to the user(s) currently using it.

This means that users who access/use the SIDW machines DO NOT login at the Windows OS level Graphical Identification and Authentication (GINA) login prompt, but rather use apps and browser-based services on the always signed-in desktop session.  At the Windows level, this results in a Windows profile that is essentially shared across all users of the MSCW PC.

Even though the local Windows profile remains constant, users still need to authenticate and do both sign-in and sign-out of apps/services within the MSCW session; it is extremely important that this transaction happens successfully and predictably without impacting user productivity.  One example of an issue customers encountered surrounded properly removing credentials to prevent “carryover” from one Office 365 user session to the next.  For example, a user might sign in, check their email, and then close their web browser.  The next user might open the service and then see the previous users email instead of their inbox; a concern both at the security and privacy level.

Authentication-management techniques for the app-level “sessions” within these MSCW are commonly supported via clinical SSO tools from Imprivata, who was our test partner for the scenario.  The technical goal is simple: secure sign in and clean sign out while preserving the common session.

Improving SIDW Scenario User Experience with Clinical SSO Tools

Clinical SSO tools such as Imprivata  are in use in most environments to provide basic authentication and SSO within the local MSCW profile.  These tools have custom in-session login windows that users sign in/out from, and they therefore can track and audit the status of local users.  They also commonly support authentication via proximity cards and/or certificates for faster or more secure login.

It is important to note that ALL of our test scenarios leveraged Imprivata as a clinical SSO provider for O365 sign-in/out management; we did not develop a reference architecture pattern for access without Imprivata OneSign in use and deployed.

At a technical level these tools operate under the single/shared profile context, and then provide their SSO and related capabilities to apps, either via direct API integration or via ‘pushed’ credentials into application-level login windows of forms.  The end goal is to give the users easy access to needed apps and services similar to what they would have in a unique Windows profile environ, but without the need to shut down other running apps/services that a Windows login would require.

One of the critical capabilities these tools offer to support our scenario is the ability to run scripts or perform actions on certain events, such as when a user uses “log in” to the SSO tool.  We focused on leveraging the built-in capabilities of OneSign and AAD/O365 in our solution development to ensure supportability and flexibility – config not code was our goal.

Reference User Experience Outline

The end goal is a good user experience that gets people signed in according to policy, and properly signed out when done.

Here is the targeted user process flow that was tested:

User A

o   User A “badges in” to ICU Workstation 1 using a SmartCard to authenticate to Imprivata OneSign.

• User A opens Imprivata-provided shortcut to Office365 portal and gets a seamless SSO experience for their account
• Microsoft Teams is auto-launched w/seamless SSO for user A
• Other Imprivata OneSign driven events are processed

User B

o   User B badges into ICU Workstation 1 (we are assuming User A just walks away)

• User A’s open browser and apps should be closed automatically
• User A is fully signed out from client app and browser services in the common MSCW session

• User B opens Imprivata-provided shortcut to Office365 portal and gets a seamless SSO experience for their account
• Microsoft Teams is auto-launched w/seamless SSO for user A

• Other Imprivata OneSign driven events are processed

Technical Recipe Card and Configuration Info

To achieve the above, the below environment config was used.  Please note that this is a general listing.  Additonal information is available on both companies technical support and documentation sites for configuration of the base environments of Office 365 and Improvata  – this is just an overview that should give admins with experience an understanding of our specific deplyment configuration that resulted in the provided demonstration.

• Microsoft
  • Office 365
    • Office 365 tenant setup and configured for basic services
      • Microsoft Teams enabled and configured
      • Additonal O365 services configured as needed (OneDrive for Business, Stream, etc.)
    • Users licensed for Office F1 + EMS capabilities
    • Current version of Azure AD Connect deployed
      • Configured to support Seamless SSO via Password Hash Sync (PHS)
      • Device configuration set to suppor
    • Workstation
      • Windows 10 build 1809 – all current patches applied
      • Joined to Active Directory Domain Services (ADDS)
      • Windows PC ybrid Azure Active Directory (AAD)
      • Internet Explorer (as present in 1809 Windows 10 build) used as browser
      • Microsoft Teams client deployed as standalone (not via join Office Pro Plus)
• Imprivata
  • Imprivata RFID Reader model HDW-IMP-75
    • Note on hardware – we a tested a few other models as well; Win 10 driver + Imprivata version + RFID card compatability are the key elements to consider
    • RFID cards assigned to users in Imprivata
  • Imprivata OneSign version 6.2
    • OneSign environment configured to integrate and sync with with ADDS
    • Configured to use “run as” impersonation technique for launching services
    • Imprivata ISXRunAs samples follow
      • Teams:  “C:\Program Files (x86)\Imprivata\OneSign Agent\ISXRunAs.exe” /profile “__INSERT COMMON SESSION PROFILE PATH OR VAR__\AppData\Local\Microsoft\Teams\update.exe” –processStart “teams.exe”
      • O365 Web Services: “C:\Program Files (x86)\Imprivata\OneSign Agent\ISXRunAs.exe” “C:\Program Files (x86)\Internet Explorer\iexplore.exe” “https://outlook.office.com”

Configuration Notes

• Local profiles are generated for each user on the machine even though they don’t interactively login – this is expected due to the Imprivata RunAs launch technique
  • Note: To avoid user “first run” settings in browsers, default initial profile setting should bet set – approaches here are mature in most IT organizations, so we did not specifically test or document these settings.
• We did not test full Office Pro Plus clients – that is planned for the future
• We did some basic successful testing of Chrome as a browser option, and did achieve seamless SSO with the Windows 10 Account extension deployed. We did not test admin-level deployment and management of the extension.
• While we see no reason it would fail, we did not test ADFS or other SAML IdPs in our deployment.

Conclusion

That’s it for our PoC results/solution overview.  We hope you find the content useful in helping you integrate Office 365 services in your environment.