VNX：SMB2セキュア チャネル通信をサポートするコードをアップグレードした後DOMAIN_CONTROLLER_NOT_FOUND
Summary: DCとのSMB2セキュア チャネル通信をサポートするコードをアップグレードした後にメッセージDOMAIN_CONTROLLER_NOT_FOUND。(Dell Correctable)
Symptoms
コードが上記のいずれかのバージョンにアップグレードされました。
次のいずれかのコードにアップグレードした後、ドメイン コントローラーがダウンしたことを示すエラー メッセージがログに表示されるようになりました:
VNX2:
8.1.9.211
VNX1:
7.1.82.0
メッセージは次のようになります。
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Cause
前述のコードはすべて、NASサーバーまたはData MoverがSMB2のドメイン コントローラーと通信できるようにする新機能に追加されています。このコードが登場する前は、ドメイン コントローラーの通信はすべて SMB1 で処理されていました (ただし、クライアントは引き続き SMB2/SMB3 で通信できました
SMB2への変更により、コマンドの一部がドメイン コントローラーにシリアル化されなくなりました。これにより、一部のコマンドが並行して同時に実行される可能性があります。
例としては、名前付きlsarpc名前付きパイプを開こうとした場合が挙げられます。
このエラーメッセージでは、バインドしようとしているサービスに注意することが重要です。
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
エラー メッセージから、LSAを開こうとしていることがわかります(赤で強調表示)。ここで問題が発生します。DC からの応答を受信する前に、lsarpc 名前付きパイプを複数回同時に開こうとします。最初の要求は成功しますが、それ以降の要求は失敗します。STATUS_PIPE_NOT_AVAILABLEを示す障害メッセージが表示され、ログにDOMAIN_CONTROLLER_NOT_FOUNDメッセージが記録されます。
これらのメッセージは必ずしもこの問題を示しているわけではないことに注意することが重要です。DOMAIN_CONTROLLER_NOT_FOUNDエラーには多くの原因が考えられます
この特定のログには、次の情報メッセージが多数含まれている可能性があります。
2017-06-28 14:37:45: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened 2017-06-28 14:37:47: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened
問題が問題と一致するかどうかについて質問がある場合は、パケットトレースで確認できます。トレースでは、それらのいずれかに対する応答を受信する前に、lsarpcを開くための複数の同時リクエストが表示され、その後、最初のリクエストが成功し、その後のリクエストはDCが応答したときにSTATUS_PIPE_NOT_AVAILABLEで失敗します。
この問題は主に、ドメイン コントローラーで多数のSIDルックアップを必要とするシステムで発生する傾向があります。環境内に孤立した SID がある場合は、これらのエラーがログに記録される傾向が強くなります。これは、DC に送信されるトラフィックの量が原因であり、ACL がアクセスされるたびに、DC に要求を送信して、SID キャッシュにない SID の ID を要求する必要があります。孤立したSIDはSIDキャッシュに存在せず、lsarpc名前付きパイプに対して実行する必要があるオープンの量が増えるたびに検索が試行されます。
最初のオープン試行が成功すると、これは影響のないイベントであり、これらのメッセージは無視できます。
Resolution
恒久的な修正:
エンジニアリング チームはこの問題を認識しており、コードの将来のリリースで修正できるよう取り組んでいます。これは無停止の問題であり、その間は無視しても問題ありません。ただし、メッセージを削減または削除したい場合は、いくつかの回避策を利用できます。
回避策1:
これらのメッセージがログに記録されないようにするには、いくつかの方法があります。lsarpcパイプで複数の同時オープン試行が問題を引き起こすため、メッセージを減らす最も簡単な方法は、必要なSIDルックアップの量を減らすことです。
孤立した SID は、これらの過剰な参照を引き起こします。次のパラメーターを変更すると、ルックアップで不明なSIDのsecmapキャッシュが参照されるため、DCに送信されるトラフィックの量を減らすことができます。
[nasadmin@CS0 ~]$ server_param server_2 -f cifs -i acl.mappingErrorAction -v server_2 : name = acl.mappingErrorAction facility_name = cifs default_value = 8 current_value = 8 configured_value = 8 user_action = none change_effective = immediate range = (0,31) description = Define rules for an unknown SID/UID/GID mapping detailed_description Defines the rules for unknown mapping between SID/UID/GID on ACL settings. Two kinds of errors might occur: the SID set in the ACL is unknown to the Domain Controllers we are using, or the username is not yet mapped to a UID/GID. 0x01: Stores unknown sid. 0x02: Stores sid with no UNIX mapping. 0x04: Enables debug traces. 0x08: Only do lookup in cache (secmap or globalSid cache or per connection SID cache) 0x08 is HIGHLY RECOMMENDED WITH OPTION=0x01. 0x10: Disable log displayed when an unknown SID resolution takes too much time.Maximum value = 0x1F Refer to param cifs.acl.retryAuthSID
これは次の情報に変換されます:
Bit0 = Stores unknown sid.
ビット1 = UNIXマッピングなしでsidを格納します。
Bit2 = デバッグ トレースを有効にします。
ビット3 = キャッシュ内のルックアップのみ(secmapまたはglobalSidキャッシュ、または接続ごとのSIDキャッシュ)
ビット0と1が設定されている場合(値として0x3)、孤立したSIDをファイル システムACLに格納できます(デフォルトでは格納されていません)。値を0x3から0x11に変更することをお勧めします。これにより、ビット0、1、3がオンになります。つまり、不明なSIDをUNIXマッピングなしで格納し、secmapキャッシュとグローバルSIDキャッシュのみを検索します。ビット 0 と 1 がオフになっている 0x8 または別の組み合わせに設定されている場合は、孤立した sid を格納できず、このパラメーターを変更しないでください。
パラメーターを変更する場合は、次のコマンドを実行できます。
server_param server_2 -f cifs -m acl.mappingErrorAction -v 11
これにより、発生回数は減少する可能性がありますが、完全に排除される場合とされない場合があります。
回避策2:
ログ内のこれらのエラーを確実に取り除く方法は、DC 通信の動作を新しいコードの前に戻すことです (つまり、SMB1 のドメイン コントローラーとのみ通信します)。
DC通信(以前のVNX動作)をSMB1に戻す場合は、Dellサポートにお問い合わせいただき、このナレッジベース記事を提示してください。