Monthly Archives: March 2018

Office Flash Friday Topic Show – M365/O365/Windows 10 and Shared Use Workstations in Health Care

Wow – what a long title!

Though it is truly what this special edition OFF show is about.  The Microsoft Technology Center (MTC) in Minneapolis did some recent PoCs with customers in health care who had a few common challenges with share workstations.  We were asked to more broadly share this content, which is why we recorded this show and the post below.

We are attempting to address the following core challenges we identified with customers when implementing Microsoft Modern Workplace solutions:

  • Many health care orgs use a “shared workstation” model and manage login/logout to apps within that tool using smartcard/tap solution
  • These locations use only a single Windows Profile – users don’t use the traditional Windows login UI
  • On these stations, Office may be deployed, but not all users have licenses  for the Office Apps; some may have web-only Office access
  • Identifying and “pre-moving” content from mapped drives or local locations is necessary to ensure a good user experience for web-only Office user

So, that’s the goal.  Now, here is overview video and the companion technical content (below the video).  While this isn’t comprehensive to all scenarios, we did find 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, Chief Architect, Microsoft Technology Center, Minneapolis

SOLUTION OVERVIEW:  COMMON HEALTH CARE “SHARED ID WORK STATION” SCENARIOS FOR WINDOWS AND OFFICE 365

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 and related technologies.

During testing we found there were several areas where issues were experienced that impacted usability and/or deployment of Office 365 (O365), Office Pro Plus, and 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 with browser-only access to services encountering issues opening local documents on PCs that also have Office Pro Plus deployed
  • IT/Support visibility into commonly accessed content from network shares/other areas and content access issues

The goal is to review customer feedback/issues in each of these areas, and then document potential approaches developed during Proof of Concept (PoC) work.

 

Clinical Shared Use Workstation Scenario Review

Many clinics hospitals have the concept of a Shared ID Workstation (SIDW) 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 SIDW 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 SIDW 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 SIDW vary, but the technical goal is secure sign in and clean sign out, regardless of the event source or tool used to manage Single Sign-On (SSO).

 

Improving SIDW Scenario User Experience with Clinical SSO Tools

Clinical SSO tools such as (Imprivata or the former Caradigm offering, now part of Impravata as of October 2017) are often in use in these environments to provide basic authentication and SSO within the local SIDW 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 a clinical SSO provider for O365 sign-in/out management; we did not develop a reference architecture pattern for access without a supported SSO provider 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 ‘stuffed’ 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 logins in to the SSO tool.  All the major providers can run scripts at both login and logout, and therefore we focused on leveraging common script-based capabilities and/or standard Windows cmd-line tools in our solution development to ensure supportability and flexibility.

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 the SSO provider.

  • Note: Could also be Username/Pass login; SmartCard used in our testing

o   User A opens shortcut to Office365 portal

o   User A is automatically logged into their Office365 Portal via the SSO provider

  • Note: Done via form/credential fill

o   User A opens their Web Outlook inbox via the tile in the O365 app launcher

o   User A launches Word 2016 client from the local PC

o   User A badges out of Workstation, but does not close their internet browser or Word with their email window open

  • User B

o   User B badges into ICU Workstation 1

  • User A’s open browser and Word/Office apps should be closed automatically
  • User A is should be signed out from all O365 client app and browser services

o   User B opens shortcut to Office365 portal

o   User B is automatically logged into their Office365 Portal via the SSO provider

o   User B opens their Web Outlook inbox via the tile in the O365 app launcher

o   User B opens the Outlook inbox via the Outlook365 Portal

The above flow is a good representation because it shows both bro

Reference Approach – Integrating Office 365 Services with Clinical SSO

By combining this SSO tool and IDP-initiated sign-on techniques with browser settings and management of the Windows Credential vault items, we were able to achieve a good user experience for browser-based and Office Pro Plus client-based access to O365 services.  Basically, the users at these stations use IE11/Edge and SSO Provider to login to apps and Office services.  Credentials are cleared at “sign out” for the user session while the desktop remains  signed in as the Share ID.

Sign In

The login scenario for browser sessions was easily handled by default SSO Provider tools.

Sign-on to the Office 2016 local applications like Word and Excel was successfully automated via SSO Provider form-fill, however as of writing this the end user must click the Login button in the local app to get signed in – there is no current way to auto-sign-in to the local Office Pro Plus Client applications as the user.  In user testing, this was only a minor training issue and did not have any significant impact on time to access data or apps.

 

Sign Out

Proper logout requires both browser settings and triggering of actions on the local workstations.  These are outlined here:

Windows Credential Vault Purge

  • Auth to local apps is stored in the Credential Vault. We tested the approach of clearing “MicrosoftO”  matched creds from the vault; this should be tested for validity in a local environ, but it seems to cover all MS Office applications that are currently available
  • We used the following command, triggered by SSO tool logout script:

           cmdkey /list | ForEach-Object{if($_ -like “*Target: LegacyGeneric:target=MicrosoftO*”){cmdkey /del:($_ -replace ” “,”” -replace “Target:”,””)}}

Browser Cache Settings

  • It is important to have the browser cookies removed on close to ensure no O365 browser session authentication remains. This can be done via policy or other supported purge method.
  • You may also force “inPrivate” or equivalent browser setting, which usually auto-purge the proper assets on exit
  • ADFS/SAML hosts which normally provide SSO for locally logged-on WIndows profiles  must not be trusted by the hosts for SIDW machines.  If they are, they will attempt to pass the ID of the local WS SIDW account; this is what we showed in the video so you can understand the possible impact.

Share Use Login with “Blended Licensing”

Many large org have licenses Office 365 E3 with Office Pro Plus for some users, E1 or E3 without Office Clients for others.  If the local Office client is installed on workstation shared by these user communities, the experience can be confusing since ‘unlicensed Office’ users may try and open a file on the PC and trigger a launch.

We successfully tested Windows Login Script automation of the desktop environ to solve this problem by managing the file associations at time of login.  We developed a small EXE to check status (managed via scripting in the SSO tool) and then either prompt the user or pass the open to the proper Office app .  Users were in AD groups that indicated their Office entitlement, and set to NOT launch the native Office apps if they were not associated to a full Office license.  The ftype and assoc commands were used to achieve this,  along with companion application association management which is shown in the video.  Details on these commands are here:

Associations in our case were set to a the sample middleware-style “shim” EXE we developed; other options (such as viewer association) could be explored if needed.

Terminal Services and SIDW Considerations

We were often asked about Terminal Services impact if we are using RDP-style remote presentation of apps.  We determined quickly during testing that it really didn’t change the architecture at all.  If your users are first authenticating via the Clinical SSO tool, and then getting a user-based (NOT shared) remote session/app/desktop/profile, then the remote session already has the full user context and there won’t be any “leak” potential – assuming of course that the SSO tool properly logs out/closes that session.  Basically, we only needed to work about locally cached content on the workstation; any other sessions we’d need to either get SSO from the provider and then inherit the users security context from the virtual Windows app/desktop, or apply the same techniques above if the scenario was truly unique.

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.

 

No Office Flash Friday on March 23rd

It is busy season in the Microsoft Technology Center and both Doug and I are working with our amazing customers today. We hope to get back to regularly scheduled shows soon! Hit us up on Twitter if you need anything!