PowerScale：OneFS：ADドメインが「オフライン」と表示されると、クライアントがノードを認証または接続できない

クライアントは、クラスター内の一部またはすべてのノードに対して認証を行うことができず、断続的または完全なデータ欠損(DU)を引き起こします。ユーザーがオフラインのADプロバイダーに依存している場合、どのプロトコルを介したアクセスにも影響します。最も一般的なのはSMBです。クラスター全体またはノード固有ベースで、このシナリオにつながる可能性のある状況は多数あります。ローカル セキュリティ機関サブシステム サービス(LSASS)がドメイン コントローラーとの接続を失うと、SMBクライアントはクラスター内のノードに接続できません。

LSASSがドメイン コントローラーとの接続を失うと、次のようなエラーが /var/log/lsassd.log ファイルに表示されます。

2012-06-11T12:58:42-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now online
2012-06-11T13:03:57-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now offline
2012-06-12T21:05:03-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now online
2012-06-13T16:35:03-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now offline
2012-06-13T16:40:03-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now online

または、Active Directoryのステータスをisi auth statusで確認すると、次のような出力が表示されることがあります。

testcluster-1# isi auth status
ID                                           Active Server      Status
-----------------------------------------------------------------------
lsa-activedirectory-provider:TESTDOMAIN.COM dc1.testdomain.com offline
lsa-local-provider:System                    -                  active
lsa-file-provider:System                     -                  active
-----------------------------------------------------------------------
Total: 3

# isi auth ads view <domain>

(Relevant output)
Hostname: isitest.example.lab.com
<snipped>
Machine Account: ISITEST$

dig @<DNS IP> SRV _ldap._tcp.dc._msdcs.domain.com

; <<>> DiG 9.10.0-P2 <<>> @<DNS IP> SRV _ldap._tcp.dc._msdcs.<domain>
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52396
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.<domain>. IN SRV

;; Query time: 0 msec
;; SERVER: <IP>#53(<IP>)
;; WHEN: <date>
;; MSG SIZE rcvd: 59

Local Security Authority Subsystem Service (LSASS) は、ハードウェアの問題、接続の問題、または DNS キャッシュ ポイズニングにより、接続されたドメイン コントローラーへの接続を失う可能性があります。または、ノードがクラスターに追加されたが、ノードにネットワーク接続がなかったために、この問題が発生することがあります。なんらかの理由でドメイン コントローラーが使用できない場合、ノードの再起動時またはLSASSの再起動時に、一部のドメイン情報が未入力のままになることがあります。通常、プライマリ ドメインのドメインGUIDは入力されないままです。これにより、そのノードに接続しているユーザーの認証を完了できなくなります。

回避策1 - ハードウェア接続の問題を調査します。

• /var/log/messagesファイルでハードウェア接続の問題を探します。ログ ファイル内のメッセージは、ノードのネットワーク ポートが「Up」状態であるかどうかを示します。クラスター内の他のノードの /var/log/messages ファイルを参照して、ネットワーク接続の問題がクラスター全体で発生しているかどうかを判断します。
• ドメイン コントローラーのシステム イベント ログとアプリケーション イベント ログを確認します。これらのログ ファイルには、ネットワーク接続の喪失に関連するドライバーまたはハードウェアの問題に関するエラーが含まれている場合があります。

回避策 2 - DNS キャッシュポイズニングを調査します。

ネットワーク接続の問題がハードウェア関連でない場合は、Active Directory ドメインの _mscds DNS ゾーンのサービス (SRV) レコードを調べる必要があります。クラスターから DNS サーバーへの DNS 要求のパケット トレースに、正しくない情報または欠落している情報が表示されます。SRV レコードに誤った情報が登録されている場合、またはドメイン コントローラーの_mscds DNS ゾーンにすべてのレコード がない場合、クラスター内のノードは、ドメイン コントローラーに接続しようとしたときに、ドメインがオフラインであると報告します。SRVレコードを現在の情報で更新するか、別のDNSサーバーに変更すると、DNSキャッシュポイズニングが解決されます。

〔実施例1〕

このパケット トレースには、クラスター内のノードに返されたDNSサーバーとSRVレコードのリストが表示されます。SRVレコード情報は dc2.domain.com に使用できませんでした。

いいえ。時刻ソース宛先プロトコル長 Info
5 16:40:19.061003 1.1.1.1 1.1.1.2 DNS 110 標準クエリ SRV _ldap._tcp.dc._msdcs.domain.com
6 16:40:19.062626 1.1.1.2 1.1.1.1 DNS 1270 標準クエリ応答 SRV 0 100 389 dc1.domain.com SRV 0 100 389 dc2.domain.com SRV 0 100 389 SRV 0 100 389 dc3.domain.com
7 16:40:19.063146 1.1.1.1 1.1.1.2 DNS 87 標準クエリ A dc2.domain.com
8 16:40:20.797403 1.1.1.2 1.1.1.1 DNS 146 標準クエリ応答、 そのような名前はありません

〔実施例2〕

