Archives: Service News

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

 

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

 

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

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

 

The Microsoft Infrastructure service will add the Preferred Name data source to its existing identity data.

 

What and When

 

On Wednesday March 1 2017, Microsoft Infrastructure will replace its existing identity data agent with a new one. The new system will add the Preferred Name data source to the existing name algorithm, giving Preferred Name preference over other data sources. We will also drop our specialized character casing for non-personal UW NetIDs like Shared UW NetIDs. These changes will result in display name changes on a broad set of user accounts in the NETID Active Directory and the uw.edu Azure Active Directory tenant. Because there are many applications leveraging those user accounts, this will also result in name changes in a large set of applications.

 

There should be no noticeable interruption to implement this change—we have staged the replacement system so it can immediately take over for the old one.

 

What This Means For You

 

Your Microsoft Infrastructure user account’s display name value may change if you have set a Preferred Name via the https://identity.uw.edu portal. If you do not like the resulting display name value for your personal UW NetID, you can use that portal to set or update a Preferred Name.

If you want a change to a non-personal UW NetID name, you can use https://uwnetid.washington.edu/manage and the Name field exposed there to change the value yourself. You do not need to contact the UW-IT service desk for those changes.

In the past, we applied an algorithm to only upper case the first character of “words” from that data source. This would often result in a display name like “Uw Pottery Department” instead of “UW Pottery Department”. This has been a source of frustration for some customers, so we are removing the case adjustments and using the value as input by the UW-IT Service Desk (which is based on your input). If the display name changes to non-personal UW NetIDs are undesired, you can contact the UW-IT Service Desk to make changes.

 

**NOTE: Exchange, Sharepoint, Skype for Business, and other applications in the Office 365 suite leverage the display name on the Microsoft Infrastructure user account, so this change affects your name in all of those applications. There are many other applications which do their UW NetID identity integration via Microsoft Infrastructure user accounts, and those applications will also be affected.**

 

More Info

 

The approach to name data at the UW is complicated because there are many different user populations with a different data source for each population. And of course, each of those data sources has different methods to make changes to the data. This means that any given application (and infrastructure like ours), must make a number of complex decisions about which name data to use, which can be especially complicated when a given identity has multiple affiliations. In contrast, the Preferred Name data source is unique in that it is a single central authority for name data for UW identities, and provides a self-service mechanism for changes.

 

Because of this complex background, Microsoft Infrastructure has always documented the algorithm behind our naming logic, so everyone can understand what we are doing and how they might change what they see. This documentation continues to be at https://it.uw.edu/wares/msinf/design/arch/id-data-mapping/#name, and has been updated to reflect this change with deeper details than noted here. Up until this change, there have been a number of scenarios where there was literally nothing you could do to change the display name on an identity. I’m happy to report that is no longer the case.

 

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 for that entire time, so we are very pleased to be able to implement this.

 

If you have questions about this change, please send an email to help@uw.edu with “Microsoft Infrastructure Preferred Name change” in the subject.

 

Brian Arkills

Microsoft Infrastructure service manager

UW-IT