olaf at netapp
Aug 28, 2009, 6:36 AM
Post #3 of 3
(2252 views)
Permalink
|
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 [at] lmco]
Sent: dinsdag 25 augustus 2009 19:01
To: Webster, Stetson; toasters [at] mathworks
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 [at] netapp
> Learn how: netapp.com/guarantee
>
>
>
>
> -----Original Message-----
> From: Tim Thomas [mailto:timothy.b.thomas [at] lmco]
> Sent: Tuesday, August 25, 2009 12:14 PM
> To: toasters [at] mathworks
> 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
>
>
>
|
