How To Disallow NTLM Authentication on a Per Resource Basis

[Alex Simons (AZURE)]

First published on CloudBlogs on Sep, 04 2007

One of the most exciting and fulfilling things that I get out of my job is the opportunity to resolve unique customer concerns and scenarios.  I’ve said this before in prior blog posts, but this one in particular, I think, will illustrate that.

One of my colleagues was working an issue where his customer mentioned that they are seeing a user being granted more access to a file resources on a share when than what they should have.  Neither the user, nor a group he had been added to, was listed as having anything more than read allow access, yet the user could edit and even delete the files.

Typically what we do in these support situations is to use a tool like MYTOKEN.EXE or WHOAMI.EXE to “dump” the information in the user’s security token to list out the security groups and other access data that the user has when they have successfully logged on.  We do a similar “dump” of the access control list (also known as permissions) on the object (file or folder typically) using SUBINACL.EXE or similar tools.

Then we compare the list of permissions with what the user has in their token.  Sort of a poor man’s dry run access check, since a similar mask comparison is actually what is done “under the hood” when a user requests access to a resource.

In my colleagues case, though, there was no explicit or inherited permission for his user account or a group that was in his token which would appear to allow him access to the files he had access to.   This was especially puzzling since most of us think of our permissions technology as complex but well understood.  Unexpected stuff happening is, well, unexpected.

There was one entry that was different than what we normally see.    Let me show you and see if you pick it out right off.

The access control list (ACL) on the folder and the files had an entry like this:

G:SHARE1

BUILTINAdministrators:(OI)(CI)F

BUILTINBackup Operators:(OI)(CI)C

DOMAIN1Domain Users:(OI)(CI)R

NT AUTHORITYNTLM Authentication:(OI)(CI)F

DOMAIN1DOMADMINS:(OI)(CI)F

NT AUTHORITYSYSTEM:(OI)(CI)F

Whoami /all from the user was (RIDs obfuscated to protect the innocent):

[User]         =  "DOMAIN1joebob"  S-1-5-21-8675309-8675309-1417005543-3544

[Group  1] = "DOMAIN1Domain Users"  S-1-5-21-8675309-748552-1417001333-513

[Group  2] = "Everyone"  S-1-1-0

[Group  3] = "BUILTINAdministrators"  S-1-5-32-544

[Group  4] = "BUILTINUsers"  S-1-5-32-545

[Group  5] = "NT AUTHORITYREMOTE INTERACTIVE LOGON"  S-1-5-14

[Group  6] = "NT AUTHORITYINTERACTIVE"  S-1-5-4

[Group  7] = "NT AUTHORITYAuthenticated Users"  S-1-5-11

[Group  8] = "LOCAL"  S-1-2-0

[Group  9] = "DOMAIN1janitors"  S-1-5-21-8675309-92003306-1417001333-1199

If you looked at the permission ACE for “NT AUTHORITYNTLM Authentication:(OI)(CI)F” as the culprit allowing the user access then you picked the right one.  Removing that from the ACL removed JoeBobs full access to the folder and it’s files.  He could only then get Read Allow via his Domain Users group membership, as originally planned.

Which leads us to our next question: Why?

We have different authentication mechanisms used for connections or network protocols, as you all likely know, and each has its own strengths.    Kerberos is the most widely used for authenticating in a Windows 2000 or 2003 domain, but there is support for NTLM (the legacy authentication used most in NT 4.0), digest, and SChannel (SSL/TLS) to name a few others.  The most secure of those named is Kerberos, and a best practice is to write applications so that they use Kerberos authentication rather than others, like NTLM, which are inherently less secure.

So back to the question of ‘why’.    As it turns out this user had connected and authenticated to the server using NTLM, and once he had done so, the authentication package used was an additional part of his token.  Now, this is somewhat of a simplification, but you can understand if we don’t get too specific in the details on this, right?

