Wednesday, August 26, 2015

Access to share denied by FQDN, allowed by NetBios Name

The setup
Normally when folks come to me and tell me that something works by NetBIOS name, but not FQDN (or more often the other way around) I end up providing a refresher lesson in DNS. Upon investigating this case, both FQDN and NetBIOS names resolved correctly to the right IP address. This was not a resolution issue. The share in question is on a NAS device and this is a Kerberos issue. The story of this issue is a gnarly and complex one, but an education. I'm going to explain this chronologically, but first a word on Tokens and Token Compression.

Kerberos Tokens.
When a user logs into an Active Directory Domain, they are presented with a Kerberos token. This represents the SID of all the groups they are a member of. One fight that many IT engineers face is the concept of Token Bloat, where the user is a member of so many AD groups, that their token can be filled and lead to seemingly random authentication issues. In an effort to re-mediate this issue, Microsoft introduced a new technology in Server 2012 R2 called Token Compression. To illustrate this, here is how a normal token is constructed, note this just is a simplification to illustrate a point.

{
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF486270200
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF429A90100
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF43A6104A3
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF49DF1F253
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF42FBCBDFF
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF49BCDCCFA
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF49A9F4BCB
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF45AA5D6DC
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF46CBFA35C
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF40DBAA87A
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF4143BBAB7
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF46A9CEC39
}

You will notice that the first 48 hex characters are the same, this is because it is the domain part of the SID. It is clear that this example token could be compressed using a format like this:

{
  010500000000000515000000CE7CB79C1977C7AC1D7B1FF4
  {
    86270200
    29A90100
    3A6104A3
    9DF1F253
    2FBCBDFF
    9BCDCCFA
    9A9F4BCB
    5AA5D6DC
    6CBFA35C
    0DBAA87A
    143BBAB7
    6A9CEC39
  }
}

As you can see, the domain section of the SID is only recorded once. Again, this is an illustration, don't expect the byte structure to be exactly like this, but you get the picture. Now on with the story...

April 2015
Around this time period, routine maintenance led to the reboot of a crucial medical application server. At that time the Active Directory Domain to which it belonged, was supported by Windows Server 2008 R2 Domain Controllers.

June 2015
Around this time, the domain was upgraded to Windows Server 2012 R2 Domain Controllers. At the end of that project, there were no more Windows 2008 R2 Domain Controllers. Under the covers, at the precise moment the last 2008 DC is retired, the domain begins to issue compressed tokens. Note: this has nothing to do with 'Domain Functional Level'.

July 2015
A network outage occurs, and the clinical application loses connectivity to a critical file share on the NAS device. The service on the application server is restarted and at that point, the service account that the service runs as, is given a new token from a Domain Controller. It receives a compressed token. The application is configured to reach the share via a UNC that includes the FQDN of the NAS device. Per the default security configuration of a Server 2012 R2 domain, the use of the FQDN facilitates the use of Kerberos authentication and so the token is presented to the NAS.

OK you waited long enough for the punchline...

The NAS devices does not support compressed tokens! So authentication fails. Replacing the FQDN with a NetBIOS name precludes the use of Kerberos authentication, and we allow the transaction to fall back to NTLM and the service account successfully gains access to the share because the token does not even get used.

So what can be done? There are five options.

  1. Move the share off of the NAS and onto a proper file server (a bit tongue in cheek).
  2. Use a NetBIOS name, and call it good.
  3. Get a patch for your NAS device if one exists.
  4. Selectively reconfigure the service account to insist on receiving uncompressed tokens from the Domain. A service accont is unlikely to be a member of so many groups that it would ever suffer from bloat.
  5. Switch off token compression across the whole domain (don't do that!)
Below is a script that provides you option 4:

Cheers!



param( $principalName)
$newValue = 0
# Get the AD principal and value
$obj = get-adobject -Filter {(cn -like $principalName)} -Properties *
if($obj -eq $null) 
{
  Write-Host "Cannot find $principalName in the directory"
  break
}
$newValue = $value = $obj."msDS-SupportedEncryptionTypes"
$msgBefore =$msgAfter = "Compression status on principal {0}: " -f $principalName
if( ($value -band 0x0080000) -eq 0) 
  {$msgBefore += "Enabled"}
else
  {$msgBefore += "Disabled"}
Write-Host $msgBefore
if( ($value -band 0x00080000) -eq 0) #enable the disable bit
  {$newValue = $value -bor 0x00080000}
if($newValue -ne $value) #update if values are different
  Set-ADObject $obj -Replace @{"msDS-SupportedEncryptionTypes"=$newValue}
  if( ($newvalue -band 0x0080000) -eq 0) 
    {$msgAfter += "Enabled"}
  else
    {$msgAfter += "Disabled"}
  Write-Host $msgAfter
}
else
{ Write-Host "Resource group compression did not change."} 

1 comment:

  1. Thank you for sharing this and the explanation.

    ReplyDelete