Since the NAS device is the mediator between the client and the data, it has to understand how to translate requests coming from the Windows world to the Unix world, or vice versa. There are several ways to do this.
First, in Unix, a Network Information System (NIS) is used mainly to maintain user account information. In Windows, meanwhile, Active Directory (AD) is used to store the information. Since the NAS device resides between AD and the NIS, when a user accesses NTFS-secured data over NFS, the NAS device needs to map the Unix ID to an NT ID. On EMC’s Celerra, for example, this is done via a user mapper daemon, while a NetApp array employs the file /etc/usermap.cfg to define how an NT user gets mapped to a Unix account and vice versa. But, this is like translating Japanese to Greek; the two file system security structures are that different. With the user mapper file, for example, you have to manage the file on every NAS device. With AD, of course, it is in a central location and can be globally managed.
I recently helped a customer with a project to provide NAS access from both Unix and Windows clients. To do this, I used Microsoft AD along with a Microsoft AD schema extension called Windows Services for Unix (SFU) to have AD hold both Windows account information as well as Unix account information. Once the schema extension was done on AD, it could manage all account information that a Unix NIS server was managing, such as Unix ID, group ID, Netgroups, Unix home directory and default shell information.
From the NAS array, we configured the array to do LDAP lookups to AD to retrieve the Unix account information. When querying the array for user account information for a specific user, the array would return both the Security ID for the AD Windows account as well as the Unix ID for that user. We also needed the Linux client to be able to perform Lightweight Directory Access Protocol (LDAP) queries to AD to get user information. We did this by having the client do an LDAP bind via the Pluggable Authentication Module (PAM). Once those pieces were in place, we could access Windows data from a Unix host, or vice versa, without using a NIS server.
When testing this multiprotocol configuration, we saw some interesting behavior around security. We locked down the file system with Unix-style permissions (“owner,” “group” and “other”). We turned off access for those users with the “other” role and gave group permissions to a specific Unix group. When accessing the data over a CIFS share, if the user’s Unix primary groups and the file system’s “group” permissions were not the same, the user would not be able to access the data. But when logging into a Unix server, the Unix server was able to enumerate all Unix groups, and if any of the groups that a user belonged to had access to the file system, the user would also have access.
After doing further research, we learned that this discrepancy stemmed from the fact that the LDAP queries from the NAS device were able to enumerate only the user’s primary group. If the NAS device had been able to enumerate all Unix groups and if one of those groups had access to the data, the user would have been able to access the data.
The bottom line is that setting up NAS access from Windows and Unix clients isn’t a perfect process. Just like in a conversation between two people whose native languages are different, some things get lost in translation. But there will always be a business case for accessing data from multiple platforms, so someone needs to figure out how to make it happen. As customers deploy more multiprotocol systems, we’ll continue to learn the small caveats of running an environment when sharing data from multiple platforms.
Seiji Shintaku is a storage consultant with extensive experience in the financial services sector.
This was first published in July 2011