NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Ray Van Dolson-3
Have an NTFS volume being shared out via NFSV3.  SVM is part of AD and
NIS.

When an NIS-joined client lists directories under the export,
everything seems to be mapped to UID 65534.  I'm able to validate this:

::*> vserver security file-directory show -vserver file_ntfs -path /setup-staging/raytest_windows

                Vserver: file_ntfs
              File Path: /setup-staging/raytest_windows
      File Inode Number: 1317151
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
 DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
           UNIX User Id: 65534
          UNIX Group Id: 65534
         UNIX Mode Bits: 777
 UNIX Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x8004
                         Owner:DOMAIN\rvandolson
                         Group:DOMAIN\Domain Users
                         DACL - ACEs
                           ALLOW-Everyone-0x1f01ff-(Inherited)
                           ALLOW-Everyone-0x10000000-OI|CI|IO (Inherited)

However, the following makes me think the filer knows how to map AD
usernames to Unix (NIS) usernames just fine:

  ::*> diag secd name-mapping show -vserver file_ntfs -direction win-unix -name DOMAIN\rvandolson -node red-str-napcl-p03-02

  ATTENTION: Mapping of Data ONTAP "admin" users to UNIX user "root" is enabled, but the following information does not reflect this mapping.

  'DOMAIN\rvandolson' maps to 'rvandolson'

  ::*> diag secd authentication translate -node red-str-napcl-p03-02 -vserver file_ntfs -unix-user-name rvandolson
  580345

I don't have a default-win-user set:

  ::*> vserver nfs show -vserver file_ntfs -fields default-win-user
  vserver   default-win-user
  --------- ----------------
  file_ntfs

(but I think the default is 65534).

Shouldn't cDOT be returning 580345 for the UNIX User Id rather than
65534?  Seems to be the case on 7-mode...

Thanks!
Ray
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Tim McCarthy
Been a while, but I think your svm may be set up to check nis first, then ad. Since it finds the user in nis, it uses that.

I can't tell you the commands offhand, but you may want to check your name service resolution....

On Tue, Feb 14, 2017 at 6:59 PM Ray Van Dolson <[hidden email]> wrote:
Have an NTFS volume being shared out via NFSV3.  SVM is part of AD and
NIS.

When an NIS-joined client lists directories under the export,
everything seems to be mapped to UID 65534.  I'm able to validate this:

::*> vserver security file-directory show -vserver file_ntfs -path /setup-staging/raytest_windows

                Vserver: file_ntfs
              File Path: /setup-staging/raytest_windows
      File Inode Number: 1317151
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
 DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
           UNIX User Id: 65534
          UNIX Group Id: 65534
         UNIX Mode Bits: 777
 UNIX Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x8004
                         Owner:DOMAIN\rvandolson
                         Group:DOMAIN\Domain Users
                         DACL - ACEs
                           ALLOW-Everyone-0x1f01ff-(Inherited)
                           ALLOW-Everyone-0x10000000-OI|CI|IO (Inherited)

However, the following makes me think the filer knows how to map AD
usernames to Unix (NIS) usernames just fine:

  ::*> diag secd name-mapping show -vserver file_ntfs -direction win-unix -name DOMAIN\rvandolson -node red-str-napcl-p03-02

  ATTENTION: Mapping of Data ONTAP "admin" users to UNIX user "root" is enabled, but the following information does not reflect this mapping.

  'DOMAIN\rvandolson' maps to 'rvandolson'

  ::*> diag secd authentication translate -node red-str-napcl-p03-02 -vserver file_ntfs -unix-user-name rvandolson
  580345

I don't have a default-win-user set:

  ::*> vserver nfs show -vserver file_ntfs -fields default-win-user
  vserver   default-win-user
  --------- ----------------
  file_ntfs

(but I think the default is 65534).

Shouldn't cDOT be returning 580345 for the UNIX User Id rather than
65534?  Seems to be the case on 7-mode...

