Windows 10 Rollout Programme

Key decision points for consideration

1. 2. Admin Rights 3. Roaming Profiles 4. Data Ownership

W10 - Key Decision 1 - Folder Redirection

We are consulting with College and Service Group Representatives on Folder Redirection for as follows:

1) Please respond by accepting the only offered solution option 1 below 2) Or by rejecting with reasons for that response.

Options: Option 1 – Folder redirection ON for desktop clients but OFF for mobile clients. This is the same as the existing SD7 “” and “MDSD ” folder redirection configuration.

This “option” is recommended by the service team.

W10 - Key Decision 2 - Admin Rights

1) Please respond by choosing one or more from the options presented below. 2) Or by rejecting all options with reasons for that response.

Option 1 – Admin rights for end users are enabled on request, are not reviewed, and are rarely revoked. This is the current solution.

Enables users to install any application they want, which means that:  The estate is vulnerable to threats posed by Potentially Unwanted Applications (PUAs). Applications which install to provide some stated function but modify the OS in unknown ways, e.g. install as search toolbar but harvest web activity.  The estate is vulnerable to threats from unmanaged applications. E.g. Applications dependant on insecure versions of , Flash or .Net.  End user’s files, data and information is unprotected. E.g. PUA’s which inspect html traffic on client and inject paid advertisements.

Enables users to change a range of setting on a device, which means that:  The state of estate is uncontrolled and unknown.  The estate cannot be efficiently managed or supported.

Ensures that UoE cannot be compliant with certain InfoSec standards, which means that:  UoE will be ineligible for some business opportunities.  UoE operates W10 with higher than desirable level of risk.

This option is not recommended by the service team.

Option 2 – Admin rights for end users are off.

Fits strictly with principle of least privilege. [See Background, Proposal and Notes below].

All applications would need to be packaged and delivered via the Software Catalogue.

Packaging all applications in use within the University would be a monumental task that would have a negative bearing on the project delivery timelines.

In the short to medium term, end users with a requirement to run a non-packaged applications must either:

1. Arrange for that application to be packaged 2. Package the application with local resources to a quality determined by ISG 3. Wait for option 3, 4 or 5 to become available.

In the medium term this option will become unworkable for a range of devices/users forcing them to become Self Supported.

This option is recommended by the service team for early adopters.

This option is not recommended for service. Option 3 – Develop a self-service, authorised, temporary enabling of admin rights for end users in accordance with Info Sec policy

Reduces the threat opportunity to a limited time window: 1 day of admin rights per year reduces the threat opportunity to 0.3% of the time for a single device.

We would need to investigate options to allow the end user to request Administrative rights for a limited period so that any additional exposure to risk is for a very minimal period.

We can envisage a service and technical solution with these features:

 A request and authorisation application; in the SCCM Software Center (similar to application approval process).  A request process where requesters confirm compliance with regulations and InfoSec policy, e.g. o confirm completion of required training: Security Essential training is mandatory for new and existing staff o an undertaking to use additional privileges in accordance with regulations and policy o acknowledging a reminder of their increased vulnerability to common threats  An approval process where requests are authorised by line managers or other responsible persons  Automated revoke of admin rights, e.g. daily at 00:01 hours

This option is recommended by the service team.

Option 3a – Admin rights for relatively few end users are permanently enabled, are managed, and maybe revoked

This a significantly more controlled and limited use version of Option 1 that is additional to Option 3.

We will need to assess the individual requirement for admin rights as part of the preparation to migrate to W10 for each area.

We can envisage a service and technical solution with those with admin rights will need to periodically confirm compliance with regulations and InfoSec policy, e.g.

 confirm completion of required training  confirm awareness of their increased vulnerability to common threats  undertake to use additional privileges in accordance with regulations and policy

This option is recommended by the service team.

Option 4 – Investigate alternative technology.

This is the preferred long-term solution. Identify, purchase and implement a commercially available product which would be fully-featured / updated and maintained by a third party.

This option is recommended by the service team.

Background

The Administrator account gives the user full control of all files, directories, services, and other resources that are under the control of the local .

The Supported Desktop has previously held the position that there should be, at most, limited granting of administrative rights. However, the final decision on granting administrative rights was left to the discretion of the local computing officer or manager of unit .

The Windows 10 is designed to be usable by a user possessing a standard user [See note 1]. It is not a requirement that users be granted administrative rights. A library of user requested software is made available via the “Application Catalog”. Installation of this software via the “Application Catalog” does not require administrative rights.

Proposal

Therefore, in conjunction with InfoSec, SDX proposes that the “Principle of least privilege” [See Note 2] is implemented, whereby users are granted a standard user token by default. Also, SDX proposes that methods and processes are brought into being which facilitate the managed granting of admin rights to end users where deemed necessary.

This proposal is based on the following:

1) Protection of end users, devices and data both directly, from own actions, and indirectly from other’s actions, e.g. an infected machine on local network. [See note 3]. Estimates vary, but conservatively, running with a non-admin account mitigates against over 90% of critical vulnerabilities. The most basic tenent of endpoint protection being 1) Patching 2) Anti-Malware 3) “Non admin” account. 2) The Principle of least privilege provides support benefits through increased consistency and automation opportunities. Administrative rights may lead to divergence of endpoint devices. For example, Microsoft Analytics has revealed the installation of competing anti-malware products with the existing Supported Desktop. Consistent data storage paths (e.g. only offline storage permitted) also offers a huge benefit particularly in the areas of data resilience (e.g. hardware failure) & OS migration. 3) SDX recognises that there are situations where Administrative rights may lessen the support burden of specific devices. For example, Administrative rights for laptop devices used in the field where access to support is not available. 4) Similarly, there may be issues with specific software requiring Administrative rights to be fully functional. For example, Veracrypt and MirrorOp.

Notes

[1] Standard User vs Admin User Windows Implementation.

As part of the logon process to a Windows computer the logging on user is granted an access token.

This token is used by the operating system to determine the Windows objects the user is permitted to access and what subsequent actions the user is permitted to carry out. For example, a Windows object can be an NTFS file and based on the user’s access token the user can read and add data to that file. Whereas a user with a differing token may read the file but is not able to make changes to its contents.

Within Windows there are two classes of tokens, “standard user tokens” and “administrative user tokens”. Administrative user tokens have full rights over the all the operating system and whereas standard user tokens are limited in their scope.

Users logging in with an account which is a member of the “Local Administrators” group on that machine are granted an administrative token. If the account is not a member of the “Local Administrators” group they are granted a standard token.

[2] Principle of least privilege

“When applied to users, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all user accounts at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible.” https://en.wikipedia.org/wiki/Principle_of_least_privilege

[3] Mitigation https://www.avecto.com/news-and-events/news/removing-admin-rights-mitigates-97-of-critical- microsoft-vulnerabilities

[4] Many valid requirements for end user having admin rights

1) Install software 2) Run installed software (which, say, requires direct access to OS (e.g. Visual Studio) or direct access to drivers/hardware) e.g. If we say to laptop users that they should install their own drivers, we have to give them means to do so. Also, NVidia, for example, releases driver update often and these may be important for both security and usability. 3) Change a protected Windows setting (network profile, firewall) 4) Install/change a device driver (due to better driver available or new device added) 5) Pause antivirus protection / encryption (for whatever reason, although some reason are “more valid” than others) 6) Be autonomous a. Mitigate the need for very high support requirements (24/7 helpdesk) or b. Situations where it is not feasible to contact support / action items remotely 7) Developers, including some researchers, who for whatever reason are not working in virtualised / “sandboxed” environment

W10 - Key Decision 3 - Roaming Profiles

We are consulting with College and Service Group Representatives on the requirements associated with Roaming User Profiles (RUP) for Windows 10 as follows:

1) Please respond by stating requirements. For example these might be, ranked in order of most value:

 As an end user, I want to login / logout of my device quickly, so that I am not delayed (and I don’t mind doing settings for apps on each machine that I use)  As an end user, I want my files and data to be available on whichever device I am using  As an end user, I want my application settings to be effective on whichever device I am using, so that I do not have to keep doing the settings (and I don’t mind it taking longer to login/logout)  As a computing officer, I want to ensure that device storage is not consumed by roaming users’ profile data

2) You may offer comments, in additional to those already covered in the ISG workshop, regarding the merits or otherwise of the solution options.

Rank your requirements in order of preference (1 being most valuable). This is important because requirements can be conflicting, .e.g. “I want X to be big so that… I want X to be fast so that…” – these may be mutually exclusive.

Please note: RUP is a solution, not a requirement.

There are many solutions here with various levels of complexity and associate cost (effort, time) to develop and operate. Such solutions offer varying degrees of benefit and flexibility for the community.

Within the ISG group there has been an inconclusive discussion regarding the relative merits of the solution options presented below. There are some notes on those discussions in blue below.

Options: Option 1 - Roaming profiles are off for the whole site.

Windows 10 and Application configuration data is local to ALL SDX clients.

This option is not recommended by the service team, as there has been a clear communication from the student community that RUP are very much needed in the open access labs (ISFM) where students move between machines. [2] [See consultation note 2 below].

Option 2 - Roaming profiles are ON for ISFM, ON for desktop clients but OFF for mobile clients.

This is the same as the existing SD7 “Windows 7” and “MDSD Windows 8” roaming profile configuration.

All staff EdLan-bound (fixed/workstation) device users and users of labs devices Roaming content is minimised A “blacklist” of profile folders excluded from roaming is maintained via Object. [4]

This option is seen as viable by the service team. There are benefits and trade-offs listed below. [1] [2]

This option could be recommended if there is proactive management of RUP size for W10.

This option was generally favoured in the ISG discussion.

Option 3 - Roaming profile are ON for ISFM, OFF for desktop clients and OFF for mobile.

Remove roaming profiles for all staff EdLan-bound (fixed/workstation) and mobile device users.

This option is also seen as viable by the service team. Like the above, there are benefits and trade- offs listed below. [1] [2]

In the ISG discussion, this option was generally:

o favoured by those looking for a relatively simple low cost solution o rejected by those looking for a user experience controlled per user

Option 4 –Investigate options to toggle RUP based on individual user preference.

Remove roaming profiles for all staff EdLan-bound (fixed/workstation) and mobile device users.

And additionally implement solution that will allow individual users to change their preference.

This option is likely to involve significant effort that will have bearing on the project delivery timelines. [3]

This option is not recommended by the project manager.

In the ISG discussion, this option was generally:

o rejected by those looking for a relatively simple low cost solution o favoured by those looking for a user experience controlled per user

It may be possible to re-purpose the solution as implemented for W7. Any potential solution would need be evaluated re cost and time to develop and resources required to operate.

PM view: If not required for a business purpose, this option should be implemented only as part of proactive RUP management as a temporary work around to manage excessively large profile sizes.

Option 5 – Investigate alternative technology.

Investigate technologies that may replace RUP (UE-V, AppSense, etc.)

In the initial fact-finding / review of Microsoft UE-V, the Service Team did not find it to be a viable alternative which would directly replace the current functionality of RUP. The option is to investigate other 3rd party offerings. E.g. AppSense

This option is very likely to involve significant effort that will have bearing on the project delivery timelines.

This option is not recommended by the project manager.

Note: Per OU / Per User config (Option 2 + 4) interference

Configuring on a per OU basis and on per user basis may lead to some unexpected behaviour. For example: an end user who expects to have a roaming profile may not actually have that on machines where the RUP service is disabled (in the OU config).

The permutations are: Per OU, all devices ON + User ON = ON Per OU, all devices ON + User OFF = OFF Per OU, all devices OFF + User ON = OFF Per OU, all devices OFF + User OFF = OFF

This is because RUPs disabled for all devices in an OU would override any RUP configuration at the user level. Consultation notes. The consultation is driven by:

1) Perceived issues with Roaming profiles in support community. 23% of device with roaming profiles have profile faults not reported and perhaps unnoticed by end users, which we suspect is because profiles are too large to replicate up to the profiles servers due to space quotas. (Bearing in mind the larger the replicated profile is, the longer the logon time as the profile is brought down.)

2) There is a reasonable requirement for some user groups to transfer configuration from one machine to another. This is to maintain consistency of application software configuration, options and preferences. Consistency of printers and mapped drives and to limit “first run configuration” times on large and complex applications to a single instance. Roaming profiles are a tried and tested solution that satisfies the above requirement. Examples of which requirement are: Open Access Labs and [reportedly] also some staff, i.e. ECA.

3) Individual user to choose a. Offering a decision to have roaming profiles on or off to individual end users: i. Would need some development, would be relatively costly and take time to implement ii. Would need supporting user docs and education to enable individuals to make an informed choice iii. Would be more complex to support, which would be relatively costly, consume operational time (lost opportunity cost). b. Managing roaming profiles “on” or “off” for SDX as a whole or a sub SDX Area would be significantly less costly, less complex, use less operational resource than doing so for individual end users.

4) Excluded paths

Downloads; Local Documents;

Saved Games; Pictures;

Documents; Contacts;

Desktop; Favorites;

Links; Music;

Pictures; Videos;

Searches; Appdata\roaming\Apple Computer;

Appdata\roaming\Thunderbird\Profiles\edin Appdata\roaming\Thunderbird\Profiles\e burgh.default\ImapMail; dinburgh.default\;

Appdata\roaming\Dropbox; DropBox;

SkyDrive; SkyDrive @ University of Edinburgh;

SkyDrive Pro; OneDrive;

Appdata\roaming\spotify; OneDrive @ University of Edinburgh;

Google Drive; AppData\Roaming\Microsoft\Templates\ LiveContent

5) General Considerations for W10

RUP is vulnerable to 2 issues:

1. Too much end user data in profile (possibly unknowingly) => End users should use network/cloud storage. 2. Too much application data in profile => The Service should package those apps and/or exclude associated paths from RUP sync. (=> And more packaging reduces need to enable admin rights)

Issue with too much profile data:

 Login/logout time is unacceptably long.  May exceed allowance on profile => o Stops syncing as a work around for long login/logout time o End user data at risk, data is not being backed-up.

RUP control:

 Per class of machine (Desktop, Laptop, Labs, etc)  Per group of machines in OU config, RUP service is enabled / disabled for that machine (overrides per user setting).  Per user, profile of the users AD object, value is valid or blank.

What current tools? https://adwebtools.is.ed.ac.uk/ -

What resources currently doing this? User Services and some local COs

Considerations for better managing RUP for W10:

 Comms, Docs: Encourage end users to network storage o At 60% profile space used . Repeating notice to end users . Data not on network / cloud may not secured o At 90% profile space used . Notice to end users . Account will be locked if space not reduce / helpline contacted to protect data  Service Design o Plan to package all apps as required (Scale? Resourcing?) o More RUP sync path exclusion  Individual RUP exclusions o Only as work around o Must include a commitment to rollback after an issue is resolved

Option 4 – Investigate options to toggle RUP based on individual user preference is already active for some schools/users under W7. They already clear the profile path of the users AD object to disable roaming for individual users as opposed to removing for an OU. The tools/scripts are already available. https://adwebtools.is.ed.ac.uk/ - Allows those with the relevant permissions to amend the profile path of individual users. This is currently undertaken by the helpline, service delivery and school support as a standard service request.

APPENDIX – Roaming User Profile (RUP) Overview, definitions and terms

A User Profile contains application settings and configuration, e.g. imperial /metric units in CAD, splash-screens, etc., and Windows personalisation, e.g. Text size, position of start button/bar, etc.

A profile can be set to roam with the user [apply to any domain-bound machine the user happens to log on] and apply settings to those machines. As the profile takes time to be brought down from the profile server, some large files are excluded from roaming, e.g. OneDrive cache files / thunderbird mail folders, etc.

Roaming profiles are most beneficial when users habitually login to multiple (different) machines. This is most applicable for users of the Open Access Labs where cached profiles are deleted (for local space) and the user would be required to reconfigure their settings for each session.

The trade-off with roaming profiles is between login speed and complexities of space and server infrastructure on one side and time saved not having to re-apply the settings on the other.

Currently, roaming user profiles are enabled by default on LAN-bound SD7 machines. There are some overrides for sub-groups of devices, notably Lecture Theatre machines and some departments. Roaming profiles are disabled on mobile desktop [MDSD].

W10 - Key decision 4 - Data Ownership

I am are consulting the W10 Programme Board on the 3 questions (below) associated with Data Ownership as follows:

Question 1: Do we confirm the “no local data” message?

Question 2: Do we take the opportunity when migration from Win7/8 to Win10 to enable and encourage end users towards OneDrive and / or other storage solutions that encourage collaborative working?

This means that:

 encouraging users to be responsible for their data is in the scope for W10  we encourage end users to keep their data not on their local device (“no local data”)  we encourage end users to keep their data on one or more of: o on MS OneDrive – particularly for management info o on UoE Datestore – particularly for large research files and data collections (and co- incidentally is the folder redirection target for desktops) o On other research services storage, e.g. HPS (Eddie) o Etc.

We do not force this change on end users, merely enable and encourage. Perhaps for UoE this should be done at business area leader level?

