In some environments the limitation of the NGROUPS_MAX define is a real limitation. Many Windows environments make excessive use of groups to deligate rights to users and it is not unusual that a user is in a couple of hundreds of groups. That's why this limit often is an important criteria for the operating system that a Samba server runs on. Here is an overview of which OSes have which limits. Please keep in mind that as well kernel and libc and friends need to be compiled with the appropriate limit. For example it is not enough to install a 2.6 Linux kernel on an old system which had the 32 NGROUPS_MAX limit.
If you use NFS, make sure you don't use more than 16 groups/user, this is a hard NFS limit. If you use NFS and have more than 16 groups/user you will end up with too few permissions on files (truncation after 16 groups) which can also mean people who should not be able to access files can access them, which may be a security problem.
65536
32
32
Tru64 only allows 32 groups altogether. So only 31 supplementary groups are supported here. If the a user is in more than 31 supplementary groups initgroups fails.
64
128
128 by default but can be configured to be up to 2048
16 (fixed)
FreeBSD is even worse as a bug (or is it a feature?) limits the supplementary groups to 15. The following *BSD systems might be affected by the same or a related problem:
Darwin is also worse - I did not try to figure out why - but "id" just shows 15 groups per user, including the primary group (don't know if Darwin internally makes a difference between primary and supplementary). So in the end there are only 14 supplementary groups supported. Hint: administering groups can be done via Applications->Utilities->netinfo manager.
NetBSD only allows 16 groups altogether. So only 15 supplementary groups are supported here. This was tested with NetBSD 3.0.
So from all mentioned *BSD systems only OpenBSD (tested OpenBSD 4.0) really supports 16 supplementary groups.
1023
16 (can vary from 0-32 by setting "set ngroups_max = 32" in /etc/system and rebooting)
16 (can vary from 0-1024 with patch bundles 144500-07 / 144501-07)
There is was a bug entry (new home at wesunsolve.net after OpenSolaris was shut down, sorry, finally in 2012 Oracle forced wesunsolve to shut down.) at the former OpenSolaris bugtracker and a
blog entry explaining why Solaris has a problem increasing the limit easily.
Starting with the patch bundle 144500-07 (sparc) and 144501-07 (x86) (Update: both wesunsolve URLs have been shut down by the Oracle legal department) the feature to raise the ngroups_max to 1024 was backported from the OpenSolaris tree. (Thanks Casper)
In the older versions of Solaris, users with more than 16 supplemental groups weren't able to access files over NFS when mounted with the security flavor "AUTH_SYS". In the later versions, NFS truncates the additional groups over 16 as the RPC protocol won't allow the client to send more than 16.
According to the mentioned blog entry the limit will be raised to 1024 (thanks to Oracle once more this URL is also not existing anymore) starting with OpenSolaris snv_129. Same for OpenIndiana, the free successor of OpenSolaris.
20
16 (can vary from 0-32(?))
32
0 (Minix-vmd: 16)
8
supposed to be unlimited, they have a define of 256 though, just to have some value here. Defining a higher value would probably be wiser.
1015 (1024)
See KB328889.