Isilion --Synthetic ACL

Synthetic ACLs come into play  ONLY when just the UNIX bits a la rwx are stored in the file system for a given file. Is that the case with your setup, or do you have actual ACLs set? (in which case no UNIX bits are stored and UNIX clients show "approximate" bits on the fly).

Useful docs:

Whitepaper: ACE/POSIX Interaction in OneFS https://support.emc.com/kb/428259

https://support.emc.com/docu53353_White-Paper:-OneFS-Multiprotocol-Security-Untangled.pdf?language=en_US

hth

-- Peter

Pete,

Thanks for the reply, actually the client is using NIS for Linux and AD for Windows servers.

Lot of issues with syntehtic ACL while using NIS. Is there any solution while we migration from Netapp to Islion One FS 7.2

Will appreciate your inputs.

Not with a single push of button...

You will need to understand how Windows (AD) and NIS user identities are mapped onto each other in the environment,

and then set up the quite flexible and powerful identity mapping on the Isilon accordingly.

For example, has the AD also the exact NIS UIDs and GIDs? (Google for RFC2307)

Or are just the textual user names identical?

Cheers

-- Peter

AD and NIS usernames are similar only but not exact word to word match. When the file was modified and saved by either Windows or Linux client, it would deny the access of the opposite client type.  So we have to manually go back in and reset Synthetic permissions.

How about we forget about NIS and consider a single authentication source for both clients (Linux and Windows), so the client is seen by Isilon as single user, preferably AD, and a single set of ACL’s from that authentication source.

Sure, if you actually have the chance to make the cut and implement a single source of truth, go for it!

Helpful KB:

OneFS: How to configure OneFS and Active Directory for RFC2307 compliance?

EMC Tech support have to say this as below, but we are running now OneFS 7.2

NIS is supported as an external authentication provider in OneFS 8.x. You can add NIS provider to an access zone as an authentication method for clients. An access zone can include at most one NIS provider.

Again I have this from microsoft for this.

https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/

It sounds like you're trying to do multiprotocol access (Windows and Unix/Linux access to the same files).

It also sounds like your authentication sources aren't correctly configured/aligned (more on this below).

A "synthetic ACL" doesn't exist on the filesystem. It is "synthesized" (created in memory on the fly) when a client that only understands ACLs (e.g. a Windows client) queries the permissions on a file and that file only has POSIX permissions (as Peter said).

If what you're seeing is that files created on one side are inaccessible to the other, then your AD and NIS are not correctly configured into the zone on the cluster, or the names don't match.

When this is all working, the normal functionality is as follows:

Unix/Linux clients accessing the cluster via NFSv3 will send and receive numeric uids and gids over the wire and that's what will be written to files and what is used for authorization. There is no authentication in NFSv3 unless you are using Kerberos.

Meanwhile, Windows clients accessing the cluster *do* authenticate (it's part of the protocol). As part of the authentication, when a name (e.g. DOMAIN\user) is looked up in AD, the ads provider on the cluster automatically looks up "user" in the Unix providers (local, file, NIS, LDAP), and if that user is found, then the Unix credentials are added to the token. In doing so, this gives the Window user access to files that were created from the NFS side, and also ensures that the identities that it writes to disk are the Unix identities (because the default on-disk setting of "native" preferentially writes Unix identities if the token contains real as opposed to cluster-generated uids/gids).

You can verify what was actually written on the cluster by running
# ls -led file
and
# ls -lend file

these will show the permissions with names, and then the same permissions with the underlying identities.

What I am expecting to see in your case is that we wrote SIDs from Windows and uids/gids from Linux which means the needed mapping is not happening.

Tim

HEagle18,

Have you tried any AD to NIS mapping as Tim says?

http://www.emc.com/collateral/white-papers/h12417-identities-access-tokens-isilon-onefs-user-mapping-service-wp.pdf

page 29:

isi zone zones modify --user-mapping-rules=' \* += * [group]' --zone=

Phil

Note that Windows Server will keep the UNIX UIDs and GIDs fields as specified in RFC 2307.

The key is to have the single source of truth, to make the id mapping as simple and fail-safe as possible.

A common practice is feeding a separate NIS -- or LDAP -- for UNIX from the AD...

Take a look at the following series of blog posts to get the full view of how Isilon handles multiprotocol and file permissioning.

EMC Isilon Multiprotocol Concepts Series

@Tim Wright, @Pete,

Is there any way we can have single source from AD, by eliminating  the NIS stuff. In  another words, present the NIS NFS shares as CIFS shares with AD authentication?

We had all working except on write/modify of a file.  Then the opposite client type could no longer access the file. We worked with Isilon support on Inheritance of parent permissions and such to try to correct but we could not get past it.

We manually edited the user token and added the user UID to the token under the guidance of Isilon support.  This allowed us to bypass having the NIS server as an authentication source.  In any case, the problem always came down to file permissions from the opposite client type not being retained after modification.

Modifying the ACL permissions had some adverse effects to how existing shares were functioning