Authentication & Authorization in CIFS - Ask The Expert - 7/16 to 7/30!

[RajeshPanda]

Click Here to post your questions

Ask the Expert Session – CIFS 

Grab the opportunity to learn from our Expert and bridge your Knowledge gap. 

Our CIFS Expert will answer your questions and help you solve your issues.

Topic: Authentication & Authorization in CIFS

Date: July 16 – 30

Expert: Vijay Ramamurthy

Vjiay is an Escalation Engineer with the NAS team.

His 10 years of experience in Information Technology has been with Data Storage.

He is with NetApp for 3 years and has strong domain knowledge in CIFS, NFS, and TCP/IP networking focus areas.

Note:

• Ask questions only related to the above topic.
• You can expect a response to your questions within 24 hours.

[AlexDawson]

Hi @RajeshPanda - our valued partner @VARONISSYSTEMS has a great question in this thread - https://community.netapp.com/t5/Data-ONTAP-Discussions/What-are-the-security-checks-that-cifs-superuser-privileges-allow-Data-ONTAP-to/m-p/141492#M313... - are you able to answer?

[AlexDawson]

Our valued partner @VARONISSYSTEMS has a great question in this thread - https://community.netapp.com/t5/Data-ONTAP-Discussions/What-are-the-security-checks-that-cifs-superuser-privileges-allow-Data-ONTAP-to/m-p/141492#M313... - are you able to answer?

[Vijay_ramamurthy]

Hi Alex,

For example:
1. I have UserA that member in the local Administrators group.
2. I have UserB that not a member of any local group but has superuser assignment.
3. I have a folder which has not direct permission or ownership for any of that users.
4. I would like to change the ACLs acting as one of those users at a time.

What will I need to do?
1. In case UserA is it, I will need first to make my self an owner and then change the permissions otherwise will get access denied?
That is correct. If the permissions on the file or object doesn't allow userA to change permission then user first needs take ownership of the folder/file and then set the DACL permissions. As the user is a member of BUILTIN\Administrators he will have the "SeTakeOwnershipPrivilege" privilege which will allow him to take ownership.
Any user who is a member of BUILTIN\Administrators will get privilege "SeTakeOwnershipPrivilege". This privilege is required to take ownership of an object without being granted discretionary access.
SeTakeOwnershipPrivilege:- User Right: Take ownership of files or other objects.

Below are the privileges that a BUILTIN\Administrator and "Domain Admins" get by default from ONTAP:
Privileges (0x22b7):
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege <<<<
SeSecurityPrivilege
SeChangeNotifyPrivilege

2. In the case of UserB, the change permission will take effect without any prior action?
That is correct. If UserB is created as a cifs superuser in ONTAP , this user will be able to change permission without any prior action.
From what i observed in LAB testing is the cifs superuser will bypass the DACL checks and will be granted access.

[AlexDawson]

Thanks Vijay!

 @VARONISSYSTEMS - does this answer your questions?

[bkamil]

Hi,

Does ONTAP 9 support CIFS authentication with a non-Microsoft LDAP, like OpenLDAP or Red Hat Directory Server?
I couldn't find any documentation on that.

We have a project that needs to maintain their own set of users and groups. They're setting up their own LDAP server on a Linux system. The requirement is to access the data from NetApp NAS using both protocols - NFS and CIFS - and having the NAS taking care of user mapping, etc.

Kamil

[Vijay_ramamurthy]

In 7-mode, there are 4 types of authentication style supported for CIFS such as: "ad" Active Directory, "nt4" Windows NT4, "workgroup" Workgroup and "passwd" Password file, NIS or LDAP.
In C-mode only active directory and Workgroup authentication are supported.

So there is no support for authentication of CIFS users using Openldap or non-microsoft LDAP in Cluster Data ONTAP.

How ONTAP handles SMB client authentication ?
Before users can create SMB connections to access data contained on the SVM, they must be authenticated by the domain to which the CIFS server belongs. The CIFS server supports two
authentication methods, Kerberos and NTLM (NTLMv1 or NTLMv2). Kerberos is the default method used to authenticate domain users.

Also Multi protocol is supported in ONTAP. So both windows and unix users can access the same volume.

User-mapping rules can also be defined locally in NetApp. 

I dont see any challenges with your requirement. 

[bkamil]

Thank you Vijay.

But the challenge is still there, unless I misunderstood something.
How to allow CIFS clients to access the data if we don't want to / cannot use Active Directory, but other LDAP for authentication?

You already confirmed cDOT does not support non-AD LDAPs for CIFS.

Looks like in cDOT we're missing the feature that was available in 7-mode and would be a perfect fit for my case.

Same data needs to be accessible by unix clients via NFS - auth with the same LDAP - but that part should be easy.

[Vijay_ramamurthy]

Welcome Bkamil,

Windows domain users reside in Active Directory and Kerberos is the default authentication protocol used by Active Directory for authenticating a user.
Also Kerberos is the most secure way of authenticating an user.

CIFS clients who connect to NetApp are authenticated via Kerberos or NTLM in Cluster Data ONTAP.

More details on the authentication can be found below :

How ONTAP handles SMB client authentication
http://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.cdot-famg-nfs%2FGUID-AA67607D-30F8-484C-A8D3-F0CA842465BB.html

How ONTAP handles NFS client authentication
http://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.cdot-famg-nfs%2FGUID-AA67607D-30F8-484C-A8D3-F0CA842465BB.html

In an NFS context, authentication is done by the client not the server.
CIFS authentication is the server’s responsibility.

In multi-protocol environment, CIFS users can access UNIX and NTFS security style volume and also NFS users can access UNIX and NTFS security style volumes. This can be accomplished with the help of name-mapping and configuring the directory store for the Unix users.

Could you let me know if the CIFS users you are referring to, are they Windows domain users ?

I still don't understand the requirement of using openLDAP to authenticate CIFS users as the domain users reside in AD and not in openLDAP.

[bkamil]

---

@Vijay_ramamurthy wrote:
[...]

Could you let me know if the CIFS users you are referring to, are they Windows domain users ?

I still don't understand the requirement of using openLDAP to authenticate CIFS users as the domain users reside in AD and not in openLDAP.

---

That's exactly the problem - users are not meant to be domain users, but only defined in OpenLDAP.

[Vijay_ramamurthy]

If these users reside in openLDAP then these users are UNIX users.

With multiprotocol configured , NFS users can access NTFS volumes.

Do these users connect via NFS or CIFS to access the volume ?

[bkamil]

The idea is to have:
- An OpenLDAP server where users and groups are defined,

- A volume on the NAS shared via both protocols, CIFS and NFS

- Volume would have NTFS security style so that CIFS client can set NTFS permissions based on users and groups defined in LDAP

- Permissions set by the CIFS client would also be in effect for NFS clients (user and permission mapping)

[Vijay_ramamurthy]

This should work fine.
1) Create a CIFS server on the SVM
2) Create volume and set security style as NTFS. Also create a CIFS shares and set the ACL.
3) Create a LDAP client configuration for the SVM using the LDAP schema.
4) Modify ns-switch files for user and passwd to point to files and LDAP.
5) Create a name-mapping rules locally.
6) Create export rules for the NFS client.

Now when unix user tries to access the export, he will be mapped to windows user based on the name-mapping rules.
After the unix->windows user mapping is over , the unix user will get the permissions accordingly on what is allowed for the mapped windows user.

[bkamil]

---

@Vijay_ramamurthy wrote:

This should work fine.
1) Create a CIFS server on the SVM

[...]

---

... and join Microsoft AD domain, you mean?

That's exactly what what we cannot do and need to use OpenLDAP instead 🙂

I'm not sure where the confusion comes from here.

The question is: can we have a CIFS server with LDAP authentication, without joining Microsft AD domain?

If the answer is "No, the only LDAP supported by CIFS server in ONTAP 9 is Microsoft one" that's fine.

[Vijay_ramamurthy]

That is correct. We cannot create a CIFS server using LDAP authentication. It is not possible in ONTAP 9. 

[ASH2017]

Hi Experts,

Could you please help in understanding what this error is pointing to.

This is a log from Security Daemon [SecD] from ONTAP 9.1, event log is recording these errors on day-2-day basis.

The erorr says very clear : FAILURE: CIFS authentication failed, is it the passsword with which CIFS server is joined to the AD ? It says - SMB_PASSWORD_MUST_CHANGE: Is it the AD password ?

ERROR:

RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in getFailureCode() at src/utils/secd_thread_task_journal.cpp:348

Security Daemon [secD log from cDOT 9.1]
+++++++++++++++++++++++++++++++++++++++++++++

00000012.00209282 0fea2360 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] CIFS SMB2 Share mapping - Client Ip = 10.x.x.x
00000012.00209283 0fea2360 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] [ 0 ms] Login attempt by domain user 'Dxxx\Administrator' using NTLMv1 style security
00000012.00209284 0fea2360 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] [ 1] Successfully connected to ip 10.x,x,x, port 445 using TCP
00000012.00209285 0fea2360 Fri Jul 20 2018 08:38:09 7 +01:00 [kern_secd:info:5480] [ 7] Successfully authenticated with DC

00000012.0020e41d 0ff356d5 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] | [000.015.336] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in handleAuthenticateMsg() at src/NtlmsspCtx.cpp:912
00000012.0020e41e 0ff356d5 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] | [000.015.344] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in acceptContext() at src/NtlmsspCtx.cpp:296
00000012.0020e41f 0ff356d5 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] | [000.015.352] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in acceptContext() at src/SpnegoCtx.cpp:244
00000012.0020e420 0ff356d5 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] | [000.015.361] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in secd_rpc_auth_extended_1_svc() at src/authentication/secd_rpc_auth.cpp:1168
00000012.0020e421 0ff356d5 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] | [000.015.372] ERR : CIFS authentication failed { in secd_rpc_auth_extended_1_svc() at src/authentication/secd_rpc_auth.cpp:1196 }
00000012.0020e422 0ff356d5 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] | [000.015.389] debug: SecD RPC Server sending reply to RPC 151: secd_rpc_auth_extended { in secdSendRpcResponse() at src/server/secd_rpc_server.cpp:1888 }
00000012.0020e423 0ff356d5 Fri Jul 20 2018 08:38:09 +01:00 [kern_secd:info:5480] | [000.015.564] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in getFailureCode() at src/utils/secd_thread_task_journal.cpp:348

00000012.00209287 0fea2360 Thu Jul 19 2018 15:53:07 +01:00 [kern_secd:info:5480] [ 9] Login attempt by local user 'Dxxxx\Administrator' using NTLMv1 style security
00000012.00209288 0fea2360 Thu Jul 19 2018 15:53:07 +01:00 [kern_secd:info:5480] **[ 10] FAILURE: CIFS authentication failed

++++++++++++++++++++++++++++++++++++++++++++++++++++++

Thanks,

-AP

[Vijay_ramamurthy]

I might need the full SECD log and also an ASUP to check the cause for the error "RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335" seen in SECD logs.
I would recommend to open a support ticket for troubleshooting this problem.

[ASH2017]

Thanks for your time. Case is already logged : 2007497995, but it's progressing slowly. I will send you the complete log shortly.

[Vijay_ramamurthy]

I did a review of ASUP and noticed , the error "RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 " seem to be because DC failed the authentication attempt for the user 'Dxxx\Administrator'

User trying to access : 'Dxxx\Administrator' <<<<? local workstation user ? different domain ?

NT status : 0xc0000064 :- STATUS_NO_SUCH_USER :- The specified account does not exist.

secd:
00000012.0015ee70 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.009.890] debug: Attempting pass-through auth with DC MDC4. { in doAuthenticateWithDC() at src/authentication/secd_seclibglue.cpp:1077 }
00000012.0015ee71 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.419] info : Authentication failed with DC MDC4. Not retriable. (Status: 0xc0000064) { in doAuthenticateWithDC() at src/authentication/secd_seclibglue.cpp:1103 }
00000012.0015ee72 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.535] info : Login attempt by local user 'Dxxx\Administrator' using NTLMv1 style security
00000012.0015ee73 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.599] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in getLocalUserHash() at src/authentication/secd_seclibglue.cpp:943
00000012.0015ee74 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.610] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in doLocalUserAuth() at src/NtlmsspCtx.cpp:989
00000012.0015ee75 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.617] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in handleAuthenticateMsg() at src/NtlmsspCtx.cpp:912
00000012.0015ee76 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.625] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in acceptContext() at src/NtlmsspCtx.cpp:296
00000012.0015ee77 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.632] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in acceptContext() at src/SpnegoCtx.cpp:244
00000012.0015ee78 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.640] ERR : RESULT_ERROR_CIFS_SMB_PASSWORD_MUST_CHANGE:335 in secd_rpc_auth_extended_1_svc() at src/authentication/secd_rpc_auth.cpp:1168
00000012.0015ee79 0f017550 Mon Jul 02 2018 00:17:31 +01:00 [kern_secd:info:5480] | [000.010.650] ERR : CIFS authentication failed { in secd_rpc_auth_extended_1_svc() at src/authentication/secd_rpc_auth.cpp:1196 }

This error is seen either because the user is from a different domain which doesn't have any trust relation with domain where CIFS server is created or this user is a local workstation user and is not a domain user.

This error should not be seen when we try using a user from same domain or trusted domain of the domain where the CIFS server is present.

[Netapp4u]

How to create local authentication for CIFS in 7 mode.