Thanks!
Ray
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
--
Sent from Gmail Mobile.

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Ray Van Dolson-3
On Wed, Feb 15, 2017 at 12:04:07AM +0000, tmac wrote:
> Been a while, but I think your svm may be set up to check nis first, then ad.
> Since it finds the user in nis, it uses that.
>
> I can't tell you the commands offhand, but you may want to check your name
> service resolution....

Thanks, I'll see if I can find something on that.  Via the GUI (I'm a
cDOT newb), I can see under the SVM Services tab that order preference
is files and then nis for 'passwd'.  So perhaps AD's role in all this
is defined elsewhere...

Ray
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

RE: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Parisi, Justin
In reply to this post by Ray Van Dolson-3
65534 is "pcuser" on a NetApp storage system. That's the user a Windows user gets mapped to when they write to a NTFS security style volume when they can't map to a specific user. It's the default UNIX user, not the default Windows user that's being leveraged.

Likely an issue with the name services. What does "name-service ns-switch show" give as the config?

What does "diag secd authentication show-creds -list-id true -list-name true" give for that user?

You could try enabling secd tracing to see what exactly happens during the requests, as well. (diag secd trace set -trace-all yes)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ray Van Dolson
Sent: Tuesday, February 14, 2017 3:56 PM
To: [hidden email]
Subject: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Have an NTFS volume being shared out via NFSV3.  SVM is part of AD and NIS.

When an NIS-joined client lists directories under the export, everything seems to be mapped to UID 65534.  I'm able to validate this:

::*> vserver security file-directory show -vserver file_ntfs -path /setup-staging/raytest_windows

                Vserver: file_ntfs
              File Path: /setup-staging/raytest_windows
      File Inode Number: 1317151
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
 DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
           UNIX User Id: 65534
          UNIX Group Id: 65534
         UNIX Mode Bits: 777
 UNIX Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x8004
                         Owner:DOMAIN\rvandolson
                         Group:DOMAIN\Domain Users
                         DACL - ACEs
                           ALLOW-Everyone-0x1f01ff-(Inherited)
                           ALLOW-Everyone-0x10000000-OI|CI|IO (Inherited)

However, the following makes me think the filer knows how to map AD usernames to Unix (NIS) usernames just fine:

  ::*> diag secd name-mapping show -vserver file_ntfs -direction win-unix -name DOMAIN\rvandolson -node red-str-napcl-p03-02

  ATTENTION: Mapping of Data ONTAP "admin" users to UNIX user "root" is enabled, but the following information does not reflect this mapping.

  'DOMAIN\rvandolson' maps to 'rvandolson'

  ::*> diag secd authentication translate -node red-str-napcl-p03-02 -vserver file_ntfs -unix-user-name rvandolson
  580345

I don't have a default-win-user set:

  ::*> vserver nfs show -vserver file_ntfs -fields default-win-user
  vserver   default-win-user
  --------- ----------------
  file_ntfs

(but I think the default is 65534).

Shouldn't cDOT be returning 580345 for the UNIX User Id rather than 65534?  Seems to be the case on 7-mode...

Thanks!
Ray
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Ray Van Dolson-3
On Wed, Feb 15, 2017 at 12:26:24AM +0000, Parisi, Justin wrote:
> 65534 is "pcuser" on a NetApp storage system. That's the user a
> Windows user gets mapped to when they write to a NTFS security style
> volume when they can't map to a specific user. It's the default UNIX
> user, not the default Windows user that's being leveraged.
>
> Likely an issue with the name services. What does "name-service
> ns-switch show" give as the config?

::*> name-service ns-switch show -vserver file_ntfs
  (vserver services name-service ns-switch show)
                               Source
Vserver         Database       Order
--------------- ------------   ---------
file_ntfs       hosts          files,
                               dns
file_ntfs       group          files,
                               nis
file_ntfs       passwd         files,
                               nis
file_ntfs       netgroup       files
file_ntfs       namemap        files
5 entries were displayed.

NOTE: I *just* changed group to include nis.

