Here’s our newsletter update on recent happenings with the Microsoft Infrastructure. This is usually semi-annual, but we’re late by 3 months this time around. Sorry!
==== New Capabilities and Improvements ====
* Azure AD application approval process. There is now a way to request AAD application identities. To find out more, we suggest you start at: https://itconnect.uw.edu/wares/msinf/aad/apps/.
* Service rename. We’ve changed our name from UW Windows Infrastructure (UWWI) to Microsoft Infrastructure (MI) to better reflect what is provided. Most everything that had the old name has now been updated.
* Our customer documentation has moved into IT Connect.
* The ‘Per OU Computers’ group feature we’ve provided since 2008 has changed so that all of these groups are in the Group service. This allows these groups to be referenced as members of other groups in the Group service.
* Significant addition of Azure AD documentation:
–FAQ: AAD terminology (e.g. you find out what that tenant term used above means)
* Addition of additional UW-IT service catalog entries provided by the Microsoft Infrastructure service offering:
* In 2016Q1, we worked with Microsoft to turn off the ability for UW users to create new Microsoft Accounts in the accepted domains of our Azure AD tenant (lots of terms here you can look up in the above FAQ link). Last week, Microsoft applied this change comprehensively to affect everyone, not just our domains: https://blogs.technet.microsoft.com/enterprisemobility/2016/09/15/cleaning-up-the-azure-ad-and-microsoft-account-overlap/. That link does a good job of explaining the poor user experience issues that this change helps address.
* We’ve done some proof of concept work around the Azure AD Application Proxy capability, but haven’t found a customer in need of this solution. This enables on-premises applications to use Azure AD based authentication without making any changes to their existing Integrated Windows Authentication configuration. They gain a hardened cloud-based endpoint (i.e. customers don’t need to VPN), the possibility of leveraging conditional access capabilities such as Azure MFA, and might leverage the logging and security anomaly analysis investments Microsoft is building. Let us know if you are interested in this.
* We’ve recently discovered that the latest Windows 10 build, 1607—the ‘anniversary edition’—has made a change to how Active Directory integrated Bitlocker works. Microsoft hasn’t documented this change well, so there is still some confusion about it. Keep in mind that this information is specific to a domain-joined computer which has enabled Bitlocker and is configured to save its bitlocker recovery key to AD.
When Bitlocker was initially introduced (vista), the TPM owner and recovery key data could be saved in AD as information on the computer object and a child object of the computer. With Windows 8, Microsoft made a change (which was not well documented) to support the ability to bitlocker non-system drives (i.e. drives that aren’t necessarily associated with a single computer). This change meant that TPM owner info was saved on a new object separate from the recovery key.
With this latest change (win10, build 1607), the TPM owner information is not saved to AD at all, but the recovery key continues to be saved to AD.
This change has been alarming to some, but the TPM owner information is not needed to recover bitlocker—only the recovery key is needed.
Relevant to this space, we have a new capability almost ready: MBAM (MS Bitlocker Administration and Monitoring). Earlier this year, we leveraged some Microsoft Windows 10 grant money for a contractor led MBAM deployment in the NETID domain. We intend to provide that MBAM deployment to all delegated OU customers, however many technical details and a scalable support model still need work.
* We’ve added some additional members to our service team: Bruce Edwards, Kevin Lee, and Patrick Lavielle. This addition provide some additional depth, and return us to 2014 overall staffing levels. We’ve been doing some training and swapping around roles and responsibilities to strengthen our skills across the team, with new ideas and perspectives already having a positive influence on the quality of what we provide.
==== Trends ====
* Since January, MI has sustained growth: +17 delegated OUs (129 total), -4 trusts (51 total), +~2700 computers (15113 total), +65k users (837k total), +8k groups (104k total).
* MI support requests are up 30%. 292 MI support records resolved between 1/15/16 and 7/15/2016 (vs. 224 in prior period). Note: the period from 7/15 through now will be covered in the January 2017 newsletter.
You can see metrics about MI at http://www.netid.washington.edu/dirinfo/stats. [Yes, this page on the “old” website still works]
==== What’s Next ====
Our objectives for the 6 months from July through Jan. 2017 include:
* Explore how to deliver MBAM capability, primarily working to develop scalable support model
* Explore local administrator password management solutions. We plan to release an analysis paper of the options & associated risks, and add the best option to our planned new capabilities.
* Replace our existing 5 wiki-based forms with UW Connect forms to help ensure accurate routing
* Continue to build AAD discovery/monitoring tools to enable better management and oversight
* Replace AAD DirSync with AAD Connect, as AAD DirSync moves to end of life in Feb 2017
* Deploy Azure Rights Management infrastructure to support RMS pilot exploration for customers with confidential data
* Partner with Managed Workstation to transition their existing Windows Imaging and Software Deployment capabilities to Microsoft Infrastructure via a SCCM deployment in NETID. This would mean delegated OU customers could have a SCCM client agent and get and share software packages.
* Support Managed Workstation migration into the NETID domain
* 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.
* Make a major change to our Azure AD App stance, re-enabling self-service AAD App approval for user-consent apps
* Begin long-term effort to build a redesigned identity data agent, incorporating a less brittle design, real-time data updates, and the preferred name data source
* Explore short-term fixes to our existing identity data agent (FIM), including possibly adding the preferred name data source
* Explore AAD Audit API to support inactive user design & regulatory business needs
Of the 15 forecasted objectives we listed in the last MI News, here’s a review of how they turned out:
- 2 were successfully completed: AD-CS, AAD app approval
- 8 were started and continue: LAPS, AAD-AP, RMS inf, Migration, inactive user design, UW firewall, Preferred name, Monitoring
- 4 were started by dependent service, but hasn’t yet reached the point where we can start: MFA, hi-sec file svc, SCCM, basic managed desktop, MIM PAM
- 0 were not started
==== 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://itconnect.uw.edu/wares/msinf/design/capability-map/. This capability map includes a high-level summary of our roadmap. We also plan to publish a ‘strategy on a page’ based on the emerging UW enterprise architecture practice soon. We can also provide more detailed information about our backlog if you have questions. For broad discussion about the Microsoft Infrastructure, the email@example.com 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 firstname.lastname@example.org.
UW-IT, MI Service Manager