インフラ管理者に向けて(基礎編)
こんにちは、タケルです。
今回は企業、個人のインフラ管理者の方や、世の中のシステムに興味のある方へ
向けて、一つ知識を共有させていただきたいと思います。
先に結論をまとめておきます。
-----------------------------------------------------------------------------------------------------
■結論
・ネットワークレベル認証（NLA）が出来ないことにより、リモートデスクトップ接続できない事象が発生した。
・上記事象の原因について
・ADサーバーとは
・サーバーの使用状況の可視化の有効性について
-----------------------------------------------------------------------------------------------------
先日あるVDIにリモートデスクトップ接続しようとした時、
以下のようなメッセージが表示されました。
「接続しようとしているリモートコンピューターには、ネットワークレベル認証（NLA）が必要ですが、
お使いのWindowsのドメインコントローラーに接続してNLAを実行することができません。、、、、、」
以下のようなメッセージです。
このメッセージだけで、原因がわかる方はいますでしょうか。
最初は接続元や、接続先のセキュリティレベルの設定を変えれば治ると私は思ってしまったのですが、、、、
原因は、接続先が使用しているADサーバーのサービスが停止してしまっていたために、
接続元の認証ができなかったため、でした。
もう少し解説します。
まずAD(Active Directory)サーバーとは。
WindowsSeverの機能である、「あなたは誰？」を確認する機能です。
企業のクライアントPCや、サーバーは基本的にはドメインNW(一つのグループのようなもの)に所属しています。
そういったクライアントPCやサーバーに、外部から何の認証もなく接続できたら嫌ですよね。
そのためにADサーバーがあります。
今回のリモートデスクトップ接続のように、外部からアクセスする際は、
必ずADサーバーを経由するようになっています。
■接続の流れ
クライアントPC
↓
ADサーバー (ここでNLAを実施。NWレベル認証です。同じドメインNWに所属しているか確認。)
↓
接続先サーバー (ここでパスワード認証等の通常の認証を実施。)
企業のNWなんてものは、ありとあらゆる技術を駆使して強固に守られているものです。
(ここで紹介したのはほんの一例です。)
今回はこの認証を行うための、ADサーバーのサービスが停止していたために、接続ができない、という事象でした。
ADサーバーが停止した時に、そこをすっとばすのではなく、そもそも一切接続できないようになっているのは、
極めて重要ですよね。
こういうのは「フェールセーフ」っていうんでしたっけ。
確か情報処理試験で出てきたはず。
ちなみに、ADサーバーが落ちた原因ですが、ADを搭載しているサーバーがADだけでなく、
DNSやらWSUSやら複数の機能を同時に無理やり実装していたために、Cドライブが圧迫して
サービスが停止したのではないか、という状態です。
ドライブを整理したことで稼働が安定したために、おそらくこれかな、という認識です。
以前サーバーのディスク使用率を可視化しようという話があったのですが、
本格的に検討しても良さそうです。
スクリプトとOSSを活用すれば、案外1週間くらいでできそう。
(使用技術としては、Windowsバッチ、シェルスクリプト、Perlくらいですかね。
CやJava等の高級言語を用いた実務経験がある人ならば、楽勝かと思います。)
こんなところですかね。
普段アプリ開発をメインにやっているものですが、こういったインフラの知見も面白いです。
ビジネスの幅が広がりますよね。
それではまた。