>
> What does "diag secd authentication show-creds -list-id true
> -list-name true" give for that user?

::*> diag secd authentication show-creds -list-id true -list-name true -node red-str-napcl-p03-02 -vserver file_ntfs -win-name DOMAIN\step

 UNIX UID: 1180 (step) <> Windows User: S-1-5-21-2050139532-2050374463-XXXXXXXXXX-2719 (DOMAIN\step (Windows Domain User))

 GID: 129 (micro)
 Supplementary GIDs:
  129  (micro)
  8001  (logs)
  0  (root)
  55  (lxadmin)
  14  (sysadmin)

 Windows Membership:
  <many groups listed>

 User is also a member of Everyone, Authenticated Users, and Network Users

 Privileges (0x2080):
  SeChangeNotifyPrivilege

I'll note here as well that the first time I ran this command, it
complained about being unable to look up the Unix GID.  This is when I
added nis to the services list for group above.

> You could try enabling secd tracing to see what exactly happens
> during the requests, as well. (diag secd trace set -trace-all yes)

I'll give this a try next.

Ray
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

RE: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Parisi, Justin
Yea, if the GID lookup fails it can fall back to 65534 in some cases.

-----Original Message-----
From: Ray Van Dolson [mailto:[hidden email]]
Sent: Tuesday, February 14, 2017 4:42 PM
To: Parisi, Justin <[hidden email]>
Cc: [hidden email]
Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

On Wed, Feb 15, 2017 at 12:26:24AM +0000, Parisi, Justin wrote:
> 65534 is "pcuser" on a NetApp storage system. That's the user a
> Windows user gets mapped to when they write to a NTFS security style
> volume when they can't map to a specific user. It's the default UNIX
> user, not the default Windows user that's being leveraged.
>
> Likely an issue with the name services. What does "name-service
> ns-switch show" give as the config?

::*> name-service ns-switch show -vserver file_ntfs
  (vserver services name-service ns-switch show)
                               Source
Vserver         Database       Order
--------------- ------------   ---------
file_ntfs       hosts          files,
                               dns
file_ntfs       group          files,
                               nis
file_ntfs       passwd         files,
                               nis
file_ntfs       netgroup       files
file_ntfs       namemap        files
5 entries were displayed.

NOTE: I *just* changed group to include nis.

>
> What does "diag secd authentication show-creds -list-id true
> -list-name true" give for that user?

::*> diag secd authentication show-creds -list-id true -list-name true -node red-str-napcl-p03-02 -vserver file_ntfs -win-name DOMAIN\step

 UNIX UID: 1180 (step) <> Windows User: S-1-5-21-2050139532-2050374463-XXXXXXXXXX-2719 (DOMAIN\step (Windows Domain User))

 GID: 129 (micro)
 Supplementary GIDs:
  129  (micro)
  8001  (logs)
  0  (root)
  55  (lxadmin)
  14  (sysadmin)

 Windows Membership:
  <many groups listed>

 User is also a member of Everyone, Authenticated Users, and Network Users

 Privileges (0x2080):
  SeChangeNotifyPrivilege

I'll note here as well that the first time I ran this command, it complained about being unable to look up the Unix GID.  This is when I added nis to the services list for group above.

> You could try enabling secd tracing to see what exactly happens during
> the requests, as well. (diag secd trace set -trace-all yes)

I'll give this a try next.

Ray

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Ray Van Dolson-3
Well, no joy yet.  The secd tracing didn't help too much as I'm not
really encountinger a permissions denied situation, just an enumeration
issue.

It *seems* like the NetApp is not handling the NTFS owner correctly.
What's weird is that if I go into a file from the Windows side and take
ownership of the account using *my* AD account, then the AD username ->
Unix UID works correctly and I see the expected username listed via
NFS.

