Can someone help me understand why my users are seeing a different behaviour with ONTAP 9 CIFS. We moved them from 8.2 7-Mode to a shinny new FAS 8040 ONTAP 9.1.
The AD Domain server remained the same 2008 R2 and the ONTAP SVM is joined to the domain as usual. All shares have default settings
nothing fancy. The windows clients are joined to the domain as a computers.
On the Old 8.2 ONTAP when they mapped a CIFS share from a client windows server all of these formats worked:
net use z: \\server\share /USER fred password
net use z: \\server\share /USER DOMAIN\fred password
net use z: \\server\share /USER firstname.lastname@example.org password
However with ONTAP 9 shares we see the following different behaviour:
net use z: \\server\share /USER fred password OK
net use z: \\server\share /USER DOMAIN\fred password FAIL
net use z: \\server\share /USER fred@domain password FAIL
All fail with:
System errror 59 has occurred'
An unexpected network error occurred
I am guess the key is something potentially kerberos name related perhaps if the client is joined to the AD domain. However thats a guess.
Any comments please.
Sounds like, this must be the issue with your unix-win or win-unix name-mapping issue.
you can use the follwoing command to check it.
::*> diag secd name-mapping show -node <node> -vserver <vserver> -direction unix-win -name <username>
::*> diag secd name-mapping show -node <node> -vserver <vserver> -direction win-unix -name <username>
Once you done the proper mapping you can check the auth using the following command.
::*> diag secd authentication login-cifs -node <node> -vserver <vserver> -user <username>
Hope this help.
Firstly thank you for taking the time to reply, Below is the output:
diag secd*> name-mapping show -node hncl1-01 -vserver hncl1-frlab -direction unix-win -name aparker 'aparker' maps to 'FRLAB\aparker'
name-mapping show -node hncl1-01 -vserver hncl1-frlab -direction win-unix -name FRLAB\aparker'FRLAB\aparker' maps to 'aparker'
authentication login-cifs -node hncl1-01 -vserver hncl1-frlab -user FRLAB\aparkerEnter the password: UNIX UID: aparker <> Windows User: FRLAB\aparker (Windows Domain User) GID: BGFIT Supplementary GIDs: BGFIT BGUSrvGrp34Admin Windows Membership: <removed lines> Privileges (0x22b7): SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeSecurityPrivilege SeChangeNotifyPrivilegeAuthentication Succeeded.
So all seems OK with the mapping and authentication. The users are happy (has users get) but it would be nice to understand why this happens. The tested versions of clients
are WIN 2012, WIN 2016 and WIN 2008 R2 all behave like this, when mapping drives to the NETAPP from another windows client within the domain.
I hope to be able to test on another AD in the near future to see if this is specific to this one AD Domain's confiiguration and policies or a version level behaviour.
Any other comments very welcome.