Presentation decks for NTLMv1/Turning off Legacy Stuff and Azure AD

I’ve given a couple presentations over the last couple months. Here are links to the slide decks and webinar:

Turning Off NTLMv1 or How to Approach Turning off  Legacy Technology given at Microsoft Redmond campus for Windows HiEd 2014 Conference. Or see the archived Webinar (requires installation of Adobe Connect add-in) given for the Internet2 IAM Online forum.

Office 365 Identity aka Azure Active Directory given at Puget Sound SharePoint Users Group.

Turning off NTLMv1

Some of you may be stuck in the uncomfortable position I was in (until recently) of having an AD environment that still permits NTLMv1. If so, you probably have done a little research to figure out what might break if you turned it off, but having been there, I know that you have found very little online that is detailed or even much in the way of resources that would allow you to move forward.

 

To be clear, having any NTLM turned on is not recommended–see http://msdn.microsoft.com/en-us/library/cc236715(v=PROT.10).aspx, where Microsoft says ““applications are generally advised not to use NTLM.” But many of us can’t completely turn off NTLMv2 quite yet (mostly because of Microsoft applications that don’t follow Microsoft’s own advice), but probably can get rid of NTLMv1, which is more heinous (than NTLMv2) in terms of the risk it poses. If you need any additional motivation, take a peek at www.cloudcracker.com, with its NTLMv1 rainbow tables available for any individual to use to crack a NTLMv1 hash in milliseconds.

 

I’ve got two resources to share with folks who want to turn off NTLMv1 but aren’t sure how to proceed.

 

First, I’ve got a document that lists known problems and potential workarounds. See https://itconnect.uw.edu/wares/msinf/other-help/lmcompatibilitylevel/ntlmv1-removal-known-problems-and-workarounds/ for that.

 

There’s a bit of background reading noted at the top of that document which is recommended for understanding the architecture and relevant settings. The NTLM referrals bit noted there is particularly important to understand, and it has a significant consequences on where NTLMv1 events are logged (hint: only at the initial server the client contacts), as well as where the LMCompatibilityLevel settings actually matter (hint: for the “server” aspect, turning off NTLMv1 on a domain joined computer doesn’t mean anything except to the local user accounts of that computer). If you don’t understand that bit, you will make the mistake I made in the summer of 2013 when I turned off NTLMv1 on our domain controllers because there were no NTLMv1 events on our domain controllers, and then had to roll that change back when lots of people still dependent on NTLMv1 couldn’t access various services.

 

Also let me highlight a couple significant potential gotchas within the known problems list:

  • Non-Windows browsers don’t support NTLMv2. To my knowledge, there is only a single exception to this statement: Safari on MacOS with an obscure Samba setting. You can find more details in the document above, as well as various workarounds we came up with. This led me to realize that for IIS, Integrated Windows Authentication is a dead end (b/c very few folks actually get Kerberos working on those non-Windows clients) that I should actively discourage within my organization.
  • IAS/RRAS/MS-CHAPv2 & the native MacOS VPN client. The native MacOS VPN client doesn’t support NTLMv2. Only known workaround is a 3rd party VPN client.

 

If anyone has additional known problems/workarounds they’d like to contribute to this document, please let me know & I’ll add them.

 

Second, we have a PowerShell script we created to parse the security event log for the important bits from NTLMv1 events. It can be used remotely. See https://itconnect.uw.edu/wares/msinf/other-help/lmcompatibilitylevel/using-get-ntlmv1logonevents-ps1/ for that. We leveraged this extensively to identify misconfigured clients which we then contacted.

 

I hope this info is helpful—I know I would have really appreciated this kind of info back when I first started down this road. 🙂

Microsoft’s JIT approach revealed

Below you’ll find a link to a TechEd Europe session earlier this week.

 

I just finished watching the 2nd half, which is much more interesting than the 1st half (which presents all the problems we all know about). Microsoft has finally revealed their planned just in time administration (JIT) approach in broad strokes.

 

Some of the major points:

  • Next version of Windows will have capability where group members can have a TTL that AD automatically respects (AD has had TTL capability for a long time, but this is the first time I think anything has used it)
  • There is a new forest trust type for admin access. Very little said about this
  • There is a concept of a bastion forest. The purpose here is twofold:

a) isolate your elevated account risk

