ONEFS UNIFIED SECURITY MODEL

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.


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


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.


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

https://msdn.microsoft.com/en-us/library/cc731178.aspx

http://https/msdn.microsoft.com/en-us/library/cc754871.aspx

http://https/msdn.microsoft.com/en-us/library/cc754202.aspx

http://https/technet.microsoft.com/en-us/library/hh852208.aspx

http://https/technet.microsoft.com/en-us/library/hh852332

https://technet.microsoft.com/en-us/library/hh852326

http://technet.microsoft.com/en-us/library/cc755885(v=ws.10).aspx

http://support.microsoft.com/kb/248717


(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


[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

http://https/access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Windows_Integration_Guide/index.html


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


[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.


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: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

https://bugzilla.redhat.com/show_bug.cgi?id=1116758


--

-- 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 ~]# 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.


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]]]


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.


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

****************************


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]


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.


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.


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"


"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


.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


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


-rw-r--r--. 1 [email protected] [email protected] 0 Nov 24 2015 file_aaa_1






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.


-sh-4.2$ ls -l blackdog_kvb

total 12


-rw-r--r--. 1 [email protected] [email protected] 0 Nov 24 14:08 file_aaa_1



-rwx------. 1 [email protected] [email protected] 0 Nov 24 14:17 file_ccc_1.txt




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.


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.

http://technet.microsoft.com/en-us/library/cc758691(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/hh831724.aspx

http://technet.microsoft.com/en-us/library/cc770962.aspx

http://msdn.microsoft.com/en-us/magazine/cc982153.aspx

https://en.wikipedia.org/wiki/File_system_permissions

http://content.hccfl.edu/pollock/aunix1/filepermissions.htm

http://permissions-calculator.org/

https://support.emc.com/docu53353_White_Paper:_OneFS_Multiprotocol_Security_Untangled.pdf?language=en_US

https://support.emc.com/docu50075_Identities,_Access_Tokens,_and_the_Isilon_OneFS_User_Mapping_Service.pdf?language=en_US

https://support.emc.com/docu42659_White_Paper:_EMC_Isilon_Multiprotocol_Data_Access_with_a_Unified_Security_Model_for_SMB_and_NFS.pdf?language=en_US

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379649(v=vs.85).aspx

http://technet.microsoft.com/en-us/library/cc781716(v=WS.10).aspx

ONEFS UNIFIED SECURITY MODEL

Documents

Transcript of ONEFS UNIFIED SECURITY MODEL