What authentication method does CIFS server use for CIFS clients?

[heightsnj]

I am confused about what authentication method is being used by the vservers here. please see the following two command and outputs. Thanks!

1. Based on the outputs, is this vserver using "MS-DC" or "KERBEROS"? My understanding is Kerberos should be the default.
2. What exactly "MS-DC" type  really is versus Kerberos or MS-LDAP? Is this same as NTLM?

*>cifs domain discovered-servers show -vserver vserver-name1

.....

Node: node-08
Vserver: vserver-name1

Domain Name Type Preference DC-Name DC-Address Status
--------------- -------- ---------- --------------- --------------- ---------
abc.organizat.com KERBEROS preferred dcservername01 1.1.1.5 undetermined
abc.organizat.com KERBEROS preferred dcservername02 1.1.1.6 undetermined
abc.organizat.com MS-LDAP preferred dcservername01 1.1.1.5 undetermined
abc.organizat.com MS-LDAP preferred dcservername02 1.1.1.6 undetermined
abc.organizat.com MS-DC preferred dcservername01 1.1.1.5 OK
abc.organizat.com MS-DC preferred dcservername02 1.1.1.6 undetermined

......

*>vserver cifs security show -vserver vserver-name1

Vserver: vserver-name1

Kerberos Clock Skew: 5 minutes
Kerberos Ticket Age: 10 hours
Kerberos Renewal Age: 7 days
Kerberos KDC Timeout: 3 seconds
Is Signing Required: false
Is Password Complexity Required: true
Use start_tls for AD LDAP connection: false
Is AES Encryption Enabled: false
LM Compatibility Level: lm-ntlm-ntlmv2-krb
Is SMB Encryption Required: false
Client Session Security: -
SMB1 Enabled for DC Connections: system-default
SMB2 Enabled for DC Connections: system-default
LDAP Referral Enabled For AD LDAP connections: false
Use LDAPS for AD LDAP connection: false

[Mjizzini]

Cifs in Ontap use Kerberos as default authentication methods when it connect to and server. 

{KERBEROS|MS-LDAP|MS-DC|LDAP|NIS}] are  Server Types that the NetApp vserver can connect to.  NOTE All above services can be located on one DC.

That been said, the client is the one that decides what protocol to use for authentication. If you have everything set up correctly in your environment, the client will try Kerberos first as it is the default.

To monitor your dc connection, use the following command. 

*>> diag secd connection show -vserver <vserver_name> -node <Node_name>

[heightsnj]

Thanks for your message!

1.     What configurations on the client to  determine what authentication method the client decides to use? In another word, how  can I find out what method the client is using if as you said it is determined by the client?

2.    What exactly MS-DC authentication is? Comparing to KERBEROS or MS-LDAP? As you see in outputs, all type are shown as MS-DC in all my vservers here. Does that mean we are using MS-DC on the vserver, not using KERBEROS or MS-LDAP?

3.    Following is the output of the command you suggested to run. Can you tell what authentication is it using from the output?

*> diag secd connection show -vserver vserver-name1 -node node-08
[ Cache: NetLogon/abc.organiz.com ]
Queue> Waiting: 0, Max Waiting: 2, Wait Timeouts: 0, Avg Wait: 0.00ms
Performance> Hits: 106030, Misses: 171539, Failures: 94422, Avg Retrieval: 1522.32ms

+ Rank: 01 - Server: 192.5.45.8 (robotron.abc.organiz.com)
Connected through the 10.192.26.17 interface, 0.5 mins ago
Version=SMB2, Credits Available=1, Signing=On
Used 1 time(s), and has been available for 30 secs
RTT in ms: mean=21.44, min=13, max=82, med=14, dev=15.86 (29.4 mins of data)

[ Cache: LSA/ais.columbia.edu ]
Queue> Waiting: 0, Max Waiting: 1, Wait Timeouts: 0, Avg Wait: 0.00ms
Performance> Hits: 435, Misses: 3463, Failures: 2131, Avg Retrieval: 3936.59ms

(No connections active or currently cached)

