topic Re: Inconsistent Behavior AD Authenticated vServer and Domain Tunnel in Active IQ Unified Manager Discussions

Inconsistent Behavior AD Authenticated vServer and Domain Tunnel

StorageNob — Wed, 04 Jun 2025 12:08:45 GMT

Hello,

We're using a vServer that's authenticated to our domain controller with AD integration. We create a domain tunnel and then give users in a specified group login rights to the cluster.

We're seeing that when we remove a user from the same group that was given cluster login rights (while forcing replication on domain controller), the user is still able to login for about 20 minutes afterward.

When we disable the account the intended effect is immediate. The user cannot login.

Also, if we remove the user from the group, disable the account, the user will not be able to login. But as soon as it is re-enabled they can login.

Every command I've tried for clearing kerberos cache or otherwise doesn't affect the results. Anyone have advice on a command that works to do this?

Also, I want to point out that I have verified that the forced AD replication is occuring immediately on the secondary domain controllers. So I believe this to be a problem on the NetApp side.

Thanks

Re: Inconsistent Behavior AD Authenticated vServer and Domain Tunnel

GidonMarcus — Mon, 18 Nov 2019 14:44:28 GMT

There's a few commands here to clear the different caches.

https://kb.netapp.com/app/answers/answer_view/a_id/1002483/loc/en_US - What is the command to expire credential cache in clustered Data ONTAP 8.2.1?

Re: Inconsistent Behavior AD Authenticated vServer and Domain Tunnel

StorageNob — Wed, 20 Nov 2019 12:10:18 GMT

Thanks for that, unfortunately none of those commands worked. Users removed from a security group could still log in for upt o 20 minutes on our NetApp systems.

I have a ticket open with support but I wasn't really getting the answers I was looking for so I came here. So far removing the security group entirely from the vsadmin role and then re-adding it back in is all I can get working. But that seems to defy the point.

security login delete -vserver <cluster> -user-or-group-name "<domain>\securitygroupname" -application ssh -authentication-method domain
security login delete -vserver <cluster> -user-or-group-name "<domain>\securitygroupname" -application http -authentication-method domain
security login delete -vserver <cluster> -user-or-group-name "<domain>\securitygroupname" -application ontapi -authentication-method domain
security login create -vserver <cluster> -user-or-group-name "<domain>\securitygroupname" -application ssh -authentication-method domain
security login create -vserver <cluster> -user-or-group-name "<domain>\securitygroupname" -application http -authentication-method domain
security login create -vserver <cluster> -user-or-group-name "<domain>\securitygroupname" -application ontapi -authentication-method domain

I think that's overkill though.