This issue was pointed out by Ryan Davies/SES on what to check when customer is connecting to NAS share

on MAC client with Active Directory or Apple OpenDirectory authentication.

 

 

 

 From: Ryan Davies <Ryan.Davies@Quantum.Com>

Date: Thursday, August 25, 2016 at 10:55
To: DL-SN-SES <DL-SN-SES@Quantum.Com>, DL-AMER-SPS <DL-AMER-SPS@Quantum.Com>
Cc: Alain Renaud <Alain.Renaud@Quantum.com>
Subject: FW: StorNext Escalation Summary: (StorNext M-Series, OPEN MEDIA FOUNDATION) SR 3719478 - M440/ cannot mount share over SMB on MAC client with Apple Open Directory

 

I just wanted to point out how important this is!

I’m copying Alain so he can keep me honest.

 

I had a few SRs that I escalated to Alain and they all were resolved by making sure the name being used to connect to shares matched what was in the Directory Services. This is all part of how Kerberos works. At the most basic level, without giving a lesson on Kerberos, this is what happens:

 

1.       Client tries to connect to share on an SN Appliance named node1.quantum.com with the UNC of \\node1\share, or smb://node1/share for OSX

2.       Client is bound to the directory services used in the customer environment

3.       Client sends a TGT (ticket granting ticket) to the KDC (key distribution center)

a.       This TGT is a request for a session to the name “node1”

4.       The client eventually gets a ticket and sends it to the SN appliance for authentication

5.       The SN appliance tries to verify the request against what is in Kerberos and fails because node1 does not exist in the Kerberos database.

6.       However, node1.quantum.com does exist. So we start the process all over again using \\node1.quantum.com\share and authentication is now successful

 

Another SR had a similar problem but was using Active Directory. The customer had created an alias in DNS for the IP on which smbd was listening on the SN Appliance.

1.       The hostname of node2 was studio51-util2

2.       They created an alias in DNS called “utility” that pointed to the samba IP on studio51-util2

3.       When trying to connect to the share manually from a MAC that was bound to AD and logged in as an AD user, they were prompted for authentication

4.       This happened because “utility” did not exist in AD, so it did not exist in the Kerberos database

5.       They used studio51-util2.nylstudio51.com and were then able to connect

 

Also important: All of this information ALSO needs to be in DNS.

 

So next time you find yourself troubleshooting an authentication problem using AD or AOD, make sure:

1.       DNS records for SN Appliance exist and are accurate

2.       Customer is using the correct name to connect to the share from the clients

 

Hope this is of help to someone in the future.