NetAppのボリュームの言語設定についてのメモ


NetAppのボリュームには言語設定があり、設定内容に応じて使える日本語文字列が異なる。

2023年8月時点での最も対応できる範囲が広い設定は4バイトのUTF-8エンコード形式をサポートしている「utf8mb4」となる。

ドキュメント: マルチバイトを含むファイル名、ディレクトリ名、 qtree 名の ONTAP での処理

utf8mb4はONTAP 9.5以降で使える設定で、Windows側でファイル名に「サロゲート文字と補助文字」を含む文字をNetApp内に保存しようとする場合は、ボリュームがutf8mb4でなければ保存できない

なお、ONTP9.7P1以降では、UTF-8系言語をutf8mb4に変更できるようになっているとのこと(Can the volume language be changed after creation in ONTAP?)

問題は旧来から存在している言語設定である。

ONTAP 8.3.2(7-mode)にある日本語系設定
 ja (Japanese euc-j+)
 ja_v1 (Japanese euc-j)
 ja_JP.PCK (Japanese PCK(sjis)*)
 ja_JP.932 (Japanese cp932*)
 ja_JP.PCK_v2 (Japanese PCK(sjis))

ONTAP 9.10.1にある日本語系設定
 ja
 ja_JP.PCK
 ja.UTF-8
 ja_v1
 ja_v1.UTF-8
 ja_JP.PCK.UTF-8
 ja_JP.932
 ja_JP.932.UTF-8
 ja_JP.PCK_v2
 ja_JP.PCK_v2.UTF-8

問題はドキュメントにここらへんの説明が見当たらないこと

volume create」にある-languageオプションの解説は「Language code」としかなく、標準ではvserverのlanguageと同じとあるので「vserver create」を参照してもたいしたことは書いていない

[-language <Language code>] – Default Volume Language Code
This optionally specifies the default language encoding setting for the Vserver and its volumes. The recommended format is to append .UTF-8 for the language encoding values. For example, for the en_US language, the recommended format is en_US.UTF-8 . The default setting is C.UTF-8 .

NetApp KBに What is the difference between ja_JP.PCK.UTF-8 and ja_JP.PCK_v2.UTF-8? があるのだが

ja_JP.PCK uses cp932_v1.ntt and eucj_v1.ntt.
ja_JP.PCK_v2 uses cp932_v1.ntt and sjis_v2.ntt.

・・・いや説明になってないのでは?という記述のみ

ONTAP 8.3時代のドキュメントの「言語オプション一覧」もたいした記述は無い

ja_v1日本語(euc-j)
ja_v1.UTF-8日本語(euc-j)(UTF-8)
ja_jp.pck_v2日本語PCK(sjis)
ja_JP.PCK_v2.UTF-8日本語PCK(sjis)(UTF-8)

おそらくPCKはSolarisにおける「PC漢字コード」が由来と想定される。

Solaris 2.6 では、従来の日本語 EUC に加えて PCK (シフト JIS あるいは MS 漢字コード) で日本語を扱う環境を新たに提供します。PCK は、Microsoft が Windows3.1 で規定したマイクロソフト標準キャラクタセットと同等の文字集合およびエンコーディングを提供するものです。また、PCK は、従来の Solaris リリースで MS 漢字コード (または シフト JIS) と呼ばれていたものに、ユーザー定義文字やベンダー定義文字を加えたもので、JIS X 0201、JIS X 0208 の 1-84 区 (13 区除く) までに関しては従来のものと互換性があります。

これがベースであるとすれば、PCKはWindows 3.1ベースのもので、PCK_v2はWindows それ以降対応。ONTAP 7.2などで既にPCK_v2は存在していたので、Windows2000ぐらいをベースにしていると想定される。

詳細を探すとSolaris 8のマニュアル PCK(5) に記載があった。

(内容については省略)

同じくONTAP 7.2ぐらいでja_v1, ja_JP.UTF-8 が登場していた。

cp932/932はMicrosoftコードページ932 と呼ばれるWindows 3.1J用にマイクロソフトとNECが定義したShift JISの独自拡張となる。

