Actually we always recommend not to use usermapper when customers want to do real multi-protocol access

I know its convinient but IMHO it shouldnt even be called usermapper since you cant configure its mapping - it just hands out unique free IDs

Usermapper is the problem here. This stores the gidNumber and uidNumbers internally to the DataMover so the Linux clients can't get at these mappings unless you do some work. It is possible to dump out the mappings from usermapper (see docs) and then add these to whatever user directory (NIS/LDAP) you have for your Linux clients. You need this for the user details to match up over the NFS mounts.

This is a pain in the proverbial though as you'll need to regularly update the maps migrated from usermapper to the Linux directory.

Personally I'd recommend migrating away from usermapper as it is less than ideal for UNIX or multiprotocol environments. As the multiprotocol and usermapper docs suggest, it only really makes sense in a windows only environment.

As far as a better place to store the mappings are concerned Active Directory (AD) is a decent place. Avoid Services for UNIX at all costs. (SFU). Windows 2003R2 and later have "proper" support for RFC2307 LDAP schemas. This is better regardless of whether you are using NIS or LDAP for your UNIX directory service. You don't even need to use IdMU for AD as the 2307 schema is in AD already.

Also be aware of the differences between RFC2307 and RFC2307bis. DART only supports 2307 for user and group data (memberUid for group memberships is supported but not member or uniqueMember which is what AD does). We've had a major headache with this as AD can only support around 1,000 memberUid entries per posixGroup object. member (same semantics as uniqueMember) is a "linked" attribute though and has the standard AD group membership limits.

Are you sure about that ?

Did you get a case through to engineering to see if this is planned to be changed ?

Dart 5.6.46-4 support getting attributes straight from AD's member attribute. So there's no limitation in AD side (member is linked attribute so there's no ~1000 user limit).

Server_ldap doesn's show members from large groups though. I have opened a case for that and it's under investigation if it's a real problem or just a problem with server_ldap command.

--
Jussi

Hi Jussi,

thanks for letting us know.

Would you like to tell us how you are using AD and how many users ?

regards
Rainer

About server_ldap

It seems like server_ldap command doesn't support paging.

I ran packet capture and sent it to emc support
---quote from emc support---
I could see type: member;range=0-1499 and the packet capture shows as vals: 1500 items and the user details(Only in packet capture).
---quote from emc support---

I really hope that it's only server_ldap command that doesn't support paging or I'll have to wait for another dart release.

I don't see disabling paging from AD's ldap as a real option. It's fine if you have only few thousand users but not in our environment.

--
Jussi

We read the uids from AD. And hopefully in near future also the gids.
We have about 25000 thousand active users and 50000 total.

--
Jussi

Ha, I have an Enhancement Request open for this. I did indeed open an SR to confirm that DART (5.6.42 at the time) did not support using the member/uniqueMember linked attributes for group memberships.

Nice of them to let me know that it's in the newer releases.

Seems like celerra doesn't support AD's ldap properly yet.

---quote from emc support---
If there are more users than ~1500 (not sure about exact number), the LDAP server responds differently, and it appears that DM does not handle this.
This is not only impact server_ldap -lookup output but also impact user access, since if a group contains more than 1500 users, the search will not be successful and a user in the group could be denied access.
---quote from emc support---

But I'm still waiting for update to that case. 1500 is the paging limit so it seems like paging isn't supported (yet I really hope).

--
Jussi

Celerra's ldap against AD doesn't work properly. It doesn't support paging.

It will be fixed within 3-6 months says the support.

--
Jussi

This is an absolute pain!