[ Cache: LDAP (Active Directory)/abc.organiz.com ]
Queue> Waiting: 0, Max Waiting: 1, Wait Timeouts: 0, Avg Wait: 0.00ms
Performance> Hits: 1, Misses: 2497, Failures: 1664, Avg Retrieval: 8100.82ms

(No connections active or currently cached)

[parisi]

Kerberos is used if there is a valid SPN associated with the machine account that operates the CIFS server and a hostname is used to access the SMB share in older versions of Windows:

https://support.microsoft.com/en-us/help/322979/kerberos-is-not-used-when-you-connect-to-smb-shares-by-using-ip-addres

Newer versions of Windows can leverage the IP address for Kerberos:

https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip

Basic process is this:

- User accesses the share via hostname or IP - Windows client version decides what happens based on the connection method

- If hostname, DNS is used to look up an IP address and the hostname is also used to search for a CIFS SPN (for example, if the hostname is cifs.domain.com, then the SPN is host/cifs.domain.com)

- If an IP address is used, Windows clients prior to Windows 10 and servers/DCs prior to 2016 will fall back to NTLM; If newer clients are used, a reverse DNS lookup is used to find the hostname, which is then used to find the SPN.

- If a valid SPN exists, then Kerberos authentication is used

- If there is no valid SPN (SPN that matches the hostname used) then CIFS falls back to NTLM

- If NTLM is not allowed in the domain, auth fails

This is the same process used by any Windows client. ONTAP doesn't really have any configuration options to control this other than the initial machine account creation. That initial creation determines the CIFS SPN associated with the machine account. For example, if I create a CIFS server named CIFS, then the SPN is host/cifs.domain.com.

You can see if your Windows client has a valid SPN to the CIFS server by running "klist" on the Windows client.

Example:

C:\>klist

Current LogonId is 0:0x2e17492

Cached Tickets: (2)

#0> Client: Administrator @ NTAP.LOCAL
Server: krbtgt/NTAP.LOCAL @ NTAP.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 8/25/2020 9:26:44 (local)
End Time: 8/25/2020 10:26:44 (local)
Renew Time: 9/17/2020 9:26:44 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: ONEWAY

#1> Client: Administrator @ NTAP.LOCAL
Server: cifs/demo.ntap.local @ NTAP.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 8/25/2020 9:26:44 (local)
End Time: 8/25/2020 10:26:44 (local)
Renew Time: 9/17/2020 9:26:44 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: ONEWAY

If you want to use an alias name, you either create a CNAME record in DNS that points back to the A record of the CIFS server or you create a new A record with that alias and a new SPN:

1> Client: Administrator @ NTAP.LOCAL
Server: cifs/demoalias.ntap.local @ NTAP.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 8/25/2020 9:34:27 (local)
End Time: 8/25/2020 10:29:38 (local)
Renew Time: 9/17/2020 9:29:38 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: ONEWAY

You can find if a valid SPN exists with:

C:\>setspn /Q cifs/demoalias.ntap.local
Checking domain DC=NTAP,DC=local
CN=DEMO,CN=Computers,DC=NTAP,DC=local
cifs/demoalias.ntap.local
cifs/demoalias
HOST/demo.ntap.local
HOST/DEMO

On the storage, you can see auth type with:

::*> cifs session show -vserver DEMO -instance

Vserver: DEMO

Node: ontap9-tme-8040-01
Session ID: 15797783067885568098
Connection ID: 4128580272
Incoming Data LIF IP Address: 10.193.67.237
Workstation IP Address: 10.193.67.236
Authentication Mechanism: Kerberos
User Authenticated as: domain-user
Windows User: NTAP\Administrator
UNIX User: administrator
Open Shares: 2
Open Files: 2
Open Other: 0
Connected Time: 7s
Idle Time: 6s
Protocol Version: SMB3
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 4

Or display just the auth-mechanism with:

::*> cifs session show -vserver DEMO -fields auth-mechanism
node vserver session-id connection-id auth-mechanism
------------------ ------- -------------------- ------------- --------------
ontap9-tme-8040-01 DEMO 15797783067885568098 4128580272 Kerberos

Or you can filter only Kerberos sessions with:

::*> cifs session show -vserver DEMO -auth-mechanism Kerberos

[heightsnj]

@parisi  Thanks so much for your messages! They are very helpful to me.