Bottom line was that the user connected to the server using RPC, and that connection was authenticated using NTLM (unfortunately, since NTLM is less secure than others like Kerberos).   As a result, a new entry was added to his token which wasn’t readily apparent from the WHOAMI output: NTLM Authentication.  It was this unseen but very present turdlet that allowed the access.

If we reason this out a bit further it becomes obvious that if the user had authenticated using Kerberos or some other mechanism then he would have received an access denied to the folder and its files.

Now let’s take that a bit further still.  What if you were to deny access to the folder and its files for the NT AuthorityNTLM Authentication group?  That would mean that any user who had used that less-than-ideal authentication when connecting would be denied access to the resource.  And that’s good since that would make only those connections who were less likely to be impersonated or spoofed the ones who would be able to read, edit, delete and such the contents of the directory.

That’s a cool thing indeed.  By the way, it really works that way.

In your Active Directory domain there are a few objects in the Configuration container which are defined as foreignSecurityPrincipal objects and are used to represent authentication mechanisms.  They are NTLM Authentication, Digest Authentication and SChannel Authentication.  Each has its own Well Known Relative Identifier, or well known RID.

These are tied together in the operating system so that, when a user has connected via RPC which was authenticated using one of those mechanisms, then that RID will be added to the token.  If you look at MSDN some of this is documented in the list of well known SIDs (below).

WELL_KNOWN_SID_TYPE (Windows)

http://msdn2.microsoft.com/en-us/library/aa379650.aspx

For the NTLM entry you’ll see this:

WinNTLMAuthenticationSid

Indicates a SID present when the Microsoft NTLM authentication package authenticated the client.

Does this mean that you can now, in a blanket manner, switch off all NTLM based authentication?  Absolutely not.  NTLM is still present, and you can mitigate it’s usage by altering the LMCompatibilitylevel of your environment and by making sure that DNS name resolution is working well throughout.

What it does mean is that if you have placed a deny access control entry (permission) on a file or folder for that authentication mechanism , and if the users connection via remote procedure call (RPC) was authenticated using that mechanism, then that user would be denied access to that file or folder.  So you can, in effect, deny access based on NTLM being used by the users connection, or digest, or SSL.

Does this carry over to when accessing objects in AD?  Good question O Reader.   Below you’ll see my connection to a test domain of mine where I used LDP.EXE, specified NTLM in my bind and then tried to access objects which I had placed an explicit Deny Full entry for NTLM Authentication.  The object I placed the deny on was OU=JP,OU=Regions,DC=tspringtest,DC=com.

I’m snipping some of the LDP.EXE output for brevity’s sake, but it’s still a bit so be ready to scroll.

ld = ldap_open("tspringdc1", 389);

Established connection to tspringdc1.

Retrieving base DSA information...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn:

1> currentTime: 08/29/2007 15:13:38 Central Standard Time Central Daylight Time;

<snip>

-----------

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 4230); // v.3

{NtAuthIdentity: User='joebob'; Pwd= <unavailable>; domain = 'tspringtest'.}

Authenticated as dn:'joebob'.

Expanding base 'DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: DC=tspringtest,DC=com

3> objectClass: top; domain; domainDNS;

<snip>

-----------

Expanding base 'OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=Regions,DC=tspringtest,DC=com

<snip>

-----------

Expanding base 'OU=JP,OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=JP,OU=Regions,DC=tspringtest,DC=com

-----------

***Calling Security...

Error: Security: No Such Attribute. <16>

Server error: <empty>

*********

That last portion above, “Calling Security”, is where I attempted a modify operation against the security descriptor of the Regions OU.  Didn’t get much did I?  In fact, I wasn’t able to see much at all with that Deny for NTLM Authentication ACE in there, was I?

Now view the same attempted access to the Regions OU after I removed the deny ACE for NTLM Authentication:

-----------

Expanding base 'OU=JP,OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=JP,OU=Regions,DC=tspringtest,DC=com

2> objectClass: top; organizationalUnit;

1> ou: JP;

1> distinguishedName: OU=JP,OU=Regions,DC=tspringtest,DC=com;

1> instanceType: 0x4 = ( IT_WRITE );

1> whenCreated: 01/19/2007 11:39:45 Central Standard Time Central Daylight Time;

1> whenChanged: 08/29/2007 15:19:58 Central Standard Time Central Daylight Time;

1> uSNCreated: 74464;

1> uSNChanged: 312236;

1> name: JP;

1> objectGUID: 47c6909b-e7da-4f69-8297-4040c8dfaaef;

1> objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=tspringtest,DC=com;

1> gPLink:  ;

1> gPOptions: 0;

-----------

Expanding base 'OU=Tokyo,OU=JP,OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=Tokyo,OU=JP,OU=Regions,DC=tspringtest,DC=com

2> objectClass: top; organizationalUnit;

1> ou: Tokyo;

1> distinguishedName: OU=Tokyo,OU=JP,OU=Regions,DC=tspringtest,DC=com;

1> instanceType: 0x4 = ( IT_WRITE );

1> whenCreated: 01/19/2007 11:39:45 Central Standard Time Central Daylight Time;

1> whenChanged: 01/19/2007 11:39:45 Central Standard Time Central Daylight Time;

1> uSNCreated: 74466;

1> uSNChanged: 74467;

1> name: Tokyo;

1> objectGUID: ca9a1171-cb3e-4d0e-a160-ad1670cf4108;

1> objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=tspringtest,DC=com;

1> gPLink:  ;

1> gPOptions: 0;

-----------

***Calling Security...

Security Descriptor:

String Format:

O:S-1-5-21-2237654438-801274086-1301698106-512G:S-1-5-21-2237654438-801274086-1301698106-513D:AI(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5- <snip>

---

Security Descriptor:SD Revision: 1

<big ole snip of more SDDL data>

-----------

What’s the point of showing all of that data from LDP.EXE?  To demonstrate that you can use the NTLM Authentication as a method to disallow access to specific resources when a user’s connection has been authenticated with a less secure mechanism in the Active Directory as well as on a network share.  The above shows, similar to what you would see any instance you connect and query the directory and do not have sufficient access to read the directory object, that the objects properties are shown when there is access and no properties are shown when a Deny entry is added for NTLM Authentication.

So let’s summarize things a bit regarding what we’ve discussed in this post.

·         Is it possible to “turn off” NTLM authentication? No.

·         Can we use the NTLM Authentication group and its peers to prevent access for users who have authenticated using NTLM? Yes, if the user connected via an RPC connection.

·         Will this work to prevent access to resources when connecting via IIS, ISA or other product? Not really. Each has its own unique code for authentication interactions that work with the platform’s SSPI.  But perhaps you could alter the permissions on the resource objects the application serves out to do this.  I encourage you to test it.

·         When should I do this in my environment? You should set permissions to disallow NTLM (or others)for specific resources (files in a share or on disk, or objects in AD) which you deem valuable enough that you want only our most secure authentication protocols to be used to allow access to them.

·         Are there dangers in setting denies for an authentication group? Much like any deny entry, there are dangers associated with over-restricting access.  In this case, there are added concerns to be kept in mind regarding when you may have a problem authenticating using a more secure method like Kerberos you will not be able to failover to NTLM and still gain access to the resource.

·         Can I place Deny access control entries based on Digest Authentication and SChannel Authentication as well as NTLM Authentication in order to deny access to those resources for people authenticated using those methods? Yes, it does.

I encourage everyone to test this in their environment, particularly when it comes to altering permissions in your directory.  As you test if you see any unexpected behavior, such as access when its unexpected, take a network trace of the connection to verify what authentication is negotiated.  I can personally attest from my own repros in preparing this post that Kerberos is one resilient and robust authentication mechanism since I had some trouble getting it to not work.   But that’s just one more reason everyone should use our product.

Finally, some folks have sent questions to me which I haven’t answered.  My apologies for the delayed replies, I’ll be replying as soon as I

can.   Have a great day everyone!