定義的に考えると、cp932とpckは同一ということになるのだが、先に出てきたWhat is the difference between ja_JP.PCK.UTF-8 and ja_JP.PCK_v2.UTF-8? によると、NetAppのPCKには、cp932範囲の他にも含まれているものがある、ということになる。

で・・・

これ以上の情報が見つからないのである

困ったもんだ

メモ veeamバックアップの資料 2023/07/06版


Veeamバックアップの資料を調べたのでメモ

とりあえずの基本: Veeam Help Center Technincal DocumentのVeeam Backup&Replication

物理サーバを取る場合につかうVeeam Agentの資料:for Windowsfor Linux

Veeamのソフトウェアバージョン確認

Build Numbers and Versions of Veeam Backup & Replication

Build Numbers and Versions of Veeam Agent for Microsoft Windows

Build Numbers and Versions of Veeam Agent for Linux

NetApp 切り替え時 メモ書き


ボリューム言語切り替えは面倒

NetAppのボリューム言語をja_JP.PCKからutf8mb4に変えたいな、と思うとsnapmirrorでのボリューム以降ではなくて、rsyncやrobocopyなどを使ってコピーする必要がある。

例えば、robocopyでやるなら以下の様なバッチファイルを動かしてコピーする

@echo off
set TIME2=%TIME: =0%
set LOGDATE=%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%-%TIME2:~0,2%%TIME2:~3,2%
robocopy \\netappfs\shares1  \\netappfsnew\shares1 /mir /copyall /R:0 /W:0 /LOG+:D:\LOGS\netappfs-shares1-%LOGDATE%.txt
robocopy \\netappfs\document \\netappfsnew\document /mir /copyall /R:0 /W:0 /LOG+:D:\LOGS\netappfs-document-%LOGDATE%.txt

D:\LOGS に実行ログを吐き出すが、バッチファイルの実行開始時間を元にしたファイル名となるので、ログ確認がしやすい

失敗した切り替え手順

IPアドレスが確保出来なかったということなので、旧NetAppのサービス用IP と 新NetAppの仮接続用IPしかない、ということなので

旧NetAppのネットワークケーブル抜いてから
新NetApp側のIPアドレスを切り替えてAD参加
旧NetApp側のIPアドレスを新NetAppについてた仮接続用IPに切り替え
旧NetAppのネットワークケーブルを接続して、AD参加

ということをやればいいかなーと以下の手順で実施した。

が・・・これだと旧NetAppがnetappfsとして参加していた情報の方が勝つらしく、12の段階で旧サーバがnetappfsだとしてAD上のアクセス情報を持っていこうとしているっぽく、問題が発生した。

このため新NetAppをもう1度Active Directoryに参加させるという対処を行う羽目になった。

  1. 旧NetAppが ADに netappfs で参加している
  2. 新NetAppが ADに netappfsnew で参加してデータ移行
    新::> vserver cifs create -vserver netappfs -cifs-server netappfsnew
  3. 切り替え日
  4. 旧NetAppのADをdown
     旧::> vserver cifs modify -vserver netappfs -state-admin down
  5. 新NetAppのADをdown
     新::> vserver cifs modify -vserver netappfs -state-admin down
  6. 旧NetAppのネットワークケーブルを外す
     (旧NetAppのIPアドレスは変更していない)
  7. 新NetAppでIPを引き継ぎ
    新::> network interface modify -vserver netappfs -lif ~ -address サービス用IP
  8. 新NetAppをnetappfsとしてAD参加
     新::> vserver cifs modify -vserver netappfs -cifs-server netappfs
  9. 新NetAppにクライアントからアクセスできるか確認
     問題ないことを確認
  10. ケーブルを外した状態で旧NetAppのIPを変更
    旧::> network interface modify -vserver netappfs -lif ~ -address 別IP1
  11. 旧NetAppのネットワークケーブルをつなぐ
  12. 旧NetAppをAD再参加
     旧::> vserver cifs modify -vserver netappfs -cifs-server netappfs-old
      → クライアントから新NetApp(netappfs)にアクセスできなくなる
       新NetAppで「vserver cifs check」コマンドを実行すると
       「down SecD Error: no server available」といったエラーが出ている
  13. 新NetAppのAD登録名を一時的に別のものに参加したあと、正式名で再参加
     新::> vserver cifs modify -vserver netappfs -state-admin down
     新::> vserver cifs modify -vserver netappfs -cifs-server netappfstmp
     新::> vserver cifs modify -vserver netappfs -state-admin down
     新::> vserver cifs modify -vserver netappfs -cifs-server netappfs
      → クライアントから新NetApp(netappfs)にアクセスできるようになる

