Hi Tim,
On an NTFS qtree, the file won't have a uid. Instead, the file will contain the SID of the mapped Windows user.
Listing that from Unix will cause the SID to be translated to the username, which in turn is looked up in NIS/LDAP/Filer's passwd for the unix username, to get the uid to show. The GID shown will be the default group of the unix user.
And you can't chown on NTFS qtrees from NFS/Unix, unless we now adjust the user SID - but you'd have to check the result from windows, not unix.
On a Unix qtree, accessing it through CIFS shows you the CIFS user that the unix username mapped to. If a CIFS user creates a file, the uid will be from the reverse mapping process.
A file can't have both the UID/GID and chmod bits AND an ACL, that's not possible, even in mixed qtrees (where the choice depends on the last access done that changed anything: CIFS or NFS).
-- Olaf Leimann
-----Original Message----- From: Tim Thomas [mailto:timothy.b.thomas@lmco.com] Sent: dinsdag 25 augustus 2009 19:01 To: Webster, Stetson; toasters@mathworks.com Subject: Re: unix UID change on NTFS file systems
Sorry, perhaps I was not clear. We are not using mixed security style on our qtrees. and our userids do map properly between the UNIX and Windows worlds. We use a combination of NTFS and UNIX security style across our 50+ filers. So if you have a user that has files in both NTFS and UNIX qtrees with say UID 1000, and then you change them to UID 1025, you simply chown the files in the UNIX qtree from 1000 to 1025, however if you do an LS on the NTFS file system it still shows 1000 and that is because the filer embeds the UNIX UID in the NTFS file. Why? You tell me... Sure they still have access, but the LS sure is deceiving.
Tim
Webster, Stetson wrote:
In mixed environments, I usually recommend NTFS qtrees (not mixed) and then make sure that the users map properly between platforms.
Whenever
a unix user (NFS on NTFS qtree) tries to access the file, because the qtree is NTFS, the storage controller will always pursue CIFS credentials for the file(s). The results will always be predictable
and
will depend on what the CIFS permissions are for that equivalent unix
ID
coming across in NFS.
Additionally, depending on your environment, here are some other
ideas:
Unified Windows and UNIX Authorization Using Microsoft Active
Directory
LDAP as a Directory Store: http://www.netapp.com/us/library/technical-reports/tr-3458.html
Unified Windows and UNIX Authentication Using Microsoft Active
Directory
Kerberos: http://www.netapp.com/us/library/technical-reports/tr-3457.html
I'm a big unix guy, but I also believe in simplification. Let the Windows shops handle authentication, etc and let the unix guys move on to the bigger projects (just my $0.02).
Good luck!
Stetson M. Webster Professional Services Consultant NCIE-SAN, NCIE-B&R, SNIA-SCSN-E NetApp Professional Services - East 919.250.0052 Mobile Stetson.Webster@netapp.com Learn how: netapp.com/guarantee
-----Original Message----- From: Tim Thomas [mailto:timothy.b.thomas@lmco.com] Sent: Tuesday, August 25, 2009 12:14 PM To: toasters@mathworks.com Subject: unix UID change on NTFS file systems
Has anyone run into the situation where you have a mixed environment (NIS/NFS for UNIX access; AD/CIFS for NTFS access) and in the process
of
changing a UNIX UID for a user it does not properly show the change
for
NTFS files when viewed via NFS from a UNIX box? If you run fsecurity
on
the ntfs file you can see that it does imbed the UNIX UID in the NTFS file itself. For unix files, it's no problem, you just chown the file
to
the new UID, however there does not appear to be any solution for NTFS
files. I had a case open with NetApp and they say it is "merely cosmetic" and doesn't actually impact the file access or security of
the
file, which is all true. However if you do an LS from a unix box and
see
a bogus UID for a user that no longer exists, you might think the file
doesn't need to be around, which is a false assumption in this case.
It
is merely cosmetic, however it can be horribly misleading. Why store
the
UID in the first place if you can't correct it when it changes.
Anyway, any insights would be appreciated.
Thanks!
Tim Thomas Lockheed Martin