Mailing List Archive

wedged updates to changes to users' group memberships
Hello All,

We recently cut over from a FAS to an AFF running 9.8P1. Serving CIFS
and NFSv3 with authentication tied to openLDAP.

When we change group memberships in LDAP the filer fails to see the
change in group memberships for some varying amount of time.

We had been able to use the flush command to force the filer to update
it's user/group membership lists. This was changed in our current
version, 9.8P1, and we have switched to using the replacement command.

This used to work:
set diag; diag nblade credentials flush -node $NODE -vserver $VSERVER
-unix-user-name $USER

We think this should be the new command but does not seem to perform as
expected:
set -privilege advanced -confirmations off; credentials flush -node
$NODE -vserver $VSERVER -unix-user-name $USER

The new flush command does not seem to perform with any reliability.
It's worth noting that we have many groups so have set the group limit
to 512 as described here:
https://library.netapp.com/ecmdocs/ECMP1610208/html/GUID-1D3D018C-DF37-4C87-A789-58526A46B1A9.html

As of this writing, we have 2 users whose group memberships were updated
over 24 hours ago and they are still unable to access the relevant files
over CIFS. We were able to demonstrate that the user can in fact access
those files over NFS using the `newgrp` command to select the new group
and access the files however after dropping the `newgrp` identity, we
were once again denied access to the location.

Are we missing something?

Grateful for any help...

Randy Rue in Seattle

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
https://www.teaparty.net/mailman/listinfo/toasters
Re: wedged updates to changes to users' group memberships [ In reply to ]
An update.

We've realized that the cluster itself is configured for LDAP, and set
to bind anonymously using invalid LDAP credentials. The SVM appears to
be correctly configured for LDAP. Is it possible the two configs are
conflicting?

Randy

On 8/19/2021 8:59 AM, Randy Rue wrote:
> Hello All,
>
> We recently cut over from a FAS to an AFF running 9.8P1. Serving CIFS
> and NFSv3 with authentication tied to openLDAP.
>
> When we change group memberships in LDAP the filer fails to see the
> change in group memberships for some varying amount of time.
>
> We had been able to use the flush command to force the filer to update
> it's user/group membership lists. This was changed in our current
> version, 9.8P1, and we have switched to using the replacement command.
>
> This used to work:
> set diag; diag nblade credentials flush -node $NODE -vserver $VSERVER
> -unix-user-name $USER
>
> We think this should be the new command but does not seem to perform
> as expected:
> set -privilege advanced -confirmations off; credentials flush -node
> $NODE -vserver $VSERVER -unix-user-name $USER
>
> The new flush command does not seem to perform with any reliability.
> It's worth noting that we have many groups so have set the group limit
> to 512 as described here:
> https://library.netapp.com/ecmdocs/ECMP1610208/html/GUID-1D3D018C-DF37-4C87-A789-58526A46B1A9.html
>
>
> As of this writing, we have 2 users whose group memberships were
> updated over 24 hours ago and they are still unable to access the
> relevant files over CIFS. We were able to demonstrate that the user
> can in fact access those files over NFS using the `newgrp` command to
> select the new group and access the files however after dropping the
> `newgrp` identity, we were once again denied access to the location.
>
> Are we missing something?
>
> Grateful for any help...
>
> Randy Rue in Seattle
>
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
https://www.teaparty.net/mailman/listinfo/toasters
Re: wedged updates to changes to users' group memberships [ In reply to ]
OK, cleared up two config glitches in case they were a factor:

1) removed the LDAP config from the cluster itself.

2) The SVM was set for anonymous LDAP binds (we allow those on our LDAP
servers) but also had a user set and with no password. Tried to remove
the user but System Manager insisted on having something there. Changed
auth to Simple and set the PW. Scary, as this is our prod system. Took
the settings and we still appear to be authenticating.

So we're still stuck on the original issue and have a prominent user
unable to work and facing a deadline/

Calling NetApp but would be grateful for any guidance.

Randy


On 8/19/2021 9:20 AM, Rue, Randy wrote:
> An update.
>
> We've realized that the cluster itself is configured for LDAP, and set
> to bind anonymously using invalid LDAP credentials. The SVM appears to
> be correctly configured for LDAP. Is it possible the two configs are
> conflicting?
>
> Randy
>
> On 8/19/2021 8:59 AM, Randy Rue wrote:
>> Hello All,
>>
>> We recently cut over from a FAS to an AFF running 9.8P1. Serving CIFS
>> and NFSv3 with authentication tied to openLDAP.
>>
>> When we change group memberships in LDAP the filer fails to see the
>> change in group memberships for some varying amount of time.
>>
>> We had been able to use the flush command to force the filer to
>> update it's user/group membership lists. This was changed in our
>> current version, 9.8P1, and we have switched to using the replacement
>> command.
>>
>> This used to work:
>> set diag; diag nblade credentials flush -node $NODE -vserver $VSERVER
>> -unix-user-name $USER
>>
>> We think this should be the new command but does not seem to perform
>> as expected:
>> set -privilege advanced -confirmations off; credentials flush -node
>> $NODE -vserver $VSERVER -unix-user-name $USER
>>
>> The new flush command does not seem to perform with any reliability.
>> It's worth noting that we have many groups so have set the group
>> limit to 512 as described here:
>> https://library.netapp.com/ecmdocs/ECMP1610208/html/GUID-1D3D018C-DF37-4C87-A789-58526A46B1A9.html
>>
>>
>> As of this writing, we have 2 users whose group memberships were
>> updated over 24 hours ago and they are still unable to access the
>> relevant files over CIFS. We were able to demonstrate that the user
>> can in fact access those files over NFS using the `newgrp` command to
>> select the new group and access the files however after dropping the
>> `newgrp` identity, we were once again denied access to the location.
>>
>> Are we missing something?
>>
>> Grateful for any help...
>>
>> Randy Rue in Seattle
>>
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
https://www.teaparty.net/mailman/listinfo/toasters