UNSOLVED

whoreallycares

updated

11 years ago

0

2849

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

    •

    8645 Posts

    1314

    1

    Posted 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

  • 1314

    0

    Posted 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

    1317

    0

    Posted 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

    1317

    0

    Posted 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

  • 1317

    0

    Posted 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

    1317

    0

    Posted 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

  • 1317

    0

    Posted 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

    1317

    1

    Posted 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

  • 1317

    0

    Posted 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

    269

    0

    Posted 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