we use an openldap server as the authentication provider in OneFS 8.1.2. The attribute sambaSID from the samba schema contains the users' SID which is used by our samba servers. Is it possible to use this attribute for smb shares in OneFS? OneFS creates its own default SID for every ldap user. For example:
On our samba servers:
# net sam show xmuster
SAMBA\xmuster is a User with SID S-1-5-21-400xxx2-314xxx9-252xxx7-69720
On our Isilon:
# isi auth users view xmuster
Provider: lsa-ldap-provider:LDAP Cluster
Sam Account Name: xmuster
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 <sharename> --sid <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.
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
Hope this helps;