NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




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