Celerra supports user authentication via Secure NFS (i.e. authentication via Kerberos) or though NFSv4, though I don't believe OS X supports either at the moment. According to Apple, OS X 10.5 is supposed to include a very basic NFSv4 client, though it is very limited and not intended to be used for production use.
Otherwise, NFS access is maintained through the export list (specifying overall access rights to a particular NFS export on a per-machine basis) and through individual permissioning of files, which is usually maintained through UIDs and GIDs. OS X users and groups are also UID/GID-based, and pass this information on to the Celerra (which we respect), so there are ways that UIDs and GIDs could be managed on the Mac side to provide user security.
Depending on your environment, current authentication scheme on the Macs, overall access requirements, and cross-protocol needs, setting this up could get somewhat complex, and you'd probably want to talk to your local EMC team if you want to start going down this path. For example, you could manually set users on each Mac to use a unique UID and/or GIDs as appropriate, and manage user access manually. This could be simplest, but might be a lot of manual work. If those Mac users need to map to Windows users as well (for example, account "Jim" is treated the same by the data mover as a Windows user named "Jim" in the "Sales" domain), then you'd need to coordinate getting the Mac UIDs and GIDs to sync up with the UIDs and GIDs that the Celerra maps CIFS users and groups to.
The Macs could also use Active Directory, NIS, LDAP, or a variety of other directory services for authentication. In the NIS and LDAP case, you'd configure users to have particular UIDs and GIDs at the server side, which might mean less manual work. In the Active Directory case, the Macs would translate a Windows user into a UID, and you'd probably have to manually make sure that the Mac UID/GID mappings match the Celerra UID/GID mappings.
...So the short answer is that yes, there are ways, but it is probably not incredibly simple.
yeah, it sounds like a lot of manual matching/creating ..considering the fact that i do not have access to client machines, it would be a support nightmare. Majority of users took the time and converted their files to CIFS friendly names, but this one groups of users (publishers) have created a lot of InDesign/Illustator files that link to other files with all kinds of characters. So for them to move to CIFS they would have to pretty much touch every file and fix links.
As Ian has said good old normal NFSv2/3 doesnt really do user authentication - the user is authenticated on the client and the NFS server just believes the UID/GID it gets sent in the NFS request. The NFS server just restricts which hosts are allowed to mount and checks the rwx permissions for ugo with the UID/GID supplied in the NFS request. A NFS server actually never cares about a user password.
Thats very different from CIFS operations where the server actually does authentication either thru NTLM passthru or Kerberors via the domain controller.
If you want to relieve the burden of maintaining the NFS export list you can use netgroups or export to a whole subnet.
If you want to improve security and prevent UID spoofing then secure (Kerberized) NFS or NFSv4 is necessary. (Unless you want to do special firewall/proxy setups like some Universities do)
If you need to do user NFS/CIFS mapping - thats a different matter and got nothing to do with authentication
i am trying to utilize AD to manage access to NFS exports.
the only way I can imagine to do that would be to install Microsoft Services for Unix on the AD controller. This provides a NIS server and should be able to be used by the Celerra to get netgroups. You could then on the Celerra side just export a netgroup and manage the host that are in that netgroup from the AD.
not sure its worth the trouble though - using SFU requires a schema extension of the AD - something that AD admins dont do lightly
thanks for suggestion, i don't see my AD people doing schema extension for just a few mac users. Oh well ...they will have to take the plunge and modify their files and move over to CIFS.
IanSchorr
117 Posts
0
May 3rd, 2007 11:00
Otherwise, NFS access is maintained through the export list (specifying overall access rights to a particular NFS export on a per-machine basis) and through individual permissioning of files, which is usually maintained through UIDs and GIDs. OS X users and groups are also UID/GID-based, and pass this information on to the Celerra (which we respect), so there are ways that UIDs and GIDs could be managed on the Mac side to provide user security.
Depending on your environment, current authentication scheme on the Macs, overall access requirements, and cross-protocol needs, setting this up could get somewhat complex, and you'd probably want to talk to your local EMC team if you want to start going down this path. For example, you could manually set users on each Mac to use a unique UID and/or GIDs as appropriate, and manage user access manually. This could be simplest, but might be a lot of manual work. If those Mac users need to map to Windows users as well (for example, account "Jim" is treated the same by the data mover as a Windows user named "Jim" in the "Sales" domain), then you'd need to coordinate getting the Mac UIDs and GIDs to sync up with the UIDs and GIDs that the Celerra maps CIFS users and groups to.
The Macs could also use Active Directory, NIS, LDAP, or a variety of other directory services for authentication. In the NIS and LDAP case, you'd configure users to have particular UIDs and GIDs at the server side, which might mean less manual work. In the Active Directory case, the Macs would translate a Windows user into a UID, and you'd probably have to manually make sure that the Mac UID/GID mappings match the Celerra UID/GID mappings.
...So the short answer is that yes, there are ways, but it is probably not incredibly simple.
dynamox
9 Legend
•
20.4K Posts
0
May 3rd, 2007 12:00
Thank you for explaining my options.
Rainer_EMC
4 Operator
•
8.6K Posts
0
May 4th, 2007 16:00
As Ian has said good old normal NFSv2/3 doesnt really do user authentication - the user is authenticated on the client and the NFS server just believes the UID/GID it gets sent in the NFS request. The NFS server just restricts which hosts are allowed to mount and checks the rwx permissions for ugo with the UID/GID supplied in the NFS request. A NFS server actually never cares about a user password.
Thats very different from CIFS operations where the server actually does authentication either thru NTLM passthru or Kerberors via the domain controller.
If you want to relieve the burden of maintaining the NFS export list you can use netgroups or export to a whole subnet.
If you want to improve security and prevent UID spoofing then secure (Kerberized) NFS or NFSv4 is necessary. (Unless you want to do special firewall/proxy setups like some Universities do)
If you need to do user NFS/CIFS mapping - thats a different matter and got nothing to do with authentication
dynamox
9 Legend
•
20.4K Posts
0
May 4th, 2007 18:00
Rainer_EMC
4 Operator
•
8.6K Posts
0
May 7th, 2007 03:00
exports.
the only way I can imagine to do that would be to install Microsoft Services for Unix on the AD controller. This provides a NIS server and should be able to be used by the Celerra to get netgroups. You could then on the Celerra side just export a netgroup and manage the host that are in that netgroup from the AD.
not sure its worth the trouble though - using SFU requires a schema extension of the AD - something that AD admins dont do lightly
dynamox
9 Legend
•
20.4K Posts
0
May 7th, 2007 04:00
Thanks guys