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.

The 48 Laws of Power

Last year, based on a extremely flattering book recommendation, I read The 48 Laws of Power, by Robert Greene.

Power has a lot of relevance to leadership. I see leadership as the process of influencing others. For example, if you consider the ‘5 steps to making an impact’ graph, there are plenty of examples we can all think of where power is used to skip those steps and make an impact without actually gaining creditability, trust, respect, or inclusion. But the reality is that the outcome isn’t as impactful because the folks following may not believe in where they are led. This is the dilemma of top-down leadership. And to tie in another book I recently read (Thinking in Systems), it’s why feedback loops are incredibly important for leaders whose impact comes from their role, not their progression up the ‘making an impact’ graph (or as power law 18 says: do not build fortresses to protect yourself–isolation is dangerous).

But there are also situations where power is used to help facilitate the steps in the impact graph. And that’s what I’d call a good use of power for a leader. And sometimes, as a leader, you must wield power to skip the steps because there isn’t time for the alternative of progressing up the graph. That’s not ideal, but we don’t live in an ideal world. That’s why repairing relationships is one of those topics all leaders need.

Yes, The 48 Laws of Power talks about Machiavellian ways of getting and using power. Yes, this is very different from the ideas and techniques promoted in the UW-IT Leadership program (or any leadership program). But as Niccolo Machiavelli wrote in The Prince: “Any man who tries to be good all the time is bound to come to ruin among the great number who are not good.” At the very least, you owe it to yourself to be aware of the techniques that might be used against you, and to avoid the worst mistakes of using the power that comes with leadership. “Hence a prince who wants to keep his authority must learn how not to be good, and use that knowledge, or refrain from using it, as necessity requires.” (the rest of the Machiavelli quote above) At the best, you may learn techniques that you can use in a good way as a leader. And be able to share those techniques with your fellow leaders. 🙂

So with that introduction, let me focus more on the book itself.

Each chapter focuses on a single law. All the chapters follow a predictable pattern:

  • The law is presented.
  • Highly interesting historical examples that support the law are shared. These come in two flavors and both are always included, usually multiple examples of each:
    •   Transgressions: Examples of someone breaking the law and losing power (and often their life). Followed by a short interpretation section with analysis.
    • Observances: Examples of someone following the law and gaining power. Followed by a short interpretation section with analysis.
  • Keys to power. Distillation and key points about this law.
  • Image: Words in the form of an image (a word picture of sorts) to help you remember the law is presented.
  • Authority: A quote that states the law in a slightly different way.
  • Reversals: Exceptions to the law are noted.

Then throughout, the margins are used to sprinkle in additional material that reinforces the law. This material comes from fables, historical examples, scripture, and other sources.

Even if I hadn’t been interested in reading about power, the history, stories, and anecdotes included were fabulous. I found myself eager to read this entertaining material and flew through the book. I read about half of it over a period of a couple weeks, recognized I wasn’t absorbing it, set it down for a couple months, and returned to finish it later. I enjoyed the history more than I was learning the power laws themselves. Eventually I realized that I’ll have to re-read the book a 2nd time to really absorb the laws. You may be different, but I’d advise that if you commit to this book recognize that it isn’t just a simple once through read.

I’d especially recommend reading this book if you are a leader who doesn’t have authority that comes from the organization, as it’ll give you lots of techniques you can use. But regardless, if you are serious about being a leader, then this book should be on your reading list.