This post is more than 5 years old
11 Posts
0
2502
Isilon usermapper rule with wildcard is not working
Hi All,
I have NIS & AD configured in my isilon, for the multi-protocol environment I am trying the change the AD user primary group from "domain users" to that of the primary group from his/her unix account.
So the usermapper rule for this is '*\* += * [group]', but this is not working. The AD user access token is still showing "domain users" as the primary group.
Where as if I create a rule specific to any single user like '*\user01 += user01 [group]' it is working just as expected.
Has anyone experienced this issue? If so how was it resolved?
Regards,
Abhilash.
abhilas945
11 Posts
1
June 29th, 2016 06:00
finally! I got the solution few days back from the support.
My NIS users have first letter in uppercase!, normalization is already enabled for AD users and somehow it is not enabled for NIS users.
The below command has normalized the NIS users & groups, after this point the usermapper rules started working.
isi auth nis modify --normalize-groups=1 --normalize-users=1
addisdaddy20
65 Posts
0
May 23rd, 2016 13:00
I would suggest be explicit with user mapping rules, I cannot find anywhere that states wildcards are supported/unsupported anywhere but I did have an issue with one of my customers where we were using mapping rules that were not explicitly correct both in syntax and naming convention and it appeared to take and create the rule but did not correctly apply the rule to the desired user.
The end result was to ensure that our usernames and groups were explicitly correct as I understand user mapping does not do any username validation so I would expect this to be part of your problem.
are you able to validate if you call the names directly/correctly does it apply the mapping rules as expected?
Peter_Sero
1.2K Posts
1
May 23rd, 2016 20:00
Wildcards are a powerful tool for user mapping -- have you seen this
Whitepaper?
https://support.emc.com/docu50075_Identities,-Access-Tokens,-and-the-Isilon-OneFS-User-Mapping-Service.pdf?language=en_U…
Page 26 gives some examples how wildcards can be applied, and what will NOT work.
Your case '*\* += * [group]', is not exactly covered -- but most likely the mapper cannot make sense of finding two wildcards on the left side and only one on the right side. Try:
YOURDOMAIN\* += * [group]
hth
-- Peter
Adam_M1
16 Posts
0
May 23rd, 2016 20:00
We use LDAP & AD in our environment,
the rule we use is
User Mapping Rules: yourdomainhere\* += * [group,groups]
all our accounts are in one domain, so it was obvious for us not to use a wildcard for the domain.
the += to insert
the [group,groups] to get primary group set and additional unix groups inserted into the identity.
our unix shares, available via SMB and NFS have no ACL's applied ( chmod -b ), and prevent ACL's via the SMB share
when SMB files are created they get the MASK as configured in the SMB share, and the primary group is set on the file, as viewed from NFS.
There is one more option in the ACL's section of the webgui, "Group owner inheritance:" is set to:
If you don't have any ACL on the parent directory, you may be getting the BSD behaviour:
This could be affecting your results.
abhilas945
11 Posts
0
May 24th, 2016 03:00
Yes Peter, I been following the same document. On page-37 under "Getting the primary group from LDAP" topic it explains the rule.
I tried with the domain name too, but it is still now working.
Peter_Sero
1.2K Posts
0
May 25th, 2016 03:00
Next thing you may try is a step by step walk through
of the Troubleshooting Identity Mapping guide
https://www.emc.com/collateral/TechnicalDocument/docu63138.pdf
which is also linked among many other guides here:
Customer Troubleshooting - Isilon Info Hub
The solution could be just a matter of flushing the right cache or something,
which is all covered in the troubleshooting guide.
Another tip from me: Start an isolated, fresh test on an OneFS simulator aka virtual node...
-- Peter