このパケット トレースでは、ノードは _ldap._tcp.dc._msdcs.domain.comの SRV レコードを検索しますが、クライアントには情報が返されません。

いいえ。時刻 ソース宛先プロトコル長 Info
15 16:40:21.458636 1.1.1.1 1.1.1.2 DNS 100 標準クエリ SRV _ldap._tcp.dc._msdcs.domain.com
16 16:40:21.783630 1.1.1.2 1.1.1.1 DNS 100 標準クエリ応答、 そのような名前はありません

このような状況では、ネットワーキングおよびActive Directoryチームと協力して、DNS SRVレコードが正確であり、ドメインコントローラーに解決されることを確認してください。

回避策3:LSASSを更新します。

1. ノードへのSSH接続を開き、「root」アカウントを使用してログインします。
2.  認証デーモンがADに接続されていないことを確認します。ここで<、nodeID>は最近追加されたノードのノード番号です。
   
   isi_for_array -n <nodeID> 'isi auth ads list'
   
   ノードがドメインに参加している場合は、次のような出力が表示されます。
    
   cluster-1: Name            Authentication Status DC Name Site
cluster-1: --------------------------------------------------------------------
cluster-1: LAB.EXAMPLE.COM Yes            online -       Default-First-Site-Name
cluster-1: --------------------------------------------------------------------
cluster-1: Total: 1
    
3.  ドメインGUIDが入力されていないことを確認します。lsassが設定を正しく取得しない場合、ドメインGUID値は入力されません。
   
   isi_for_array -n <nodeID> /usr/likewise/bin/lw-lsa get-status | egrep -A 12 "Domain:" | egrep "Domain (SID|GUID)"
   
   次のような出力が表示されます。
    
   cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain GUID:
    
4. 新しく追加されたノードで次のコマンドを実行します。
   
   isi_for_array -n < node_range /> usr/likewise/bin/lwsm refresh lsass
    
5. 新しいノードがADプロバイダーに接続されていることをレポートしていることを確認します。
   
   isi_for_array -n < node_range> 'isi auth ads list -v'
    
6.  GUID 値が表示されていることを確認します。
   
   isi_for_array -n <node_range> /usr/likewise/bin/lw-lsa get-status | egrep -A 12 "Domain:" | egrep "Domain (SID|GUID)"
   
   次のような出力が表示されます。
    
   cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain GUID: 61b2a8c6-af25-1941-8d57-59073b7ceb19
    
7. Windowsクライアントで、新しく追加したノードのIPアドレスを指定してドライブをマッピングすることで、ユーザーがクラスターに対して認証できることを確認します。

回避策 4 - LSASS を再起動します。

1.最近追加したノードへのSSH接続を開き、「root」アカウントを使用してログインします。
2.使用可能なドメイン コントローラーを一覧表示します。ここで<domain_name>は、クラスターが参加しているドメインの完全修飾ドメイン名(FQDN)です。

isi auth ads trusts controllers list --provider=<domain_name> -v

3.ドメイン コントローラーに強制的に接続します。ここで<、domain_name>はクラスターが参加している<ドメインのFQDN、dc_name>はドメイン コントローラーのFQDNです。

isi auth ads modify <domain_name> --domain-controller <dc_name> --v

4.ADステータスの更新:

isi_classic auth ads status --refresh --all

[Status]が次のように[Online]に変わります。
 

5.ステータスがまだオフラインと表示される場合は、認証デーモンを再起動します(これにより、ノードへの認証が最大1分間中断されることに注意してください)。 

Single node:
pkill -f 'lw-container lsass'
Multiple nodes (nodes 1-3 here as an example):
isi_for_array -n1-3 'pkill -f "lw-container\ lsass"'

6.ステップ4を繰り返します。
7.Windowsクライアントで、LSASSが再起動されたノードのIPアドレスを指定してドライブをマッピングし、ユーザーがクラスターに対して認証できることを確認してください。

ドメイン接続の問題に関するトラブルシューティング メモ:
ドメインを脱退して再度参加する場合は、再参加後に、関連するゾーンの認証プロバイダーの一覧に Active Directory プロバイダーが表示されていることを確認します。

この example.com ドメインについては、[Auth Providers]セクションから削除されたため、再度追加する必要があります。

isi zone zones list -v:

                       Name: accesszonedev1
                       Path: /ifs/accesszone1
                   Groupnet: groupnet0
              Map Untrusted: -
             Auth Providers:  lsa-ldap-provider:Primary, lsa-file-provider:System, lsa-local-provider:accesszone1 **No Active Directory Provider** <<<<<<<<<<<<<
               NetBIOS Name: -
         User Mapping Rules:
       Home Directory Umask: 0077
         Skeleton Directory: /usr/share/skel
         Cache Entry Expiry: 4H
Negative Cache Entry Expiry: 1m
                    Zone ID: 2

WebUIは、それを再び追加して、必要な順序で検索されることを確認する最も簡単な方法です。お使いのOneFSのバージョンに応じて、該当する管理ガイドを参照してください。PowerScale OneFS情報ハブ