There are a couple of items that may be of relevance when migrating to LDAP.
Number of Group Memberships#
Although not a NIS limitation, it is an OS limitation that could be manifested (or perpetuated) when moving to LDAP.A user can not be a member of more than sixteen (16) groups. There is apparently a limitation of some of the low levels of the Unix/Linux APIs present in most Unix OSs. This limitation should be adhered to within your LDAP migration.
Some more information on this issue:#
What's the deal on the 16 group id limitation in NFS?
and Increasing UNIX group membership - easy, surely?
NFS, or rather AUTH_SYS, can't handle it#
The most obvious breakage is NFS. Strictly speaking it's not NFS that's at fault, it's more a victim. The underlying problem is a limitation in an authentication flavor commonly used - AUTH_SYS - and is pretty much the default. From RFC 1057:
9.2 UNIX Authentication
The client may wish to identify itself as it is identified on a
UNIX(tm) system. The value of the credential's discriminant of an
RPC call message is "AUTH_UNIX". The bytes of the credential's
opaque body encode the the following structure:
struct auth_unix {
unsigned int stamp;
string machinename<255>;
unsigned int uid;
unsigned int gid;
unsigned int gids<16>;
};
In other words, the list of supplementary groups is a variable sized array of up to 16 entries. You simply cannot have more than 16 groups and use AUTH_SYS.
Of course, NFSv4 isn't affected by this as there are plenty of other authentication flavors that are mandatory for clients and servers which are not affected by the group limits. Other applications that do utilize AUTH_SYS maybe affected.
How does Linux handle this?#
If you've been paying attention you might be given to wonder how the Linux 2.6 kernel handles this.Answer? It doesn't, it just truncates the group list at NFS_NGROUPS (16).
Does this Effect LDAP?#
If you have migrated NIS to LDAP, this limitation still exists.Number of Bytes in a Record#
The database used by NIS has a record size limitation of 1024 bytes.This limitation is only when NIS is used. If you are completely off of NIS this limitation is not relevant to a pure LDAP environment. This is due to an underlying DBM database issue; the database has a record size limit of 1,024 bytes.
This seems to show up as an issue within NIS most often with the number of members within a netGroup but could be manifested from any record.
The best solution is to use LDAP instead.
Workaround?#
We saw this used and it appeared to work. The client had implemented groups like cvs. cvs2 and cvs3. All of these groups had the same gidNumber assigned in NIS.So when the limit was reached with cvs, users were then added to cvs2, etc.
As we were going to utilize the N2L gateway, we continued use the same fashion of using the gidNumber on multiple groups.
The only issue we did see was under some circumstances (like using ls -l), we would see cvs2 returned as the groupName when the groups the user was actually a member of was cvs. (Or similar items)