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.
Believe it or not....a typo in the NIS files could cause this. I ran into before. Hard to figure out without lots of troubleshooting.
--tmac
*Tim McCarthy, **Principal Consultant*
*Proud Member of the #NetAppATeam https://twitter.com/NetAppATeam*
*I Blog at TMACsRack https://tmacsrack.wordpress.com/*
[image: FlexPod Design Badge] https://www.youracclaim.com/badges/58cf082d-acd8-4529-821a-bb7eb93a296c/public_url[image: NCIE SAN Badge] https://www.youracclaim.com/badges/162b629e-b4f1-48af-a8f9-d2a9517ec100/public_url[image: NCSIE Badge] https://www.youracclaim.com/badges/367c462d-d58b-4cbf-9e8d-a5068b247cd6/public_url[image: NCSE Badge] https://www.youracclaim.com/badges/618b30bf-7acc-473d-8b06-827062653565/public_url[image: NAHSE Badge] https://www.youracclaim.com/badges/aa9be0e4-2eac-45eb-85e0-0e11035b62a5/public_url[image: SME Badge] https://www.youracclaim.com/badges/6eb5d0cd-acf4-40ac-a50c-73f1c0c009e9/public_url[image: NCDA Badge] https://www.youracclaim.com/badges/b41a5941-6885-4181-b984-21df36bc27a8/public_url[image: NCIE Data Protection Badge] https://www.youracclaim.com/badges/51e81930-cad0-4e1f-b54d-dde7f181516c/public_url[image: FlexPod Impl & Admin Badge] https://www.youracclaim.com/badges/53a73b2a-ca83-43b8-895e-3299735dd406/public_url
On Fri, Mar 9, 2018 at 5:09 PM, Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com wrote:
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
Hi Tim I'll double check our NIS netgroup file. We do use it to define easily addressable sets of machines. Thanks.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: tmac tmacmd@gmail.com Sent: Friday, March 9, 2018 7:26:27 PM To: Ehrenwald, Ian Cc: toasters@teaparty.net Subject: Re: AD Group enumeration problem?
Believe it or not....a typo in the NIS files could cause this. I ran into before. Hard to figure out without lots of troubleshooting.
--tmac
Tim McCarthy, Principal Consultant
Proud Member of the #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
[FlexPod Design Badge]https://www.youracclaim.com/badges/58cf082d-acd8-4529-821a-bb7eb93a296c/public_url[NCIE SAN Badge]https://www.youracclaim.com/badges/162b629e-b4f1-48af-a8f9-d2a9517ec100/public_url[NCSIE Badge]https://www.youracclaim.com/badges/367c462d-d58b-4cbf-9e8d-a5068b247cd6/public_url[NCSE Badge]https://www.youracclaim.com/badges/618b30bf-7acc-473d-8b06-827062653565/public_url[NAHSE Badge]https://www.youracclaim.com/badges/aa9be0e4-2eac-45eb-85e0-0e11035b62a5/public_url[SME Badge]https://www.youracclaim.com/badges/6eb5d0cd-acf4-40ac-a50c-73f1c0c009e9/public_url[NCDA Badge]https://www.youracclaim.com/badges/b41a5941-6885-4181-b984-21df36bc27a8/public_url[NCIE Data Protection Badge]https://www.youracclaim.com/badges/51e81930-cad0-4e1f-b54d-dde7f181516c/public_url[FlexPod Impl & Admin Badge]https://www.youracclaim.com/badges/53a73b2a-ca83-43b8-895e-3299735dd406/public_url
On Fri, Mar 9, 2018 at 5:09 PM, Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.commailto:Ian.Ehrenwald@hbgusa.com> wrote: 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/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.commailto: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.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters
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.
What's your LDAP schema settings?
::> set diag ::*> ldap client show -instance ::*> ldap client schema show -schema <schema in previous output> -instance
Secondary groups aren't even getting fetched in your output, which means it's likely an issue with the schema settings vs. what you have in AD. No secondary groups = nothing for extended groups to fetch.
Changing the LDAP port does nothing for this issue; you only do that if you're not able to bind to LDAP to begin with. Changing to 3268 is the global catalog port, which won't do anything for you unless you've configured AD to replicate unix attributes at the GC level, as per TR-4073.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Friday, March 09, 2018 5:09 PM To: toasters@teaparty.net Subject: AD Group enumeration problem?
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
Hi Justin I've been flipping though TR-3458 and your TR-4073 however my eyes are glazing over from information overload, sorry. LDAP schema mapping is where I was slowly wandering towards too. Here's the requested output with company-specific information masked. The schema I am using is a copy of AD-IDMU with the exception of uid-attribute set to sAMAccountName.
My-Cluster1::*> ldap client show -instance -client-config MyDomain -vserver my-nas
Vserver: my-nas Client Configuration Name: MyDomain LDAP Server List: - Active Directory Domain: MyDomain.MyCompany.COM Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: true Schema Template: MySchema LDAP Server Port: 389 Query Timeout (sec): 8 Minimum Bind Authentication Level: sasl Bind DN (User): MyDomain\utl-ldap-mynas Base DN: dc=MyDomain,dc=MyCompany,dc=com Base Search Scope: subtree User DN: - User Search Scope: subtree Group DN: - Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: true Use start-tls Over LDAP Connections: false (DEPRECATED) Allow SSL for the TLS Handshake Protocol: false Enable Netgroup-By-Host Lookup: false Netgroup-By-Host DN: - Netgroup-By-Host Scope: subtree
My-Cluster1::*> My-Cluster1::*> ldap client schema show -schema MySchema -instance
Vserver: - Schema Template: MySchema Comment: RFC 2307 posixAccount Object Class: User RFC 2307 posixGroup Object Class: Group RFC 2307 nisNetgroup Object Class: nisNetgroup RFC 2307 uid Attribute: sAMAccountName RFC 2307 uidNumber Attribute: uidNumber RFC 2307 gidNumber Attribute: gidNumber RFC 2307 cn (for Groups) Attribute: cn RFC 2307 cn (for Netgroups) Attribute: name RFC 2307 userPassword Attribute: unixUserPassword RFC 2307 gecos Attribute: name RFC 2307 homeDirectory Attribute: unixHomeDirectory RFC 2307 loginShell Attribute: loginShell RFC 2307 memberUid Attribute: memberUid RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple Enable Support for Draft RFC 2307bis: false RFC 2307bis groupOfUniqueNames Object Class: groupOfUniqueNames RFC 2307bis uniqueMember Attribute: uniqueMember Data ONTAP Name Mapping windowsToUnix Object Class: User Data ONTAP Name Mapping windowsAccount Attribute: msDS-PrincipalName Data ONTAP Name Mapping windowsToUnix Attribute: sAMAccountName No Domain Prefix for windowsToUnix Name Mapping: true Vserver Owns Schema: false Maximum groups supported when RFC 2307bis enabled: 256 RFC 2307 nisObject Object Class: nisObject RFC 2307 nisMapName Attribute: nisMapName RFC 2307 nisMapEntry Attribute: nisMapEntry
My-Cluster1::*>
When I flip to a PowerShell console and do "Get-ADUser -Identity TestUser -Properties *" I can see that the MemberOf property contains a list of DNs that correspond to group membership. What I don't see is any reference to MemberOf within the SVM's LDAP client config? I guess I need to do some closer reading in the TRs, could you at least point me in the right direction? Thanks a lot.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Friday, March 9, 2018 10:49:09 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
What's your LDAP schema settings?
::> set diag ::*> ldap client show -instance ::*> ldap client schema show -schema <schema in previous output> -instance
Secondary groups aren't even getting fetched in your output, which means it's likely an issue with the schema settings vs. what you have in AD. No secondary groups = nothing for extended groups to fetch.
Changing the LDAP port does nothing for this issue; you only do that if you're not able to bind to LDAP to begin with. Changing to 3268 is the global catalog port, which won't do anything for you unless you've configured AD to replicate unix attributes at the GC level, as per TR-4073.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Friday, March 09, 2018 5:09 PM To: toasters@teaparty.net Subject: AD Group enumeration problem?
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/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/toastershttp://www.teaparty.net/mailman/listinfo/toasters 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.
Enable RFC-2307bis in the schema and read up on BIS in TR-4073. That will help with secondary group membership. There are sample schemas in there to compare to.
-----Original Message----- From: Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com Sent: Saturday, March 10, 2018 9:23 AM To: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Subject: Re: AD Group enumeration problem?
Hi Justin I've been flipping though TR-3458 and your TR-4073 however my eyes are glazing over from information overload, sorry. LDAP schema mapping is where I was slowly wandering towards too. Here's the requested output with company-specific information masked. The schema I am using is a copy of AD-IDMU with the exception of uid-attribute set to sAMAccountName.
My-Cluster1::*> ldap client show -instance -client-config MyDomain -vserver my-nas
Vserver: my-nas Client Configuration Name: MyDomain LDAP Server List: - Active Directory Domain: MyDomain.MyCompany.COM Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: true Schema Template: MySchema LDAP Server Port: 389 Query Timeout (sec): 8 Minimum Bind Authentication Level: sasl Bind DN (User): MyDomain\utl-ldap-mynas Base DN: dc=MyDomain,dc=MyCompany,dc=com Base Search Scope: subtree User DN: - User Search Scope: subtree Group DN: - Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: true Use start-tls Over LDAP Connections: false (DEPRECATED) Allow SSL for the TLS Handshake Protocol: false Enable Netgroup-By-Host Lookup: false Netgroup-By-Host DN: - Netgroup-By-Host Scope: subtree
My-Cluster1::*> My-Cluster1::*> ldap client schema show -schema MySchema -instance
Vserver: - Schema Template: MySchema Comment: RFC 2307 posixAccount Object Class: User RFC 2307 posixGroup Object Class: Group RFC 2307 nisNetgroup Object Class: nisNetgroup RFC 2307 uid Attribute: sAMAccountName RFC 2307 uidNumber Attribute: uidNumber RFC 2307 gidNumber Attribute: gidNumber RFC 2307 cn (for Groups) Attribute: cn RFC 2307 cn (for Netgroups) Attribute: name RFC 2307 userPassword Attribute: unixUserPassword RFC 2307 gecos Attribute: name RFC 2307 homeDirectory Attribute: unixHomeDirectory RFC 2307 loginShell Attribute: loginShell RFC 2307 memberUid Attribute: memberUid RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple Enable Support for Draft RFC 2307bis: false RFC 2307bis groupOfUniqueNames Object Class: groupOfUniqueNames RFC 2307bis uniqueMember Attribute: uniqueMember Data ONTAP Name Mapping windowsToUnix Object Class: User Data ONTAP Name Mapping windowsAccount Attribute: msDS-PrincipalName Data ONTAP Name Mapping windowsToUnix Attribute: sAMAccountName No Domain Prefix for windowsToUnix Name Mapping: true Vserver Owns Schema: false Maximum groups supported when RFC 2307bis enabled: 256 RFC 2307 nisObject Object Class: nisObject RFC 2307 nisMapName Attribute: nisMapName RFC 2307 nisMapEntry Attribute: nisMapEntry
My-Cluster1::*>
When I flip to a PowerShell console and do "Get-ADUser -Identity TestUser -Properties *" I can see that the MemberOf property contains a list of DNs that correspond to group membership. What I don't see is any reference to MemberOf within the SVM's LDAP client config? I guess I need to do some closer reading in the TRs, could you at least point me in the right direction? Thanks a lot.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Friday, March 9, 2018 10:49:09 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
What's your LDAP schema settings?
::> set diag ::*> ldap client show -instance ::*> ldap client schema show -schema <schema in previous output> -instance
Secondary groups aren't even getting fetched in your output, which means it's likely an issue with the schema settings vs. what you have in AD. No secondary groups = nothing for extended groups to fetch.
Changing the LDAP port does nothing for this issue; you only do that if you're not able to bind to LDAP to begin with. Changing to 3268 is the global catalog port, which won't do anything for you unless you've configured AD to replicate unix attributes at the GC level, as per TR-4073.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Friday, March 09, 2018 5:09 PM To: toasters@teaparty.net Subject: AD Group enumeration problem?
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/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/toastershttp://www.teaparty.net/mailman/listinfo/toasters 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.
Hi Justin I read over the suggested sections and implemented the changes (which were noted as optimal for AD) with the exception of my uid-attribute still remaining sAMAccountName. We are getting better but incomplete results now from getxxbyyy:
My-Cluster1::*> getxxbyyy getgrlist -vserver MySvm -username MyTestUser -show-source true -node MyNode (vserver services name-service getxxbyyy getgrlist) Source used for lookup: Unknown pw_name: MyTestUser Groups: 1154000513 1154012638 1154013779 1154013778 1154012938 1154013945 1154016114 1154026093 My-Cluster1::*>
While on the PowerShell side, a Get-ADUser on MyTestUser and looking at the MemberOf property shows a count of 28.
I do see the note about bug 994736 and DNs with commas, of which all of ours are ("Lastname, Firstname" as in your example) however that's fixed in 8.3.2P5 and I'm on P12.
.... and I just figured out why: PS C:\Users\me> Get-ADUser -Identity MyTestUser -Properties MemberOf | Select MemberOf -ExpandProperty MemberOf | foreach { Get-ADGroup -LDAPFilter "(DistinguishedName=$_)" -Properties Name,gidNumber | Select Name,gidNumber }
Name gidNumber ---- --------- groupA groupB groupC groupD groupE groupF groupG groupH groupI groupJ groupK 1154026093 groupL groupM groupN groupO groupP groupQ groupR groupS groupT groupU groupV groupW 1154016114 groupX 1154013945 groupY 1154012938 groupZ 1154013778 groupAA 1154013779 groupAB 1154012638
PS C:\Users\me>
Duh. The groups with gidNumber set correctly correspond with the groups that the SVM LDAP client returns. Thanks for your nudge in the right direction re: rfc2307bis. Off to figure out why a ton of our groups don't have gidNumbers.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Sunday, March 11, 2018 9:37:18 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
Enable RFC-2307bis in the schema and read up on BIS in TR-4073. That will help with secondary group membership. There are sample schemas in there to compare to.
-----Original Message----- From: Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com Sent: Saturday, March 10, 2018 9:23 AM To: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Subject: Re: AD Group enumeration problem?
Hi Justin I've been flipping though TR-3458 and your TR-4073 however my eyes are glazing over from information overload, sorry. LDAP schema mapping is where I was slowly wandering towards too. Here's the requested output with company-specific information masked. The schema I am using is a copy of AD-IDMU with the exception of uid-attribute set to sAMAccountName.
My-Cluster1::*> ldap client show -instance -client-config MyDomain -vserver my-nas
Vserver: my-nas Client Configuration Name: MyDomain LDAP Server List: - Active Directory Domain: MyDomain.MyCompany.COM Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: true Schema Template: MySchema LDAP Server Port: 389 Query Timeout (sec): 8 Minimum Bind Authentication Level: sasl Bind DN (User): MyDomain\utl-ldap-mynas Base DN: dc=MyDomain,dc=MyCompany,dc=com Base Search Scope: subtree User DN: - User Search Scope: subtree Group DN: - Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: true Use start-tls Over LDAP Connections: false (DEPRECATED) Allow SSL for the TLS Handshake Protocol: false Enable Netgroup-By-Host Lookup: false Netgroup-By-Host DN: - Netgroup-By-Host Scope: subtree
My-Cluster1::*> My-Cluster1::*> ldap client schema show -schema MySchema -instance
Vserver: - Schema Template: MySchema Comment: RFC 2307 posixAccount Object Class: User RFC 2307 posixGroup Object Class: Group RFC 2307 nisNetgroup Object Class: nisNetgroup RFC 2307 uid Attribute: sAMAccountName RFC 2307 uidNumber Attribute: uidNumber RFC 2307 gidNumber Attribute: gidNumber RFC 2307 cn (for Groups) Attribute: cn RFC 2307 cn (for Netgroups) Attribute: name RFC 2307 userPassword Attribute: unixUserPassword RFC 2307 gecos Attribute: name RFC 2307 homeDirectory Attribute: unixHomeDirectory RFC 2307 loginShell Attribute: loginShell RFC 2307 memberUid Attribute: memberUid RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple Enable Support for Draft RFC 2307bis: false RFC 2307bis groupOfUniqueNames Object Class: groupOfUniqueNames RFC 2307bis uniqueMember Attribute: uniqueMember Data ONTAP Name Mapping windowsToUnix Object Class: User Data ONTAP Name Mapping windowsAccount Attribute: msDS-PrincipalName Data ONTAP Name Mapping windowsToUnix Attribute: sAMAccountName No Domain Prefix for windowsToUnix Name Mapping: true Vserver Owns Schema: false Maximum groups supported when RFC 2307bis enabled: 256 RFC 2307 nisObject Object Class: nisObject RFC 2307 nisMapName Attribute: nisMapName RFC 2307 nisMapEntry Attribute: nisMapEntry
My-Cluster1::*>
When I flip to a PowerShell console and do "Get-ADUser -Identity TestUser -Properties *" I can see that the MemberOf property contains a list of DNs that correspond to group membership. What I don't see is any reference to MemberOf within the SVM's LDAP client config? I guess I need to do some closer reading in the TRs, could you at least point me in the right direction? Thanks a lot.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Friday, March 9, 2018 10:49:09 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
What's your LDAP schema settings?
::> set diag ::*> ldap client show -instance ::*> ldap client schema show -schema <schema in previous output> -instance
Secondary groups aren't even getting fetched in your output, which means it's likely an issue with the schema settings vs. what you have in AD. No secondary groups = nothing for extended groups to fetch.
Changing the LDAP port does nothing for this issue; you only do that if you're not able to bind to LDAP to begin with. Changing to 3268 is the global catalog port, which won't do anything for you unless you've configured AD to replicate unix attributes at the GC level, as per TR-4073.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Friday, March 09, 2018 5:09 PM To: toasters@teaparty.net Subject: AD Group enumeration problem?
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/http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/<http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/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/toastershttp://www.teaparty.net/mailman/listinfo/toasters<http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters> 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. 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.
No problem. BIS is the ideal schema to use with MS AD, due to how they natively treat group membership.
-----Original Message----- From: Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com Sent: Monday, March 12, 2018 11:49 AM To: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Subject: Re: AD Group enumeration problem?
Hi Justin I read over the suggested sections and implemented the changes (which were noted as optimal for AD) with the exception of my uid-attribute still remaining sAMAccountName. We are getting better but incomplete results now from getxxbyyy:
My-Cluster1::*> getxxbyyy getgrlist -vserver MySvm -username MyTestUser -show-source true -node MyNode (vserver services name-service getxxbyyy getgrlist) Source used for lookup: Unknown pw_name: MyTestUser Groups: 1154000513 1154012638 1154013779 1154013778 1154012938 1154013945 1154016114 1154026093 My-Cluster1::*>
While on the PowerShell side, a Get-ADUser on MyTestUser and looking at the MemberOf property shows a count of 28.
I do see the note about bug 994736 and DNs with commas, of which all of ours are ("Lastname, Firstname" as in your example) however that's fixed in 8.3.2P5 and I'm on P12.
.... and I just figured out why: PS C:\Users\me> Get-ADUser -Identity MyTestUser -Properties MemberOf | Select MemberOf -ExpandProperty MemberOf | foreach { Get-ADGroup -LDAPFilter "(DistinguishedName=$_)" -Properties Name,gidNumber | Select Name,gidNumber }
Name gidNumber ---- --------- groupA groupB groupC groupD groupE groupF groupG groupH groupI groupJ groupK 1154026093 groupL groupM groupN groupO groupP groupQ groupR groupS groupT groupU groupV groupW 1154016114 groupX 1154013945 groupY 1154012938 groupZ 1154013778 groupAA 1154013779 groupAB 1154012638
PS C:\Users\me>
Duh. The groups with gidNumber set correctly correspond with the groups that the SVM LDAP client returns. Thanks for your nudge in the right direction re: rfc2307bis. Off to figure out why a ton of our groups don't have gidNumbers.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Sunday, March 11, 2018 9:37:18 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
Enable RFC-2307bis in the schema and read up on BIS in TR-4073. That will help with secondary group membership. There are sample schemas in there to compare to.
-----Original Message----- From: Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com Sent: Saturday, March 10, 2018 9:23 AM To: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Subject: Re: AD Group enumeration problem?
Hi Justin I've been flipping though TR-3458 and your TR-4073 however my eyes are glazing over from information overload, sorry. LDAP schema mapping is where I was slowly wandering towards too. Here's the requested output with company-specific information masked. The schema I am using is a copy of AD-IDMU with the exception of uid-attribute set to sAMAccountName.
My-Cluster1::*> ldap client show -instance -client-config MyDomain -vserver my-nas
Vserver: my-nas Client Configuration Name: MyDomain LDAP Server List: - Active Directory Domain: MyDomain.MyCompany.COM Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: true Schema Template: MySchema LDAP Server Port: 389 Query Timeout (sec): 8 Minimum Bind Authentication Level: sasl Bind DN (User): MyDomain\utl-ldap-mynas Base DN: dc=MyDomain,dc=MyCompany,dc=com Base Search Scope: subtree User DN: - User Search Scope: subtree Group DN: - Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: true Use start-tls Over LDAP Connections: false (DEPRECATED) Allow SSL for the TLS Handshake Protocol: false Enable Netgroup-By-Host Lookup: false Netgroup-By-Host DN: - Netgroup-By-Host Scope: subtree
My-Cluster1::*> My-Cluster1::*> ldap client schema show -schema MySchema -instance
Vserver: - Schema Template: MySchema Comment: RFC 2307 posixAccount Object Class: User RFC 2307 posixGroup Object Class: Group RFC 2307 nisNetgroup Object Class: nisNetgroup RFC 2307 uid Attribute: sAMAccountName RFC 2307 uidNumber Attribute: uidNumber RFC 2307 gidNumber Attribute: gidNumber RFC 2307 cn (for Groups) Attribute: cn RFC 2307 cn (for Netgroups) Attribute: name RFC 2307 userPassword Attribute: unixUserPassword RFC 2307 gecos Attribute: name RFC 2307 homeDirectory Attribute: unixHomeDirectory RFC 2307 loginShell Attribute: loginShell RFC 2307 memberUid Attribute: memberUid RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple Enable Support for Draft RFC 2307bis: false RFC 2307bis groupOfUniqueNames Object Class: groupOfUniqueNames RFC 2307bis uniqueMember Attribute: uniqueMember Data ONTAP Name Mapping windowsToUnix Object Class: User Data ONTAP Name Mapping windowsAccount Attribute: msDS-PrincipalName Data ONTAP Name Mapping windowsToUnix Attribute: sAMAccountName No Domain Prefix for windowsToUnix Name Mapping: true Vserver Owns Schema: false Maximum groups supported when RFC 2307bis enabled: 256 RFC 2307 nisObject Object Class: nisObject RFC 2307 nisMapName Attribute: nisMapName RFC 2307 nisMapEntry Attribute: nisMapEntry
My-Cluster1::*>
When I flip to a PowerShell console and do "Get-ADUser -Identity TestUser -Properties *" I can see that the MemberOf property contains a list of DNs that correspond to group membership. What I don't see is any reference to MemberOf within the SVM's LDAP client config? I guess I need to do some closer reading in the TRs, could you at least point me in the right direction? Thanks a lot.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Friday, March 9, 2018 10:49:09 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
What's your LDAP schema settings?
::> set diag ::*> ldap client show -instance ::*> ldap client schema show -schema <schema in previous output> -instance
Secondary groups aren't even getting fetched in your output, which means it's likely an issue with the schema settings vs. what you have in AD. No secondary groups = nothing for extended groups to fetch.
Changing the LDAP port does nothing for this issue; you only do that if you're not able to bind to LDAP to begin with. Changing to 3268 is the global catalog port, which won't do anything for you unless you've configured AD to replicate unix attributes at the GC level, as per TR-4073.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Friday, March 09, 2018 5:09 PM To: toasters@teaparty.net Subject: AD Group enumeration problem?
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/http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/<http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/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/toastershttp://www.teaparty.net/mailman/listinfo/toasters<http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters> 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. 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.
In case anyone is following along at home... I was confused about still only seeing 16 groups in a tcpdump packet disassembly of an RPC call after making the prescribed changes and observing it work correctly on the client side. Then I read the bottom of page 73 in TR-4067 explaining how some trickery happens:
"SecD populates the NAS credential cache with the appropriate group membership for that user up to the extended group limit. The cluster then replies to the NFS request and allows or denies access based on what is in the credential cache and not what was in the RPC packet."
Developers can't break how the protocol works by stuffing more data into the RPC payload, that part is pretty much set in stone. So, instead, work above and around :) Cool stuff.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Ehrenwald, Ian Sent: Monday, March 12, 2018 11:48:37 AM To: Parisi, Justin; toasters@teaparty.net Subject: Re: AD Group enumeration problem?
Hi Justin I read over the suggested sections and implemented the changes (which were noted as optimal for AD) with the exception of my uid-attribute still remaining sAMAccountName. We are getting better but incomplete results now from getxxbyyy:
My-Cluster1::*> getxxbyyy getgrlist -vserver MySvm -username MyTestUser -show-source true -node MyNode (vserver services name-service getxxbyyy getgrlist) Source used for lookup: Unknown pw_name: MyTestUser Groups: 1154000513 1154012638 1154013779 1154013778 1154012938 1154013945 1154016114 1154026093 My-Cluster1::*>
While on the PowerShell side, a Get-ADUser on MyTestUser and looking at the MemberOf property shows a count of 28.
I do see the note about bug 994736 and DNs with commas, of which all of ours are ("Lastname, Firstname" as in your example) however that's fixed in 8.3.2P5 and I'm on P12.
.... and I just figured out why: PS C:\Users\me> Get-ADUser -Identity MyTestUser -Properties MemberOf | Select MemberOf -ExpandProperty MemberOf | foreach { Get-ADGroup -LDAPFilter "(DistinguishedName=$_)" -Properties Name,gidNumber | Select Name,gidNumber }
Name gidNumber ---- --------- groupA groupB groupC groupD groupE groupF groupG groupH groupI groupJ groupK 1154026093 groupL groupM groupN groupO groupP groupQ groupR groupS groupT groupU groupV groupW 1154016114 groupX 1154013945 groupY 1154012938 groupZ 1154013778 groupAA 1154013779 groupAB 1154012638
PS C:\Users\me>
Duh. The groups with gidNumber set correctly correspond with the groups that the SVM LDAP client returns. Thanks for your nudge in the right direction re: rfc2307bis. Off to figure out why a ton of our groups don't have gidNumbers.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Sunday, March 11, 2018 9:37:18 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
Enable RFC-2307bis in the schema and read up on BIS in TR-4073. That will help with secondary group membership. There are sample schemas in there to compare to.
-----Original Message----- From: Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com Sent: Saturday, March 10, 2018 9:23 AM To: Parisi, Justin Justin.Parisi@netapp.com; toasters@teaparty.net Subject: Re: AD Group enumeration problem?
Hi Justin I've been flipping though TR-3458 and your TR-4073 however my eyes are glazing over from information overload, sorry. LDAP schema mapping is where I was slowly wandering towards too. Here's the requested output with company-specific information masked. The schema I am using is a copy of AD-IDMU with the exception of uid-attribute set to sAMAccountName.
My-Cluster1::*> ldap client show -instance -client-config MyDomain -vserver my-nas
Vserver: my-nas Client Configuration Name: MyDomain LDAP Server List: - Active Directory Domain: MyDomain.MyCompany.COM Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: true Schema Template: MySchema LDAP Server Port: 389 Query Timeout (sec): 8 Minimum Bind Authentication Level: sasl Bind DN (User): MyDomain\utl-ldap-mynas Base DN: dc=MyDomain,dc=MyCompany,dc=com Base Search Scope: subtree User DN: - User Search Scope: subtree Group DN: - Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: true Use start-tls Over LDAP Connections: false (DEPRECATED) Allow SSL for the TLS Handshake Protocol: false Enable Netgroup-By-Host Lookup: false Netgroup-By-Host DN: - Netgroup-By-Host Scope: subtree
My-Cluster1::*> My-Cluster1::*> ldap client schema show -schema MySchema -instance
Vserver: - Schema Template: MySchema Comment: RFC 2307 posixAccount Object Class: User RFC 2307 posixGroup Object Class: Group RFC 2307 nisNetgroup Object Class: nisNetgroup RFC 2307 uid Attribute: sAMAccountName RFC 2307 uidNumber Attribute: uidNumber RFC 2307 gidNumber Attribute: gidNumber RFC 2307 cn (for Groups) Attribute: cn RFC 2307 cn (for Netgroups) Attribute: name RFC 2307 userPassword Attribute: unixUserPassword RFC 2307 gecos Attribute: name RFC 2307 homeDirectory Attribute: unixHomeDirectory RFC 2307 loginShell Attribute: loginShell RFC 2307 memberUid Attribute: memberUid RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple Enable Support for Draft RFC 2307bis: false RFC 2307bis groupOfUniqueNames Object Class: groupOfUniqueNames RFC 2307bis uniqueMember Attribute: uniqueMember Data ONTAP Name Mapping windowsToUnix Object Class: User Data ONTAP Name Mapping windowsAccount Attribute: msDS-PrincipalName Data ONTAP Name Mapping windowsToUnix Attribute: sAMAccountName No Domain Prefix for windowsToUnix Name Mapping: true Vserver Owns Schema: false Maximum groups supported when RFC 2307bis enabled: 256 RFC 2307 nisObject Object Class: nisObject RFC 2307 nisMapName Attribute: nisMapName RFC 2307 nisMapEntry Attribute: nisMapEntry
My-Cluster1::*>
When I flip to a PowerShell console and do "Get-ADUser -Identity TestUser -Properties *" I can see that the MemberOf property contains a list of DNs that correspond to group membership. What I don't see is any reference to MemberOf within the SVM's LDAP client config? I guess I need to do some closer reading in the TRs, could you at least point me in the right direction? Thanks a lot.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Friday, March 9, 2018 10:49:09 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: AD Group enumeration problem?
What's your LDAP schema settings?
::> set diag ::*> ldap client show -instance ::*> ldap client schema show -schema <schema in previous output> -instance
Secondary groups aren't even getting fetched in your output, which means it's likely an issue with the schema settings vs. what you have in AD. No secondary groups = nothing for extended groups to fetch.
Changing the LDAP port does nothing for this issue; you only do that if you're not able to bind to LDAP to begin with. Changing to 3268 is the global catalog port, which won't do anything for you unless you've configured AD to replicate unix attributes at the GC level, as per TR-4073.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Friday, March 09, 2018 5:09 PM To: toasters@teaparty.net Subject: AD Group enumeration problem?
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/http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/<http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/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/toastershttp://www.teaparty.net/mailman/listinfo/toasters<http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters> 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. 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.
-
Ehrenwald, Ian -
Parisi, Justin -
tmac