同じではないが、OUがちゃんと変更されていない場合の再変更手順「Organizational Unit (OU) is not updated in ONTAP after Active Directory object move」を見ると「vserver cifs stop -vserver netappfs」で止めたあと、もう1回「vserver cifs modify -vserver netappfs -cifs-server netappfs -ou OU=NewOU」と実行する、という風になっていた

いつもの切り替え手順

いつもは旧NetAppのサービス用IP と 新NetAppの仮接続用IP、旧NetAppの仮接続用IPの3つを用意してもらって切り替えている

1. 旧NetAppが ADに netappfs で参加している
2. 新NetAppが ADに netappfsnew で参加してデータ移行
  新::> vserver cifs create -vserver netappfs -cifs-server netappfsnew
3. 切り替え日
4. 旧NetAppのADをdown
 旧::> vserver cifs modify  -vserver netappfs -state-admin down
5. ケーブルを外した状態で旧NetAppのIPを変更
  旧::> network interface modify -vserver netappfs -lif ~ -address 旧NetAppの仮接続用IP
6. 旧NetAppをAD再参加
 旧::> vserver cifs modify  -vserver netappfs -cifs-server netappfs-old
7. 新NetAppのADをdown
 新::> vserver cifs modify  -vserver netappfs -state-admin down
8. 新NetAppでIPを引き継ぎ
  新::> network interface modify -vserver netappfs -lif ~ -address サービス用IP
9. 新NetAppをnetappfsとしてAD参加
 新::> vserver cifs modify  -vserver netappfs -cifs-server netappfs
10. 新NetAppにクライアントからアクセスできるか確認
 問題ないことを確認

メモ

secd logにログが出ているらしい?

/mroot/etc/log/mlog/secd.log というパス? (Overview of ONTAP Logs)

SVMのマシンアカウントのパスワードを再設定する「vserver cifs domain password reset」を実行することで解消する?


2023/11/23追加

Windowsサーバ→NetAppのrobocopy実行時にいくつか問題がある

(1) audit/監査設定周り

Windowsサーバ上で監査設定をちゃんと使っている場合、NetApp ONTAP側で使える監査機能との差異によって監査設定が期待通りにコピーできずにrobocopyがエラーになる。

具体的には「/copyall」もしくは「/copy:DATSOU」ではエラーとなる

robocopy D:\share\ \\netapp\share\ /COPYALL /MIR /B /EFSRAW /R:1 /W:1 /NP
<略>
	          古い		   3.0 g	SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Japanese_w_SP1_MLF_X17-22600.ISO
2023/11/01 xx:xx:xx エラー 31 (0x0000001F) NTFS セキュリティをコピー先ファイルにコピーしています D:\share\ISO\SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Japanese_w_SP1_MLF_X17-22600.ISO
システムに接続されたデバイスが機能していません。
<略>
2023/11/01 xx:xx:xx エラー 32 (0x00000020) ファイルをコピーしています	F:\COMMON\document\testdocument.docx
プロセスはファイルにアクセスできません。別のプロセスが使用中です。
エラー: 再試行が制限回数を超えました。
<略>

(オマケ:Notepad++でrobocopyのログ確認する時は、「^(.+新しいディレクトリ).+\r\n」「^(.+新しいファイル).+\r」「^(.+更新済み).+\r\n」の3つを「」(置き換え文字列を何も指定しない)に置き換えると問題となっているファイルを探しやすい。英語の場合はNew Dir,Newer,New File,Modified)

How to move files to a NetApp CIFS server using Robocopy to retain Windows ACLs

Does robocopy need to use /copy:datso option if the source has Windows Mandatory Level permission? (対象がcloud volumes ONTAPと書いてあるが、一般のONTAPも対象)

