ONTAP Discussions

AD to NETAPP Differences 8.2 to 9.1

parkea2
3,530 Views

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 fred@my.domain 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.

 

Rgds Andy

 

2 REPLIES 2

robinpeter
3,506 Views

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.

parkea2
3,473 Views

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\aparker

Enter 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
  SeChangeNotifyPrivilege
Authentication 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.

 

aparker   OK

FRLAB\aparker  FAIL

 

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.

 

Public