Possible secmap issue?

Question

I have recently begun to receive reports from new users that they are not receiving some drive mappings to shares on our Celerra the first few times that they log in. There should be two shares on the Celerra (one just a standard share, the other is the HOME share from Celerra Home Directory) that the users receive at log in, but it the first time they log in they get neither of them, if they try another day they then get both mappings and it all seems okay from then on. The amount of time between first log in and the log in when they finally receive the drive mappings seems to vary, and to make it a little more unusual, they will often get one of the drive mappings on log ins after the first, but not receive the second drive mapping until a few more logins.

The error that is reported by the (VBscript) login script when mapping the drive(s) is "Could not create drive: The specified user does not exist.". Based on that error, my initial guess was that perhaps the users did not have a uidNumber and therefore there was no SID to UID mapping occuring, however I have been able to confirm that they do infact have a uidNumber.

So, my next guess is that perhaps there is a delay with the uidNumber lookup during the drive mapping which is causing a delay, but I cannot be sure of that. A few things I have noticed, but may just be red herrings:

1) The server_log for the data mover logs quite a lot of the following entries:

USRMAP: 6:[MYVDMNAME] Broadcast timeout, No answer received.

2) Looking at the secmap entry for the users, the "Date of creation" matches the date that they first start getting one of the two drives, as opposed to when they were first attempting to map a share on the Celerra.

Unfortunately, the reports are not coming to me instantly, so for most of the users who have reported this issue, it has already rectified itself. My concern here is that, while it does eventually "fix" itself, I would like to know what is happening, and if possible avoid the issue occuring in the first place.

Has anyone experienced a similar issue to this? Any idea whether the message generated by USRMAP in the server_log is relevant at all and if it points to an actual cause.

We are currently running DART 5.6.49-3, and not using the Celerra usermapper service, we have the idMU schema extensions for AD, and Celerra naming services using AD for the user and group IDs.

If this is related to secmap, are there any limitations to the size the secmap list can grow to for each DM or VDM? We have close to 70,000 entries, so wondering whether this would need clearing up, or does secmap do any of its own maintenane to remove perhaps old entries that have not been used for a while?

Thanks

bergec · Answer

I think this is more related to Ldap client on the Data Mover timing out trying to get a mapping

The error you see about Usermapper bcast is because you don't have the service running (how many Data Movers in your configuration?)

Unfortunately I do not think that the Ldap client will log a message in server_log if it cannot get a mapping. You have to open a SR so that someone from Tech Support increases Ldap logging in order to have a chance to see something in server_log

Claude

PebbleMatt · Answer

I should have considered the possibility of it being an LDAP client issue, I will open a SR and see what tech support say.  Thanks.

Rainer_EMC · Answer

As Claude said its much more likely to be an LDAP issue Since DART 5.6.36.4 secmap actually uses a database instead of rootfs entries so its quite fast and scalable Rainer

Jeffey1 · Answer

Please using the command server_cifssupport to check secmap.

PebbleMatt · Answer

@Jeffey, how in particular are you suggesting I check secmap by using the server_cifssupport? As mentioned in my description of the issue, the users who are having issues mapping to shares on the CIFS servers are those who do not have an mapping entry in the secmap table. But the question is, why? Eventually their uid/sid will be created in secmap and future share mappings then work, but it seems to take several attempts mapping to a share for the entry to be created in secmap.

@bergec, you mentioned that Tech support could increase ldap logging, that is not something that they have suggested or done yet. I will try pushing for them to do that since the tcp dump has not yet revealed anything, other than ldap queries are possibly not occuring.

I am currently still working with EMC support to resolve this issue without much sucess so far unfortunately. I have provided EMC with a tcpdump of the IPs of the DCs, and then provided them with some usernames and times of logins, but they said that at those times when I reported a user logged in but did not receive a mapping, there was no ldap query reported in the dump file, but the times I indicated that they (the users) logged in and did then manage to get the share mappings, there were ldap queries logged. One of the problems with the trace is that we have had to do one IP at a time, so it is possible that for the times we ran a trace for failed users, they ldap client possibly used on one of the other DCs for the ldap query. Trying to find out now if we can run multiple tcp dumps at the same time, cannot run an unfiltered dump as the files get too large too quickly.

Jeffey1 · Answer

Pebble, could you please do the following check?

How many Celerras do you use?

please verify the status of the usermapper service, use this command syntax: server_usermapper server_X. Is it a primary, secondary or client? please take notes.

Use the command "server_cifs server_x" and "more /etc/nsswitch.conf" to check NAS and let us know the result.

Using the command "server_cifssupport -secmap -list" or "server_cifssupport -secmap -verify {name -domain | -sid }" to check the secmap status after a new client login in and take note.

Jeffey1 · Answer

Yeah, By default NIS have more higher priority than LDAP in the secmap, we could adjust it in the nsswitch.conf file.

urle · Answer

Just for the records: we face the same problems with NIS instead of LDAP. As a workaround we use cifssupport -secmap -create when we add new accounts to our NIS/LDAP.

PebbleMatt · Answer

@Jeffey, we are not using the usermapper service. We have AD extended with the idMU schema extensions.

I am guessing that you actually meant for me to check the nsswitch.conf file of the data movers as opposed to the control station nsswitch.conf file. The nsswitch.conf for the data mover contains only the following:

passwd: ldap files

group: ldap files

hosts: ldap dns files

We removed all other references (such as nis) from the nsswitch.conf file a long time ago.

The problem, and the point is, that new users are not always having an entry created in secmap, it seems intermittent as to whether it does create it on the first attempt at mapping a network drive on the Celerra, or whether it creates only after several attempts.

@urle, we can manually create the entries (tested it once I noticed that users did not have secmap entries being created), but we have a lot of users who do not necessarily ever log in, so I do not want to create secmap entries for every single user.

bergec · Answer

Not sure if that applies to your configuration but it could be that when a nrw user is created (along with Ldap info) this will go to one DC (eg DC1) but when that user logs in the the Data Mover talks to another DC (eg DC2) for Ldap mapping, but at that time AD replication between DC1 and DC2 is not finished

Claude

Celerra

Possible secmap issue?

Was this post helpful?