Robocopy unable to set all ACLs on a file (The SACL includes a Mandatory Label which is not supported by ONTAP)

対象方法は「/copy:DATSO」でコピーする、とある

(2) 毎回modifyになるという事象

タイムスタンプまわりの挙動がWindowsサーバとONTAPとで違うらしく、それが差分と認識されることがあるようだ。

ただ、情報の更新だけが行われているようで、ファイルの実体コピーは行われていない模様


robocopyのログで出る「*EXTRA File」は、コピー先にしか存在しないファイル

代表的なrobocopyエラーコードと対処一覧

エラー 2 (0x00000002)→指定したフォルダが存在しない
エラー 5 (0x00000005)→アクセス権がない。robocopyに/Bオプションを付ける
エラー 31 (0x0000001F)→コピー先に元と同じNTFSセキュリティ設定が行えない(OS制約などの可能性)
エラー 32 (0x00000020)→ファイルがアプリケーションからロックされているのでアプリを閉じる
エラー 64 (0x00000040)→指定した共有にアクセスできない
エラー 87 (0x00000057)→指定した共有にアクセスするためのユーザ名/パスワード指定が誤っている
エラー 112(0x00000070)→コピー先容量が足らない

参考:SEの道標【robocopy】のログの見方、エラーコード一覧〜不一致、EXTRAS〜
robocopyのエラーコードはWin32のエラーコードそのままなので上記以外については 「Win32 Error Codes」を参照

Active Directoryサーバのセキュリティ強化アップデート(CVE-2022-38023)に伴うONTAPファイルサーバへの影響についてのメモ


WindowsのActive Directoryサーバに対してセキュリティ攻撃ができることが判明したため、Active Directoryサーバに対してセキュリティ強化がWindows Update経由で2022年11月に配布されている。

このときのアップデートで対応されたのは下記の3点

KB5021131: CVE-2022-37966 に関連する Kerberos プロトコルの変更を管理する方法
KB5020805: CVE-2022-37967 に関連する Kerberos プロトコルの変更を管理する方法
KB5021130: CVE-2022-38023 に関連する Netlogon プロトコルの変更を管理する方法

CVE-2022-37966とCVE-2022-38023はどちらも暗号化方式として脆弱なRC4-HMACを使用するのをやめてAESに変更する、というものとなっている。

このため、Kerberos/NTLMv2のどちらを使っていてもRC4-HMACを使用している場合は、このWindows Update適用後に問題が発生する、ということになる。

Windows サーバで構成されているActive Directoryサーバ側での対応については以下にまとめられている

CVE-2022-37966 への対応とその影響について
CVE-2022-37967 への対応とその影響について
CVE-2022-38023 への対応とその影響について

いろいろ書いてあるが、Windowsサーバのレジストリ設定をすることで、強制適用を延期できるけど、最終的にはアクセスできなくなるよ、ということになっている。

で・・・どういう場合に問題が発生するのか?というところが問題となる。

問題が発生するもの

・Active Directoryサーバに対してRC4-HMAC暗号化を使ってKerberos認証を行う場合
・Active Directoryサーバに対してRPC署名を使ってNTLMv2認証を行う場合
・Active Directoryサーバに対してRPCシールとRC4-HMAC暗号化を使ってNTLMv2認証を行う場合

2023/07/24追記: sambaによるActive Direcotryサーバで NTLMv2認証を使う場合(詳細は一番下で解説)

問題が起こらないもの

・Active Directoryサーバに対してAES暗号化を使ってKerberos認証を行う場合
・Active Directoryサーバに対してRPCシールとAES暗号化を使ってNTLMv2認証を行う場合
 (NTLM/Netlogon Secure Channel は同じ意味)

(他にも大丈夫な場合はあると思います)

具体的な環境

2023年5月時点で適切にWindows Updateが実施されているWindows 7 / Windows Server 2012以降のマシンで、Active Directoryに参加している場合はKerberos/AESなので問題ない

Windowsであってもworkgroupとして認証を行う場合はNTLMv2となる場合があるので注意が必要

