none
NPSでイベントID6273 RRS feed

  • 質問

  • お世話になっております。
    NPSを用いてIKEv2接続を行なっています。今までは発生してなかったのですが、ID6273が発生しIKEv2接続ができなくなりました。
    少し前にRAサーバ(VPNサーバ)の証明書の期限を延長させるためにキーを変えずに書き換えを行なってはいますが、それ以降も接続は行なえていました。

    メッセージには「失効サーバーがオフラインだったため、失効関数は失効を確認できませんでした。」というメッセージが出ています。ADCSでは失効した証明書、失敗した要求、保留中の要求、には何も表示されておらず、NPSの証明書は発行済でNPS側でも認められます。
    NPSとADサーバ間にLDAP(ID4400)接続が開始されているとあります。ADアカウントのロックも疑い、ロックの解除も行なっています。

    私の知識不足で一歩んではまた戻る、という感じです。どなたか改善策をご存知の方がいらっしゃいましたらヒントでも構いませんので教えていただけないでしょうか?
    よろしくお願い致します。


    toya

    2022年8月4日 11:06

回答

  • チャブーンです。

    この件ですが、直接の原因は「CRLが読み取りできなかった」がほぼ正しいように思われます。その意味ではZaamasuさんのおっしゃるとおりなのですが、「CAがダウンしている」というのは、あまり当てはまらないように思います。

    AD CSのエンタープライズ CA の場合、CRLはActive DirectoryのLDAPデータベースに直接公開されます。つまり、CRLがよみとれない唯一のケースは「任意のドメインコントローラーと通信ができなかった」という話しで、AD CSサーバーのダウンとはおそらく無関係です。

    このケースが頻発する場合、ドメインコントローラーへの通信がキチンとできているのか、ドメイン内のActive Directory複製は大丈夫なのか、といったCRLの最新内容が継続的に公開されて続けているか、を確認するとよいかと思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク toya1105 2022年8月26日 6:43
    2022年8月9日 3:14

