Re: Isilon share access to only specific users from an AD?

Jay,

Yes, there are 2 ways to do this.

1. The most simple approach is to simply use SMB Share ACLs for the security groups that contain the users that you want to have access to a specific share. Turn on ABE (Access Based Enumeration), and then if they don’t have access to the share they won’t even be able to see that it exists. In reality it’s a bit of a false sense of security, however because Share Security should generally be set to Everyone full control, and you should restrict access based upon filesystem permissions (NTFS ACLs in this case). Remember that Security by Obscurity is no Security at all.

2. The other approach if you wanted to for instance only permit users that are in a specific building is to allow or deny specific host systems, or subnets. This is a CLI only option (last time I checked). And you’d do: ‘isi smb share modify <sharename> –host-acl <host_acl>”. Where the <host_acl> is defined like this:

Argument Formats:

<host_acl>

Accepted values are formatted as comma-separated clauses beginning with

allow: or deny: and followed by a range of IP addresses, a subnet, or a

FQDN. Use EXCEPT to add an exception within a clause.

Note:

* The input string must include a deny clause as the final entry.

* EXCEPT and ALL are case-sensitive.

The following examples display correctly formatted option-value pairs.

–host-acl=allow:1.23.4.56

–host-acl=deny:somedomain.com

–host-acl=’allow:1.23.4.56-1.23.4.200 EXCEPT 1.23.4.59′

–host-acl=deny:ALL

–host-acl=deny:subnet2

Anyway hope that makes sense. In general focus more on your filesystem permissions that share or client export lists, and you’ll be in a much better position in the long run.

Hope this makes sense,

~Chris Klosterman

Principal SE, Datadobi

chris.klosterman@datadobi.com

Related:

  • No Related Posts

Isilon share access to only specific users from an AD?

Jay,

Yes, there are 2 ways to do this.

1. The most simple approach is to simply use SMB Share ACLs for the security groups that contain the users that you want to have access to a specific share. Turn on ABE (Access Based Enumeration), and then if they don’t have access to the share they won’t even be able to see that it exists. In reality it’s a bit of a false sense of security, however because Share Security should generally be set to Everyone full control, and you should restrict access based upon filesystem permissions (NTFS ACLs in this case). Remember that Security by Obscurity is no Security at all.

2. The other approach if you wanted to for instance only permit users that are in a specific building is to allow or deny specific host systems, or subnets. This is a CLI only option (last time I checked). And you’d do: ‘isi smb share modify <sharename> –host-acl <host_acl>”. Where the <host_acl> is defined like this:

Argument Formats:

<host_acl>

Accepted values are formatted as comma-separated clauses beginning with

allow: or deny: and followed by a range of IP addresses, a subnet, or a

FQDN. Use EXCEPT to add an exception within a clause.

Note:

* The input string must include a deny clause as the final entry.

* EXCEPT and ALL are case-sensitive.

The following examples display correctly formatted option-value pairs.

–host-acl=allow:1.23.4.56

–host-acl=deny:somedomain.com

–host-acl=’allow:1.23.4.56-1.23.4.200 EXCEPT 1.23.4.59′

–host-acl=deny:ALL

–host-acl=deny:subnet2

Anyway hope that makes sense. In general focus more on your filesystem permissions that share or client export lists, and you’ll be in a much better position in the long run.

Hope this makes sense,

~Chris Klosterman

Principal SE, Datadobi

chris.klosterman@datadobi.com

Related:

  • No Related Posts

Permissions Repair Job – Part 1

The OneFS job engine provides a Permission Repair job which, as the name suggests, provides an automated way to fix and manage access controls across a dataset. The job is run against a target, which can be a file or directory under /ifs. Depending on the job mode Pemission Repair enables:

  • Permissions to be copied from a template to target
  • The target to acquire inheritable permissions from a template
  • Changing the on-disk identity type stored within files and directories



Compared to the UNIX ‘chmod’ command, Permission Repair is considerably more efficient becuase it performs its operations in parallel across all nodes in the cluster (albeit using the same system calls that chmod uses). As such, Permission Repair is a much faster way to effect large scale permissions changes across a sizable directory tree.



The Permission Repair job itself can be run in three different modes:

Mode

Description

Clone

Applies the permissions settings for the directory specified by the Template File or Directory setting to the directory you set in the Paths fields.

Convert

For each file and directory in the specified Paths fields, converts the owner, group, and access control list (ACL) to the target on-disk identity based on the Mapping Type setting.

Inherit

Recursively applies the access control list (ACL) of the directory that is specified by the Template File or Directory setting to each file and subdirectory in the specified Paths fields, according to standard inheritance rules.

The job can be initiated via the OneFS WebUI by navigating to Cluster Management > Job Operations > Job Types > PermissionRepair > Start Job.

Or via the ‘isi job jobs start’ CLI command, with the following available options:



–path=<ifs-directory> Path to delete.

–mode=<clone | inherit | convert> Mode for PermissionRepair. (clone, inherit or convert)

–type=<system | sid | unix | native> Type for PermissionRepair. (system, native, unix, or sid)

–zone=<zone-name> Authentication zone for PermissionRepair convert

–template=<ifs-path> Template file/directory for PermissionRepair

But first, a quick review of OneFS permissions configuration and reporting.



For OneFS to natively support concurrent, multi-protocol data access, it maps the POSIX mode bits from the NFS world to the access control model of the Windows SMB protocol, and vice versa. To achieve this, OneFS provides:



  • Transparent mapping of an on-disk identity to the correct requesting protocol.
  • Equivalency method to transform authoritative permissions into a form that the requesting access protocol can comprehend.
  • Permissions representation of where one permission style (ie. ACL) is authoritative and the other an approximation (ie. mode bits).
  • The ability to configure how OneFS manages permissions for different environments.
  • A default access control policy that optimally merges new permissions with existing ones.
  • A ‘Synthetic ACL’ that approximates the mode bits of a UNIX file for an SMB client.

Within OneFS, each ACE within a security descriptor is displayed as a single line prefaced by an index number and containing the following:

ACE Property

Description

Identity

The identity to which the ACE applies

Allow or Deny

Whether the ACE allows or denies the permissions listed as part of the ACE

Permissions

A list of one or more permissions that are allowed or denied by the ACE

Permissions words

These indicate flags that affect inheritance behavior, if present in the ACE

The identity can be one of three types: user (listed as “user:”), group (listed as “group:”), or the special identity, everyone. For directories, it can also be one of two special template identities: creator_owner or creator_group. When present in the ACL of a containing directory, these template identities are replaced in the ACL of a newly created file system object with the specific user and group of the respective creator.

An ACE can optionally contain flags that specify whether it is inherited by subdirectories and/or files. Inheritance takes place when objects are created. Modifying an inherited rule affects only new files and subdirectories, as opposed to existing ones.

The following flags specify the types of inheritance for permissions in the ACE:

Inheritance Type

Description

Object_inherit

Only files in this directory and its descendants inherit the ACE.

Container_inherit

Only directories in this directory and its descendants inherit the ACE

No_prop_inherit

This ACE will not propagate to descendants (applies to object_inherit and container_inherit ACEs)

Inherit_only

The ACE does not apply for permissions to this object, but will apply to descendants when inherited

Inherited_ace

The ACE was inherited

To help support multi-protocol permissions mapping, OneFS has extended the ‘chmod’ and ‘ls’ CLI commands to provide more fine grained access control configuration and reporting.



In OneFS, the ‘ls’ command has a ‘-e’ flag extension, which reports on any Windows-style Access Control Entries (ACEs) the security descriptor contains, in addition to the traditional POSIX mode bits. For example, consider the following file: /ifs/data/file1.txt.

A regular long listing (ls –l) on this file shows the POSIX mode bits (644), as expected:

# ls -l /ifs/data/file1

-rw-r–r– + 1 root wheel 6 Feb 12 10:49 /ifs/data/file2