Linuxからcifs-utilsを使ってCIFS領域をマウントする場合、標準設定ではNTLMv2を使用するため注意が必要

LinuxをActive Directoryに参加させる場合、注意が必要
 Microsoft の 2022 年 11 月の更新により Active Directory の統合が中断される
 Red Hat Enterprise Linux and Microsoft security update of November 2022

ファイルサーバでの問題発生例

Active Directoryに参加しているファイルサーバでは以下のような形で認証が行われる模様

・[クライアント]→Kerberos認証→[ファイルサーバ]→Kerberos認証→[Active Directory]
・[クライアント]→NTLMv2認証→[ファイルサーバ]→NTLMv2認証→[Active Directory]

クライアントからどちらの形式でアクセスをしてくるかで、ファイルサーバ側からActive Directoryへの問いあわせ手法も変わる、ということになる。

このため、ファイルサーバの仕様で問題が発生することとなるため各社がお知らせを出している

・sambaでの問題 RC4/HMAC-MD5 NetLogon Secure Channel is weak and should be avoided Samba 4.15.13/4.16.8/4.17.4以降で対応
・NetAppでの問題 SU530: [Impact Critical] NTLM authentication fails due to enforcement of Netlogon RPC sealing (Microsoft CVE-2022-38023) ONTAP 9.7以降の2023年4月中旬以降提供バージョンで対応
・RedHat/samba CVE-2022-38023
・DELL PowerScale/iSilon PowerScale: Isilon: Netlogon RPC Elevation of Privilege Vulnerability (CVE-2022-38023) OneFS 9.5.0以降で対応
・DELL Unity Dell Unity: Is Unity affected by CVE-2022-38023? (User Correctable) Unity OE 5.1.0以降で対応

・Synology Synology-SA-22:24 Samba AD DC 2023/05/11時点では未提供だが対象リストを見ると通常のファイルサーバ用途では対応不要?
 QNAP,バッファローなども特にお知らせは無し

2023/07/24追記

・バッファロー TeraStation/LinkStation CVE-2022-38023の脆弱性対応によるTeraStation/LinkStationへの影響について
WindowsOSじゃないLinuxベースのやつは影響を受けるようです

・QNAP QTSシリーズ Vulnerabilities in Samba CVE-2022-37966 | CVE-2022-37967 | CVE-2022-38023 | CVE-2022-45141
FreeBSDベースのQESシリーズは影響なし、ですが、それ以外の通常QNAPは影響あり、と

NetApp ONTAPでの対応

対応が必要であるかの調査

NetApp ONTAPでは、ファイルサーバ=>Active Directoryの通信をRC4-HMACで行ってたということで修正がONTAP OSの修正がリリースされています。

2023年4月後半以降にリリースされたONTAP 9.7以降のパッチリリースのみが今回の問題に対応しています。

詳細については富士通が見える状態でリリースを置いてくれています

ETERNUS AX/HXシリーズ, ETERNUS NR1000シリーズにおける WindowsのNetlogon脆弱性対応(CVE-2022-38023)による影響(CIFS接続不可)について

いろいろ書いてありますが、とりあえず、今使ってるNetAppファイルサーバにNTLMv2を使ってアクセスしてきてるユーザがいるのかを確認しましょう

「vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address」を実行して、auth-mechanismに「NTLMv2」がいる場合は対処が必須です。

netapp9101::> vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address
node          vserver session-id           connection-id address       auth-mechanism windows-user  protocol-version
------------- ------- -------------------- ------------- ------------- -------------- ------------- ----------------
netapp9101-01 svm0    14421088956793749524 535041285     172.17.44.173 Kerberos       VM2\testuser1 SMB2_1
netapp9101-01 svm0    14421088956793749539 535041298     172.17.44.174 NTLMv2         VM2\testuser1 SMB3
2 entries were displayed.
netapp9101::>

このテスト環境では、172.17.44.173はWindows 7 SP1クライアント、172.17.44.174はRHEL 7.6からCIFSマウントしている環境でした。

このRHEL7.6は「mount -t cifs //svm0.adosakana.local/testutf /mnt2 -o user=testuser1@adosakana.local,password=パスワード,vers=3.0」と実行してマウントしているもので、sec=オプションを付けていない場合はNTLMv2を使用しているようでした。

この「vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address」はCIFS接続が継続している間は表示される、というものになっているため、数分間アクセスを行わないとリストから消えます。

このため、NTLMv2でアクセスしているかどうかが分からない機械がある場合は、アクセス操作を行ってみた直後にコマンドを実行してみる必要があります。

必要な対応

ONTAP OSのバージョンアップが必要な場合はアップデートを行います。

2023/05/11時点ではCVE-2022-38023に対応するアップデートとして以下が提供されています。

 ONTAP 9.7P22 (End of Limited Support 2025/07/31)
 ONTAP 9.8P18 (End of Limited Support 2025/12/31)
 ONTAP 9.9.1P15 (End of Limited Support 2026/06/30)
 ONTAP 9.10.1P12(End of Limited Support 2027/01/31)
 ONTAP 9.11.1P8 (End of Limited Support 2027/07/31)
 ONTAP 9.12.1P2 (End of Limited Support 2028/02/28)

FAS2520/2552/2554,FAS8020/8040/8060/8080 は ONTAP 9.9.1 までサポート
FAS2620/2650 は ONTAP 9.11.1 までサポート
FAS2720/2750などの現行機種は 制限なし

アップデート先は、同じONTAP OSバージョン内の最新にするか、ハードウェアがサポートされている範囲の新しいバージョンにするかはご自由に

ONTAP OS 9.6などのアップデート提供がバージョンを使用している場合は、ONTAP 9.7以降にアップデートする必要があります。

古いONTAPを新しいONTAPにアップデートする場合、状態によっては複数回のアップデートが必要となります

詳細は「どのバージョンの ONTAP にアップグレードできますか。」を参照してください

例えばONTAP 9.11.1へアップデートする場合、下記のような手順となります。

  ONTAP 9.4→(9.5+9.7)→9.9.1→9.11.1
  ONTAP 9.5→(9.7+9.9.1)→9.11.1
  ONTAP 9.6→9.8→9.11.1
  ONTAP 9.7→(9.8+9.11.1)

(9.5+9.7)というのはONTAP 9.5とONTAP 9.7のアップデートファイルを読み込ませてONTAP 9.7のアップデートとして実行すると、内部的に自動的にONTAP 9.5の適用を行ったあとに9.7適用を行ってくれる、ということをします。

どんな感じでアップデートするか、というのは「この記事」から持ってきた下記画面を参照してください。

1)「イメージの追加」からアップデートするファイルを2つ登録する

2) 新しいバージョンを選択して「更新」

3) まずは古いバージョンの方の適用が開始される

4) 続いて新しいバージョンの方が適用される

5) 終了


NetAppでの調査/対応に関するメモ

NetAppでサポートする認証方式の変更

Set the SMB server minimum authentication security level

「vserver cifs security show -fields lm-compatibility-level」で現在設定されている認証方式を確認

netapp9101::> vserver cifs security show -fields lm-compatibility-level
vserver lm-compatibility-level
------- ----------------------
Cluster -
Snapmirror-WAN
        -
netapp9101
        -
netapp9101-01
        -
svm0    lm-ntlm-ntlmv2-krb
svm2    lm-ntlm-ntlmv2-krb
svm3    lm-ntlm-ntlmv2-krb
7 entries were displayed.
netapp9101::>

値の意味は下記

ValueDescription
lm-ntlm-ntlmv2-krb (default)The storage virtual machine (SVM) accepts LM, NTLM, NTLMv2, and Kerberos authentication security.
ntlm-ntlmv2-krbThe SVM accepts NTLM, NTLMv2, and Kerberos authentication security. The SVM denies LM authentication.
ntlmv2-krbThe SVM accepts NTLMv2 and Kerberos authentication security. The SVM denies LM and NTLM authentication.
krbThe SVM accepts Kerberos authentication security only. The SVM denies LM, NTLM, and NTLMv2 authentication.

標準ではLM, NTLM, NTLMv2, Kerberosに対応している、ということになっている。

