#SVM Migration Feedback

1 messages · Page 1 of 1 (latest)

void oriole
#

Hi,

Not sure where best to post this, but my team have been using the SVM Migrate feature to evacuate one of our datacentres. A super useful mechanism by the way, many thanks for implementing it!

We do have some feedback, specifically around SMB/CIFS SVM migrations.

The pre-check mechansim doesn't assess the source cluster on whether or not the SVM being migrated is being utilised as the domain-tunnel for cluster authentication.
We found this out the hard way! Luckily we have breakglass local accounts.

This may already be considered in newer version of code, in which case this can be ignored by staff but taken into consideration by consumers!
We are running 9.12.1P5.

Thanks,
Dan

errant raptor
#

I think it is still best practice to have a separate SVM that is doing tunnel authentication (it doesn't even need CIFS, only an active directory connection)

void oriole
main pebble
#

I’ve been trying to to get the security folk at Netapp to update. Why on earth are they still using a cifs svm for domain tunnel?!!!

The more secure method is to create a dedicated auth svm. Then add a single lif with a” default-management “ service-policy and place on e0M. Add the default route/gw. Configure DNS for the svm. Modify the “cifs “ security parameters as needed. Then instead of “cifs create”, do the “active-directory create” instead.
Why?
No change in hell of having any cifs data served. Can’t serve data on e0M and there is technically no cifs server. Guess what? Domain-tunnel still works.

NETAPP: contact me. Let’s fix this! In ask the security hardening documents!

subtle elbow
#

Thanks @main pebble for the hint. We still use on the dedicated auth SVM a cifs server for the AD join. Do you potentially have like a best practice guide for for the AD access?

main pebble
#

Not really. One person can’t do best practices. Should be agreed upon

round slate
#

Does it bug me? Yes.

main pebble
#

I’m definitely referring to the security hardening guides. Absolutely they should do the most secure option. They should be using the Active Directory create instead of cifs create. No question in my mind it is flawed in that regard

#

Either way, you still need the domain tunnel command to make it work. Do the more secure thing

errant raptor
#

wouldn't the most secure thing to use local accounts with separate passwords, instead of AD accounts which can get more easily compromised? 😉

main pebble
#

All the Harding guides say only use the local account as a last resort. Make the password random and lock it in a safe. No one should know it unless there is an emergency. They want you to use domain authentication

#

I do not completely agree but it is secure. Plus domain accounts can’t access the console or service processor. They also have you disable the service processor.

#

And they have you disable the https interface so you must ssh in and only use cli.

#

The military/dod one is even worse which I can’t share

errant raptor
#

we had customers where some attackers used an exploit to gain access as "backup" user in the domain and were then able to ssh into ONTAP since a domain tunnel was used. Then they deleted all backups and encrypted live data. This wouldn't have happened if they had used local users with different passwords.

main pebble
#

Yep. That would fall under reading the items in the guide and locking down which users/groups are authorized. Clearly it was too broad or the backup user was possibly not secured

errant raptor
#

yeah, well, by that argument every single security incident boils down to "not reading/properly implementing the hardening guide" 😄

#

but we all knonw that for 99% of customers, security is a tradeoff

buoyant moon
#

Wasn't there some talk about domain-tunneling changing in ONTAP 9.13?
I don't see anything about it in the Release notes though.
Edit: Maybe it was in a dream, can't find anything about it here on the Discord either.