Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
Hey Randy,
you need to use `registry set` to set them in privileged mode, f.ex:
devastator*> registry walk options.nfs.a options.nfs.acache.persistence.enabled=on options.nfs.always.deny.truncate=on options.nfs.assist.queue.limit=40 options.nfs.authsys.extended_groups_ns.enable=off options.nfs.authsys.extended_groups_ns.queue_max=80
Use registry set to change these values.
Best,
Alexander Griesser System-Administrator
ANEXIA Internetdienstleistungs GmbH
Telefon: +43-5-0556-320 Telefax: +43-5-0556-500
E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.athttp://www.anexia.at/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Im Auftrag von Rue, Randy Gesendet: Donnerstag, 27. März 2014 22:02 An: toasters@teaparty.net Betreff: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
8.1 in C-mode or 7-mode?
IN 7-mode it's: options nfs.authsys.extended_groups_ns.enable on
We have this enabled on a lot of 8.1.2/8.1.4 (and 8.0.3) machines. I don't remember which revision of 8.1 it was introduced in, could be it wasn't in the base version of 8.1 ?
It's not implemented in C-mode.
--rdp
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 5:02 PM To: toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I've mounted a test volume on the 8.2 simulator to our HPC cluster and am su'd to an account that is a member of 17 groups. "id" shows me all seventeen groups. "ls -l" shows me directories that the user 's individual group owns, and directories owned by groups he's a member of, and all with the appropriate permissions. But he's unable to cd into any of them, or to write anything to the pwd (which is owned by a group he's a member of).
I used cifs setup to add the filer to our AD and that fact that "id" gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
From: Rue, Randy Sent: Thursday, March 27, 2014 4:00 PM To: toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
Is anyone using this feature to allow access to NFS for users who are members of more than 16 groups? What setup was required?
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 02, 2014 6:51 AM To: toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I've mounted a test volume on the 8.2 simulator to our HPC cluster and am su'd to an account that is a member of 17 groups. "id" shows me all seventeen groups. "ls -l" shows me directories that the user 's individual group owns, and directories owned by groups he's a member of, and all with the appropriate permissions. But he's unable to cd into any of them, or to write anything to the pwd (which is owned by a group he's a member of).
I used cifs setup to add the filer to our AD and that fact that "id" gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
From: Rue, Randy Sent: Thursday, March 27, 2014 4:00 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
Yes, we make extensive use of this feature, you need to set:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 256
--rdp
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 3, 2014 9:58 AM To: toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Is anyone using this feature to allow access to NFS for users who are members of more than 16 groups? What setup was required?
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 02, 2014 6:51 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I've mounted a test volume on the 8.2 simulator to our HPC cluster and am su'd to an account that is a member of 17 groups. "id" shows me all seventeen groups. "ls -l" shows me directories that the user 's individual group owns, and directories owned by groups he's a member of, and all with the appropriate permissions. But he's unable to cd into any of them, or to write anything to the pwd (which is owned by a group he's a member of).
I used cifs setup to add the filer to our AD and that fact that "id" gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
From: Rue, Randy Sent: Thursday, March 27, 2014 4:00 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
Had the feature enabled and the max_num at the default 32. Shouldn't make much difference as in this test case the user is a member of 17 groups. Upped it to 256 anyway.
No luck. "id" shows the user is a member of the right group(s) but access is denied.
Have I missed some other more basic step in configuring the simulator from scratch? Can anyone think of anything obvious or anything that changed from 8.1 to 8.2?
Randy in Seattle
From: Payne, Richard [mailto:richard.payne@amd.com] Sent: Thursday, April 03, 2014 10:01 AM To: Rue, Randy; toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Yes, we make extensive use of this feature, you need to set:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 256
--rdp
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 3, 2014 9:58 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Is anyone using this feature to allow access to NFS for users who are members of more than 16 groups? What setup was required?
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 02, 2014 6:51 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I've mounted a test volume on the 8.2 simulator to our HPC cluster and am su'd to an account that is a member of 17 groups. "id" shows me all seventeen groups. "ls -l" shows me directories that the user 's individual group owns, and directories owned by groups he's a member of, and all with the appropriate permissions. But he's unable to cd into any of them, or to write anything to the pwd (which is owned by a group he's a member of).
I used cifs setup to add the filer to our AD and that fact that "id" gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
From: Rue, Randy Sent: Thursday, March 27, 2014 4:00 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
"I used cifs setup to add the filer to our AD"
Hmmm....we're using traditional NIS so I'm not sure what else might need to be setup there.
I know from diag mode you can use 'getXXbyYY' to see which groups the filer thinks the user(s) are in.
--rdp
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 09, 2014 12:08 PM To: toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Had the feature enabled and the max_num at the default 32. Shouldn't make much difference as in this test case the user is a member of 17 groups. Upped it to 256 anyway.
No luck. "id" shows the user is a member of the right group(s) but access is denied.
Have I missed some other more basic step in configuring the simulator from scratch? Can anyone think of anything obvious or anything that changed from 8.1 to 8.2?
Randy in Seattle
From: Payne, Richard [mailto:richard.payne@amd.com] Sent: Thursday, April 03, 2014 10:01 AM To: Rue, Randy; toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Yes, we make extensive use of this feature, you need to set:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 256
--rdp
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 3, 2014 9:58 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Is anyone using this feature to allow access to NFS for users who are members of more than 16 groups? What setup was required?
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 02, 2014 6:51 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I've mounted a test volume on the 8.2 simulator to our HPC cluster and am su'd to an account that is a member of 17 groups. "id" shows me all seventeen groups. "ls -l" shows me directories that the user 's individual group owns, and directories owned by groups he's a member of, and all with the appropriate permissions. But he's unable to cd into any of them, or to write anything to the pwd (which is owned by a group he's a member of).
I used cifs setup to add the filer to our AD and that fact that "id" gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
From: Rue, Randy Sent: Thursday, March 27, 2014 4:00 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
While we are using a netgroup file to allow access to the export, we're not actually running NIS. We do it this way on other filers and I'm guessing it's working as I can mount the volume just fine, the problem is when I su to a user and try to touch the file system.
Good idea on the cli tools, will try that...
From: Payne, Richard [mailto:richard.payne@amd.com] Sent: Wednesday, April 09, 2014 9:15 AM To: Rue, Randy; toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
"I used cifs setup to add the filer to our AD"
Hmmm....we're using traditional NIS so I'm not sure what else might need to be setup there.
I know from diag mode you can use 'getXXbyYY' to see which groups the filer thinks the user(s) are in.
--rdp
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 09, 2014 12:08 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Had the feature enabled and the max_num at the default 32. Shouldn't make much difference as in this test case the user is a member of 17 groups. Upped it to 256 anyway.
No luck. "id" shows the user is a member of the right group(s) but access is denied.
Have I missed some other more basic step in configuring the simulator from scratch? Can anyone think of anything obvious or anything that changed from 8.1 to 8.2?
Randy in Seattle
From: Payne, Richard [mailto:richard.payne@amd.com] Sent: Thursday, April 03, 2014 10:01 AM To: Rue, Randy; toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Yes, we make extensive use of this feature, you need to set:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 256
--rdp
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 3, 2014 9:58 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Is anyone using this feature to allow access to NFS for users who are members of more than 16 groups? What setup was required?
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 02, 2014 6:51 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I've mounted a test volume on the 8.2 simulator to our HPC cluster and am su'd to an account that is a member of 17 groups. "id" shows me all seventeen groups. "ls -l" shows me directories that the user 's individual group owns, and directories owned by groups he's a member of, and all with the appropriate permissions. But he's unable to cd into any of them, or to write anything to the pwd (which is owned by a group he's a member of).
I used cifs setup to add the filer to our AD and that fact that "id" gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
From: Rue, Randy Sent: Thursday, March 27, 2014 4:00 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
OK, I think we're getting closer. Got some excellent feedback (thanks!).
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I'm trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
Added this to the usermap.cfg file: NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running "getXXbyYY getpwbyname_r whoever" at the shell on the filer returns "Could not get passwd entry for name = whoever." Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I'm trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that's running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 09, 2014 2:59 PM To: toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
While we are using a netgroup file to allow access to the export, we're not actually running NIS. We do it this way on other filers and I'm guessing it's working as I can mount the volume just fine, the problem is when I su to a user and try to touch the file system.
Good idea on the cli tools, will try that...
From: Payne, Richard [mailto:richard.payne@amd.com] Sent: Wednesday, April 09, 2014 9:15 AM To: Rue, Randy; toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
"I used cifs setup to add the filer to our AD"
Hmmm....we're using traditional NIS so I'm not sure what else might need to be setup there.
I know from diag mode you can use 'getXXbyYY' to see which groups the filer thinks the user(s) are in.
--rdp
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 09, 2014 12:08 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Had the feature enabled and the max_num at the default 32. Shouldn't make much difference as in this test case the user is a member of 17 groups. Upped it to 256 anyway.
No luck. "id" shows the user is a member of the right group(s) but access is denied.
Have I missed some other more basic step in configuring the simulator from scratch? Can anyone think of anything obvious or anything that changed from 8.1 to 8.2?
Randy in Seattle
From: Payne, Richard [mailto:richard.payne@amd.com] Sent: Thursday, April 03, 2014 10:01 AM To: Rue, Randy; toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Yes, we make extensive use of this feature, you need to set:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 256
--rdp
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 3, 2014 9:58 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Is anyone using this feature to allow access to NFS for users who are members of more than 16 groups? What setup was required?
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Wednesday, April 02, 2014 6:51 AM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I've mounted a test volume on the 8.2 simulator to our HPC cluster and am su'd to an account that is a member of 17 groups. "id" shows me all seventeen groups. "ls -l" shows me directories that the user 's individual group owns, and directories owned by groups he's a member of, and all with the appropriate permissions. But he's unable to cd into any of them, or to write anything to the pwd (which is owned by a group he's a member of).
I used cifs setup to add the filer to our AD and that fact that "id" gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
From: Rue, Randy Sent: Thursday, March 27, 2014 4:00 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: nfs.authsys.extended_groups_ns.enable?
Figured this out with some help from you all.
We're running 8.1 and this option is only supported 8.1.1 and onward for : https://communities.netapp.com/thread/20549
Confirmed it on a 8.2 simulator. Still needed to use registry walk and set to even see/set the option but it is there. Once you've set it, even in non-privileged mode it appears if you run options nfs.
Thanks to all!
Randy
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, March 27, 2014 2:02 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: nfs.authsys.extended_groups_ns.enable?
Hello All,
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a "hidden" option "nfs.authsys.extended_groups_ns.enable" that will effectively disable group lookups via auth_sys/RPC and instead look to the filer's AD authentication for a user's group memberships. This is similar in spirit to Isilon's "mapuid" feature and "regular" NFS's -manage-gid switch.
But I've tried in regular mode, priv set advanced and priv set diag, and I always get "No such option nfs.authsys.extended_groups_ns.enable" if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I’m trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported. I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.
auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different. So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).
So far so good.
Now you've done this:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 64 (or whatever)
Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)
It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group. N.B. this includes the users primary GID :-(
I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want. user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do
Regards, /M
Added this to the usermap.cfg file:
NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running “getXXbyYY getpwbyname_r whoever” at the shell on the filer returns “Could not get passwd entry for name = whoever.” Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I’m trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that’s running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
I've been able to get it to work with DOT7 mode but have't tried with 8. MS AD 2003R2 or above supports RFC2307bis attributes (although you can use other values for them, like I am using sAMAccountName instead of UID below).
Some of the required option are not shown by default which is odd but this works for me, I am using port 3268 because I have multiple domains, to support that you need to make sure your required attributes (UID,GID etc) are replicated to Global Catalogs (not all are by default) and have "ldap.site.company.com" resolve to a Global Catalog. ldap.ADdomain company.com ldap.base dc=company,dc=com ldap.base.group dc=company,dc=com ldap.base.netgroup ldap.base.passwd dc=company,dc=com ldap.enable on ldap.minimum_bind_level simple ldap.name cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=com ldap.nssmap.attribute.gecos gecos ldap.nssmap.attribute.gidNumber gidNumber ldap.nssmap.attribute.groupname cn ldap.nssmap.attribute.homeDirectory UnixHomeDirectory ldap.nssmap.attribute.loginShell loginShell ldap.nssmap.attribute.memberNisNetgroup memberNisNetgroup ldap.nssmap.attribute.memberUid memberUid ldap.nssmap.attribute.netgroupname cn ldap.nssmap.attribute.nisNetgroupTriple nisNetgroupTriple ldap.nssmap.attribute.uid sAMAccountName ldap.nssmap.attribute.uidNumber uidNumber ldap.nssmap.attribute.uniqueMember member ldap.nssmap.attribute.userPassword unixUserPassword ldap.nssmap.objectClass.groupOfUniqueNames group ldap.nssmap.objectClass.nisNetgroup nisNetgroup ldap.nssmap.objectClass.posixAccount user ldap.nssmap.objectClass.posixGroup group ldap.passwd ****** ldap.port 3268 ldap.rfc2307bis.enable on ldap.servers ldap.site.company.com ldap.servers.preferred ldap.skip_cn_unescape.enable on ldap.ssl.enable off ldap.timeout 20 ldap.usermap.attribute.unixaccount sAMAccountName ldap.usermap.attribute.windowsaccount sAMAccountName ldap.usermap.base ldap.usermap.enable on
*Jeremy Page* | Senior Technical Architect | *Gilbarco Veeder-Root, A Danaher Company* *Office:*336-547-5399 | *Cell:*336-601-7274 | *24x7 Emergency:*336-430-8151 ------------------------------------------------------------------------ On 04/10/2014 12:51 PM, Michael Bergman wrote:
Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I’m trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported. I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.
auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different. So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).
So far so good.
Now you've done this:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 64 (or whatever)
Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)
It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group. N.B. this includes the users primary GID :-(
I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want. user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do
Regards, /M
Added this to the usermap.cfg file:
NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running “getXXbyYY getpwbyname_r whoever” at the shell on the filer returns “Could not get passwd entry for name = whoever.” Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I’m trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that’s running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.
Will compare your options below to mine on the simulator.
Should also clarify I meant NFSv3 (curse that fat finger!)
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeremy Page Sent: Thursday, April 10, 2014 10:10 AM To: toasters@teaparty.net Subject: Re: nfs.authsys.extended_groups_ns.enable?
I've been able to get it to work with DOT7 mode but have't tried with 8. MS AD 2003R2 or above supports RFC2307bis attributes (although you can use other values for them, like I am using sAMAccountName instead of UID below).
Some of the required option are not shown by default which is odd but this works for me, I am using port 3268 because I have multiple domains, to support that you need to make sure your required attributes (UID,GID etc) are replicated to Global Catalogs (not all are by default) and have "ldap.site.company.com" resolve to a Global Catalog. ldap.ADdomain company.com ldap.base dc=company,dc=com ldap.base.group dc=company,dc=com ldap.base.netgroup ldap.base.passwd dc=company,dc=com ldap.enable on ldap.minimum_bind_level simple ldap.name cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=com ldap.nssmap.attribute.gecos gecos ldap.nssmap.attribute.gidNumber gidNumber ldap.nssmap.attribute.groupname cn ldap.nssmap.attribute.homeDirectory UnixHomeDirectory ldap.nssmap.attribute.loginShell loginShell ldap.nssmap.attribute.memberNisNetgroup memberNisNetgroup ldap.nssmap.attribute.memberUid memberUid ldap.nssmap.attribute.netgroupname cn ldap.nssmap.attribute.nisNetgroupTriple nisNetgroupTriple ldap.nssmap.attribute.uid sAMAccountName ldap.nssmap.attribute.uidNumber uidNumber ldap.nssmap.attribute.uniqueMember member ldap.nssmap.attribute.userPassword unixUserPassword ldap.nssmap.objectClass.groupOfUniqueNames group ldap.nssmap.objectClass.nisNetgroup nisNetgroup ldap.nssmap.objectClass.posixAccount user ldap.nssmap.objectClass.posixGroup group ldap.passwd ****** ldap.port 3268 ldap.rfc2307bis.enable on ldap.servers ldap.site.company.com ldap.servers.preferred ldap.skip_cn_unescape.enable on ldap.ssl.enable off ldap.timeout 20 ldap.usermap.attribute.unixaccount sAMAccountName ldap.usermap.attribute.windowsaccount sAMAccountName ldap.usermap.base ldap.usermap.enable on
Jeremy Page | Senior Technical Architect | Gilbarco Veeder-Root, A Danaher Company Office:336-547-5399 | Cell:336-601-7274 | 24x7 Emergency:336-430-8151 ________________________________ On 04/10/2014 12:51 PM, Michael Bergman wrote: Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I'm trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported. I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.
auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different. So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).
So far so good.
Now you've done this:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 64 (or whatever)
Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)
It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group. N.B. this includes the users primary GID :-(
I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want. user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do
Regards, /M
Added this to the usermap.cfg file:
NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running "getXXbyYY getpwbyname_r whoever" at the shell on the filer returns "Could not get passwd entry for name = whoever." Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I'm trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that's running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.
Should clarify I meant NFSv3. Typo.
I hadn't thought about that. Under this new scheme (the filer is ignoring the group information included via RPC in NFSv3 and instead getting an AD lookup for the user), where is the system mapping POSIX groups to/from AD groups?
But I suspect we're not even there yet. I'd like to get the 8.2 filer to recognize the AD users and see if I'm still broken.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Michael Bergman Sent: Thursday, April 10, 2014 9:52 AM To: Toasters Subject: Re: nfs.authsys.extended_groups_ns.enable?
Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I'm trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported. I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.
auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different. So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).
So far so good.
Now you've done this:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 64 (or whatever)
Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)
It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group. N.B. this includes the users primary GID :-(
I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want. user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do
Regards, /M
Added this to the usermap.cfg file:
NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running "getXXbyYY getpwbyname_r whoever" at the shell on the filer returns "Could not get passwd entry for name = whoever." Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I'm trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that's running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Still more progress but no win yet.
After comparing the ldap options for one filer that does resolve AD users and groups to my flawed simulator, I can now run getXXbyYY and resolve users and groups in the AD. And if I su to the test user I can touch files and folders he owns. But not ones he should have access to right of a group membership.
Any ideas?
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 10, 2014 10:24 AM To: Michael Bergman; Toasters Subject: RE: nfs.authsys.extended_groups_ns.enable?
Should clarify I meant NFSv3. Typo.
I hadn't thought about that. Under this new scheme (the filer is ignoring the group information included via RPC in NFSv3 and instead getting an AD lookup for the user), where is the system mapping POSIX groups to/from AD groups?
But I suspect we're not even there yet. I'd like to get the 8.2 filer to recognize the AD users and see if I'm still broken.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Michael Bergman Sent: Thursday, April 10, 2014 9:52 AM To: Toasters Subject: Re: nfs.authsys.extended_groups_ns.enable?
Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I'm trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported. I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.
auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different. So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).
So far so good.
Now you've done this:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 64 (or whatever)
Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)
It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group. N.B. this includes the users primary GID :-(
I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want. user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do
Regards, /M
Added this to the usermap.cfg file:
NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running "getXXbyYY getpwbyname_r whoever" at the shell on the filer returns "Could not get passwd entry for name = whoever." Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I'm trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that's running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
What does /etc/nsswitch.conf look like on the filer?
Not sure it plays a role here but I wonder if you have to put ldap in the search order?
--rdp
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 10, 2014 7:36 PM To: Toasters Subject: RE: nfs.authsys.extended_groups_ns.enable?
Still more progress but no win yet.
After comparing the ldap options for one filer that does resolve AD users and groups to my flawed simulator, I can now run getXXbyYY and resolve users and groups in the AD. And if I su to the test user I can touch files and folders he owns. But not ones he should have access to right of a group membership.
Any ideas?
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rue, Randy Sent: Thursday, April 10, 2014 10:24 AM To: Michael Bergman; Toasters Subject: RE: nfs.authsys.extended_groups_ns.enable?
Should clarify I meant NFSv3. Typo.
I hadn't thought about that. Under this new scheme (the filer is ignoring the group information included via RPC in NFSv3 and instead getting an AD lookup for the user), where is the system mapping POSIX groups to/from AD groups?
But I suspect we're not even there yet. I'd like to get the 8.2 filer to recognize the AD users and see if I'm still broken.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Michael Bergman Sent: Thursday, April 10, 2014 9:52 AM To: Toasters Subject: Re: nfs.authsys.extended_groups_ns.enable?
Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I'm trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported. I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.
auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different. So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).
So far so good.
Now you've done this:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 64 (or whatever)
Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)
It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group. N.B. this includes the users primary GID :-(
I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want. user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do
Regards, /M
Added this to the usermap.cfg file:
NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running "getXXbyYY getpwbyname_r whoever" at the shell on the filer returns "Could not get passwd entry for name = whoever." Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I'm trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that's running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Randy,
The filer will not look up AD for UNIX account information, because AD is a Windows service not a UNIX service.
What you can do, and has been alluded to by a previous poster, is store POSIX attributes into your Active Directory, and then access that information via the ldap options (see "options ldap") on the filer, treating your AD servers as LDAP servers.
AD 2003 R2 and later support the RFC2307 schema out of the box, but the attributes are empty by default. In order to manage POSIX attributes for users and groups in your AD, you need to install the UNIX Identity Management option to AD (I might not have the name exactly correct).
AD does not directly support RFC2307bis (which is an obsolete document). However, that only really matters for automounts. You might be able to use rfc2307bis in your filer to access AD style group membership (RFC2307 uses a different attribute for that).
I suggest using your web search engine to find out more about the subject of POSIX (RFC2307) attributes in AD. It’s a bit too complex to explain in an email.
Regards, Jeremy
On 11 Apr 2014, at 3:24 am, Rue, Randy rrue@fhcrc.org wrote:
Should clarify I meant NFSv3. Typo.
I hadn't thought about that. Under this new scheme (the filer is ignoring the group information included via RPC in NFSv3 and instead getting an AD lookup for the user), where is the system mapping POSIX groups to/from AD groups?
But I suspect we're not even there yet. I'd like to get the 8.2 filer to recognize the AD users and see if I'm still broken.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Michael Bergman Sent: Thursday, April 10, 2014 9:52 AM To: Toasters Subject: Re: nfs.authsys.extended_groups_ns.enable?
Randy Rue wrote:
The real filer that I'm trying to add this to has so far only been serving NFS/unix even though CIFS is enabled and it's added to our AD. But so far it's only serving NFSv2 with auth_sys. Now I'm trying to enable the extended_groups magic and I'm guessing I need to add enough AD capability for users to map between unix and AD accounts. And sure enough, the usermap.cfg file on both the real and simulated filers is the default.
To make the mapping actually happen (user mapping is fine, but where's your UNIX group info? Nowhere? In MS AD somehow?) you might need to actually CIFS share the data paths you have NFS exported. I'm not sure, it could be enough to just have the CIFS service active and correctly configured in the vfiler in Q.
auth_sys is depending on UID & GID which come in inside the NFS packets. There's no translation or lookups anywhere taking place. It's the same for NFSv3 as v2, NFSv4 is different. So in a basic setup, there's no NIS or MS AD lookups taking place for antyhing that has to do with File Level ACLs *provided* you have unix style security for your data (which you have).
So far so good.
Now you've done this:
nfs.authsys.extended_groups_ns.enable on nfs.max_num_aux_groups 64 (or whatever)
Suddenly everything changes. Now ONTAP has to look up the user corresponding to the UID in the NFS packet, in group. Either NIS group or in /etc/group in the machine (if all this works via /etc/nsswitch.conf, I'm not sure as I've never tried it.)
It will then replace all the GIDs it got in the NFS packet that came in, with what it found in group. N.B. this includes the users primary GID :-(
I don't know if there's any connection to any MS AD "groups" in all this, if not then you can never get this to work the way you want. user <-> user mappings in usermap.cfg fine, but if you don't have any UNIX users anyway, neither in NIS nor in /etc/passwd & /etc/group in the filer, there's not really anything for the mapping function to do
Regards, /M
Added this to the usermap.cfg file:
NTDOM* == *
Where NTDOM is our AD domain. This should map NTDOM\whoever to the unix whoever in both directions? Rebooted the simulator to make sure this took effect. Still no luck.
Another new clue, running "getXXbyYY getpwbyname_r whoever" at the shell on the filer returns "Could not get passwd entry for name = whoever." Sure looks like the filer is not resolving AD accounts. And sure enough, if I run that command on the NFS-only filer that I'm trying to add extended_groups to, I get the same error. And if I run it on yet a different filer that's running multiprotocol, the user resolves.
What step have I missed?
Randy in Sunny Seattle
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
1. We're not using this, but I went through *everything* about how it works not long ago.
2. There is one very big caveat if you want to start using it. It works just like the mountd –-manage-gid feature in Linux NFS services. With one very important exception
So WARNING: if you in any corner/nook/cranny of your NFS based environment depend on newgrp, i.e. changing the effective GID (primary group) of a process/shell or whatever to make things work, do not use this ONTAP feature.
It doesn't "merge" things togheter like happens in Linux when using –-manage-gid, where the "primary" GID sent by the NFS client in the packets that come to the server is heeded and the rest is replaced by what's in NIS group. Instead it simply replaces everything (total ignore w.r.t. what was sent in the NFS command), all the GIDs, with what's in NIS group for that particular UID.
In our Enterpriuse SW/HW development environment this would wreak havoc so fast, my head would spin. So we have to live with the NFS protocol limitation of max 16 gids, as good as we can. It's not that easy, the environment is big... really big. So the amount of bad-will from end users this has caused over the last 15 years you can imagine
/M
Randy Rue wrote:
Is anyone using this feature to allow access to NFS for users who are members of more than 16 groups? What setup was required?
*From:* toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] *On Behalf Of *Rue, Randy *Sent:* Wednesday, April 02, 2014 6:51 AM *To:* toasters@teaparty.net *Subject:* RE: nfs.authsys.extended_groups_ns.enable?
Hello Again All,
Phase 2 of this puzzle is making this new setting work.
I’ve mounted a test volume on the 8.2 simulator to our HPC cluster and am su’d to an account that is a member of 17 groups. “id” shows me all seventeen groups. “ls –l” shows me directories that the user ‘s individual group owns, and directories owned by groups he’s a member of, and all with the appropriate permissions. But he’s unable to cd into any of them, or to write anything to the pwd (which is owned by a group he’s a member of).
I used cifs setup to add the filer to our AD and that fact that “id” gets all his groups suggests his AD account is resolving correctly on the client. Did I miss a step in setting up the filer?
Hope to hear from you,
Randy in Seattle
Trying to work around the 16 group limitation of NFS v3 on our 8.1 vfiler and finding references to a “hidden” option “nfs.authsys.extended_groups_ns.enable” that will effectively disable group lookups via auth_sys/RPC and instead look to the filer’s AD authentication for a user’s group memberships. This is similar in spirit to Isilon’s “mapuid” feature and “regular” NFS’s –manage-gid switch.
But I’ve tried in regular mode, priv set advanced and priv set diag, and I always get “No such option nfs.authsys.extended_groups_ns.enable” if I try to view or change the option.
Am I missing some step to make this hidden double-secret-probationary option available?
Randy
-
Alexander Griesser -
Jeremy Page -
Jeremy Webber -
Michael Bergman -
Payne, Richard -
Rue, Randy