SolidFire PowerShell Discussions

Highlighted

New-NcSecurityTraceFilter bug on WindowsName vs UnixName (they are inversed)

Hello,

There seems to be bug with the sectrace cmdlet "New-NcSecurityTraceFilter".

 

When creating a new filter with a "WindowsName" the specified WindowsName is passed as "UnixName".

 

See here:

secfilterbug1.png

 

And UnixName is submitted as WindowsName:

secfilterbug2.png

Kind regards,

Didier

3 REPLIES 3
Highlighted

Re: New-NcSecurityTraceFilter bug on WindowsName vs UnixName (they are inversed)

Hmm...in my test environment (PSTK 9.6, ONTAP 9.5P8) it actually appears that the cmdlet runs as expected, but the data returned is incorrect (both in the results output of the "New-NcSecurityTraceFilter" cmdlet as well as the "Get-NcSecurityTraceFilter" cmdlet) . Here's what it looked like when I tested it:

 

New-NcSecurityTraceFilter -Index 1 -Path /testpath -VserverContext lab-vserver-01 -WindowsName DOMAIN\test

Path Index IsEnabled ClientIp WindowsName UnixName Vserver ---- ----- --------- -------- ----------- -------- ------- /testpath 1 True DOMAIN\test lab-vserver-01

However, if you actually run the "vserver security trace filter show" command, you see that the filter was created properly: 

 

lab-clst-01::> vserver security trace filter show
Vserver  Index Client-IP    Path          Trace-Allow Windows-Name Protocol
-------- ----- ------------ ------------- ----------- ------------ --------
lab-vserver-01  1     -            /testpath      no          DOMAIN\test      cifs

Can you confirm that the behavior is the same for your environment? 

 

 

 

 

Highlighted

Re: New-NcSecurityTraceFilter bug on WindowsName vs UnixName (they are inversed)

Aha! Went down a rabbit hole and found the issue. If you run:

 

PS H:\> $filter = Get-NcSecurityTraceFilter
PS H:\> $filter.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    SecurityTraceFilterAttributes            NetApp.Ontapi.NaSerializable

 

You can see it has a PS data type of "SecurityTraceFilterAttributes" (you can also see this in longer from in the source code of the function itself by de-compiling the DataONTAP.C.dll file inside of the PSTK module directory, but gettype() is quicker. Smiley Happy )

 

Since it looks like it's a formatting bug, I checked out the "DataONTAP.C.Format.ps1xml" file in the module directory and searched for "SecurityTraceFilterAttributes" and found this:

 

    <View>
      <Name>SecurityTraceFilter_table</Name>
      <ViewSelectedBy>
        <TypeName>DataONTAP.C.Types.Sectrace.SecurityTraceFilterAttributes</TypeName>
      </ViewSelectedBy>
      <TableControl>
        <TableHeaders>
          <TableColumnHeader>
            <Label>Path</Label>
            <Width>35</Width>
            <Alignment>Left</Alignment>
          </TableColumnHeader>
          <TableColumnHeader>
            <Label>Index</Label>
            <Width>6</Width>
            <Alignment>Right</Alignment>
          </TableColumnHeader>
          <TableColumnHeader>
            <Label>IsEnabled</Label>
            <Width>10</Width>
            <Alignment>Center</Alignment>
          </TableColumnHeader>
          <TableColumnHeader>
            <Label>ClientIp</Label>
            <Width>16</Width>
            <Alignment>Left</Alignment>
          </TableColumnHeader>
          <TableColumnHeader>
            <Label>WindowsName</Label>
            <Width>18</Width>
            <Alignment>Left</Alignment>
          </TableColumnHeader>
          <TableColumnHeader>
            <Label>UnixName</Label>
            <Width>18</Width>
            <Alignment>Left</Alignment>
          </TableColumnHeader>
          <TableColumnHeader>
            <Label>Vserver</Label>
            <Alignment>Left</Alignment>
          </TableColumnHeader>
        </TableHeaders>
        <TableRowEntries>
          <TableRowEntry>
            <TableColumnItems>
              <TableColumnItem>
                <PropertyName>Path</PropertyName>
              </TableColumnItem>
              <TableColumnItem>
                <PropertyName>Index</PropertyName>
              </TableColumnItem>
              <TableColumnItem>
                <PropertyName>IsEnabled</PropertyName>
              </TableColumnItem>
              <TableColumnItem>
                <PropertyName>ClientIp</PropertyName>
              </TableColumnItem>
              <TableColumnItem>
                <PropertyName>UnixName</PropertyName>
              </TableColumnItem>
              <TableColumnItem>
                <PropertyName>WindowsName</PropertyName>
              </TableColumnItem>
              <TableColumnItem>
                <PropertyName>Vserver</PropertyName>
              </TableColumnItem>
            </TableColumnItems>
          </TableRowEntry>
        </TableRowEntries>
      </TableControl>
    </View>
    <View>

Long story short, lines 10751 and 10754 are inverted - if you change 10751 to "WindowsName" and 10754 to "UnixName" and reload the module, it will fix the issue for your environment. Hopefully the PSTK developers are watching and can fix it in future versions of the module. 

 

 

 

View solution in original post

Highlighted

Re: New-NcSecurityTraceFilter bug on WindowsName vs UnixName (they are inversed)

Hello,

Excellent ... perfect, yes that works!

Thanks a lot!

Didier

Check out the KB!
NetApp Insights To Action
All Community Forums