Unsolved
This post is more than 5 years old
25 Posts
0
2828
April 8th, 2010 06:00
secmap entry creation and update/verify inconsistency (?)
Hi,
server_cifssupport server_2 -secmap -update (or -verify) -sid xxxxx
gives different UID mapping than when creating this same SID entry with -create
I'm performing tests with NTXMAP
Windows user W1 is mapped to unix user U1.
Actually both usernames exist on both worlds (DCs for windows, LDAP for unix).
I mean that is NTXMAP was not in use, SID and UID of each username would nicely match.
If user W1 creates a directory on a CIFS share, an entry is automaticaly created in the secmap:
Name is W1
UID is U1's UID
Origin is NTXMAP
This is correct according to the NTXMAP rules.
I get the same result if I do the following:
server_cifssupport server_2 -secmap -create -sid xxxxx
The problem is that if I ask the secmap to be "verified" or "updated", the entry is modified:
Name is still W1
UID is now the true UID of W1
Origin is LDAP
How can -update (or -verify) and -create have different behaviour ?
FYI:
the user mapper running on the DM remains empty during all the test period
I'm running version 5.6.47.11
Eric
Rainer_EMC
6 Operator
•
8.6K Posts
1
April 8th, 2010 07:00
Hi Eric,
welcome to the forum.
Its probably behaving differenty whether you have built a credential with -cred before or not.
Rainer
whoreallycares
25 Posts
0
April 9th, 2010 07:00
Hi,
-cred is an interesting option I didn't have given a try yet.
Thanks for pointing it.
But it does not change the behaviour.
When playing with -cred, the displayed information show that NTXMAP is not taken into account.
-cred shows the TRUE UID for the requested user (same ad -update or -verify do)
Could the test you adviced be irrelevant because of NTcred cache mecanism ?
Eric
bergec
275 Posts
0
April 9th, 2010 07:00
I think you should open a service request for that problem
It looks like secmap bypasses Ntxmap when doing an update
Claude
bergec
275 Posts
0
April 9th, 2010 10:00
Let us know the Service Request number when submitted
The -cred option of server_cifssupport will display all groups the user belongs to and help decypher if the mapping for that user and his groups are correct in case that user has access permission issues.
Claude
whoreallycares
25 Posts
0
April 12th, 2010 00:00
Hi,
I think we should focus on the initial problem.
-create seems to take NTXMAP into account
-verify and -update seems not to
What's the link with -cred ? It's just a way to check what is in the NTcred cache, right ?
Eric
bergec
275 Posts
0
April 13th, 2010 00:00
It looks like it is not working as designed since in your case, secmap is bypassing NTXMAP. This is why I asked if you could open a Service Request
Claude
whoreallycares
25 Posts
0
April 13th, 2010 05:00
Understood. If you feel the same as me (sounds like a bug) I will.
I was presentely stucked with another bug.
I tried to get rid of the NTcred mecanism to avoid any cache effect during the tests.
I crashed our Celerra (non prod system) by setting the NTcred size to 0.
We just recovered from this issue.
May I use the hidden NTcred.enable option to disable NTcreds during the test phase ?
I know how to proceed with .server_config.
It's really unpleasant when tests are fooled by cache mecanism.
bergec
275 Posts
1
April 14th, 2010 15:00
The nfs param NTcred.TTL should work (even if set to 0) and not panic the Data Mover. If this is a bug and reproducible, please submit a Service Request and let is know the SR #
Claude
whoreallycares
25 Posts
0
April 15th, 2010 00:00
Good hint.
Playing with TTL is probably a better option than playing with the size.
You say that setting the TTL to 0 will not make the DM crash.
Hopefully yes. NTcred.size was also supposed to support a 0 value (according to the documentation), but it actually made the DM crash badly...
Anyway, now I know how to recover from this kind of pb.
I will open a SR for this secmap problem, but currently I do have problem in mysupport regarding the site ID my account can access to.
I'm waiting for this to be fixed before opening a SR.
Eric
bergec
275 Posts
0
November 26th, 2015 12:00
Hello
Hard to tell
How are cifs param set on the Data Mover (server_param server_2 –f cifs –list)?
Wondering if that could be an unknown SID coming from a migration and you’ve param “acl.mappingErrorAction” set to a value different from default
Other than that I would open a case with EMC Support
Claude