SHA256 and Isilon connection issues

Hello gem_guy,

Thank you for your question! Are you asking about Kerberos encryption? Per our Compatibility Guide OneFS supports the following Kerberos encryption types:

• DES-CBC-CRC

• DES-CBC-MD5

• RC4-HMAC

OneFS does not support Kerberos AES256 encryption.

If this is not what you're looking for, can you clarify your question a bit so we can get an answer for you?

I know this is an ancient post but when one searches for Isilon and kerberos authentication type support, this thread is one of the few that shows up. We're looking to do the exact same thing and wondering if this limitation is still in effect. The Compatibility Guide that johnsonka posted in Feb 2016 goes to a new version (with totally different content). Kerberos encryption types are no longer mentioned in the new October 2021 version.

Before we disable RC4 kerberos hashtypes in our domain we'd like to know if modern OneFS supports this.

The most updated article I have found, but not the most current version still doesn’t list it. https://dell.to/3GI3lwU Let us know if you have any additional questions.

"This article is permission based. Find another article."

Heh. Sheesh, that's a little brusque isn't it. Can you copy the relevant page contents here please, Josh? Thank you.

Hi - sorry, but I tried that link in 4 different browsers (firefox, MS edge, Brave, Vivaldi, and even good ol' IE) but it just whips back and forth between dell.com/sso and dell.com/identity and never loads any content. I intentionally used Vivaldi and IE last because they don't have any adblockers loaded.

Any chance you can send me right to the guide page without your dell.to shortlink system getting in the way, please?

Hello HornHead,

Here is the link to the security and configuration guide which explains what is supported for encryption.

https://dell.to/3FIGgZF

If you go to https://dell.to/3rB6W9y  and search for docu95378. It is the OneFS 8.2.x Security Configuration Guide.

The linked Security and Configuration Guide actually does list AES256 (and AES128) as supported for SMB3.x.  In practice, our cluster doesn't try anything besides RC4.

SMB signing algorithms

SMB 3.0, 3.0.2, 3.11 AES-128-CMAC (signing)
GSS-API SessionKey and KDF (key derivation)

Used via GSS-API, NTLM mechanism:
● RC4 (schannel encryption)
● MD5-HMAC (signing)

Used via GSS-API, KRB5 mechanism (all encryption types provide signing and
encryption):

● AES256-CTS
● AES128-CTS
● RC4-HMAC
● DES-CBC-MD5
● DES-CBC-CRC

" In practice, our cluster doesn't try anything besides RC4."

Is there a way to force OneFS to utilize AES rather RC4?   We are going to be disabling RC4 on our Domain Controllers in our environment and our concern is whether our endpoint clients will have issues. 

I"m seeing the same result  as anonymous_stranger mentioned in that when I run  "klist" from a client connected to an Isilon Share I see only RSADSI RC4-HMAC (NT)

We are an all Windows environment  and only use the Microsoft implementation of Kerberos.  No NFS at all

I'm looking for a way to either force AES on the Isilon side or ensure that client authentication will just magically work when RC4 is turned off

We did eventually get this fixed.  Dell Support was zero help, but one of our Dell account guys had customers with similar issues and they shared what worked in the field...

You need to look at the AD computer account for your cluster, and check the msDS-SupportedEncryptionTypes attribute.  If this value is blank, then when this cluster attempts to authenticate, AD will check this attribute and perform the default of RC4 only.  

I don't know why it was blank in our case on one of our clusters.  The cluster has been around for a long time, and maybe it was a bug or maybe it was the standard behavior when it was first joined to the domain.  

I have another cluster that had the value set to 0x1F (31), which means the computer account supports all encryption types, even DES.

The value for any Windows device when it is created in the domain is 0x1C (or decimal 28), which means the computer supports RC4, AES 128, and AES 256.  

YMMV, and do your own due diligence, but we were able to change this value live, and new authentications from Windows clients immediately started using AES 256.

Relevant Microsoft article:

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

Hey anonymous_stranger!   I just want to say thank you!   This matches our situation pretty accurately.  We have one of our clusters with the existing msDS-SupportedEncryptionTypes value set to "blank" and we'll be able to test setting the value to one of the other options in a week or so.   Fingers crossed, this solves it.   

I wanted to follow up on my own post to let future searchers know that changing the msDS-SupportedEncryptionTypes attribute on the Isilon computer object in AD worked for us with no problems to report.  We chose 0x18 (24) which only supports AES 128 / AES256.  We were able to eliminate RC4 from our Isilons.   Dell support wasn't much help, but this forum did.  Thanks again anonymous_stranger.

I was curious about this and checked our system is already setup with 0x1F, which allows all types. running klist ona a user desktop machine only shows AES 256, however I never see our isilon directly listed. am I missing something, what is the best way to check a live connection from onefs to see the type of encryption used to be sure we are no longer using RC4?

So all I did was map a drive letter to the Isilon and write a test file to the share.   Once I did that, I was able to run 'klist' and it showed up with AES256.  Not sure what else you could try to get that working for you? 

If you see nothing listed at all on your client, it may be using NTLM instead of Kerberos for some reason.