Monthly Archives: August 2012

EMC VNX Celerra NAS Multiprotocol Environment Planning

A mixed protocol environment means that you have two means of accessing the same data generally through SMB/CIFS/Samba and NFS. SMB is natively supported in Windows and NFS is natively in *nix environments.

There are complexities an organization will always run into when running in a mixed protocol environment which is a result of how Windows and *nix systems handle security at the core of their respective operating systems. *nix platforms handles permissions by using permission bits and Windows uses Access Control Lists (ACL). Ownership of a file is either defined by a User ID (UID) in the Unix world or a Security ID (SID) in Windows.

Fundamentally, *nix and Windows platforms handles files, permissions and sharing completely differently and this introduces new complexities because of this business requirement. It is my personal advice, try to avoid running a mixed protocol environment if possible. If a there is a requirement that mandates this need, then design and plan accordingly to prevent future headaches down the road.

This article is not a how-to guide on how to implement a mixed protocol environment since each implementation is unique since there is a complexity reason for driving to use the mixed protocol environment to begin with. Use the following as things to understand and to take in account BEFORE you implement a mixed protocol environment.

This article is a cliff-notes version of the following EMC documents,  Multiprotocol Environment Guide and the User Mapper Guide.

It is important that the sections below are completely understood a head of time for accurate planning of multiprotocol environment. If a change is required after the filesystem is already in production, there is no easy way to change these settings without creating another filesystem and rsync’ing/robocopy’ing the data between filesystems.

Understanding CIFS and Unix Permissions

CIFS

  • Access Control Lists
  • SID Ownership
  • Username Passwords

*nix

  • Permission Bits
  • UID & GID Ownership Bits
  • IP Address Access

Understand the CIFS User ID Resolution Options

• Active Directory
• LDAP Directory
• Local Files
• Network Information Service (NIS)
• Usermapper (Internal or External)

To understand your mappings in technical detail please review the EMC Naming Services Guide.

NOTE: EMC recommends use of Internal Usermapper in Windows-only environments.
NOTE: Avoid static mappings if possible, it becomes a management nightmare. Even if you use custom Active Director Schema Attributes/software to deal with Windows-to-Unix mappings, the Naming Services Guide will provide you with the information to accommodate custom schema attributes and fields.

Understanding Access-checking Policies

Access-checking policy Description
Native (default)
  • Access to a file or directory through NFS or UNIX authenticated FTP is granted only if the UNIX permissions on the file or directory allow it.
  • Access through CIFS or Windows authenticated FTP is granted only if the Windows permissions on the file or directory allow it.
  • ACL and UNIX permissions are maintained for every file and directory.
  • A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
NT
  • Access to a file or directory through NFS or UNIX authenticated FTP is granted only if the UNIX and Windows permissions allow it.
  • Access through CIFS or Windows authenticated FTP is granted only if the Windows permissions allow it (the UNIX permissions do not have any effect).
  • ACL and UNIX permissions are maintained for every file and directory.
  • A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
UNIX
  • Access to a file or directory through NFS or UNIX authenticated FTP is granted only if the UNIX permissions allow it (the Windows permissions do not have any effect).
  • Access through CIFS or Windows authenticated FTP is granted only if the UNIX and Windows permissions on the file or directory allow it.
  • ACL and UNIX permissions are maintained for every file and directory.
  • A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
SECURE
  • Provides the greatest security across CIFS and NFS.
  • Access to a file or directory through either NFS or FTP or CIFS is granted only if the UNIX and Windows permissions on the file or directory allow it.
  • ACL and UNIX permissions are maintained for every file and directory.
  • A change in permissions on a file system object in NFS has no impact on permissions in CIFS and a change in permissions on a file system object in CIFS has no impact on permissions in NFS.
MIXED
  • Access to a file or directory through either NFS or FTP or CIFS is always determined by the ACL.
  • ACL and UNIX permissions are maintained for every file and directory.
  • ACLs for files and directories are created from the protocol that last set or changed the permissions. For example, if an NFS client sets or changes permissions on a file or directory, the ACL is rebuilt based on the UNIX mode bits. If a CIFS client sets or changes permissions on a file or directory, the ACL is built based on the standard Windows permissions.
  • In all cases, the ACL determines file and directory access regardless of whether the client is using the NFS, CIFS or FTP protocol.
  • ACL permissions are more granular than UNIX mode bits, consequently not all permissions set in an ACL can be translated to UNIX mode bits. In some cases, the mode bits might show more permissions than a user actually has
MIXED_COMPAT
  • Access to a file or directory through NFS or FTP or CIFS is determined by which protocol (NFS or CIFS) last set or modified the permissions.
  • ACL and UNIX permissions are maintained for every file and directory.
  • If the permissions of a file or directory are set or changed from a CIFS client, then access is determined by the ACL (EXPLICIT ACL). UNIX mode bits are generated based on the ACL but are not used for access checking.
  • If the permissions of a file or directory are set or changed from a UNIX client, then UNIX mode bits dictate access. An ACL is still created but is not used for access checking.
  • ACL permissions are more granular than UNIX mode bits, consequently not all permissions set in an ACL can be translated to UNIX mode bits. In some cases, the mode bits might show more permissions than a user actually has.


Understand Permission Translations

ACL to Unix Rights
EMC VNX Celerra ACL to Unix Rights Screenshot

Unix to ACL Rights
EMC VNX Celerra Unix to ACL Rights Screenshot

Understand your Inheritance

NATIVE, UNIX, NT, and SECURE
EMC VNX Celerra Native Inheritance Modes

MIXED and MIXED_COMPAT
EMC VNX Celerra Mixed Inheritance Modes

You can find this information and a wealth of other information in EMC’s Multiprotocol Environment Guide and User Mapper Guide.

Other Observed Notes:

  • Taking ownership from Windows Permissions/ACL will change the underlying UID/GID owner even though it is stated otherwise in Native Mode.
Advertisements
Tagged , , , , , , , , , , , ,

EMC DataDomain Default BIOS CMOS Password

If you ever have a need to get into an EMC DataDomain BIOS screen the default password is a simple pattern based off the major series model number. For example:

DD460 = d400d (delta four zero zero delta)

DD670 = d600d (delta six zero zero delta)

DD880 = d800d (delta four zero zero delta)

The pattern is simple, “d + major series model number + d

Tagged , , , , , , ,

EMC Isilon Clear Cached UID GID Mappings

During testing, the EMC Isilon storage was successfully reading the Active Directory Attributes but the data was incorrect. The data that was in the uid & gid fields were id’s that were automatically generated by the Isilon storage itself. The id’s that were generated by the Isilon storage took precedence over any mappings that were stored in the Active Directory Schema.

The fix was to delete all mappings from the Isilon storage by logging into the CLI and issuing a

isi_clean_idmap --clean-idmap

… to clean up all the mappings!

EMC Isilon Test Mappings Screenshot

EMC Isilon Clean Up Mappings Screenshot

Tagged , , , , ,

EMC Isilon Integration Quest Vintela Authentication Services VASD

There are many challenges that are faced when an organization is forced to run a mixed protocol environment to serve up the same data. This introduces additional management tasks and additional complexities. In a mixed protocol environment you must manage Windows Access Control Lists (ACL) to enforce Windows permissions in addition to managing *nix user/group ids with permission bits to control access. The EMC Isilon solution is a great platform to support mixed protocol environments. In my opinion this far, the Isilon platform is the ideal solution to deal with a mixed protocol environment due to it’s integration with authentication services such as Windows Active Directory or any LDAP service. There are a number of products that provide extensions to Windows Active Directory to provide UID/GID authentication and mappings. One of those products is Quest’s (Vintela) Authentication Services.

Quest Authentication Services uses five fields in the Windows Active Directory. These are the five attributes that Quest Authentication Services uses:

  • gecos
  • uidNumber
  • gidNumber
  • loginShell
  • unixHomeDirectory

Using that information, we are now able to integrate the Quest (Vintela) Authentication Services with the EMC Isilon NAS Storage. The screenshot below displays the correct settings to use on the EMC Isilon storage to integrate with Quest Authentication Services.

EMC Isilon Quest Authentication Services Settings Screenshot

Finally, test your mappings to ensure your AD/LDAP authentication and mappings work correctly.

Tagged , , , , , , , , , , , ,

TACACS.net Server Cisco IOS NX OS Configurations TACACS+ AAA

“TACACS+ is an Authentication, Authorization, and Accounting (AAA) protocol originally developed for the U.S. Department of Defense for authentication to network devices such as routers, switches, and firewalls. Unlike RADIUS, it separates the Authentication and Authorization functionalities, which makes it more flexible for administrative access. The current version of the protocol standard was developed by Cisco Systems.”

That gives you a good idea of what TACACS+ is used for. TACACS.net is freeware application which makes any Windows Server installation a TACACS+ server. I found that it made most sense to place the TACACS+ server on the Domain Controller since lookups can be done locally with the fastest speed but if your security model requires them to be separated, then you must stay in compliance and separate the roles by spinning up another Windows server.

Below is the configuration for using a TACACS.net Server with Cisco MDS Series Fabric Switches with Cisco Nexus 7000 Network Switches. Both the Nexus and MDS share the same NX-OS operating system at the core but require separation in the TACACS.net server. These have been tested and verified working! Enjoy!

Configuration files for TACACS.net

  • tacplus.xml
  • authentication.xml
  • authorization.xml
  • clients.xml

Download the configuration bundle, TACACS+ Configuration Bundle

Cisco Nexus 7K/5K & MDS 9124/9148 Configuration

ip domain-name northwind.lan
ip name-server 10.10.10.1 10.10.10.2
feature tacacs+
tacacs-server key mds_preshared_key
tacacs-server host tacacs-server-1.northwind.lan
tacacs-server host tacacs-server-2.northwind.lan
aaa group server tacacs+ san_admin
server tacacs-server-1.northwind.lan
server tacacs-server-2.northwind.lan
exit
aaa authentication login default group san_admin local
tacacs+ enable

NOTE: The Nexus 7000 and the MDS series switches both run NX-OS, the commands are the same for the MDS series as it is for the Nexus series Cisco product lines. If you have an MDS switch running SAN-OS, the following commands will not work.

Cisco IOS Configuration

ip domain-name northwind.lan
ip name-server 10.10.10.1
ip name-server 10.10.10.2
aaa new-model
aaa authentication login default group network_admins local
aaa authentication enable default group network_admins enable
aaa authorization config-commands
aaa authorization commands 0 default group network_admins none
aaa authorization commands 1 default group network_admins none
aaa authorization commands 15 default group network_admins none
aaa accounting exec default start-stop group network_admins
aaa accounting commands 15 default start-stop group network_admins
tacacs-server host tacacs-server-1.northwind.lan key ios_preshared_key
tacacs-server host tacacs-server-2.northwind.lan key ios_preshared_key
Tagged , , , , , , , , , , ,