NetApp側で強制的にLM,NTLM,NTLMv2クライアントを排除する、という場合は「krb」に変更する

Kerberos接続時のAES暗号化を有効化

Enable or disable AES encryption for Kerberos-based communication

「vserver cifs security show -fields is-aes-encryption-enabled」を実行して確認。ONTAP 9.12.1以降は「true」が標準値となる。

netapp9101::> vserver cifs security show -fields is-aes-encryption-enabled
vserver is-aes-encryption-enabled
------- -------------------------
Cluster -
Snapmirror-WAN
        -
netapp9101
        -
netapp9101-01
        -
svm0    false
svm2    false
svm3    false
7 entries were displayed.
netapp9101::>

なお設定を変更する場合は、ドメイン認証を求められるので注意

netapp9101::> vserver cifs security modify -vserver svm0 -is-aes-encryption-enabled true
Info: In order to enable CIFS AES encryption, the password for the CIFS server
      machine account must be reset. Enter the username and password for the
      CIFS domain "ADOSAKANA.LOCAL".
Enter your user ID: administrator
Enter your password:
netapp9101::> vserver cifs security show -fields is-aes-encryption-enabled
vserver is-aes-encryption-enabled
------- -------------------------
Cluster -
Snapmirror-WAN
        -
netapp9101
        -
netapp9101-01
        -
svm0    true
svm2    false
svm3    false
7 entries were displayed.
netapp9101::>

なお、AES暗号化に関連する設定は is-aes-encryption-enabled 以外に aes-enabled-for-netlogon-channel という設定もある。こちらの詳細については「CVE-2022-38023適用後 NetAppがActive Directoryに参加できない」参照


2023/07/24追記

sambaによるActive Direcotryサーバで NTLMv2認証を使う場合のトラブル

sambaの商業サポートを行っているOSStechに2023/07/21付けのお知らせとして「Windows Updateに伴うSambaの認証の問題を解消するアップデートです。」が掲載されています。

曰く、セキュアチャネルが壊れ、下記3種類の問題が発生するとのこと。

・Sambaのみを使用したActive Directoryサーバ環境におけるNTLM認証が失敗
・リモートデスクトップの認証が失敗
・Sambaのみを使用したNTドメイン環境でNTドメインのログオンが失敗

バグとしては恐らく「BUG 15418: Secure channel faulty since Windows 10/11 update 07/2023」となる

てっきりActive Directoryサーバを運用しているWindows Serverのみ気を使っていればいいのかと思ったら、クライアント側にも影響があったとは・・・


2023/11/14追記

ONTAP 9.10.1より前のONTAPで、CVE-2022-38023適用したActive Directoryドメイン(sambaドメイン含む)に参加できない、という事象が発生した。

詳細は「CVE-2022-38023適用後 NetAppがActive Directoryに参加できない」に書いたが、Active DIrectoryサーバとONTAP間のkerberos通信の暗号化をRC4 MD5ではなくて、AESを使うようにしなければならないので、NetAppのcifsオプションにあるis-aes-encription-enabledとaes-enabled-for-netlogon-channelを有効にする必要がある、というものだった。


2024/05/23メモ

接続状態を確認するときに、どの共有にアクセスしてるか、と、ローカルユーザなのかADユーザなのかをわかるようにするオプション

「vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address,user-type,is-session-signed,smb-encryption-status,share-names,continuously-available,is-large-mtu-enabled」

ontap9131::> vserver cifs session show -fields auth-mechanism,protocol-version,windows-user,address,user-type,is-session-signed,smb-encryption-status,share-names,continuously-available,is-large-mtu-enabled
node            vserver      session-id          connection-id address       auth-mechanism windows-user  protocol-version continuously-available is-session-signed user-type   smb-encryption-status is-large-mtu-enabled share-names
--------------- ------------ ------------------- ------------- ------------- -------------- ------------- ---------------- ---------------------- ----------------- ----------- --------------------- -------------------- ---------------
ontap9131 svm01 6194701287448117256 2260371604    172.17.44.162 Kerberos       ADOSAKANA\testuser1 SMB3_1           No                     false             domain-user unencrypted           true                 ipc$,testshare2

ontap9131::>