SMBファイルサーバー上のアクセス権限がないフォルダを参照しようとしたときに There's a problem accessing と長期間エラーメッセージが表示される場合はWinRMのポートへのアクセスを疑おう
2025.04.05アクセス許可をしていないフォルダを開こうとした際に拒否されたことを示すエラーダイアログが表示されるまで時間がかかる
こんにちは、のんピ(@non____97)です。
皆さんはSMBファイルサーバーを運用する中で、アクセス許可をしていないフォルダを開こうとした際に、拒否されたことを示すエラーダイアログが表示されるまで時間がかかるなと思ったことはありますか? 私はあります。
例えば以下のようにThere's a problem accessing (日本語 : アクセスの問題が発生しました)というダイアログが15秒ほど表示され、その後ようやくアクセスできない旨のメッセージが表示されるといった具合です。
それはもしかすると、WimRM のポート TCP/5985をセキュリティグループで許可していないからかもしれません。
実際にこちらの事象について紹介します。
いきなりまとめ
- Kerberos認証を行うSMBアクセスの場合、アクセス権限がないフォルダを参照しようとすると、WinRMのポートであるTCP/5985にアクセスしようとしてしまう
- セキュリティグループでTCP/5985を許可していない場合、アクセス拒否されたことを示すエラーダイアログが表示されるまで10秒から15秒ほど時間がかかる
- セキュリティグループはパケットをREJECTではなく、DROPするため、クライアント側がタイムアウトするまでトライしてしまうため
There's a problem accessingというエラーメッセージの表示期間を短くする、もしくは表示させないために考えられる対応は以下- セキュリティグループでWinRMのポートを許可する
- Network Firewallやオンプレミスファイアウォールなど前段のネットワーク機器でWinRMへのアクセスをREJECTするルールを追加する
- クライアントのファイアウォールのアウトバウンドルールでWinRMへのアクセスをREJECTするルールを追加する
- ABEを有効化し、アクセス権限が付与されていないフォルダは表示させない
- 個人的には2~4の方法が望ましい
- 1つ目の方法はLISTENしている/いないにも関わらず、本来の用途ではないポートを広い範囲で許可することになりがちであるため、好ましくない
やってみる
検証環境
検証環境は以下のとおりです。
(別AZのManaged Microsoft ADは割愛)
Amazon FSx for NetApp ONTAP(以降FSxN)のSMBファイルサーバーはManaged Microsoft ADのドメインに参加させています。
SVMは以下のようになっています。
用意したSMBファイル共有vol_share配下にNew folderというフォルダを作成しました。
ACLを変更して、ドメインのAdminユーザーの読み込みを拒否するように設定します。
WinRMのポートが空いていない場合
SMB DNS名でアクセス
まず、WinRMのポートをセキュリティグループで空けていない場合から確認します。
SMB DNS名を用いて\\SMB-SERVER.corp.non-97.net\vol1_shareでアクセスします。
この状態でNew folderをドメインのAdminユーザーで開こうとすると、There's a problem accessing (日本語 : アクセスの問題が発生しました)とエラーのダイアログが表示されました。
15秒ほど待つとようやくWindows cannot accessとアクセスできない旨のメッセージが表示がされました。
何回か確認しましたが、おおよそ最初のエラーダイアログが表示されている期間は10秒~15秒で、それなりに長いという印象です。
この時のパケットキャプチャの結果を確認すると、[The RTO for this segment was: 15.022186000 seconds]やThis frame is a (suspected) retransmissionという記述から、最初にWinRMのポートTCP/5985へパケットを送信してから15秒後に、TCPパケットの再送を行なっていることが分かります。
リクエストは11:49:43に行われており、最後のTCP Retransmissionが発生したのは11:49:58と15秒かかっています。これは1つ目のエラーダイアログが表示され、2つ目のエラーダイアログが表示されるまでのタイミングと一致しています。
セキュリティグループで許可していないパケットはDROPされます。REJECTではありません。そのため、RSTパケットは返って来ず、タイムアウト = 今回の場合は15秒経過するまで待ち続けるという動きになります。
参考までにこちらのSMBセッションはKerberos認証で行われています。
::*> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, smb-encryption-status
node vserver session-id connection-id address auth-mechanism windows-user shares protocol-version smb-encryption-status
------------------------- ------- ------------------ ------------- ------------- -------------- ------------ ------ ---------------- ---------------------
FsxId064d286a4aeabacb8-01 svm 460493061898633223 2456725581 172.31.34.150 Kerberos CORP\Admin 2 SMB3_1 unencrypted
これはドメイン参加時に自動でSMB DNS名でSPNが設定されるためです。
SVM DNS名でアクセス
続いて、SVM DNS名でアクセスしてみます。
\\svm-0f28df34252ac20e0.fs-064d286a4aeabacb8.fsx.us-east-1.amazonaws.com\vol1_share\New folderにアクセスします。
はい、こちらはThere's a problem accessingとエラーのダイアログが表示されずに、即座にWindows cannot accessとアクセスできない旨のメッセージが表示がされました。
パケットキャプチャを確認すると、そもそもWinRMのポートにアクセスしようとした形跡がありませんでした。
また、こちらのSMBセッションはNTLM認証です。
::*> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, smb-encryption-status
node vserver session-id connection-id address auth-mechanism windows-user shares protocol-version smb-encryption-status
------------------------- ------- ------------------ ------------- ------------- -------------- ------------ ------ ---------------- ---------------------
FsxId064d286a4aeabacb8-01 svm 460493061898633224 2456725582 172.31.34.150 NTLMv2 CORP\Admin 2 SMB3_1 unencrypted
IPアドレスでアクセス
NTLM認証とKerberos認証とが差異として怪しそうということでIPアドレスでアクセスします。
\\172.31.43.110\vol1_share\New folderにアクセスします。
こちらもThere's a problem accessingとエラーのダイアログが表示されずに、即座にWindows cannot accessとアクセスできない旨のメッセージが表示がされました。
パケットキャプチャを確認すると、こちらもWinRMのポートにアクセスしようとした形跡がありませんでした。
こちらのSMBセッションもNTLM認証です。
::*> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, smb-encryption-status
node vserver session-id connection-id address auth-mechanism windows-user shares protocol-version smb-encryption-status
------------------------- ------- ------------------ ------------- ------------- -------------- ------------ ------ ---------------- ---------------------
FsxId064d286a4aeabacb8-01 svm 460493061898633227 2456725593 172.31.34.150 NTLMv2 CORP\Admin 1 SMB3_1 unencrypted
このことからKerberos認証をする場合においてのみ、WinRMのポートへのアクセスに対する何かしらのケアが必要ということが分かります。
WinRMのポートをセキュリティグループで許可
試しにセキュリティグループでWinRMのポートを許可します。
なお、FSxNはデフォルトでWinRMのポートであるTCP/5985はLISTENしていません。
::*> network connections listening show
Vserver Name Interface Name:Local Port Protocol/Service
---------------- ------------------------------------- -----------------------
Node: FsxId064d286a4aeabacb8-01
svm nfs_smb_management_1:40001 TCP/cifs-msrpc
svm nfs_smb_management_1:135 TCP/cifs-msrpc
svm nfs_smb_management_1:445 TCP/cifs-srv
svm nfs_smb_management_1:139 TCP/cifs-srv
svm nfs_smb_management_1:4049 UDP/rquota
svm nfs_smb_management_1:111 TCP/port-map
svm nfs_smb_management_1:111 UDP/port-map
svm nfs_smb_management_1:4046 TCP/sm
svm nfs_smb_management_1:4046 UDP/sm
svm nfs_smb_management_1:4045 TCP/nlm-v4
svm nfs_smb_management_1:4045 UDP/nlm-v4
svm nfs_smb_management_1:2049 TCP/nfs
svm nfs_smb_management_1:2049 UDP/nfs
svm nfs_smb_management_1:635 TCP/mount
svm nfs_smb_management_1:635 UDP/mount
15 entries were displayed.
WinRMのポートが空いている場合
SMB DNS名でアクセス
この状態でSMB DNS名でアクセスします。
すると、There's a problem accessingとエラーのダイアログが表示されましたが、2秒ほどでWindows cannot accessとアクセスできない旨のメッセージが表示がされました。
パケットキャプチャを確認するとRSTパケットが確かに返ってきていますね。
これによってタイムアウトまで待たず、Windows cannot accessとアクセスできない旨のメッセージを表示するようになったのだと考えます。
もちろん、このSMBセッションの認証はKerberos認証です。
::*> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, smb-encryption-status
node vserver session-id connection-id address auth-mechanism windows-user shares protocol-version smb-encryption-status
------------------------- ------- ------------------ ------------- ------------- -------------- ------------ ------ ---------------- ---------------------
FsxId064d286a4aeabacb8-01 svm 460493061898633230 2456725600 172.31.34.150 Kerberos CORP\Admin 1 SMB3_1 unencrypted
また、SVM DNS名やIPアドレスで接続した場合は変わらず、即Windows cannot accessとアクセスできない旨のメッセージが表示がされました。
考えられる対応の整理
There's a problem accessingというエラーメッセージの表示期間を短くする、もしくは表示させないために考えられる対応を整理してみましょう。
方法としては以下が考えられます。
- セキュリティグループでWinRMのポートを許可する
- Network Firewallやオンプレミスファイアウォールなど前段のネットワーク機器でWinRMへのアクセスをREJECTするルールを追加する
- クライアントのファイアウォールのアウトバウンドルールでWinRMへのアクセスをREJECTするルールを追加する
- ABEを有効化し、アクセス権限が付与されていないフォルダは表示させない
1つ目から3つ目についてはWinRMへのアクセスを制御することで対応するというアプローチです。
Network FirewallのREJECTルールについては以下記事をご覧ください。
4つ目については、そもそもアクセス権限が付与されていないフォルダは表示させないことにするアプローチです。ABEについては以下記事をご覧ください。
個人的には1つ目の方法は極力避けたいところです。FSxNについてはWinRMをそもそもLISTENしていないため問題はないです。
ただし、Amazon FSx for Windows File ServerなどWindows Serverベースのファイルサーバーの場合はLISTENしているため、SMBのアクセス元 = WinRMのアクセス元とするのはリスクだと考えます。
そのため、2つ目から4つ目の案を検討すると良いでしょう。
クライアントのファイアウォールのアウトバウンドルールでWinRMへのアクセスをREJECTするルールを追加する
「クライアントのファイアウォールのアウトバウンドルールでWinRMへのアクセスをREJECTするルールを追加する」の方法を試してみましょう。
今回のクライアントはWindows Serverでドメイン参加しています。
ということで、グループポリシーを用いてWindowsファイアウォールでWinRMのポートへのアクセスを拒否するアウトバウンドルールを設定します。
gpmc.mscを用いて、クライアントのコンピューターオブジェクトが存在するComputers OUにreject-winrmというGPOを作成しました。
作成したGPOを編集し、コンピューターの構成>Policies>Windows 設定>セキュリティ設定>セキュリティが強化された Windows ファイアウォールからreject-winrmというアウトバウンドルールを作成しました。
Scopeで送信先IPアドレスがSMBファイルサーバーのIPアドレスのみの場合にこのルールが適用されるようにしています。
GPOを用いてWindowsファイアウォールを定義する際は以下Microsoft公式ドキュメントも参考になります。
GPOを強制的に適用します。
> gpupdate /force
Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.
検証結果が分かりやすくなるようにセキュリティグループに追加していたWinRMのポートへの許可をするインバウンドルールは削除しておきます。
この状態で\\SMB-SERVER.corp.non-97.net\vol1_share\New folderをドメインのAdminユーザーで開こうとすると、There's a problem accessingとエラーのダイアログが表示されず、即Windows cannot accessとアクセスできない旨のメッセージが表示がされました。
この時のパケットキャプチャは以下のとおりです。WinRMポートへの通信は発生してませんね。
ということで、クライアントがドメイン参加しているのであればWindowsファイアウォールのドメインネットワークプロファイルで対応するのが楽そうです。
ちなみに、このSMBセッションもKerberos認証です。
::*> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, smb-encryption-status
node vserver session-id connection-id address auth-mechanism windows-user shares protocol-version smb-encryption-status
------------------------- ------- ------------------ ------------- ------------- -------------- ------------ ------ ---------------- ---------------------
FsxId064d286a4aeabacb8-01 svm 460493061898633235 2456725614 172.31.34.150 Kerberos CORP\Admin 1 SMB3_1 unencrypted
unencryptedとなっていますが、これはFSxNの設定でSMBファイルサーバーレベルでの転送時の暗号化を有効化していないためです。
以下のようにしかるべき設定をしてあげれば、次回セッションから暗号化されます。
::*> cifs security show -fields is-smb-encryption-required
vserver is-smb-encryption-required
------- --------------------------
svm false
::*> cifs security modify -vserver svm -is-smb-encryption-required true
::*> cifs security show -fields is-smb-encryption-required
vserver is-smb-encryption-required
------- --------------------------
svm true
::*> cifs session close -node FsxId064d286a4aeabacb8-01
Warning: This will close all the CIFS sessions on the node FsxId064d286a4aeabacb8-01.
Do you really want to continue? {y|n}: y
# セッション削除後に再接続した際のセッション
::*> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, smb-encryption-status
node vserver session-id connection-id address auth-mechanism windows-user shares protocol-version smb-encryption-status
------------------------- ------- ------------------ ------------- ------------- -------------- ------------ ------ ---------------- ---------------------
FsxId064d286a4aeabacb8-01 svm 460493061898633236 2456725618 172.31.34.150 Kerberos CORP\Admin 1 SMB3_1 encrypted
WinRMのポートへのアクセスが発生していないか疑ってみよう
SMBファイルサーバー上のアクセス権限がないフォルダを参照しようとしたときに There's a problem accessing と長期間エラーメッセージが表示される場合はWinRMのポートへのアクセスを疑ってみましょう。
個人的にはクライアント側で絞るのとABEの有効化による対応が好きです。
ちなみに、今回はAmazon FSx for NetApp ONTAPで検証しましたが、Amazon FSx for Windows File Server、Windows Serverでも同様の事象は発生します。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
![[登壇レポート] Storage-JAWS #7 AWS Pi Day 2025直前スペシャル！ 「Windows Server に FSx for NetApp ONTAP を iSCSI 接続してみた」という内容で登壇してきました #storagejaws #jawsug](https://devio2024-media.developers.io/image/upload/v1741670860/user-gen-eyecatch/wxb5zcp77pvprmifqtkd.png)
