CSTMay19DocRecommendation

A. Use modern industry standard native protocols for all important data

Text in blue from J. Altman, AuriStorFS. Mr. Altman is an internationally-recognized expert on filesystems and Kerberos. ARCS condsiders the quotes from Mr. Altman contained in this document to be objective. Mr. Altman would be glad to meet in person with IST staff to discuss any issues relevant to this discussion.

Definitions for "standard" and "native" are important. Does "standard" mean a protocol which is published by a standards body such as ISO or IETF? There are plenty of examples of standards such as NFSv4 which are designed to provide a false sense of interoperability and portability.

NFSv4 defines a minimal set of requirements and a very large set of optional behaviors. Finding the overlapping set between clients and servers (especially servers from different vendors) is difficult.

Or "standard" could mean "ubiquitous" such as CIFS/SMB. However, there are many variants of CIFS/SMB protocol with wide-ranging differences. Most non-Microsoft implementations are at least one major Windows OS revision behind and Microsoft has frequently broken interoperability by disabling support for older variants in more modern OS releases.

The Windows OAFS client used to be an SMB/AFS proxy server. The reason for building the kernel mode OAFS redirector (aka the "native" client) is that Microsoft removed the CIFS support for the variant of SMB that the OAFS SMB/AFS proxy server implemented.

To a file system developer "native" means a file system that is implemented in the OS as a kernel mode driver that integrates with the OS vfs/ifs layer. By that definition "AFS" clients are native to Linux, MacOSX, and Windows.

One of the challenges of relying on OS vendor-shipped functionality is that it becomes imperative to upgrade the OS to get access to new features and capabilities. OS vendors rarely backport new functionality to prior OS releases.

This is a strong point for a vendor such as AuriStorFS that supplies new features and capabilities across several OS releases.

There is no single "standard". Billion-dollar corporations relying on AFS for infrastructure is a standard : Corporations

B. Use existing deployed and secure authentication methods (Microsoft Active Directory) to provide seamless authentication across Windows and Unix/Linux

MIT Kerberos 5 is also already deployed (for the cad.njit.edu.cell)

Do not tie NJIT's authentication to a vendor's Kerberos implementation, which can be changed at will by that vendor. Use instead a tried and trusted opensource implementation.

The use of MS AD goes against UIS's IDM effort, which is LDAP-based. UIS strongly prefers the continued use of OpenDJ for LDAP.

C. Utilize existing owned technology: NetApp Multiprotocol Support (CIFS/DFS/NFS), Microsoft Active Directory (Kerberos+LDAP), Desktop OS (Linux, Mac, Windows)

Use the existing deployed secure authentication method, OpenDJ, managed by UIS, to provide services authentication across Linux/MacOSX, CP, and other Shibboleth-supported portals. This method could also provide AD access via a cross-realm trust with MIT Kerberos.

Use AFS for academic and research computing - strong security and common global namespace across multiple client platforms, with no user impact during reconfigurations - rather than CIFS/DFS/NFS.

D. Consolidate storage silos and provide a more unified user experience using existing owned technology.

• D1. Windows and Mac users will see their files mapped in the CIFS/DFS name space as native windows files

• Do away with OS namespace silos and ACL incompatibilities by using AuriStorFS - strong security and global namespace for all clients is built in.

• D2. Access and Authentication controlled by Active Directory

• Use OpenDJ and Kerberos for all authorization and access. The Protection Service model used in AFS is more secure than the Privilege Authorization Certificate used by AD.
  

  CIFS uses the group membership information that AD puts in the Privilege Authorization Certificate (PAC) portion of the Kerberos service ticket. AFS uses the Protection Service database. The Protection Service model is more secure.

  There are a number of problems with the use of PACs in multi-domain forests because the groups that are evaluated and included in the PAC are entirely dependent upon the trust path used to cross the forest.

  The group memberships do not expire nor are they re-evaluated until the Ticket Granting Ticket expires. With the Protection Service model the group memberships (also known as the Current Protect Set) are re-evaluated with each new connection to the a file server.

  The Protection Service can also notify file servers of PTS IDs (users or groups) whose state is modified. This can be used to force the re-evaluation of the Current Protection Set for existing connections when the next call is received.

• D3. No need for 3rd party software on desktops

• AFS client software is very light weight. With AuriStorFS, we get full native client support for all platforms; support of OS desktops is made simpler.

• D4. Eliminate need for additional Kerberos realms, reducing password headaches

• One MIT central Kerberos server for all platforms will also solve this problem. This was demonstrated with an OpenLDAP in a working model circa 2008.

• D5. Important data replicated using NetApp SnapMirror to DR Storage

• Applications and infrastructure software replicated via read-only volumes; this is native to AFS.

• D6. Provides Hourly, Daily and Weekly filesystem snapshots for self service user initiated file restores. (Supported natively on all platforms)

• These services can be accomplished, if considered useful, via scripting and the vos copy AFS utility. AuriStorFS has plans to implement additional online snapshots.

• D7. Solutions fully supported by existing partners under contract /w NJIT: NetApp, Red Hat, Microsoft

• A contract with AuriStorFS is an investment in a strong security and common global namespace across multiple clients. Purchasing support from AuriStorFS is likely to result in faster fixes of any AFS issues that arise with NetApp, Red Hat, and Microsoft on both the server and clients sides - AuriStorFS is expected to be more responsive to NJIT's needs than these larger vendors. The cost of AuriStorFS support is a small fraction of the cost of the enterprise infrastructure already in place.

• D8. The above represents how the rest of the IT industry provides file services to these platforms. Implementing the above puts us back in a much larger user group

• To the contrary, there is a substantial body of commercial and academic institutions using AFS :
  • Commercial and academic
  • AuriStorFS deployment status

• D9. Other vendors provide similar solutions, the reason we are focusing on NetApp is because we already own the technology to support the VM environment. All licensed features to implement above are included in the base product

• This technology was not obtained for the purpose of academic and research file services. AFS is better suited to this purpose. The underlying infrastructure must be structured for the specific services it is meant to provide.