If you’re having issues on a UNIX security style qtree with Windows users, you have two main issues that come up:

• Name mapping is incorrect
• UNIX permissions are incorrect

When a Windows user wants to access a UNIX security style object, ONTAP wants the user to authenticate and map to a valid UNIX user. That’s how ONTAP and the file system determine if you have permissions to the object or not.

For example, a qtree is owned by prof1, with a group of ProfGroup. The UNIX permissions are 770.

That means:

• Prof1 has full control
• ProfGroup has full control
• Everyone else is denied access

The only way any user can get access to the qtree is if they authenticate as prof1 or they are a member of ProfGroup.

If a Windows user named “student1” tries to access the qtree, the following happens:

• ONTAP tries to map student1 using 1:1 implicit name mapping. This means it will look in its ns-switch (files, nis or ldap) for a valid UNIX user named “student1”
• If no UNIX user named student1 exists, ONTAP tries name mapping rules
• If no name mapping rules exist, ONTAP falls back to the default UNIX user (by default, it’s pcuser which is uid 65534)

One the most common issues I see involve Windows users writing files as 65534 when admins expect the files to be written as the UNIX user name. However, if ONTAP can’t find the UNIX user, it doesn’t just pretend the user exists; that would be a security issue.

In most cases, 65534 isn’t a user that gets assigned to UNIX permissions and usually doesn’t belong in a group. On most UNIX clients, 65534 is considered the anon user named “nfsnobody,” which is a user that compares similarly to Windows guest users.

In the qtree above, if my Windows account maps to pcuser, I get denied access because pcuser falls into the “Everyone” mode bit, which gets 0 access.

I can verify who my Windows user is mapping as, as well as what groups ONTAP thinks it belongs to with the following diag level command:

::*> diag secd authentication show-creds -node node1 -vserver SVM -win-name student1 -list-name true -list-id true

When I run that command, I get output that looks like this:

That will tell you a few things:

• Is my Windows user mapping to the desired user? (yes)
• What is that UNIX user’s numeric ID? (1301)
• Does that Windows user belong to the desired UNIX groups? (ProfGroup? No)

You can compare that to the file or qtree permissions with the following command:

::*> vserver security file-directory show -vserver DEMO -path /shared/unix

                Vserver: DEMO

              File Path: /shared/unix

      File Inode Number: 20034

         Security Style: unix

        Effective Style: unix

         DOS Attributes: 10

DOS Attributes in Text: ----D---

Expanded Dos Attributes: -

           UNIX User Id: 1100

          UNIX Group Id: 1101

         UNIX Mode Bits: 770

UNIX Mode Bits in Text: rwxrwx---

                   ACLs: NFSV4 Security Descriptor

                         Control:0x8014

                         DACL - ACEs

                           ALLOW-OWNER@-0x1601ff

                           ALLOW-user-prof1-0x1601ff

                           ALLOW-GROUP@-0x1201ff-IG

                           ALLOW-EVERYONE@-0x120080

We can translate the UNIX owner and group with:

ontap9-tme-8040::*> diag secd authentication translate -node ontap9-tme-8040-02 -vserver DEMO -uid 1100

prof1

ontap9-tme-8040::*> diag secd authentication translate -node ontap9-tme-8040-02 -vserver DEMO -gid 1101

ProfGroup

That means, to get access, student1 would need to be a member of ProfGroup, which he/she is not.

To solve your problem, you need to:

• Figure out what UNIX user ONTAP thinks your Windows user maps to
  • If it’s the wrong user, fix the mapping/name service issue
• If the user is correct, figure out if the user truly is supposed to have access
  • Are they the owner?
  • Does ONTAP think they belong to the group?
  • Does “everyone” have any access?

Hope this helps.

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Martin Sandell
Sent: Wednesday, December 20, 2017 2:24 AM
To: toasters@teaparty.net
Subject: Windows access issues on cifs for a both linux adn windows qtree.

Hello all smart people.

Hopefully someone has the answer on how to solve this, because I’m out of ideas….

We have a volume with on qtree that our customer is mounting on both Linux and Windows. Qtree sec. style is unix, and the unix parts work without issue, the problems are on windows.

After implementing a vserver name mapping and creating a few unix users and groups they can now access things based on the unix owner. But it seems no matter what I try so far, I can’t seem to solve how to fix so they can access based on group membership. All I get during my tests are “Access Denied”.

I have:

• Added the group to the Netapp as a local unix group
• Added a name mapping I the veserver from the windows group to the unix group. That is direction unix-win and the windows domain group some_group to some (the same name minus _group)
• Added the group on the cifs share with its correct windows name and the permission full control

If someone knows how to solve this or has seen it before, please help!

The Netapp system is a clustred ONTAP 9.1P2.

Martin Sandell

Storage Systems Consultant Basefarm

BASEFARM | Sveavägen 159 | 113 46 Stockholm | Sweden

Phone: +46 8 5011 26 82 | Mobile: +46 735 260 082

Martin.sandell@basefarm.com | www.basefarm.com 

Blog | Twitter | Facebook | LinkedIn