topic Re: AD to NETAPP Differences 8.2 to 9.1 in ONTAP Discussions

AD to NETAPP Differences 8.2 to 9.1

parkea2 — Wed, 04 Jun 2025 15:04:07 GMT

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

Re: AD to NETAPP Differences 8.2 to 9.1

robinpeter — Thu, 18 May 2017 16:17:07 GMT

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.

Re: AD to NETAPP Differences 8.2 to 9.1

parkea2 — Thu, 18 May 2017 18:38:43 GMT

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.