In theory you could do it manually via the CLI; but the issue that you're of course seeing is that the SID listed in your command output is just a generic local one, with the UID appended to it.  You might be able to customize the LDAP provider on the cluster's schema to perhaps get it to ask for the correct attribute.  Alternatively if you could get it to work, you could join the cluster the the SAMBA domain's representation of AD, but I know there are a number of pitfalls there, and it may not be fully supported.

Your syntax might look something like this to add the SID manually;

isilon-1# isi smb share permission create --sid -d allow -p full

The trouble is that the cluster doesn't know that UID 34360 is the same as the SID for SAMBA\xmuster ending in 69720 that you listed above.  You may need a user mapping rule to make that happen.

Hi Chris,

thanks for the explanation. The creation rule of samba is

(uidNumber * 2) + 1000

Seems not to be that simple to create a user mapping rule in OneFS.

User mapping rules in OneFS are all about joining together two different users into a single persona.  This is best viewed from the CLI as 'isi auth mapping token domain\\username' and 'isi auth mapping token username'. The goal is that the output of the 2 commands match, so that the user coming in over SMB and using AD (or SAMBA) as the auth provider and the user coming in over NFS, and being looked up via LDAP have the same:

UID (from LDAP)

GID (from LDAP)

SID (from AD)

&
Secondary groups (a merged list of those provided by the 2 different auth providers).

Let's look at this the other way, if you had AD w/ RFC2307 extensions enabled (Services for Unix), then we would want all of that info to come from a single auth source, so your goal with LDAP should be no different.  There are ways to customize the LDAP Schema, and what attributes are pulled, so perhaps play with that? 

All of this said, if this cluster is in production, don't touch it.  Deploy a virtual cluster / Isilon Simulator on VMware and play with this configuration there until you get the behavior that you're looking for.

As to user mapping rules, here is a setup with wildcards that that I've used in the past; domain info omitted for obvious reasons (also these were written for 7.2, it'll probably be a bit different in newer versions of OneFS):

#NIS and AD in system zone

#The user mapping rules

isi zone zones modify --add-user-mapping-rules='DOMAIN\* ++ * [groups]' System

isi zone zones modify --add-user-mapping-rules='DOMAIN\* &= * []' System

isi zone zones modify --add-user-mapping-rules='DOMAIN\* += * [group,groups]' System

#This one is dangerous, if set to NO, users without a valid UID/GID will not have one generated by the internal mappingDB

isi auth settings global --uid-range-enabled no

isi auth ads modify domain.com --allocate-uids no

#Just saying convert everything to lowercase before comparing

isi auth ads modify domain.com --lookup-normalize-groups yes

isi auth ads modify domain.com --lookup-normalize-users yes

isi auth nis modify engineering --normalize-groups yes

isi auth nis modify engineering --normalize-users yes

#Dump the current mappings

isi auth mapping flush --all

isi_clean_idmap --clean-idmap

Hope this helps;

~Chris