Computer renames happening 5/17

A notification like the following one was sent to the primary user, last user, and department contacts for the ~380 computers with a name that included an underscore character (_).

———–

You are listed as a contact for the Managed Workstation (Nebula) department MAA.

The computers listed below all have the underscore character (“_”) in their name, which is no longer permitted in the name of Managed Workstation computers. This Wednesday, May 17, at 5pm we will be automatically renaming these computers to remove the underscore character from the computer’s name. In most cases, the process will simply remove the underscore and everything to the right of it (i.e. TK421_SW would become TK421). In some cases, we may have to change the name more significantly. The process will, unfortunately, require a reboot.

NetbiosName	primaryUser	Last User	LogonTime
00542xx732_POT	xxxxxxxx	NETID\yyyy	5/9/2017 11:46:23 AM
SxxET2_POT	xxxxxxx	NETID\yyyy	5/14/2017 3:41:04 PM

Once completed, we will send you an updated list that includes the new name for each computer. If the process fails for some reason, such as the computer being turned off, we will be following up on these on Thursday.

Where we have it, we will be notifying the primary user of each computer about this work later today.

We apologize for the short notice on this work, but we have to get it done before we can star migrating computers to the NETID domain next week. A separate notice about that work will be going out later this morning.

Please contact us immediately if you have any questions.

Managed Workstation Service E: help@uw.edu | V: 206.221.5000

Migrating workstations to the NETID domain

Managed Workstation is migrating workstations from the Nebula2 domain to the NETID domain.

What and When:

Beginning Monday, May 22nd at 5pm, and every night through Friday June 2nd, we will attempt to automatically migrate a set of managed workstations to the NETID domain. Any given managed workstation will be scheduled for one night during this period, and we will publish the schedule next week.

There are two user impacts of this work:

-computers that are being migrated will be rebooted, with a user visible 5 minute warning message when the migration agent is ready to initiate the reboot

-the computer’s name will change from xxx.clients.nebula2.washington.edu to xxx.clients.uw.edu

Users will continue to log into their managed workstation with their NETID user.

Because all Managed Workstation customers are impacted by this work and may need to take action, we also plan to notify all users via the mws-users@uw.edu mailing list. That notification is planned for Wednesday, May 17th and will include a link to the schedule so users can take appropriate action when needed.

What you need to do:

If you are a department contact, we’d appreciate if you make sure folks in your department know to expect a notification from us via the mws-users mailing list. We don’t often use that mailing list, so there may not be strong trust associated with it. It also wouldn’t hurt for folks to hear about this planned work more than once.

Plan to ensure your managed workstation is turned on and on the UW network on the day it is scheduled for migration.

If you remote desktop to your managed workstation, adjust your practices after your computer is migrated. First, connect to the VPN, then remote desktop to your computer’s new name.

More info:

Domain migrations are a pretty standard activity, and UW-IT’s Microsoft Infrastructure service (who we are leveraging) has experience doing tens of thousands of these migrations using the same automated toolset as planned here. Failure rates are extremely low. So we do not expect significant problems, but with ~3500 computers to migrate, there will be a few which encounter problems. if there are problems which result in an unusable workstation, we will treat it as an urgent issue and prioritize returning the workstation to service. You can call 221-5000 or send an email to help@uw.edu and let the UW-IT Service Center know that you are experiencing an incident with your managed workstation.

Managed workstations, which have an underscore character (_) in their name, will need some extra preparation. Early this week, we plan to send a notification to the primary user and contacts of the 381 computers, which have an underscore, character in their name, to let them know about our plans to resolve that.

If your managed workstation cannot be migrated on the day it is scheduled, it will be for one of several reasons. We will attempt to contact customers to resolve any issues and re-attempt a later migration.

Migration scheduling is not planned to follow department boundaries. This is for several reasons, which include avoiding the potential to impact an entire department. If your department has a significant scheduling issue during this 2-week period, please let us know and we will try to accommodate you.

Dawn Cullerton

Service Manager

Managed Workstation

UW Information Technology

Phone: 206-685-3071

Office 2007 End of Life (EOL)

Office 2007 (along with Vista) will got its last security updates in April 2017.

What and When:

Office 2007 reached its end of support lifecycle on 4/11/2017.

What does this mean?

This means there will be no new security updates, non-security updates, free or paid assisted support options. Customers who are using Office 2007 products and services should move to Office 2016. See our Operating System lifecycle and support page for additional info.

What You Need to Do:

If you have a computer running Office 2007, we recommend you upgrade to Office 2016.

If your department wants us to automatically remove Office 2007 from a list of machines, or automatically upgrade your devices to 2016, let us know.

2017 April

Here’s our semi-annual newsletter update on recent happenings with the Microsoft Infrastructure.

==== New Capabilities and Improvements ====

* Self-service Entra ID application identities. On 2/15/2017, we enabled UW users to create and integrate Entra ID application identities. This provides an easy way for developers to integrate with UW identities, but also allows a variety of 3^rd party applications to easily be integrated. Users are advised to carefully evaluate the risk of application integrations. This new capability also introduces the ability for users to individually consent to applications acting on their behalf with other applications. More info is available at https://it.uw.edu/wares/msinf/aad/apps/.

* Preferred name data source. On 3/1/2017, we added the preferred name data source to existing data sources that result in the name commonly shown in a variety of locations like Exchange. This improvement means that all UW NetIDs now have a self-service method to update their Microsoft Infrastructure user name value, and significantly increased control of the resulting value. Via a customer survey 8 years ago, you indicated this was your top desired change for this service, and we have been advocating for this type of solution over that entire time period, so we are very pleased to be able to have implemented this. Detailed documentation about how your Microsoft Infrastructure user name value is chosen is at: https://it.uw.edu/wares/msinf/design/arch/id-data-mapping/#name.

* Entra ID Connect. On 1/6/2017, we replaced our aging Entra ID Dirsync infrastructure with the latest Entra ID sync tool. This did not result in immediate new capabilities, but does set us up to take advantage of some new capabilities in the future.

====Spotlights====

* Microsoft Technology Community. Brian Smith has formed a new community for those active with Microsoft technologies, and the Microsoft Infrastructure service team are active participants. In fact, we’ve given a couple presentations on Microsoft Infrastructure capabilities there. We encourage you to consider joining this community. See https://it.uw.edu/work/resources/ms-tech/ for how to join.

* Microsoft LAPS in the NETID domain. Many of you have asked for a solution to managing local admin passwords. We evaluated the need and possible solutions, and explored whether LAPS met UW security expectations or not. At the April meeting of the Microsoft Technology community (4/19 1:30-3p, Odegaard 220), Patrick Lavielle will present our findings and discuss our plans to provide a solution.

* Entra ID monitoring. Eric Kool-Brown has built special tools for our service to identify Entra ID configurations which are risky in nature, so we are alerted and can take action. Part of this work included exploring the Entra ID Audit API (which is still in preview) and leveraging data from it. One of the user-visible aspects of this effort will be a tool we’ll release that allows you to find Entra ID app user consent details. More info will be provided when that tool is released.

==== What’s Next ====

Our objectives for the 6 months from April through October 2017 include:

* Support Managed Workstation migration into the NETID domain (~3300 computers)

* Identity a delegation and support model to release MBAM for Bitlocker recovery key support. We deployed MBAM in the last 6 months, but still need to find a way to delegate access before releasing it for use.

* ADFS modernization. We’re now 2 major versions behind and plan to jump ahead to ADFS 2016. We’ll work with existing customers to migrate, when ready.

* DC modernization. We need to upgrade all the NETID domain controllers to WS2016. 3 of the 5 DCs are also near end of life, so need to be replaced. Expect lots of communication about this.

* AD-CS stabilization. The issuing CA’s cert is very short-lived, which limits the lifetime of certs it issues and creates maintenance friction. We’ll be replacing the existing issuing CA cert with a longer term one. Expect communication on this planned change.

* Engage with UW MFA program to add future capabilities for Microsoft technologies

* Software deployment capability via central SCCM based service option

* Computer domain join refactor. Supporting the Managed Workstation adoption of the NETID domain, along with plans to move some MWS capabilities (like SCCM) to the Microsoft Infrastructure service, has given us a fresh opportunity to tweak the existing approach and add some new options. We’ll share more when these new options are ready, but know that the existing approach will continue to work as is.

* Release a ‘UW network’ Windows firewall GPO for re-use by delegated OU customers. This reference GPO will be maintained by us, and you’d be able to make a copy (and refresh your copy), without doing any of the work of building it or keeping current on what the existing definition of the UW network space is.

* Refactored identity data integration. This is a longer-running goal to replace our integration based on MIM and file-based data to an event-based architecture. This likely won’t come to fruition for a while, but we are investing in it. The upside for customers will be lower latency of identity data changes, more stability, and increased agility.

* Invest in mitigations to reduce risks from privilege escalation

Of the 13 objectives listed in the last MI news, here’s a review of how they turned out:

7 were successfully completed: LAPS analysis, forms refactor, Entra ID monitoring, Entra ID Connect, RMS, self-svc Entra ID Apps, Preferred name
5 were started and continue: MBAM, SCCM, reference firewall, ID agent refactor, Entra ID Audit API
1 was started by dependent service, but hasn’t yet reached the point where we can start: MWS migration
0 were not started

==== Trends ====

* Since September, MI has sustained growth: +6 delegated OUs (135 total), 0 trusts (51 total), +~1200 computers (16356 total), +63k users (900K total), +9k groups (113K total).

* MI support requests are up 48%. 432 MI support records resolved between 9/30/16 and 3/31/2017 (vs. 292 in prior period).

==== Your Feedback ====

Supporting your needs for MI capabilities offered via the Basic Services Bundle is our priority, so we welcome feedback on how we can make the MI service more valuable to you.

The MI service has a capability map publicly visible at https://it.uw.edu/wares/msinf/design/capability-map/, which was just updated.

Many more details are available about the 6 month objectives listed above, and you are welcome to engage with us to find out more.

For broad discussion about the Microsoft Infrastructure, the mi-discuss@uw.edu mailing list is a great option.

You can voice your support for future objectives to help us rank priorities by voting in customer surveys when we have them, ask for things that aren’t yet on our radar, or simply contact us via help@uw.edu.

Brian Arkills

UW-IT, MI Service Manager

LAPS – Local Administrator Password Solution

A new capability is available to delegated OU customers.

What and When:

As of yesterday, a new capability is available allowing automated management of a Windows computer local admin password. This includes delegated password escrow.

What you need to do:

Use of this capability is optional and requires you to take action if you want to leverage it

Good management of your computer local admin passwords mitigates a key risk in the Microsoft ecosystem. This mitigation reduces the severity of compromises by helping to prevent lateral movement and subsequent privilege escalation.

Delegated OUs are strongly encouraged to consider implementing it. Please reference our customer documentation, https://it.uw.edu/wares/msinf/ous/laps/, for details on how to get started.

More info:

Background on this capability was presented by Patrick Lavielle at the April meeting of the Microsoft Technology community, and a copy of the slide deck will be shared with that community–so follow the link and join that community, if you want that deck.

An analysis paper documenting our process of evaluating the problem of managing local admin passwords is published at https://wiki.cac.washington.edu/x/HFCIB. This includes our review of other solutions, the appropriateness of the plaintext password storage used by LAPS, and other details. Most of the content of this paper is in the slide deck mentioned above.

Brian Arkills

Microsoft Infrastructure service manager

UW-IT

Disabling SMBv1

We are disabling SMBv1 (a file service protocol) on all Managed Workstations

What and When

We are disabling SMBv1, which is a file service protocol used by Windows, on all Managed Workstations. The change is going out starting now, but it will not take effect until the next time each computer is rebooted.

More Info

As you may have seen from media reports over the weekend, several vulnerabilities in Windows were reported on Friday. These reports were mostly overblown, as Microsoft had already patched most of these vulnerabilities, and basic security configurations would block or mitigate the remaining ones. SMBv1, which is a very old file service protocol that is generally not used today, is still vulnerable in certain configurations. To ensure that there is no risk to Managed Workstations, we are disabling SMBv1. This change requires a reboot for it to take effect, however we are not forcing reboots on computers at this time.

If you are using a very old printer or network storage device, it’s possible that it may still be using SMBv1 and thus it will no longer be accessible after this change. Please contact us, via help@uw.edu, if you run into this issue or have any questions or concerns.

—
James Morris
Managed Workstation Service
UW Information Technology

Consistent group naming in Microsoft Infrastructure services

A change in how group names are populated will occur to ensure a more consistent user experience across service interfaces which leverage Microsoft Infrastructure (MI).

What and When:

On April 26^th, we’ll be making a couple changes related to group naming in Microsoft Infrastructure (MI). These changes may take as much as a day to propagate to all interfaces.

Some application interfaces that leverage MI for groups use the ‘display name’ value and others use the ‘identifier’ value to help customers identify groups in group picker interfaces. Groups Service (GS) customers can choose a different value for the ‘group display name’ than the ‘group id’. These two differing values can lead to confusion in different application interfaces.

We currently populate the MI group ‘display name’ value with the Group Service’s ‘group display name’ value. This change will alter that approach so that the MI group ‘display name’ value comes from the Group Service’s ‘group id’ value.

What you need to do:

No action is required unless you have processes which are built on the assumption that the MI group ‘display name’ value will come from the Group Service ‘group display name’ value. You may need to alter those processes to align with this change.

In general, we believe this change will support more wide-spread use of groups for applications.

More info:

Entra ID based applications and Sharepoint Server (on-premises) are the most common examples using the ‘display name’ attribute in their group interfaces, whereas most other applications use the ‘identifier’ attribute.

There is a strong practice around assignment of the group identifier value and stronger historical reliance on it, so this is the group name value we’ve chosen to standardize on. By standardizing on one value for both of the MI group attributes commonly used in application interfaces, consistency is achieved despite application design that differs.

Several more specific changes are happening, see below for the logic:

-Changing the group agent logic by which all future changes from the Groups Service propagate to MI.

-Running a one time “fix” on existing groups to update their display name value.

-Populating the ‘group name’ value to the ‘description’ attribute if there isn’t otherwise a description value.

The logic:

-map GS.groupid value to MI.displayName value, i.e. MI.displayName = GS.groupid

-continue to map GS.description to MI.description value, i.e. MI.description = GS.description

-if GS.description value = NULL, then MI.description = GS.groupName

MI documentation will be updated after this change to reflect these details.

Brian Arkills

Microsoft Infrastructure service manager

UW-IT

Planned work on 4/2 for home and group directories

A service outage is planned for all Managed Workstation home (H:) and group (I:\groups) directories.

What and When:

On Sunday, April 2, 2017, all Managed Workstation home (H:) and group (I:\groups) directories will be unavailable from 8am to 9am, for planned maintenance.

More info:

This work is required to switch the underlying authentication mechanisms for the file servers that provide the home and group directories as part of the migration to the NETID domain. During this work, there will be no access to files and folders in both user home directories (H:) and group directories (i:\groups).

If you have questions about this planned work, please send email to help@uw.edu with “MWS: Planned file server work” in the subject line.

James Morris

Delegated OU role group changes

The role groups for delegated OUs will be changing. Delegated OU role groups are those groups which Microsoft Infrastructure provides to delegate permissions in your delegated OU.

What and When:

Later today March 29^th, 2017, there will be two changes to the delegated OU role groups.

First, all delegated OU role groups will be moving to a new stem. They will move from the u_windowsinfrastructure stem to the u_msinf_delou stem. This is being done to reflect the service name change, as well as to shorten the overall length. For example, u_windowsinfrastructure_pottery_ouadmins will move to u_msinf_delou_pottery_ouadmins. This change will also move the _computers OU computers group.

Second, we’re making an adjustment related to the _computerjoiners role group. Existing _computerjoiners role groups will be renamed to _computermanagers to better reflect the permissions granted. A brand new _computerjoiners role group will be added for each delegated OU. This new role group will only have the permisissions necessary to create a computer account.

This change (by itself) will result in no one gaining additional permissions in your delegated OU.

What you need to do:

This announcement is advisory, but you may have follow-up actions to take. Actions you may want to consider:

There is a very small chance you have services dependent on the existing group names. If you have group policies or code which statically references the name of your delegated OU role groups, you should adjust those references to the new name. See the note below for important context.
You may want to adjust the membership of your role groups to better reflect what permissions individuals have. If so, request a change or use the self-service capabilities provided via UW NetID Computing Support Org to be able to manage those delegated OU role group memberships. Note: _computermanagers is not yet available in this tool, so you’ll need to contact us for changes to it.

Important note: Group moves/renames are generally a non-event for Microsoft technologies because most Microsoft technologies do not store the group name, but instead the objectSID of the group. NTFS and share permissions and many other Microsoft ACL capabilities have this dynamic reference which is not tied to the group name. Some group policy settings do store group names. So in almost all cases, you need do nothing.

More info:

When we released delegated OUs, the _computerjoiner role group only had permissions to create a computer account. Over time, some customers asked for this role to have more permissions—particularly when we started asking customers to provide valid dnsHostname values. So we grew the permissions of this role to be full control on computer objects. We now recognize that this choice was a mistake on our part—we should have added a new _computermanagers role, and left the _computerjoiners role as named & designed.

Two things brought this mistake to the forefront:

-In reviewing supportability for LAPS, we didn’t feel that the _computerjoiners role should have the ability to get the local admin password (more details about future LAPS support and changes related to that will be forthcoming)

-To support the Managed Workstation service’s adoption of delegated OUs, we recognized their broad need to delegate only the ability to create a computer account

We welcome comments, questions, requests, or issues related to these planned changes. Please send those to help@uw.edu with ‘Delegated OU role group changes’.

Brian Arkills

Microsoft Infrastructure service manager

UW-IT

Microsoft LAPS schema and permission changes

The NETID Active Directory will have minor changes to set the stage to add support for LAPS, a Microsoft provided capability, for delegated OU customers.

What and When:

On Friday March 31, 2017, the Microsoft Infrastructure (MI) team will be making a change to the NETID domain in preparation to implement Microsoft’s Local Administrator Password Solution (LAPS).

The first change is a schema updates to allow two additional attributes on computer objects in the domain.

The second change will update permissions on each delegated OU to allow for the secure storage of a password when LAPS is implemented. Note: A separate but related change is planned to delegated OU role groups—you’ll see a separate announcement about that.

What you need to do:

This announcement if only advisory. Additional announcements will be made when Microsoft Infrastructure releases LAPS for general availability in the NETID domain.

More Info:

Schema changes are considered very low risk. NETID domain schema documentation will be updated to reflect this change. Delegated OU permission documentation will also be updated to reflect this change.

More info about LAPS: https://technet.microsoft.com/en-us/mt227395.aspx.

Brian Arkills

Microsoft Infrastructure service manager

UW-IT