b) have a known place of goodness (i.e. you may already have bad actors in your forest that you don’t know about)

  • There is some newly extended capability leveraging sidHistory such that you can now stick the SID of well-known groups on objects (this is key to allowing the bastion forest accounts/groups to “own” objects in your existing forest)
  • Next version of Windows will know that when it goes to issue a logon token, the TTL of that token should be constrained by the smallest TTL of your security group memberships
  • There are capabilities in MIM.vNext (was FIM) that permit workflow behaviors such that pre-defined “candidates” can self-elevate themselves subject to approval workflows you design and TTLs you specify
  • A key point: you don’t need to move any of your existing environment to Windows 10 to take advantage of this new goodness. You deploy a new Windows 10 forest, setup the elements required to support the stronger access management scenario you need (in that new forest), map them to your existing groups, and empty those existing groups. At that point, no one has access by default, and everyone has to use the JIT mechanism.

Footnote:

I’ve gotten a couple “huh?” sorts of inquiries related to my parenthetical comment above about how AD has had TTL capability for a long time. Mostly about how Microsoft might get something like this to work and whether this TTL stuff happens in AD or MIM. My educated guess is the TTL stuff happens in AD, not MIM.

Here are a few breadcrumbs to allow you to get a handle on this yourself. 

entry-TTL attribute http://msdn.microsoft.com/en-us/library/ms675669(v=vs.85).aspx

dynamicObject (auxiliary) object class http://msdn.microsoft.com/en-us/library/ms682219(v=vs.85).aspx

If you aren’t really into schema, I can’t say I blame you, but you are missing out on understanding a bunch of details. An auxiliary class is one that can be added to an existing directory object. In contrast, a structural class is the class that must be specified at the time of creation of the object. The structural class determines a bunch of things e.g. what defaultSecurityDescriptor the object has. An auxiliary class is typically used to “add” capability without the permanent overhead of modifying an existing structural class. Another important detail here is that you can “layer” (or inherit) structural classes on top of each other—the most common example of that is the computer object class layered on top of the user object class (and you can layer many times, e.g. the gMSA class is layered on top of the computer class).

Now, with those breadcrumbs, the only real mystery to me here is how Microsoft managed to take these existing mechanisms and get them to apply the “automatic deletion” not at the object level as is currently the limit of this existing AD mechanism, but at the attribute level.

In other words, today, you could add a dynamicObject class to any group object and set an entryTtl value. When that TTL expired, the group would be deleted. And there are likely use cases for that scenario (automated clean-up of the group sprawl if the owners don’t “re-authorize” keeping the group around), but that’s different than the use case here where one value of a multivalued attribute (member) on a group object gets deleted when a TTL reaches zero.

So put another way, assuming my educated guess that AD is performing this new group member TTL capability, then there’s some real neat stuff here under the covers. And that neat stuff may be highly relevant to a bunch of other use cases. I’d have to reflect on this, but I can imagine there are use cases where you’d want some other attribute’s value to expire after a period of time.

——–

 

markwahl (@markwahl)
10/29/14 3:42   AMTechEd Europe: Privileged Access Management for Active   Directory (Channel 9 recording) channel9.msdn.com/Events/TechEd/…   #tee14

 

Preferred Name, Shared UW NetIDs, UWWI, and Exchange

You may be familiar with the friction we’ve experienced over the years around displayName. Here are a couple past posts I’ve written on this:

 

I’m writing to make sure you are aware of a new behavior that was introduced likely at or after the PersonReg 3.0 release (now called IdentityReg). The effect of this new behavior is that the benefits to UWWI of the imagined “preferred name” work for Shared UW NetIDs are, for the most part, here today.

 

Prior to this, if you wanted to change the name value on a UWWI user that was a Shared UW NetID, you called the UW-IT Service Center and asked them to change the AVF displayName value. It wasn’t ideal, but it worked. That still works (except in some cases—more on that in a second), but there’s a better scenario now.

 

From the UW NetID Manage tool, if you set the Name value (see “Basic Settings”) for a Shared UW NetID, it now results in the PDS displayName value being set to that value (overriding any AVF displayName value). This then results in the UWWI FIM system using that value and propagation to UWWI. Keep in mind that account owners or admins can use the Manage tool on their Shared UW NetIDs by logging in with their personal UW NetID, so they don’t even need to have the Shared UW NetID password handy.

 

So in summary, self-service UWWI user name changes have been attained for Shared UW NetIDs. Getting to this milestone for Personal UW NetIDs still remains outstanding.