すべての返信

  • はじめまして。
    イベントログの理由欄を見る限り、CAサーバが一時的に停止 or NWの不具合等でCRLが読み込めなかったと考えられます。

    以下Webに本件と類似の情報があり、こちらを試す(AD CSサービスを再起動し、Delta CRLを生成させる)と問題が解消するかもしれません。
    証明書発行に失敗

    • 編集済み Zaamasu 2022年8月4日 12:13
    2022年8月4日 12:11
  • Zaamasu様、ご返信をありがとうございました。わたしも当該ページを読んでいたのですが、エラーの出現の仕方が違っていることと、DeltaCRLの再発行、についても無知であったため、これは行わなず以前にも接続ができない事象に悩まされたこともあり、既出の<https://social.technet.microsoft.com/Forums/ja-JP/68ce9007-5ad3-4071-a029-59824a96419f/ikev2255093215429872226591239112398adcs31227353731239512388123561?forum=windowsserver2019ja>の最後スレッドを再度、行なう事でこの問題が解消され接続がいともあっさりと行なえるようになりました。
    VPNサーバの証明書の期間を書き換えたりした場合、これを行なうことでNPSとAD CSがしっかりと動くようです・・。

    釈然としないのですが。。IKEv2接続は何とも不安定というか、、少し信頼がおけないというか、たぶん、わたしがどこかいけないのだとは思うんですがNW系のこういった作業をWindowsServerに任せるのが良くないのかも、、とか思い始めています。

    まだまだ勉強不足ではありますが経験者の皆さんにお知恵をいただきながら運用を進めてまいりたいと思います。今後ともよろしくお願いいたします。


    toya

    2022年8月8日 9:46
  • チャブーンです。

    この件ですが、直接の原因は「CRLが読み取りできなかった」がほぼ正しいように思われます。その意味ではZaamasuさんのおっしゃるとおりなのですが、「CAがダウンしている」というのは、あまり当てはまらないように思います。

    AD CSのエンタープライズ CA の場合、CRLはActive DirectoryのLDAPデータベースに直接公開されます。つまり、CRLがよみとれない唯一のケースは「任意のドメインコントローラーと通信ができなかった」という話しで、AD CSサーバーのダウンとはおそらく無関係です。

    このケースが頻発する場合、ドメインコントローラーへの通信がキチンとできているのか、ドメイン内のActive Directory複製は大丈夫なのか、といったCRLの最新内容が継続的に公開されて続けているか、を確認するとよいかと思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク toya1105 2022年8月26日 6:43
    2022年8月9日 3:14
  • チャプーンさんいつもアドバイスをいただきましてありがとうございます。
    NPSに関しては今も問題なく動作しております。現象は頻発するのではなく、AD CSやVPNサーバに処理を行なった時に発生している感じがします。

    NPSとAD CSの設置拠点は物理的に離れており、DC(GCとして稼働)はその両拠点に存在します。このDC間のレプリケーションに問題が無いか、
    repadmin /showrepl
    にて確認したのですが、両拠点のDCではほぼ同時刻の同期が行なわれており問題は無さげです。ただ180分に一度の同期となっており皆さんの同期タイミングより少し長いのかな?と思ったりもしました。

    本件とはズレてしまうのですが、添付画像のように「ActiveDirectoryのサイトとサービス」には表示されます。この、???と記したサーバは昨年の7月までDC(GC、WS2019)として動作していたのですがメンバサーバに降格後、ADから外し既に物理的にも存在しないサーバです。ADのグループ、DNS、DHCPでも痕跡は無いのですが、何故かここに表示されています。
    本件とか関わりが無いと思うのですが、???は削除してもよろしいのか、また、、迷っています。
    別スレッドにてお聞きした方がよろしいかも迷ったのですが同じ状態の方もいらっしゃるかと思い、こちらに記載させていだきました。NPSとDC間での情報交換の際の問題と思い、おかしなところはつぶして行こうと考えています。

    経験された方がいらっしゃればご教示いただければ幸いです。よろしくお願いいたします。

    ???を選択しています

    toya

    2022年8月10日 4:08
  • チャブーンです。

    本件とはズレてしまうのですが、添付画像のように「ActiveDirectoryのサイトとサービス」には表示されます。この、???と記したサーバは昨年の7月までDC(GC、WS2019)として動作していたのですがメンバサーバに降格後、ADから外し既に物理的にも存在しないサーバです。

    ですが、消してしまって問題はありません。そのオブジェクトが置かれている場所は「設定パーティション」と呼ばれる、一般的なドメインパーティションと異なる場所においてあるので、削除漏れが発生したのではないでしょうか。念のためADSIEdit.msc等で、???オブジェクトの中に子オブジェクトが一切ないことを再確認してください。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2022年8月10日 7:14
  • チャプーンさんご回答をありがとうございました。
    ADSIEdit.mscなどを利用して調査した後、削除を行いたく思います。結果につきましては来週、こちらにコメントさせていただきます。「設定パーティション」は初めて知りました。。勉強不足です。

    御礼が遅れてしまって申し訳ございませんでした。
    ちなみにNPSは元気に稼働しています。このNPS、LAN内Wifiで802.1x認証(EAP-TLS)する際にも利用しており、そちらの処理には問題ありませんでした。

    証明書関係と合わせて勉強してゆきたいと思います。
    今後ともよろしくお願いいたします。

    toya

    2022年8月14日 1:51
  • その後を記載させていただきます。
    ???のサーバはADSIEdit.msc等でオブジェクトを有していないことを確認した後、削除いたしました。その後もイベントログ等を見ておりますが特に問題はありませんでした。チャプーンさん、ご教示ありがとうございました。

    本題のID6273はWindowsUpdateでの再起動、もしくはVPNサーバが再起動された時に発生する場合があり、その都度ADから外したり登録したりを行なっていたのですが、その処置でも6723を検出するようになりました。
    確認するに、NPSのサービスでFunction Discovery Resource Publicationが動作しておらずこれを機能させて、NPSを再起動したところ6273は発生しなくなりました。。
    正直、原因が分かっていないのですが今は6272が上がります。

    引き続きこの現象には悩まされるおり、NPSの再インストールもしくは異なったサーバでの運用なども視野に入れて検討します。
    Wifi認証も考えるにNPS一つでVPNもWifiもADを利用してユーザ証明書認証ができるならと思ったのですが、利用台数の割にリッチなサーバ環境と繊細な挙動を考えるとアプライアンスに逃げたくなりました。

    引き続き情報をお待ちしております。ここを見るといいよ、的なものがありましたらお教えください。チャプーンさんがおっしゃっている通り、NPSとDCとのLDAP通信が怪しいです・・

    すみません、、今後ともよろしくお願いいたします。

    toya

    2022年8月26日 6:42