60-70% of total of 1,000 Windows(VMware) here are 2016 version. The rest is older. Based on my understanding to your messages, for 2016, we should be able to use Kerberos authentication, no matter of if DNS name or IP is used. However, after checked by running “cifs session show -auth-mechanism Kerberos”, there are absolutely no sessions are using Kerberos. All of them are NTLMv2. So, that turns to the possibility as for why,  SPN may not exist in AD.

I randomly picked several Windows, and run “klist”. As the result, there are no any CIFS SPN's. It tells me that there are no valid CIFS SPN, and therefore explained why there are no Kerberos authentication.

Here are my follow-ups, if you can help me out:
1. Can you think of possible reasons why there are no CIFS SPN created?
2. To fix it, is manually creating SPN a solution?
3. What command to tell me if my initial creation of CIFS server on NetApp is using Kerberos or not, and to find out what SPN is?

Thanks again!

[parisi]

When the initial CIFS server is created, the SPNs are defined by the CIFS server name.

For example, if I create a CIFS server named "CIFS" then my SPNs are host/cifs.

::*> cifs server create -vserver parisi -cifs-server CIFS -domain NTAP.LOCAL


PS C:\> setspn /L CIFS
Registered ServicePrincipalNames for CN=CIFS,CN=Computers,DC=NTAP,DC=local:
HOST/cifs.ntap.local
HOST/CIFS

If my DNS name is not "CIFS" (ie, if my users don't use \\cifs to access shares), then I won't use Kerberos. If I use an IP address and there's no corresponding PTR for the IP, then I won't use Kerberos.

The CIFS server I created has no DNS entries; these don't get created by default unless you enable dynamic DNS.

My SVM doesn't have that enabled:

::*> dynamic-update show -vserver parisi
(vserver services name-service dns dynamic-update show)

Vserver: parisi
Is Dynamic DNS Update Enabled?: false
Use Secure Dynamic Update?: false
Vserver FQDN to Be Used for DNS Updates: -
Time to Live for DNS Updates: 24h

Here's the DNS lookup for that new CIFS server:

C:\>nslookup 10.193.67.230 10.193.67.236
Server: oneway.ntap.local
Address: 10.193.67.236

*** oneway.ntap.local can't find 10.193.67.230: Non-existent domain

C:\>nslookup cifs 10.193.67.236
Server: oneway.ntap.local
Address: 10.193.67.236

*** oneway.ntap.local can't find cifs: Non-existent domain

As a result, I use NTLM:

::*> cifs session show -node * -vserver parisi -fields auth-mechanism
node vserver session-id connection-id auth-mechanism
------------------ ------- ------------------- ------------- --------------
node2 parisi 6974949922890059117 3649016229 NTLMv2

To use Kerberos, I need DNS records (A/AAAA and PTR).

C:\>nslookup cifs 10.193.67.236
Server: oneway.ntap.local
Address: 10.193.67.236

Name: cifs.NTAP.local
Address: 10.193.67.230

Now when I access that name, I use Kerberos:

C:\>net use * \\cifs\cifs
Drive Z: is now connected to \\cifs\cifs.

The command completed successfully.

::*> cifs session show -node * -vserver parisi -fields auth-mechanism
node vserver session-id connection-id auth-mechanism
------------------ ------- ------------------- ------------- --------------
node2 parisi 6974949922890059118 3649016230 Kerberos

If I want to use a *different* DNS name, I need A/AAAA and PTR records for the name I want to use (or a CNAME record that points to the original DNS record), and I need to create a new SPN for that account. 

Here's the CNAME:

C:\>nslookup cifsalias 10.193.67.236
Server: oneway.ntap.local
Address: 10.193.67.236

Name: cifs.NTAP.local
Address: 10.193.67.230
Aliases: cifsalias.NTAP.local

Here's the new SPNs:

C:\>setspn /a cifs/cifsalias CIFS
Checking domain DC=NTAP,DC=local

Registering ServicePrincipalNames for CN=CIFS,CN=Computers,DC=NTAP,DC=local
cifs/cifsalias
Updated object

C:\>setspn /a cifs/cifsalias.ntap.local CIFS
Checking domain DC=NTAP,DC=local

Registering ServicePrincipalNames for CN=CIFS,CN=Computers,DC=NTAP,DC=local
cifs/cifsalias.ntap.local
Updated object

C:\>setspn /L CIFS
Registered ServicePrincipalNames for CN=CIFS,CN=Computers,DC=NTAP,DC=local:
cifs/cifsalias.ntap.local
cifs/cifsalias
HOST/cifs.ntap.local
HOST/CIFS

And when I access via that CNAME, I use Kerberos:

C:\>net use * \\cifsalias\cifs
Drive Z: is now connected to \\cifsalias\cifs.

The command completed successfully.

::*> cifs session show -node * -vserver parisi -fields auth-mechanism
node vserver session-id connection-id auth-mechanism
------------------ ------- ------------------- ------------- --------------
node2 parisi 6974949922890059122 3649016234 Kerberos

[heightsnj]

We have about 700 Window clients with 2016 version. None of them are using Kerberos. As far as I can see, it is due to no valid SPNs’. So, my main question was:

What could be the reason can you think of for non-existing valid SPN’s?

What is the fix to that?

[parisi]

I explained in the previous post why you might not have valid SPNs, how to query SPNs, etc. as well as how to fix it.

[heightsnj]

@parisi  Thanks again!

Following is an example in our case here.  Based on my understanding to your message, it did not use Kerberos as expected. Why?

cluster::*> cifs server show -vserver vserver1 -fields cifs-server, domain
vserver cifs-server domain
------- ----------- -----------------
vserver1 VSERVER1 ABC.ORG.COM

G:\>setspn /L VSERVER1
Registered ServicePrincipalNames for CN=VSERVER1,OU=NetApp,OU=Servers,OU=ABCIT,OU=Resources,DC=abc,DC=org,DC=com:
HOST/vserver1.abc.org.com
HOST/VSERVER1

G:\>nslookup                                     # there is corresponding PTR for this IP "10.192.26.45". Right?
Default Server: int-ns2.org.com
Address: 128.59.2.6

> set type=ptr
> 10.192.26.45
Server: int-ns2.org.com
Address: 128.59.2.6

Non-authoritative answer:
45.26.192.10.in-addr.arpa name = vserver1-cifs.abcit.org.com
45.26.192.10.in-addr.arpa name = vserver1-cifs-06.abcit.org.com
45.26.192.10.in-addr.arpa name = vserver1-cifs-05.abcit.org.com

# I accessed a share under this vserver using IP 10.192.26.45, but command below shows it is not using kerberos, but NTLMv2

cluster::*> cifs session show -vserver vserver1 -auth-mechanism kerberos    
There are no entries matching your query.

[parisi]

Your SPN uses vserver1.

Your DNS PTR points to vserver-cifs.

Those don’t match.

Add cifs/vserver1-cifs and cifs/vserver1-cifs.domain.org to the machine account, or have a DNS record vserver1.domain.org as the PTR for the IP.

[heightsnj]

By create the DNS name for CIFS server (in your example) as you suggested, I am able to use Kerberos authentication. 

There is one thing left. I don't quite understand what you said below. To me the command "C:\>nslookup 10.193.67.230 10.193.67.236" is not  valid, because nslookup can only take an IP as the argument, not two IP's. What does 10.193.67.230 and 10.193.67.236 represent respectively?

C:\>nslookup 10.193.67.230 10.193.67.236
Server: oneway.ntap.local
Address: 10.193.67.236

*** oneway.ntap.local can't find 10.193.67.230: Non-existent domain

C:\>nslookup cifs 10.193.67.236
Server: oneway.ntap.local
Address: 10.193.67.236

*** oneway.ntap.local can't find cifs: Non-existent domain

also below is not valid to me neither:

C:\>nslookup cifs 10.193.67.236
Server: oneway.ntap.local
Address: 10.193.67.236

Name: cifs.NTAP.local
Address: 10.193.67.230

When I use the IP with PRT record for that IP, Kerberos is not used. 

Hopefully, this is going to be my last question for you. You have been extremely helpful to me. 

[parisi]

https://man.cx/nslookup(1)

My command was:

nslookup [A record or PTR] [DNS server]