What I'm struggling with now is getting it to let me change the owners
on all of the files to someone other than myself.  I keep getting an
error "You do not have the Restore privilege required".  I've added my
AD username to the BUILTIN\Administrators group on the SVM (I think!),
but still no joy.  Maybe I actually need to have a Domain Administrator
account do this, or try via whatever the cDOT equivalent of fsecurity
is (though my recollection is that that's kind of a PITA).

Ray

On Wed, Feb 15, 2017 at 12:43:42AM +0000, Parisi, Justin wrote:

> Yea, if the GID lookup fails it can fall back to 65534 in some cases.
>
> -----Original Message-----
> From: Ray Van Dolson [mailto:[hidden email]]
> Sent: Tuesday, February 14, 2017 4:42 PM
> To: Parisi, Justin <[hidden email]>
> Cc: [hidden email]
> Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534
>
> On Wed, Feb 15, 2017 at 12:26:24AM +0000, Parisi, Justin wrote:
> > 65534 is "pcuser" on a NetApp storage system. That's the user a
> > Windows user gets mapped to when they write to a NTFS security style
> > volume when they can't map to a specific user. It's the default UNIX
> > user, not the default Windows user that's being leveraged.
> >
> > Likely an issue with the name services. What does "name-service
> > ns-switch show" give as the config?
>
> ::*> name-service ns-switch show -vserver file_ntfs
>   (vserver services name-service ns-switch show)
>                                Source
> Vserver         Database       Order
> --------------- ------------   ---------
> file_ntfs       hosts          files,
>                                dns
> file_ntfs       group          files,
>                                nis
> file_ntfs       passwd         files,
>                                nis
> file_ntfs       netgroup       files
> file_ntfs       namemap        files
> 5 entries were displayed.
>
> NOTE: I *just* changed group to include nis.
>
> >
> > What does "diag secd authentication show-creds -list-id true
> > -list-name true" give for that user?
>
> ::*> diag secd authentication show-creds -list-id true -list-name true -node red-str-napcl-p03-02 -vserver file_ntfs -win-name DOMAIN\step
>
>  UNIX UID: 1180 (step) <> Windows User: S-1-5-21-2050139532-2050374463-XXXXXXXXXX-2719 (DOMAIN\step (Windows Domain User))
>
>  GID: 129 (micro)
>  Supplementary GIDs:
>   129  (micro)
>   8001  (logs)
>   0  (root)
>   55  (lxadmin)
>   14  (sysadmin)
>
>  Windows Membership:
>   <many groups listed>
>
>  User is also a member of Everyone, Authenticated Users, and Network Users
>
>  Privileges (0x2080):
>   SeChangeNotifyPrivilege
>
> I'll note here as well that the first time I ran this command, it complained about being unable to look up the Unix GID.  This is when I added nis to the services list for group above.
>
> > You could try enabling secd tracing to see what exactly happens during
> > the requests, as well. (diag secd trace set -trace-all yes)
>
> I'll give this a try next.
>
> Ray
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

RE: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Parisi, Justin
I cover the fsecurity equivalent a bit here:

https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-multiprotocol-nas/ 

It sounds like the issue might be UNIX -> Windows mapping rather than Windows -> UNIX.

Does this issue happen on files that get created from NFS only? Do the clients leverage LDAP/NIS?

SecD tracing should help us see who that user is coming in as and why it's mapping the way it is. It's more useful for authentication issues (like this) than authorization (permission) issues.

If you can unicast me the cluster SN so I can see the secd trace, I can have a look.


-----Original Message-----
From: Ray Van Dolson [mailto:[hidden email]]
Sent: Tuesday, February 14, 2017 7:16 PM
To: Parisi, Justin <[hidden email]>
Cc: [hidden email]
Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Well, no joy yet.  The secd tracing didn't help too much as I'm not really encountinger a permissions denied situation, just an enumeration issue.

It *seems* like the NetApp is not handling the NTFS owner correctly.
What's weird is that if I go into a file from the Windows side and take ownership of the account using *my* AD account, then the AD username -> Unix UID works correctly and I see the expected username listed via NFS.

What I'm struggling with now is getting it to let me change the owners on all of the files to someone other than myself.  I keep getting an error "You do not have the Restore privilege required".  I've added my AD username to the BUILTIN\Administrators group on the SVM (I think!), but still no joy.  Maybe I actually need to have a Domain Administrator account do this, or try via whatever the cDOT equivalent of fsecurity is (though my recollection is that that's kind of a PITA).

Ray

On Wed, Feb 15, 2017 at 12:43:42AM +0000, Parisi, Justin wrote:

> Yea, if the GID lookup fails it can fall back to 65534 in some cases.
>
> -----Original Message-----
> From: Ray Van Dolson [mailto:[hidden email]]
> Sent: Tuesday, February 14, 2017 4:42 PM
> To: Parisi, Justin <[hidden email]>
> Cc: [hidden email]
> Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting
> mapped to 65534
>
> On Wed, Feb 15, 2017 at 12:26:24AM +0000, Parisi, Justin wrote:
> > 65534 is "pcuser" on a NetApp storage system. That's the user a
> > Windows user gets mapped to when they write to a NTFS security style
> > volume when they can't map to a specific user. It's the default UNIX
> > user, not the default Windows user that's being leveraged.
> >
> > Likely an issue with the name services. What does "name-service
> > ns-switch show" give as the config?
>
> ::*> name-service ns-switch show -vserver file_ntfs
>   (vserver services name-service ns-switch show)
>                                Source
> Vserver         Database       Order
> --------------- ------------   ---------
> file_ntfs       hosts          files,
>                                dns
> file_ntfs       group          files,
>                                nis
> file_ntfs       passwd         files,
>                                nis
> file_ntfs       netgroup       files
> file_ntfs       namemap        files
> 5 entries were displayed.
>
> NOTE: I *just* changed group to include nis.
>
> >
> > What does "diag secd authentication show-creds -list-id true
> > -list-name true" give for that user?
>
> ::*> diag secd authentication show-creds -list-id true -list-name true
> -node red-str-napcl-p03-02 -vserver file_ntfs -win-name DOMAIN\step
>
>  UNIX UID: 1180 (step) <> Windows User:
> S-1-5-21-2050139532-2050374463-XXXXXXXXXX-2719 (DOMAIN\step (Windows
> Domain User))
>
>  GID: 129 (micro)
>  Supplementary GIDs:
>   129  (micro)
>   8001  (logs)
>   0  (root)
>   55  (lxadmin)
>   14  (sysadmin)
>
>  Windows Membership:
>   <many groups listed>
>
>  User is also a member of Everyone, Authenticated Users, and Network
> Users
>
>  Privileges (0x2080):
>   SeChangeNotifyPrivilege
>
> I'll note here as well that the first time I ran this command, it complained about being unable to look up the Unix GID.  This is when I added nis to the services list for group above.
>
> > You could try enabling secd tracing to see what exactly happens
> > during the requests, as well. (diag secd trace set -trace-all yes)
>
> I'll give this a try next.
>
> Ray

_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Ray Van Dolson-3
(Apologies for the URL mangling below -- darn Corporate email)

So, have found a workaround for this.  By explicitly changing the AD
owner on the file(s) in question (well, not really changing -- I just
re-set the owner explicitly to the owner which was already set),
something jogged in the NetApp's brain and it can now properly map the
owner to a valid UID.  As mentioned, this is bizarre, since the owner
is EXACTLY the same as it was originally and a comparison of the
vserver security file-directory show output before and after shows no
notable differences other than the expected Unix UID/GID's now
displayed.

So, these files were initially populated via a robocopy copy from
Windows.  I suspect something with the original syntax resulted in the
ACL being "off" enough to confuse cDOT.  I'll need to do some
additional testing on that, but have confirmed that if I use the /MIR
/SEC /COPY:DATO arguments to robocopy, the owner is preserved in such a
way that cDOT is able to properly map that owner to a Unix UID/GID.

Ray

On Wed, Feb 15, 2017 at 07:07:15PM +0000, Parisi, Justin wrote:

> I cover the fsecurity equivalent a bit here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__whyistheinternetbroken.wordpress.com_2017_01_24_mixed-2Dperceptions-2Dmultiprotocol-2Dnas_&d=DwIFAg&c=n6-cguzQvX_tUIrZOS_4Og&r=WoGou9bjN14EvLKS6DHxfMEG6f2_bRhXNpedbbFoYDk&m=s4PaKdj-_NUkc_ec1eveH2WdRjGE_m333D0Y2iD_vG0&s=1JMEtwOhwsYwPLMLM1Zx_syN-6uq68TcuLgLbIVtUEc&e= 
>
> It sounds like the issue might be UNIX -> Windows mapping rather than
> Windows -> UNIX.
>
> Does this issue happen on files that get created from NFS only? Do
> the clients leverage LDAP/NIS?
>
> SecD tracing should help us see who that user is coming in as and why
> it's mapping the way it is. It's more useful for authentication
> issues (like this) than authorization (permission) issues.
>
> If you can unicast me the cluster SN so I can see the secd trace, I
> can have a look.
>
>
> -----Original Message-----
> From: Ray Van Dolson [mailto:[hidden email]]
> Sent: Tuesday, February 14, 2017 7:16 PM
> To: Parisi, Justin <[hidden email]>
> Cc: [hidden email]
> Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534
>
> Well, no joy yet.  The secd tracing didn't help too much as I'm not
> really encountinger a permissions denied situation, just an
> enumeration issue.
>
> It *seems* like the NetApp is not handling the NTFS owner correctly.
> What's weird is that if I go into a file from the Windows side and
> take ownership of the account using *my* AD account, then the AD
> username -> Unix UID works correctly and I see the expected username
> listed via NFS.
>
> What I'm struggling with now is getting it to let me change the
> owners on all of the files to someone other than myself.  I keep
> getting an error "You do not have the Restore privilege required".
> I've added my AD username to the BUILTIN\Administrators group on the
> SVM (I think!), but still no joy.  Maybe I actually need to have a
> Domain Administrator account do this, or try via whatever the cDOT
> equivalent of fsecurity is (though my recollection is that that's
> kind of a PITA).
>
> Ray
>
> On Wed, Feb 15, 2017 at 12:43:42AM +0000, Parisi, Justin wrote:
> > Yea, if the GID lookup fails it can fall back to 65534 in some cases.
> >
> > -----Original Message-----
> > From: Ray Van Dolson [mailto:[hidden email]]
> > Sent: Tuesday, February 14, 2017 4:42 PM
> > To: Parisi, Justin <[hidden email]>
> > Cc: [hidden email]
> > Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting
> > mapped to 65534
> >
> > On Wed, Feb 15, 2017 at 12:26:24AM +0000, Parisi, Justin wrote:
> > > 65534 is "pcuser" on a NetApp storage system. That's the user a
> > > Windows user gets mapped to when they write to a NTFS security style
> > > volume when they can't map to a specific user. It's the default UNIX
> > > user, not the default Windows user that's being leveraged.
> > >
> > > Likely an issue with the name services. What does "name-service
> > > ns-switch show" give as the config?
> >
> > ::*> name-service ns-switch show -vserver file_ntfs
> >   (vserver services name-service ns-switch show)
> >                                Source
> > Vserver         Database       Order
> > --------------- ------------   ---------
> > file_ntfs       hosts          files,
> >                                dns
> > file_ntfs       group          files,
> >                                nis
> > file_ntfs       passwd         files,
> >                                nis
> > file_ntfs       netgroup       files
> > file_ntfs       namemap        files
> > 5 entries were displayed.
> >
> > NOTE: I *just* changed group to include nis.
> >
> > >
> > > What does "diag secd authentication show-creds -list-id true
> > > -list-name true" give for that user?
> >
> > ::*> diag secd authentication show-creds -list-id true -list-name true
> > -node red-str-napcl-p03-02 -vserver file_ntfs -win-name DOMAIN\step
> >
> >  UNIX UID: 1180 (step) <> Windows User:
> > S-1-5-21-2050139532-2050374463-XXXXXXXXXX-2719 (DOMAIN\step (Windows
> > Domain User))
> >
> >  GID: 129 (micro)
> >  Supplementary GIDs:
> >   129  (micro)
> >   8001  (logs)
> >   0  (root)
> >   55  (lxadmin)
> >   14  (sysadmin)
> >
> >  Windows Membership:
> >   <many groups listed>
> >
> >  User is also a member of Everyone, Authenticated Users, and Network
> > Users
> >
> >  Privileges (0x2080):
> >   SeChangeNotifyPrivilege
> >
> > I'll note here as well that the first time I ran this command, it
> > complained about being unable to look up the Unix GID.  This is
> > when I added nis to the services list for group above.
> >
> > > You could try enabling secd tracing to see what exactly happens
> > > during the requests, as well. (diag secd trace set -trace-all yes)
> >
> > I'll give this a try next.
> >
> > Ray
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|

Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting mapped to 65534

Parisi, Justin
Well, you might have also fixed something or a cache flushed between the
last time you ran it and now. :)

On 2/17/17, 10:59 AM, "Ray Van Dolson" <[hidden email]> wrote:

>(Apologies for the URL mangling below -- darn Corporate email)
>
>So, have found a workaround for this.  By explicitly changing the AD
>owner on the file(s) in question (well, not really changing -- I just
>re-set the owner explicitly to the owner which was already set),
>something jogged in the NetApp's brain and it can now properly map the
>owner to a valid UID.  As mentioned, this is bizarre, since the owner
>is EXACTLY the same as it was originally and a comparison of the
>vserver security file-directory show output before and after shows no
>notable differences other than the expected Unix UID/GID's now
>displayed.
>
>So, these files were initially populated via a robocopy copy from
>Windows.  I suspect something with the original syntax resulted in the
>ACL being "off" enough to confuse cDOT.  I'll need to do some
>additional testing on that, but have confirmed that if I use the /MIR
>/SEC /COPY:DATO arguments to robocopy, the owner is preserved in such a
>way that cDOT is able to properly map that owner to a Unix UID/GID.
>
>Ray
>
>On Wed, Feb 15, 2017 at 07:07:15PM +0000, Parisi, Justin wrote:
>> I cover the fsecurity equivalent a bit here:
>>
>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__whyistheinternetbrok
>>en.wordpress.com_2017_01_24_mixed-2Dperceptions-2Dmultiprotocol-2Dnas_&d=
>>DwIFAg&c=n6-cguzQvX_tUIrZOS_4Og&r=WoGou9bjN14EvLKS6DHxfMEG6f2_bRhXNpedbbF
>>oYDk&m=s4PaKdj-_NUkc_ec1eveH2WdRjGE_m333D0Y2iD_vG0&s=1JMEtwOhwsYwPLMLM1Zx
>>_syN-6uq68TcuLgLbIVtUEc&e=
>>
>> It sounds like the issue might be UNIX -> Windows mapping rather than
>> Windows -> UNIX.
>>
>> Does this issue happen on files that get created from NFS only? Do
>> the clients leverage LDAP/NIS?
>>
>> SecD tracing should help us see who that user is coming in as and why
>> it's mapping the way it is. It's more useful for authentication
>> issues (like this) than authorization (permission) issues.
>>
>> If you can unicast me the cluster SN so I can see the secd trace, I
>> can have a look.
>>
>>
>> -----Original Message-----
>> From: Ray Van Dolson [mailto:[hidden email]]
>> Sent: Tuesday, February 14, 2017 7:16 PM
>> To: Parisi, Justin <[hidden email]>
>> Cc: [hidden email]
>> Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting
>>mapped to 65534
>>
>> Well, no joy yet.  The secd tracing didn't help too much as I'm not
>> really encountinger a permissions denied situation, just an
>> enumeration issue.
>>
>> It *seems* like the NetApp is not handling the NTFS owner correctly.
>> What's weird is that if I go into a file from the Windows side and
>> take ownership of the account using *my* AD account, then the AD
>> username -> Unix UID works correctly and I see the expected username
>> listed via NFS.
>>
>> What I'm struggling with now is getting it to let me change the
>> owners on all of the files to someone other than myself.  I keep
>> getting an error "You do not have the Restore privilege required".
>> I've added my AD username to the BUILTIN\Administrators group on the
>> SVM (I think!), but still no joy.  Maybe I actually need to have a
>> Domain Administrator account do this, or try via whatever the cDOT
>> equivalent of fsecurity is (though my recollection is that that's
>> kind of a PITA).
>>
>> Ray
>>
>> On Wed, Feb 15, 2017 at 12:43:42AM +0000, Parisi, Justin wrote:
>> > Yea, if the GID lookup fails it can fall back to 65534 in some cases.
>> >
>> > -----Original Message-----
>> > From: Ray Van Dolson [mailto:[hidden email]]
>> > Sent: Tuesday, February 14, 2017 4:42 PM
>> > To: Parisi, Justin <[hidden email]>
>> > Cc: [hidden email]
>> > Subject: Re: NFSv3 mount on NTFS volume on cDOT 9.0 - UID getting
>> > mapped to 65534
>> >
>> > On Wed, Feb 15, 2017 at 12:26:24AM +0000, Parisi, Justin wrote:
>> > > 65534 is "pcuser" on a NetApp storage system. That's the user a
>> > > Windows user gets mapped to when they write to a NTFS security
>>style
>> > > volume when they can't map to a specific user. It's the default
>>UNIX
>> > > user, not the default Windows user that's being leveraged.
>> > >
>> > > Likely an issue with the name services. What does "name-service
>> > > ns-switch show" give as the config?
>> >
>> > ::*> name-service ns-switch show -vserver file_ntfs
>> >   (vserver services name-service ns-switch show)
>> >                                Source
>> > Vserver         Database       Order
>> > --------------- ------------   ---------
>> > file_ntfs       hosts          files,
>> >                                dns
>> > file_ntfs       group          files,
>> >                                nis
>> > file_ntfs       passwd         files,
>> >                                nis
>> > file_ntfs       netgroup       files
>> > file_ntfs       namemap        files
>> > 5 entries were displayed.
>> >
>> > NOTE: I *just* changed group to include nis.
>> >
>> > >
>> > > What does "diag secd authentication show-creds -list-id true
>> > > -list-name true" give for that user?
>> >
>> > ::*> diag secd authentication show-creds -list-id true -list-name
>>true
>> > -node red-str-napcl-p03-02 -vserver file_ntfs -win-name DOMAIN\step
>> >
>> >  UNIX UID: 1180 (step) <> Windows User:
>> > S-1-5-21-2050139532-2050374463-XXXXXXXXXX-2719 (DOMAIN\step (Windows
>> > Domain User))
>> >
>> >  GID: 129 (micro)
>> >  Supplementary GIDs:
>> >   129  (micro)
>> >   8001  (logs)
>> >   0  (root)
>> >   55  (lxadmin)
>> >   14  (sysadmin)
>> >
>> >  Windows Membership:
>> >   <many groups listed>
>> >
>> >  User is also a member of Everyone, Authenticated Users, and Network
>> > Users
>> >
>> >  Privileges (0x2080):
>> >   SeChangeNotifyPrivilege
>> >
>> > I'll note here as well that the first time I ran this command, it
>> > complained about being unable to look up the Unix GID.  This is
>> > when I added nis to the services list for group above.
>> >
>> > > You could try enabling secd tracing to see what exactly happens
>> > > during the requests, as well. (diag secd trace set -trace-all yes)
>> >
>> > I'll give this a try next.
>> >
>> > Ray


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters