User manipulation fails on vfiler

[heyfisch]

Hi,

while adding users on the root filer works fine, I have problems doing the same thing on the vfiler. WFA/PoSh comes back with a group error.

root Filer - all cool:

PS C:\Program Files\NetApp\WFA> New-NaUser -User wfa -Password mrgl0815  -Comment "wfa test" -Groups administrators

Name                 Comment                                  Groups

----                 -------                                  ------

wfa                  wfa test                                 {Administrators}

vFiler - strange group error:

PS C:\Program Files\NetApp\WFA> New-NaUser -User wfa -Password mrgl0815  -Comment "wfa test" -Groups administrators

New-NaUser : Could not add user <wfa>. Error: User cannot access group(s)

At line:1 char:11

+ New-NaUser <<<<  -User wfa -Password mrgl0815 -Comment "wfa test" -Groups administrators

    + CategoryInfo          : InvalidOperation: (itana09.muc:NaController) [New-NaUser], EINTERNALERROR

    + FullyQualifiedErrorId : ApiException,DataONTAP.PowerShell.SDK.Cmdlets.Useradmin.NewNaUser

Same thing happens, when creating the user without a group and trying to add the user to a group afterwords.

Any ideas?

Thx and rgds,

Dieter

[bdave]

My guess would be that the vfiler doesn't know about the administrators group.  Can you try adding the administrators group to the vfiler then re-run the new-nauser cmdlet?

New-NaGroup -Group administrators -Roles admin

Or, start with verifying whether the administrators group exists.

Get-NaGroup -GetCapabilities

Hope this helps,

Dave

[goodrum · Accepted solution]

The issue is that the vFiler command doesn't support adding the group when executed against the context of the vFiler.  This means that you need to use a two fold step to set the group for a new vFiler user.  Below is a code snippet from a command that I will soon publish called - Prepare System for Cifs.  In this case, we are either setting up Cifs on the vFiler0 or vFiler context and depending on the variable set, the appropriate selection is made.  The issue is with the PoSH cmdlet and not WFA or the syntax.  Hope this helps!

--SNIPPET CODE--

# Create Built-In Administrator Account

$userExists = Get-NAUser

if($builtin_admin -and !($userExists.name -contains "administrator"))

  {

    if(!$VfilerName)

    {

        Get-WFALogger -Info -message $("Setup CIFS Local Administrator account")

        New-NaUser Administrator $builtin_admin Administrators

    } else

    {

        $addAdmin = "vfiler run " + $VfilerName + " useradmin user modify administrator -g Administrators"

        Get-WFALogger -Info -message $("Setup CIFS Local Administrator account")

        New-NaUser Administrator $builtin_admin

        Invoke-NaSSH $addAdmin

    }

  }

########################

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com

[heyfisch]

Hi Jeremy,

invoke-nassh works fine for me! I was close to go totally crazy about this. As I can see in your discussion with J the problem is not an easy one.

Thx so far,

Dieter

[jshelton]

I think Jeremy is close to being right here. I've been fighting a similar issue with adding a new user to one of the built-in groups through the API recently, but my experience has been a bit different. When I utilize the API calls to create the new user through vFiler tunneling while using a created administrator account on vFiler0, I receive the same message as shown by Dieter. However, if I use the actual root account of vFiler0 to perform the exact same API call, it executes perfectly every time. So, I'm of the current opinion that there is an API bug or undocumented requirement of using a "real" root account for iterating the groups of a vFiler. Once I learn the answer...I'll make sure to update this discussion.

[goodrum]

I know the issue that you are seeing and it is different than the Dieter's use case and the issue that I saw.  The PoSH cmdlet has the option to add the vFiler context to the Array connection option.  The issue that I found with the PoSH cmdlet is that the New-NaUser cmdlet does not have support to associate the user to a specific group.  When not specifying the group, the cmdlet works perfectly.  I only use the Array root account and not a different account.  I have seen weird behavior when not using the root account with WFA but that was only with vFilers.

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com

[jshelton]

Well, not to step on toes or anything, but I have extensive PowerShell experience especially in conjunction with multistore and in secure multi-tenant environments and this description just doesn't jive with my experience.

I personally haven't had any issues passing the group parameter to the New-NaUser commandlet at any time. But I did do a quick experiment tonight, just to verify that my suspicions were true, and I was certainly able to confirm my thoughts. Those thoughts being that the New-NaUser commandlet behaves when using vFiler tunneling exactly as any call made to the Ontapi useradmin-user-add API call behaves when using tunneling. To demonstrate that this is the case, I made a quick screen capture demonstrating such behavior:

https://www.dropbox.com/s/kmlud688ygqkjza/NewUserCreationInAVfiler.mov

In the video, I show a vFiler running in an 8.1 simulator. This vFiler has only the root user created inside it at the time. On vFiler0, I show several users created, including one assigned to the root group and a root role granting all permissions. I go on to show that I capture two connections to the vFiler, one utilizing the root account from vFiler0 and another using the created user account that has root privileges. I then demonstrate how I can create a new "TestUser" in the built-in Users group of the vFiler without issue while utilizing the "true" root connection, but the same commandlet fails when used with the non-"true root" account with the exact same API return string as seen by Dieter and myself in other areas.

So...long story short... Until proven otherwise, I'm of the opinion that Dieter's issue is not a failure of the commandlet, a failure of WFA, or any type of user issue, but more so is a fundamental issue with the underlying Ontapi interaction between the useradmin-user-add API call and vFilers. It's certainly not documented that this is the way that the call should function, so perhaps it is a documentation failure instead of a true bug. My money is on that this is not intended behavior however, as I can execute almost any other API call that supports vFiler tunneling using a similarly permissioned non-root account without issue.

To further expound on this issue, I also tested against vFiler0 using the same two accounts (the "real" root account, and an account with all permissions). In this test, you'll see that when ran against the vFiler0 context or root controller, there is no issue creating a new user when using either set of credentials...

https://www.dropbox.com/s/6wv5v07lk1lxdhp/NewUserCreationInVfiler0.mov

[goodrum]

No toe stepping and no worries.  There are two issues that I have seen in the past and I think that I have munged them into one small comment.  In doing so, I failed to explain my thoughts entirely.  So about a year ago, I was doing some initial testing of the Cifs Setup command that I released in the first Pirate Pack for NAS.  When I released this version of the command, I had a customer have some issues due to use the use of a non-Root account on the physical Filer context (vFiler0).  Through some testing and research, I found others had the same issue and the customer made a modification to the command and it worked for him. (https://communities.netapp.com/docs/DOC-14074). 

I also ran into an issue where I was testing the command on different versions of ONTAP and found that the API wasn't available at that time for some versions of Data ONTAP (I am still looking for my notes).  In this case, I found that only some of the later versions of DOT actually supported fully the API into the vFiler context.  This is part of the reason that I made the change to the overall command.  As a way of preventing failure due to a) DOT version or b) security context.  Like I said in my earlier post, I have seen some issues when using a non-root account and working with a vFiler.

I would agree that there does seem to be a disconnect with the Ontapi capabilities of a root account and a non-built in root level account (that is a mouthful) with regards to the context of a vFiler0 or a child vFiler.  Either way, the workaround that I provided will work and solve for both use cases. 

Great Video btw

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com

[jshelton]

Thanks! I won't be entering into the world of broadcasting anytime soon with my hick accent, but I try! 🙂 

Well...from an API perspective the minimum API version that supports vFiler tunneling is 1.7 I believe. And you're right, falling back to a non-interactive SSH session will also work with either type of user account, but the API call that underlies the New-NaUser command does exhibit this bug. And thanks to one of our esteemed colleagues from Japan, Hideki Masu, it is confirmed that this is related to a documented BURT #642918. According to the BURT, the behavior is expected to be corrected in 7.3.7P1D6, 8.1.3, and 8.2.1

So...the ways to get around it for now:

1.) Use the vFiler0 root account to tunnel to the vFiler in question and add the new user

2.) Use Jeremy's solution of utilizing non-interactive SSH to execute the command

3.) Use a connection made to an IP owned by the vFiler along with the credentials from an account inside the vFiler to create the new user

All three will work until the "real" fix comes out in a future version of DataONTAP.

Message was edited by: James Shelton (***deleted the vFiler API table***)

[arndt]

Is this just an issue with builtin groups?  I was able to write a WFA command that could succesfully add a new role, new group, and new user to a vfiler, with the user properly associated to the new group, the group properly associated to the new role, etc.  Thoughts?

[arndt]

Not sure what is different in my lab, but now I am hitting this problem when trying it in my customer's lab.  So, I went with using vfiler run commands via SSH in my WFA command, and that is working.

[hill]

What version of ONTAP is in your customer's lab?  I ask because on various versions of DOT 8.0.x... certain vFiler API's were missing...  The only options are to upgrade to a newer version of DOT, or... use the SSH commands as you have done.

Hope this helps,

Kevin.