Question 3: Do we recommend Option 3 – End users own their files, data and application settings during the migration?

Background

At the Programme Board meeting on 8th Jan we amended a key message: ‘References to key messages “move your data to the cloud” [and similar message statements when found elsewhere] to be re-phrased as “no local data” ‘.

Previously we’d considered the question of data ownership only in the context of migrating a Win7/8 device to Win10, with an assumption that the migration method would be Wipe and load (WAL) initially and then, when available, in-place upgrade (IPUP).

However, the context is broader than that and some clarification should be considered. There are 3 scenarios: 1. Wipe and load (WAL).

By this we mean:  For existing devices: the user’s files and data is moved or copied off of the device, we reformat the device’s local storage (HDD or SSD) and in so doing destroy the end user’s files and data, we re-build as UoE Win10  New devices: re-build as UoE Win10  Unmanaged devices: re-build as UoE Win10

Either way, the end user’s files and data are not on their newly re-built device. 2. In-place upgrade (IPUP).

By this we mean that the current UoE Win7/8 OS managed (not Win7/8 unmanaged OS) is replaced by the UoE Win10 OS.

From our own past migration experience and that of other large organisations is that there is a risk of a migration failing. This risk is minimal (between 2% and 5%?) [1], and will happen to some UoE devices, e.g. due to an incompatible hardware driver. In the event of a failure a rollback scenario is provided to revert the machine back to its previous state prior to migration. However, a subset of migration failures have the potential to result in data loss, e.g. hard disk failure due to uncommon amount of disk activity. This may happen to a small percentage of a small percentage.

We would still encourage end users to back up their really important files and data in the cloud.

3. Ongoing normal operation “in the cloud” and enabling collaborative working.

The direction of travel for Windows users as promoted by Microsoft is Office 365 (with OneDrive / SharePoint) for working with files, storing those files “in the cloud” and sharing those file with others.

Many organisation use the migration from W7/8 to W10 as the moment to trigger new ways of working with cloud service that are support and governed (as opposed those that are selected by individual end users). https://support.office.com/en-us/article/Why-use-OneDrive-to-store-your-docs-e55c4fa8-1e03- 4d75-956b-924620bdfa2d https://blogs.technet.microsoft.com/josebda/2016/01/26/my-top-reasons-to-use-onedrive/

Benefits of Office 365:  Files are secured, i.e. are highly available and backed up  Files are accessible from any device  The most recent version of a file is available on those devices  Can be shared easily with other (including people who don’t have MS Office apps installed) by reference (and not by creating and transmitted a copy of the file).  People can work collaboratively on the same document, at the same time.

We want to use the migration from Win7/8 to Win10 as an opportunity to enable and encourage users towards to the benefits of “the cloud” and collaborative working. (Is this an objective, do we want to do this?).

The University has already arranged up to 1TB of cloud storage per user with Microsoft. https://uoe-my.sharepoint.com/personal/_ed_ac_uk/ Solution Options

The answers to the three questions can lead to the selection of certain solution options, and discarding the others(s). These solution options are:

Option 1 – ISG owns end user files, data and application settings during the migration.

This option is not recommended by the service team for early adopters.

We may offer this solution later as part of an improving product.

Needs development + testing effort; needs Datastore capacity.

If we were to back-up end users data this should be a contingency option to recover something very valuable or important?

Would files only be available for a limited period of time? (30 days)

Would the recover process be slow? (With an unattractive max time to resolve?).

All the above “offer” would need to be very clearly communicated to end users.

Option 2 – Local support owns end user files, data and application settings during the migration.

This option is not recommended by the service team.

Option 3 – End users own their files, data and application settings during the migration.

This option is recommended by the service team.

Means that we all have to embrace the “no local data” message and impress that upon the end user community.

Means that end users accept:  Treat WAL much like receiving a new computer.  IPUP is a relatively migration easy for some  But IPUP is not without risk; the risks are: o Risk of data loss and app setting loss during IPUP. o Risk that app settings may not automatically carry through from W7/8 to W10 during IPUP (testing will mitigate this risk). o Will some or all end users accept option 3 if put to them in a constructive manner?

We assume that the majority of end users are capable of managing their own files, data and application settings. We assist those that cannot do this for themselves, with centrally (and maybe locally) developed special measures may be required to keep some application setting safe.

We generally treat the migration to W10 as being much like getting a new computer with the user’s files and data being stored off the local device.