onefs unified security model
TRANSCRIPT
ONEFS UNIFIED SECURITY MODEL
Steffen ThuemmelAdvisory Systems Engineer Dell EMC [email protected]
2016 EMC Proven Professional Knowledge Sharing 2
Table of Contents
Preface 2
Definitions, System Setup and Configuration 3
NFSv4 Identity Management 4
Windows AD Configuration (Directory Services) 4
Global Catalog Configuration 5
Linux Client Configuration (AD join) 5
Isilon Cluster Configuration (NFS Server, SMB Server) 8
Linux Client Configuration (NFS Client) 12
NFSv4, Kerberos Authentication 13
REVERSE DNS 14
Service Principal Names (SPN) 15
Isilon Cluster SPNs 15
Linux Client SPNs 15
Linux Client, NFS Kerberos Configuration 16
Example Linux Client access 18
Example Windows Client access 18
NFSv4 ACLs 19
Summary 19
Disclaimer: The views, processes or methodologies published in this article are those of the authors. They do not necessarily reflect Dell EMC’s views, processes or methodologies.
2016 EMC Proven Professional Knowledge Sharing 3
Preface
Compared to version 2 and 3, NFSv4 contains several improvements and advantages. In contrast to v2/3, which have been developed with the speed and distance of LAN in mind, NFSv4 has been introduced while file access also over longer distances using the Internet was ubiquitous. Some of the advantages are:
• User name to UID mapping, to overcome the problem with overlapping numeric IDs in different domains
• Built-in security, using Kerberos authentication when a user tries to get access to a remote system.
• Compound procedures, client side caching and delegation for improved performance. With these advantages and improvements NFSv4 gets more and more adopted in enterprises. Most Linux distributions use v4 as default protocol when mounting a remote file system. Kerberos security and the use of names instead of numeric values for UID and GID lead to a bit more complexity in the configuration of NFSv4. As operating systems still use numeric values to control user processes, those values need to mapped into names when NFSv4 is used to access remote file systems. This mapping needs to be unique within a domain and therefore centrally managed (directory services and protocol, LDAP for instance). Encryption keys need to be managed centrally using a KDC, standalone (MIT) or built in to directory servers (ApacheDS, MS AD), which also is responsible for user authentication using krb5 Protocol. The previous articles of this series dealt with the deployment of the Isilon OneFS unified security Model in Multiprotocol use cases in general. This article will specifically focus on NFSv4 use cases. The described scenario uses Microsoft Windows AD (Win2012 server) for central user management not only for Windows users but also for UNIX users. The built-in KDC is used for user authentication. For the UNIX/NFSv4 client, a CentOS 7 has been chosen. The NFS server is an Isilon cluster running OneFS 7.2.1.
Definitions, System Setup and Configuration
File System Object: Contents of a File System to which users may have access. Generally, those are Files and Directories. ACE: Access Control Entry. An ACE represents a well defined rule, which defines access permissions to a file system object for a specific user or group. ACL: Access Control List. An ACL contains one or more ACEs, which all together govern overall access to a File System Object. SID: Security Identifier (numeric value). A Windows term. One SID uniquely identifies one object within a Windows AD. Such an object could be an ordinary user or group, a machine account or other special objects. UID: A numeric User ID is a unique identifier for a user within a Unix/Linux system. If no central Directory Services (LDAP, NIS) are used, this UID is only unique within one specific system/server. GID: Same as a UID but valid for a group of users. Command examples and screenshots in this article have been created in a test lab containing the following components. 1. virtual Isilon Cluster, OneFS 7.2.1, Hostname „blackdog“
1.1. OnDisk Identity setting = native 1.2. OnDisk ACL Policy = balanced 1.3. SFU enabled 1.4. NFS und SMB global settings = customized, see text below 1.5. NFSv4 1.6. SMB 2
2. Server Windows2012, AD (domain coda.local), DNS
2016 EMC Proven Professional Knowledge Sharing 4
3. CentOS7 Linux, Hostname „blacknight“
It is assumed that the Isilon Cluster is already configured and joined into an AD. For the sake of easier readability, the command examples executed at different Operating Systems are marked in different colors: black —> Isilon OneFS
blue —> Windows2012
amber —> CentOS7
Some of the command outputs are quite lengthy with information not relevant for the subject of this article. Therefore, the command output sometimes has been truncated.
NFSv4 Identity Management
If NFSv4 is used without the requirement of extended security (auth_sys is sufficient for authentication) the configuration is similar to NFSv3, with only a few differences. NFSv4 uses the concept of a domain in which a name for a user or group is valid. The name of this NFS domain has to be configured equal on all involved instances. As mentioned before, NFSv4 is no
longer using numerical ID but an alphanumerical name of the form user@domain or
group@domain. With that, UIDs in different domains might be equal, but NFSv4 is able to distinguish
them by the user name they are associated with. For instance: the user jbonham could have the
same UID in domain CODA as well as in domain GEBEISI. But the user name is uniquely
distinguishable: [email protected] and [email protected].
While the name of the NFSv4 domain does not need to be equal to the name of the DNS domain, if the names are equal, administration is easier and transparency is better. Some Linux distribution require case sensitivity for that NFSv4 domain name. The picture below shows a snapshot from a line trace documenting the use of names for user identities in NFSv4, aka principal names.
A user is now uniquely identifiable between domains. Contrary to older NFS versions, configuration requires a bit more effort. The following sections describe the configuration of each participating instance, server, client and directory service.
Windows AD Configuration (Directory Services)
In Windows Server 2008(R2) for the server role ”Active Directory“ an additional feature exists, IDMU (Identity Management for UNIX). This feature can be installed with the help of the Server Manager GUI. Not so with Windows Server 2012(R2). The feature is still there, but not installable with the Server Manager GUI. The installation has to be carried out with DISM.EXE.
2016 EMC Proven Professional Knowledge Sharing 5
More details about the feature and its installation can be found in the following Microsoft articles:
• Install Identity Management for UNIX Components
• Overview of Identity Management for UNIX • Identity Management for UNIX: How To... Once IDMU is successfully installed, the user properties screen in the Active Directory management tool contains one more tab, UNIX-Attributes.
The task to set Unix attributes for many (already existing) users can be automated with the help of PS commands (Windows Server 2012):
• Get-ADUser
• Get-ADObject
• Set-ADObject
(Windows Server 2008: Set-ADUser)
Global Catalog Configuration
If the configuration contains more than one AD server or there are multiple domains with trust relationships, the Linux Client SSSD (see further down in the text) will contact the Global Catalog first. However, the POSIX Unix attributes will not be replicated by default to the Global Catalog. For performance reasons it’s recommended to replicate those attributes. To do that, a schema snap-in is necessary. An installation guide can be found in that article here. Another article found here describes how to replicate attributes. For this deployment scenario it would be necessary to replicate uidNumber, gidNumber, unixHomeDirectory and loginShell.
Linux Client Configuration (AD join)
Shall all users – Windows and Unix – be maintained in Windows AD, the Unix Systems need to be
integrated into the Windows AD. The Unix deamon sssd is suitable to fulfill that task. In more modern
Linux distributions (CentOS 7, for instance) it replaces older services identity management in Windows
2016 EMC Proven Professional Knowledge Sharing 6
(Winbind). A detailed description of possible scenarios for Windows AD Integration using the sssd
deamon can be found in „Red Hat Enterprise Linux 7 - Windows Integration GuideWindows Integration Guide“ .
The sssd deamon has a comprehensive number of features and functions. However, immediately
after system installation it is not yet configured. The configuration file does not yet exist as the following command example shows.
[root@blacknight ~]# more /etc/sssd/sssd.conf
/etc/sssd/sssd.conf: No such file or directory
To use sssd for Identity Management the configuration could be simplified by using realmd. (This daemon generates and configures all necessary files). [root@blacknight ~]# realm discover coda.local
coda.local
type: kerberos
realm-name: CODA.LOCAL
domain-name: coda.local
configured: no
[root@blacknight ~]# realm join CODA.LOCAL
Password for Administrator: XXXXXXXX
Once the system is successfully joined into the AD Domain coda.local the command realmd returns more details and the configuration file /etc/sssd/sssd.conf exists.
[root@blacknight ~]# realm discover coda.local
coda.local
type: kerberos
realm-name: CODA.LOCAL
domain-name: coda.local
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common
login-formats: %[email protected]
login-policy: allow-realm-logins
[root@blacknight ~]# more /etc/sssd/sssd.conf
[sssd]
domains = coda.local
config_file_version = 2
services = nss, pam
[domain/coda.local]
ad_domain = coda.local
krb5_realm = CODA.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = ad
2016 EMC Proven Professional Knowledge Sharing 7
The default value for ID Mapping type is set so, that sssd uses generic UIDs/GIDs. (ldap_id_mapping = True) To force sssd to use the POSIX-Attributes from AD, this value has to be set to False. [root@blacknight ~]# vi /etc/sssd/sssd.conf
[root@blacknight ~]# more /etc/sssd/sssd.conf
[sssd]
domains = coda.local
config_file_version = 2
services = nss, pam
[domain/coda.local]
ad_domain = coda.local
krb5_realm = CODA.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = ad
[root@blacknight ~]#
After that change in /etc/sssd/sssd.conf the sssd cache needs to be cleared. Without
doing so, a restart of the SSSD is not possible (see RH Bug 1116758 )
[root@blacknight ~]# rm -f /var/lib/sss/db/*
[root@blacknight ~]# systemctl restart sssd.service
Now a user which is maintained in Windows AD is able to log on to the CentOS System.
[root@blacknight ~]# su [email protected]
sh-4.2$ id
uid=194106([email protected]) gid=196806([email protected])
groups=196806([email protected]) context=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023
sh-4.2$
Remark:
The command "sss_cache -E" (see man page sss_cache (8)) is supposed to invalidate all sssd cache entries. But it simply does not do its job. As mentioned earlier, without clearing the cache the sssd restart terminates with error.
[root@blacknight ~]# systemctl restart sssd.service
Job for sssd.service failed. See 'systemctl status sssd.service' and 'journalctl -xn' for
details.
[root@blacknight ~]# journalctl -xn
-- Logs begin at Thu 2015-11-05 12:18:03 CET, end at Fri 2015-11-06 17:56:44 CET. --
Nov 06 17:55:35 blacknight.coda.local sssd_be[5456]: GSSAPI client step 1
Nov 06 17:55:35 blacknight.coda.local sssd_be[5456]: GSSAPI client step 1
Nov 06 17:55:35 blacknight.coda.local sssd_be[5456]: GSSAPI client step 1
Nov 06 17:55:35 blacknight.coda.local sssd_be[5456]: GSSAPI client step 2
Nov 06 17:56:42 blacknight.coda.local systemd[1]: sssd.service operation timed out.
Terminating.
Nov 06 17:56:42 blacknight.coda.local sssd[be[coda.local]][5456]: Shutting down
Nov 06 17:56:42 blacknight.coda.local sssd[nss][5457]: Shutting down
Nov 06 17:56:42 blacknight.coda.local sssd[pam][5458]: Shutting down
Nov 06 17:56:42 blacknight.coda.local systemd[1]: Failed to start System Security Services
Daemon.
-- Subject: Unit sssd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
2016 EMC Proven Professional Knowledge Sharing 8
--
-- Unit sssd.service has failed.
--
-- The result is failed.
Nov 06 17:56:42 blacknight.coda.local systemd[1]: Unit sssd.service entered failed state.
[root@blacknight ~]# rm -f /var/lib/sss/db/*
[root@blacknight ~]# systemctl restart sssd.service
[root@blacknight ~]# ls -f /var/lib/sss/db/*
/var/lib/sss/db/cache_coda.local.ldb /var/lib/sss/db/config.ldb
/var/lib/sss/db/ccache_CODA.LOCAL /var/lib/sss/db/sssd.ldb
It's not necessary to delete all files in /var/lib/sss/db//var/lib/sss/db/. Deleting cache_coda.local.ldb (allg: cache_DOMAIN.ldb) is sufficient.
Isilon Cluster Configuration (NFS Server, SMB Server)
On the Isilon Cluster some of the properties of the Active Directory Provider need to be changed and the value for the NFSv4-Domain has to be set. To force AIMA to query the Active Directory Provider for Posix attributes, the parameter “Services For Unix“ has to be set to “RFC2307“. In addition, "auto assign UID/GID" will be switched off. For ease of management and use the primary domain will be assumed as „default“ Domain.
2016 EMC Proven Professional Knowledge Sharing 9
Next step is to set the parameter Store SFU Mappings, in version 7.2.1 This can only be done by
vorliegenden CLI. blackdog-3# isi auth ads modify coda.local --store-sfu-mappings=yes
blackdog-2# isi auth ads view coda.local -v
Name: CODA.LOCAL
Machine Account: BLACKDOG$
Authentication: Yes
Status: online
Primary Domain: CODA.LOCAL
Forest: coda.local
Site: Default-First-Site-Name
NetBIOS Domain: CODA
Hostname: blackdog.coda.local
Controller Time: 2015-11-05T19:07:34
Cache Entry Expiry: 4H
Node DC Affinity: -
Node DC Affinity Timeout: -
NSS Enumeration: No
SFU Support: rfc2307
Store SFU Mappings: Yes
Ignore All Trusts: No
Ignored Trusted Domains: -
Include Trusted Domains: -
Domain Offline Alerts: No
LDAP Sign And Seal: No
Lookup Users: Yes
Lookup Normalize Users: Yes
Allocate UIDs: No
Lookup Normalize Groups: Yes
Allocate GIDs: No
Lookup Domains: -
Lookup Groups: Yes
Assume Default Domain: Yes
Check Online Interval: 5m
Machine Password Changes: Yes
Machine Password Lifespan: 1M
Create Home Directory: No
Home Directory Template: /ifs/home/%D/%U
Login Shell: /bin/zsh
With that parameter set, ID-Mappings generated during authentication will be stored persistent in the mapping DB.
blackdog-3# isi auth mapping dump --zone kvb
["ZID:3", "UID:194106", [["SID:S-1-5-21-4232337086-2338087048-3331830585-1111", 128]]]
["ZID:3", "UID:194806", [["SID:S-1-5-21-4232337086-2338087048-3331830585-1112", 128]]]
["ZID:3", "UID:1000011", [["SID:S-1-5-21-4232337086-2338087048-3331830585-1131", 48]]]
["ZID:3", "UID:19440109", [["SID:S-1-5-21-4232337086-2338087048-3331830585-1106", 128]]]
["ZID:3", "UID:31051948", [["SID:S-1-5-21-4232337086-2338087048-3331830585-1107", 128]]]
["ZID:3", "GID:196806", [["SID:S-1-5-21-4232337086-2338087048-3331830585-1110", 128]]]
["ZID:3", "GID:196807", [["SID:S-1-5-21-4232337086-2338087048-3331830585-1108", 128]]]
["ZID:3", "GID:1000014", [["SID:S-1-5-21-4232337086-2338087048-3331830585-515", 48]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-1110", [["GID:196806", 144]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-1107", [["UID:31051948", 144]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-1112", [["UID:194806", 144]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-1131", [["UID:1000011", 32]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-1108", [["GID:196807", 144]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-515", [["GID:1000014", 32]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-1106", [["UID:19440109", 144]]]
["ZID:3", "SID:S-1-5-21-4232337086-2338087048-3331830585-1111", [["UID:194106", 144]]]
2016 EMC Proven Professional Knowledge Sharing 10
Since 7.2, authentication always happens in the context of an access zone. The command isi
auth , if the parameter zone is omitted, always works in the default zone, that is „system“. The
setup shown here uses the concept of access zones for Multi Tenancy. The example zone is called
„kvb“.
blackdog-3# isi zone zones view kvb
Name: kvb
Path: /ifs/data/kvb
Cache Size: 9.54M
Map Untrusted:
Auth Providers: lsa-local-provider:System, lsa-activedirectory-
provider:CODA.LOCAL
NetBIOS Name:
All Auth Providers: No
User Mapping Rules: -
Home Directory Umask: 0077
Skeleton Directory: /usr/share/skel
Audit Success: create, delete, rename, set_security, close
Audit Failure: create, delete, rename, set_security, close
HDFS Authentication: all
HDFS Root Directory: /ifs/data/kvb
WebHDFS Enabled: Yes
HDFS Ambari Server:
HDFS Ambari Namenode:
Syslog Forwarding Enabled: No
Syslog Audit Events: create, delete, rename, set_security
Zone ID: 3
Since OneFS 7.2.1, NFS is zone aware. Therefore, all the NFS parameters and shares/exports have to be configured in the context of an Access Zone, as is the NFS4-Domain. The name specified here has to be identical to the name used in the idmapd.conf file of the Linux Clients (Case Sensitive !) further down.
2016 EMC Proven Professional Knowledge Sharing 11
The directory /ifs/data/kvb is shared via SMB , as well as via NFS. SMB share and NFS export
are configured in zone kvb.
blackdog-3# isi smb shares view kvb --zone kvb
Share Name: kvb
Path: /ifs/data/kvb
****************************************
Browsable: True
Permissions:
Account Account Type Run as Root Permission Type Permission
----------------------------------------------------------------
Everyone wellknown False allow full
----------------------------------------------------------------
Total: 1
Access Based Enumeration: No
Access Based Enumeration Root Only: No
Allow Delete Readonly: No
Allow Execute Always: No
Change Notify: norecurse
Create Permissions: default acl
*************************
Host ACL: -
Impersonate Guest: never
Impersonate User:
*************************
Ntfs ACL Support: Yes
*************************
blackdog-3# isi nfs exports list --zone=kvb
ID Zone Paths Description
-------------------------------------
8 kvb /ifs/data/kvb kvb
-------------------------------------
Total: 1
blackdog-3# isi nfs exports view 8 --zone=kvb
ID: 8
Zone: kvb
Paths: /ifs/data/kvb
Description: kvb
*************************
Map Lookup UID: Yes
Map Retry: Yes
Map Root
Enabled: True
User: nobody
Primary Group: nobody
Secondary Groups: -
Map Non Root
Enabled: False
User: nobody
Primary Group: -
Secondary Groups: -
Map Failure
Enabled: False
User: nobody
Primary Group: -
Secondary Groups: -
Map Full: Yes
****************************
Security Type: unix, krb5, krb5i, krb5p
****************************
2016 EMC Proven Professional Knowledge Sharing 12
Linux Client Configuration (NFS Client)
NFSv4 Identity Mapping (UID/GID <—> Principal Name) is the task of the idmapd Daemon, the NFS
Identity Mapper. Similar as sssd the idmapd also possesses a comprehensive configuration file,
/etc/idmapd.conf. In contrast to sssd, this file is already present after installation of the nfs-utils
and only needs to be adjusted. For the use case outlined in this article only a few changes are required.
1. Remove the comment sign from the line in which the domain is specified and insert the domain exactly the same as before as NFSv4 domain name at the Isilon cluster.
2. Switch on the SSS plugin that is specified in section [Translation] „sss“ as additional method. 3. Define Mapping for “Nobody-User“ and “Nobody-Group“.
Here is an example of how the entries in idmapd.conf would look:
[root@blacknight ~]# more /etc/idmapd.conf
[General]
Domain = CODA.LOCAL
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = nsswitch,sss
Additional hints and tips for the use of the sss switch can be found in man pages
SSS_RPCIDMAPD(5)and idmapd.conf(5).
Now the idmapd could be started. But because of a problem with the CentOS7 Distribution used here, the service file for that daemon needs to be adjusted first.
[root@blacknight ~]# vi /usr/lib/systemd/system/nfs-idmapd.service
The file needs the following entry inserted at the end of the file:
[Install]
WantedBy=multi-user.target
Now the daemon starts without problems.
[root@blacknight ~]# systemctl start nfs-idmapd.service
Warning: Unit file of nfs-idmapd.service changed on disk, 'systemctl daemon-reload'
recommended.
[root@blacknight ~]# systemctl daemon-reload
To make sure idmapd also starts after a reboot:
[root@blacknight ~]# systemctl enable nfs-idmapd.service
ln -s '/usr/lib/systemd/system/nfs-idmapd.service' '/etc/systemd/system/multi-
user.target.wants/nfs-idmapd.service'
At that point a NFSv4 mount, using sec=sys (AUTH_SYS) is already possible.
[root@blacknight ~]# mount -o sec=sys kvb.blackdog.coda.local:/ifs/data/kvb /mnt/blackdog_kvb
Change into the context of an AD-Benutzer and creating a file system object is successful:
[root@blacknight ~]# su [email protected]
2016 EMC Proven Professional Knowledge Sharing 13
sh-4.2$ cd /mnt/blackdog_kvb
sh-4.2$ mkdir jlord_u
sh-4.2$ ls -l /mnt/blackdog_kvb
total 2
drwxr-xr-x. 2 [email protected] [email protected] 0 Nov 5 18:16 jlord_u
And natural access from Windows is possible:
PS C:\Users\Administrator> net use X: \\kvb.blackdog.coda.local\kvb /USER:[email protected]
Geben Sie das Kennwort für "[email protected]" ein, um eine Verbindung mit
"kvb.blackdog.coda.local" herzustellen:
Der Befehl wurde erfolgreich ausgeführt.
NFSv4, Kerberos Authentication
NFSv4 supports a Kerberos protocol-based authentication and transport encryption (krb5i, krb5p). If NFS Client and Server want to use the Kerberos protocol (Kerberos 5 (krb5)) for authentication of user access, they need to negotiate a so-called “security context for NFS requests“. This “security context“ is a data structure called TICKET. The Ticket is user-related and contains the encryption keys (krb5p). Tickets are valid for a certain amount of time only and have to be renewed after their validation expires. To use this extended form of access security, more configuration changes are required.
2016 EMC Proven Professional Knowledge Sharing 14
Reverse DNS
Kerberos authentication enables the possibility for reverse lookup of authorized SPNs for the Cluster (the SmartConnect Zone) in AD. Therefore, a DNS Pointer Record (PTR) for that Zone is necessary.
2016 EMC Proven Professional Knowledge Sharing 15
Service Principal Names (SPN)
During Kerberos authentication hosts are represented by a unique identifier, the “machine principal name“. This “machine principal“ is created when the host joins the Kerberos realm. In this example the realm is represented by the Windows AD, the “machine principal“ has been created during “realm join“ described above. The “machine principal name“ is the fully qualified host name with the indicator host/
in front (for instance host/[email protected]).
For the NFS Service one more identifier is of importance; the NFS Service Principal. That is the SPN which represents the NFS Service available on a specific host (Client and Server). This “service principal name“ is the fully qualified host name with the indicator nfs/ in front (for instance, in
nfs/[email protected]). NFS clients using Kerberos authentication identify
themselves against the NFS with this service principal. For the Linux Client, as well as for any SmartConnect-Zone (respectively Access Zone) of the Isilon Clusters, SPNs need to exist.
Isilon Cluster SPNs
There is a sub command to the OneFS Command isi auth ads which queries the SPNs listed in
the AD.
blackdog-3# isi auth ads spn check --domain coda.local
No missing SPNs found.
blackdog-3# isi auth ads spn list --domain coda.local
SPNs registered for BLACKDOG$:
nfs/kvb.blackdog.coda.local
HOST/kvb.blackdog.coda.local
HOST/kvb
nfs/system.blackdog.coda.local
HOST/system.blackdog.coda.local
HOST/system
nfs/blackdog
HOST/blackdog
HOST/blackdog.coda.local
In case the spn check lists missing SPNs, those have to be created manually, for example:
blackdog-3# isi auth ads spn create --domain coda.local „SPN-name“
Linux Client SPNs Checking SPNs for the Linux Client can be done with the help of Powershell -Commands at the AD server. PS C:\Users\Administrator> setspn -L blacknight
Registrierte Dienstprinzipalnamen (SPN) für CN=blacknight,CN=Computers,DC=coda,DC=local:
HOST/blacknight.coda.local
HOST/BLACKNIGHT
As described above, the SPN for the Linux host has already been created during AD “join“. Before the SPN for the NFS Service at the Linux host can be created, a computer account for that service needs to be added to the AD.
PS C:\Users\Administrator> dsadd computer "CN=nfsblacknight,CN=Computers,DC=coda,DC=local"
PS C:\Users\Administrator> dsquery computer
"CN=WIN-5C6IA1CH1JS,OU=Domain Controllers,DC=coda,DC=local"
"CN=BLACKDOG,CN=Computers,DC=coda,DC=local"
"CN=WIN8,CN=Computers,DC=coda,DC=local"
"CN=blacknight,CN=Computers,DC=coda,DC=local"
2016 EMC Proven Professional Knowledge Sharing 16
"CN=nfsblacknight,CN=Computers,DC=coda,DC=local"
PS C:\Users\Administrator> setspn -A nfs/blacknight.coda.local nfsblacknight
Die Domäne "DC=coda,DC=local" wird überprüft.
Dienstprinzipalnamen (SPN) für CN=nfsblacknight,CN=Computers,DC=coda,DC=local werden
registriert.
nfs/blacknight.coda.local
Aktualisiertes Objekt
Remark:
An alternative to the method described above for checking Cluster SPNs with the help of OneFS
commands, the same could be achieved using the Windows Powershell.
PS C:\Users\Administrator> setspn -l blackdog
Registrierte Dienstprinzipalnamen (SPN) für CN=BLACKDOG,CN=Computers,DC=coda,DC=local:
nfs/kvb.blackdog.coda.local
HOST/kvb.blackdog.coda.local
HOST/kvb
nfs/system.blackdog.coda.local
HOST/system.blackdog.coda.local
HOST/system
nfs/blackdog
HOST/blackdog
HOST/blackdog.coda.local
Linux Client, NFS Kerberos Configuration
As the Linux host is already a member of the Microsoft Active Directory (see realm join above ) a Kerberos configuration file with all the necessary entries already exists. Details about parameters and
entries in that file can be found in man page KRB5.CONF(5).
[root@blacknight ~]# more /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = CODA.LOCAL
[realms]
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
CODA.LOCAL = {
kdc = win-5c6ia1ch1js.coda.local
admin_server = win-5c6ia1ch1js.coda.local
default_domain = win-5c6ia1ch1js.coda.local
}
[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
coda.local = CODA.LOCAL
2016 EMC Proven Professional Knowledge Sharing 17
.coda.local = CODA.LOCAL
Next a keytab file containing encryption keys for the service principals mentioned above needs to be created. A keytab file itself is encrypted and is unique for a specific host (a principal key contains also the Host name). The Windows PowerShell Command ktpass used at the AD server generates the required keytab files for the SPNs.
PS C:\Users\Administrator> ktpass -princ host/[email protected] -mapuser
coda.local/computers/blacknight
-crypto RC4-HMAC-NT -pass * -ptype KRB5_NT_PRINCIPAL -out hostblacknight.krb
Targeting domain controller: WIN-5C6IA1CH1JS.coda.local
Using legacy password setting method
Successfully mapped host/blacknight.coda.local to blacknight$.
Type the password for host/blacknight.coda.local:
Type the password again to confirm:
WARNING: Account blacknight$ is not a user account (uacflags=0x11001).
WARNING: Resetting blacknight$'s password may cause authentication problems if blacknight$
is being used as a server.
Reset blacknight$'s password [y/n]? y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to hostblacknight.krb:
Keytab version: 0x502
keysize 72 host/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x17 (RC4-HMAC) keylength 16 (0
xe4dbbd60e843a003917efd77efeaaa1e)
PS C:\Users\Administrator> ktpass -princ nfs/[email protected] -mapuser
coda.local/computers/nfsblacknigh
t -crypto RC4-HMAC-NT -pass * -ptype KRB5_NT_PRINCIPAL -out nfsblacknight.krb
Targeting domain controller: WIN-5C6IA1CH1JS.coda.local
Using legacy password setting method
Successfully mapped nfs/blacknight.coda.local to NFSBLACKNIGHT$.
Type the password for nfs/blacknight.coda.local:
Type the password again to confirm:
WARNING: Account NFSBLACKNIGHT$ is not a user account (uacflags=0x1021).
WARNING: Resetting NFSBLACKNIGHT$'s password may cause authentication problems if
NFSBLACKNIGHT$ is being used as a serv
er.
Reset NFSBLACKNIGHT$'s password [y/n]? y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to nfsblacknight.krb:
Keytab version: 0x502
keysize 71 nfs/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 2 etype 0x17
(RC4-HMAC) keylength 16 (0x
fec21e85e95417aa05cf6438cd132724)
PS C:\Users\Administrator>
After these files have been created and copied onto the Linux Host, ktutil (Kerberos keytab file
maintenance utility, see Man page KTUTIL(1)) reads those into the local keytab .
[root@blacknight ~]# ktutil
ktutil: rkt /mnt/blackdog_kvb/hostblacknight.krb
ktutil: rkt /mnt/blackdog_kvb/nfsblacknight.krb
ktutil: wkt /etc/krb5.keytab
ktutil: exit
[root@blacknight ~]# kinit -k
[root@blacknight ~]# klist -e
Ticket cache: KEYRING:persistent:0:0
2016 EMC Proven Professional Knowledge Sharing 18
Default principal: host/[email protected]
Valid starting Expires Service principal
11/24/2015 12:14:27 11/24/2015 22:14:27 krbtgt/[email protected]
renew until 12/01/2015 12:14:27, Etype (skey, tkt): arcfour-hmac, aes256-cts-hmac-
sha1-96
[root@blacknight ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 host/[email protected] (arcfour-hmac)
2 nfs/[email protected] (arcfour-hmac)
[root@blacknight ~]# umount /mnt/blackdog_kvb
[root@blacknight ~]# mount -t nfs4 -o sec=krb5 kvb.blackdog.coda.local:/ifs/data/kvb
/mnt/blackdog_kvb
[root@blacknight ~]# ls -l /mnt/blackdog_kvb
total 855
-rwxrw-r--. 1 [email protected] [email protected] 0 Nov 19 14:56 file_aaa
-rwxrwx---. 1 [email protected] [email protected] 0 Nov 19 14:58 file_bbb.txt
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:10 file_ccc
-rwx------. 1 [email protected] [email protected] 0 Nov 19 15:14 file_ccc.txt
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:27 file_ddd
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:28 file_eee
REMARK:
In cases where generating and/or copying the keytab files went wrong and therefor kinit terminates with error, KRB5_TRACE helps search for the cause. [root@blacknight ~]# KRB5_TRACE=/dev/stdout kinit -k
The following command examples show that once the mount succeeded, an ordinary user accessing a file cannot determine any difference whether the mount happened with sec=sys or sec=krb5. If the mount command would be executed with options krb5i or krb5p, a performance penalty would have to be taken into account, because of the extra amount of processing necessary for encryption.
Example Linux Client access
login as: [email protected]
[email protected]@10.64.247.164's password:
Last login: Tue Nov 24 12:46:48 2015
-sh-4.2$ id
uid=194806([email protected]) gid=196806([email protected])
groups=196806([email protected]) context=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023
-sh-4.2$ cd /mnt/blackdog_kvb
-sh-4.2$ touch blackdog_kvb/file_aaa_1
-sh-4.2$ ls -l
total 857
-rwxrw-r--. 1 [email protected] [email protected] 0 Nov 19 14:56 file_aaa
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 24 2015 file_aaa_1
-rwxrwx---. 1 [email protected] [email protected] 0 Nov 19 14:58 file_bbb.txt
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:10 file_ccc
-rwx------. 1 [email protected] [email protected] 0 Nov 19 15:14 file_ccc.txt
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:27 file_ddd
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:28 file_eee
Example Windows Client access
PS C:\Users\Administrator> net use X: \\kvb.blackdog.coda.local\kvb /User:[email protected]
Geben Sie das Kennwort für "[email protected]" ein, um eine Verbindung mit
"kvb.blackdog.coda.local" herzustellen:XXXXXXXX
Der Befehl wurde erfolgreich ausgeführt.
2016 EMC Proven Professional Knowledge Sharing 19
-sh-4.2$ ls -l blackdog_kvb
total 12
-rwxrw-r--. 1 [email protected] [email protected] 0 Nov 19 14:56 file_aaa
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 24 14:08 file_aaa_1
-rwxrwx---. 1 [email protected] [email protected] 0 Nov 19 14:58 file_bbb.txt
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:10 file_ccc
-rwx------. 1 [email protected] [email protected] 0 Nov 24 14:17 file_ccc_1.txt
-rwx------. 1 [email protected] [email protected] 0 Nov 19 15:14 file_ccc.txt
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:27 file_ddd
-rw-r--r--. 1 [email protected] [email protected] 0 Nov 19 15:28 file_eee
NFSv4 ACLs
While there are Unix/Linux distributions which support ACLs on their file system, remote support of ACLs via NFS is only implemented since NFSv4. To use NFSv4 ACLs it’s necessary to install an additional package at the NFS Client.
[root@blacknight ~]# yum install nfs4-acl-tools
-sh-4.2$ nfs4_getfacl /mnt/blackdog_kvb/file_ccc_1.txt
A::OWNER@:rwadxtTnNcCoy
-sh-4.2$ nfs4_getfacl /mnt/blackdog_kvb/file_ccc
A::OWNER@:rwatTnNcCy
A::GROUP@:rtncy
A::EVERYONE@:rtncy
-sh-4.2$ nfs4_getfacl /mnt/blackdog_kvb/file_aaa
A::EVERYONE@:rtncy
A::OWNER@:rwadxtTnNcCoy
A::OWNER@:rwaxtTnNcCy
A::GROUP@:rwatTnNcy
Summary
The OneFS Unified Security Model supports a wide range of configuration options to apply to nearly any multiprotocol requirement. NFSv4 is supported with auth_sys authentication and also with the kerberos options auth_krb, auth_krbi, auth_krbp, for higher security. Implementation and configuration of NFSv4 and NFSv4_krb in particular is much more complex than NFSv3. As an alternative to the setup shown here, it would be also possible to set up a separate directory service for Unix (openLDAP, ApacheDS for instance). The KDC could also be separated (MIT) or integrated in ApacheDS, for instance.
2016 EMC Proven Professional Knowledge Sharing 20
Further Reading
I. NTFS TECHNICAL REFERENCE
II. RESILIENT FILE SYSTEM OVERVIEW
III. WINDOWS SERVER 2008, WINDOWS 7 - MANAGING PERMISSIONS
IV. UNDERSTANDING WINDOWS FILE AND REGISTRY PERMISSIONS
V. FILE SYSTEM PERMISSIONS
VI. UNIX FILE AND DIRECTORY PERMISSIONS AND MODES
VII. UNIX PERMISSIONS CALCULATOR
VIII. WHITE PAPER: ONEFS MULTIPROTOCOL SECURITY UNTANGLED
IX. IDENTITIES, ACCESS TOKENS, AND THE ISILON ONEFS USER MAPPING SERVICE
X. WHITE PAPER: EMC ISILON MULTIPROTOCOL DATA ACCESS WITH A UNIFIED SECURITY MODEL FOR SMB AND NFS
XI. WELL-KNOWN SIDS
XII. HOW SECURITY DESCRIPTORS AND ACCESS CONTROL LISTS WORK
Dell EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” DELL EMC MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying and distribution of any Dell EMC software described in this publication requires an applicable software license.
Dell, EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries.