Hello everyone
I'm having a problem where users with more than 16 group memberships are unable to perform operations on files or directories that live on NFS volumes and are owned by groups that they are members of. This seems to be the classic and documented RPC spec limit as blogged about at http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/ and discussed in various forum posts when doing web searches for the old 7-mode option "nfs.authsys.extended_groups_ns.enable" and "nfs.max_num_aux_groups".
I've found the cDOT options "auth-sys-extended-groups" and "extended-groups-limit" within the "vserver nfs" tree, and have adjusted them to "enabled" and "64" (my test user is a member of 29 groups). However, the problem I am observing still remains. I tried unmounting and remounting my test volume on my test host (RHEL7.3 x86_64) with no observable change in behavior.
My SVMs are talking LDAP to Active Directory in a Windows 2008R2 forest level. My SVM LDAP client schema is a copy of AD-IDMU with a single change, uid-attribute is set to sAMAccountName.
If I go into diag mode and issue "getxxbyyy getgrlist -vserver MySvm -username MyTestUser -node MyNode", I get back this:
pw_name: MyTestUser
Groups: 1154000513
While still in diag mode I issue "secd authentication show-creds -node MyNode -vserver MySvm -unix-user-name MyTestUser" and get back:
UNIX UID: MyTestUser <> Windows User: MyDomain\MyTestUser (Windows Domain User)
GID: Domain Users
Supplementary GIDs:
Domain Users
Windows Membership:
*(A list of 29 other groups as defined in Active Directory)*
BUILTIN\Users (Windows Alias)
User is also a member of Everyone, Authenticated Users, and Network Users
So it looks like getxxbyyy is either only getting back the users' primary group, or its not enumerating the supplementary group memberships?
Based on some suggestions from Support, I tried changing the LDAP client configuration to use port 3268 (global catalog) instead of 389 (ldap) but that actually resulted in no user information being returned. I also tried setting a preferred DC within the LDAP client configuration (option "preferred-ad-servers") with no change in returned data. I tried setting a preferred DC with the ldap server port back at 389 too, no difference.
Our DNs do have commas in them. Example taken from within AD: CN=Lastname\, Firstname,OU=SomeDivision,OU=SomeCompany,DC=SomeDomain,DC=SomeBigOrg,DC=com . Could this cause problems? I did see some brief mention of an old hidden 7-mode option "ldap.skip_cn_unescape.enable" but can't find a cDOT equivalent. Does anyone have experience with this problem and can provide some hints? Thanks!
Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com
This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
I'm having a problem where users with more than 16 group memberships are unable to perform operations on files or directories that live on NFS volumes and are owned by groups that they are members of. This seems to be the classic and documented RPC spec limit as blogged about at http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/ and discussed in various forum posts when doing web searches for the old 7-mode option "nfs.authsys.extended_groups_ns.enable" and "nfs.max_num_aux_groups".
I've found the cDOT options "auth-sys-extended-groups" and "extended-groups-limit" within the "vserver nfs" tree, and have adjusted them to "enabled" and "64" (my test user is a member of 29 groups). However, the problem I am observing still remains. I tried unmounting and remounting my test volume on my test host (RHEL7.3 x86_64) with no observable change in behavior.
My SVMs are talking LDAP to Active Directory in a Windows 2008R2 forest level. My SVM LDAP client schema is a copy of AD-IDMU with a single change, uid-attribute is set to sAMAccountName.
If I go into diag mode and issue "getxxbyyy getgrlist -vserver MySvm -username MyTestUser -node MyNode", I get back this:
pw_name: MyTestUser
Groups: 1154000513
While still in diag mode I issue "secd authentication show-creds -node MyNode -vserver MySvm -unix-user-name MyTestUser" and get back:
UNIX UID: MyTestUser <> Windows User: MyDomain\MyTestUser (Windows Domain User)
GID: Domain Users
Supplementary GIDs:
Domain Users
Windows Membership:
*(A list of 29 other groups as defined in Active Directory)*
BUILTIN\Users (Windows Alias)
User is also a member of Everyone, Authenticated Users, and Network Users
So it looks like getxxbyyy is either only getting back the users' primary group, or its not enumerating the supplementary group memberships?
Based on some suggestions from Support, I tried changing the LDAP client configuration to use port 3268 (global catalog) instead of 389 (ldap) but that actually resulted in no user information being returned. I also tried setting a preferred DC within the LDAP client configuration (option "preferred-ad-servers") with no change in returned data. I tried setting a preferred DC with the ldap server port back at 389 too, no difference.
Our DNs do have commas in them. Example taken from within AD: CN=Lastname\, Firstname,OU=SomeDivision,OU=SomeCompany,DC=SomeDomain,DC=SomeBigOrg,DC=com . Could this cause problems? I did see some brief mention of an old hidden 7-mode option "ldap.skip_cn_unescape.enable" but can't find a cDOT equivalent. Does anyone have experience with this problem and can provide some hints? Thanks!
Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com
This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters