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