Note the plus (`+’) character following the mode bit representations. This plus indicates that either the file has an NTFS ACL, or a security descriptor and the ACL is NULL. A space here (‘ ‘) indicates there is no security descriptor. Every file will have a default synthetic ACL that is created on the fly, based on the file’s mode bits. A file with a synthetic ACL will not have a plus `+’ next to it, although the ACL will still be viewable if the -e option is used. The (`+o’) output indicates that a file is wide-open in terms of permissions.

Adding the ‘e’ flag to the command returns both the mode bits, plus the ACL contents:

# ls -le /ifs/data/file1

-rw-r–r– 1 root wheel 6 Feb 12 10:49 /ifs/data/file1

OWNER: user:root

GROUP: group:wheel

SYNTHETIC ACL

0: user:root allow file_gen_read,file_gen_write,std_write_dac

1: group:wheel allow file_gen_read

2: everyone allow file_gen_read

Note: The ‘–e’ option for the ‘ls’ command (or the ability to view ACL information in addition to mode bits) will not be available from any NFS clients that remotely mount a OneFS export.

Similarly, the ‘chmod’ command in OneFS has an ‘a’ mode extension, which allows for ACL and ACE (re)configuration. This includes:

Chmod ‘A’ Mode

Description

+a

Inserts a new ACE into the canonical location in the ACL. If the supplied entry refers to an identity already listed, the two entries are combined.

-a

Deletes ACL entries. All entries exactly matching the supplied entry will be deleted. If the entry lists a subset of rights granted by an entry, only the rights listed are removed. Generic rights (generic_all, generic_read, etc.) can not be subtracted, they can only be added.

+a#

When a specific ordering is required, the exact location at which an entry will be inserted is specified with the +a# mode.

=a#

Individual entries are rewritten using the =a# mode. Note: Some shells require “=” to be escaped with the “” character.

For example, the following command will add a ‘deny file read’ ACE for the group ‘Administrators’:

# chmod +a group administrators deny file_read /ifs/data/file1

# ls -le /ifs/data/file1

-rw-r–r– + 1 root wheel 6 Feb 12 10:49 /ifs/data/file1

OWNER: user:root

GROUP: group:wheel

0: group:Administrators deny file_read

1: user:root allow file_gen_read,file_gen_write,std_write_dac

2: group:wheel allow file_gen_read

3: everyone allow file_gen_read

Since mode bits are a subset of the more comprehensive Windows ACL model, mapping mode bits to ACLs is straightforward. When a Windows client changes the permissions of a file with an ACL, no information is lost because OneFS stores the original ACL and replaces it. Similarly, when a Windows client changes the permissions of a file with mode bits, OneFS replaces the file’s synthetic ACL with an actual ACL which is equivalent to the mode bits. However, things get a little trickier when the permissions of a file protected by an ACL are a modified via chmod. OneFS must map the permission changes between two non-corresponding security models. To do so, OneFS, in its default setting, merges the ACL with a patch derived from the change in mode bits.



For example, consider the file ‘file2.txt’. This file was created by a Windows client, and the permissions listed are the generic access rights for files and directories. OneFS correctly approximates the mode bits as ‘764’:

# ls -le file2.txt

-rwxrw-r– + 1 WIND1jdoe WIND1tme 2056 Feb 12 10:18

file2.txt

OWNER: user:WIND1jdoe

GROUP: group:WIND1tme

0: user:WIND1jdoe allow

file_gen_read,file_gen_write,file_gen_execute,std_write_dac

1: group:WIND1tme allow file_gen_read,file_gen_write

2: everyone allow file_gen_read

If the mode bits are changed from ‘764’ to ‘744’, OneFS removes the write permission of the primary group, while preserving the other permissions:

# chmod 744 file2.txt

# ls -le file2.txt

-rwxr–r– + 1 WIND1jdoe WIND1tme 2056 Feb 12 10:18

file2.txt

OWNER: user:WIND1jdoe

GROUP: group:WIND1tme

0: user:WIND1jdoe allow

file_gen_read,file_gen_write,file_gen_execute,std_write_dac

1: group:WIND1tme allow file_gen_read

2: everyone allow file_gen_read

In most cases, a result like this preserves the ACL information and minimizes conflicts between actual and expected behavior. However, there are some anomalies to be aware of.



Here’s an example where the mode bits and ACEs do not map directly. If the mode bits on the file (file3.txt) are changed from 750 (rwxr-x—) to 650 (rw-r-x—), the resulting merge removes the right to modify the owner in the object’s security descriptor, leaving the user with the standard right to modify the discretionary access control list in the object’s security descriptor:

# chmod 650 file3.txt

# ls -le file3.txt

-rwxr-x— + 1 WIND1jdoe WIND1tme 807 Feb 12 10:19

  1. print.css

OWNER: user: WIND1jdoe

GROUP: group: WIND1tme

0: user: WIND1jdoe allow

file_gen_read,file_gen_write,std_write_dac

1: group: WIND1tme allow file_gen_read,file_gen_execute

2: everyone allow std_read_dac,std_synchronize,file_read_attr



The following table attempts to provide an equivalency of permissions entities between Windows access rights, POSIX mode bits, and OneFS permissions.

POSIX Mode Bits (Approximation)

OneFS Representation

Windows ACE

d-w

add_file

FILE_ADD_FILE

d-w

add_subdir

FILE_ADD_SUBDIRECTORY

drwx or -rwx

dir_gen_all, file_gen_all

FILE_ALL_ACCESS

–w- or d-w

append, add_subdir

FILE_APPEND_DATA

d-w

delete_child

FILE_DELETE_CHILD

—x

execute

FILE_EXECUTE

dr–

list

FILE_LIST_DIRECTORY

-r–

file_read_attr

FILE_READ_ATTRIBUTES

-r–

file_read

FILE_READ_DATA

-r–

file_read_ext_attr

FILE_READ_EA

d–x

traverse

FILE_TRAVERSE

–w

file_write_attr

FILE_WRITE_ATTRIBUTES

–w

file_write

FILE_WRITE_DATA

–w

file_write_ext_attr

FILE_WRITE_EA

d-w- or –w

std_delete

DELETE

dr– or -r–

std_read_dac

READ_CONTROL

drwx or -rwx

std_write_dac

WRITE_DAC

drwx or -rwx

std_write_owner

WRITE_OWNER

N/A

std_synchronize

SYNCHRONIZE

In the next blog article in this series, we’ll take a closer look at the three Permissions Repair job modes.

Related:

  • No Related Posts

Re: Control Batches Permissions using Code

Hello Hosam,

I believe you were referring to Access Control List at the process level and provide access to particular users/groups.

ACL‘s allow definition of access permission for modules, departments, batches, and processes. The Access Control List window is displayed from any pane displaying modules, departments, batches, or processes. The Access Control List window can remain open while browsing in Captiva Administrator.

Depending on granted permissions, some of these options may be disabled in Captiva Administrator.

Refer to Access Control List Window available @ Administration Guide > Using Captiva Administrator > Captiva Administrator Reference > Windows > Access Control List

Captiva Administrator enables administrators to configure roles and assign permissions to individuals responsible for performing tasks in Captiva Administrator.

A list of the predefined roles for Captiva Capture are available @ Administration Guide > Using Captiva Administrator > Captiva Administrator Reference > Predefined Roles

The below links will lead you to configure and defining the roles for your implementation of ACL’s

Administration Guide > Using Captiva Administrator > Managing Captiva Capture using the Captiva Administrator > Managing Security > Configuring Roles

Administration Guide > Using Captiva Administrator > Managing Captiva Capture using the Captiva Administrator > Managing Security > Configuring Roles > Defining Roles, Role Members, and Role Permissions

When a process is installed to the server, it inherits certain default ACL information which is where the “Everyone” is coming from.

Please follow the event sequence.

1) Install new process

2) AddRemove default ACLs from it

Hope the above helps.

Regards,

Naresh Kumar.

Related:

The inherited access control list (ACL) or access control entry (ACE) could not be built.

Details
Product: Windows Operating System
Event ID: 1340
Source: Security
Version: 5.0
Component: System Resources
Symbolic Name: ERROR_BAD_INHERITANCE_ACL
Message: The inherited access control list (ACL) or access control entry (ACE) could not be built.
   
Explanation

For example, the length of the system access control list (SACL) might be shorter than the sum of the lengths of the access control entries (ACEs) in the SACL.

   
User Action

Use the access control list editor to fix the structure of the ACL.

Related:

Automating Cisco ACL changes

I’ve recently started taking on more network management tasks to help our short staffed networking team. I’m very comfortable with network theory and have configured an number of IOS devices, but am hardly a IOS guru.

One of the first large tasks I was assigned was to add some ACL rules to a hundred plus ACLs we have. Coming from the sys admin side of things, I was baffled to find out that these changes are all made by hand.

Is there not a way to automate these types of configuration issues? What tools should I be learning to use for changing configurations in a scripted fashion across many devices/ACLs? So far my Googlefu has only pointed to Python with pexpect. Just seems like this is such a common task that there would be better tools already setup for it.

I understand that this could be a fairly broad question, but I’m just looking for a starting place to work from.

Note: If there is a commercial tool that is a perfect fit for this case, just assume that we didn’t pay for it. That is normally how it goes.

Related: