リモートデスクトップ接続ファイルの電子署名

リモートデスクトップサービスに接続するための情報を保存したテキストファイル(RDP)は、改ざん防止のため電子署名を追加できます。

RDPファイルは、リモートデスクトップ接続クライアントで[オプション表示]を行うことで保存できます。

RDPファイルに接続先ホスト名まで保存しておけば、ダブルクリックするだけでホストに接続できます。

しかし、システム管理者が「ここに接続してね」と配布したRDPファイルを使ってみたら、接続先で個人情報を聞かれた、実はRDPファイルは改ざんされており、本来の接続先とは違うホストにつながるようになっていたらどうでしょう。かなり危険な状態になります。

RDPファイルに電子署名を付けることで、こうした危険性に気付きやすくなります。

▼署名なしのRDPファイルを実行した場合

いかにも怪しそうです。

▼署名付きのRDPファイルの場合

だいぶいい感じです。

署名付きRDPファイルの中身を直接書き換えてみます。

▼RDPファイルの接続先をメモ帳で変更

エラーになりました。ただし、セキュリティ上問題ない変更については警告は出ないみたいです。

RDPファイルの署名手順は意外に知られていないので紹介します。

基本的な作業は以下の3ステップです。

1. 証明書のインストール
2. 証明書の拇印(Thumbprint)の取得
3. RDPファイルに署名

1. 証明書のインストール

まず、RDPファイルに署名作業を行うコンピュータに電子証明書をインストールします。信頼できるコンピュータであれば何でも構いません。

2. 証明書の拇印(Thumbprint)の取得

次に、[証明書]の管理ツールを構成します。

1. MMCコマンドを実行
2. [ファイル]メニューから[スナップインの追加と削除]を選択 (またはCtrl-M)
3. [証明書]スナップインを選択した[追加]をクリック
4. [コンピューターアカウント]を選択して[次へ]をクリック
5. [ローカルコンピューター]を選択して[完了]をクリック
6. [OK]をクリック

次に、自分のコンピュータの証明書に含まれる「拇印(Thumbprint)」を取得します。

1. [コンソールルート]-[証明書(ローカルコンピューター)]-[個人]-[証明書]を展開
2. 自分のコンピューターをダブルクリック
3. [詳細]タブを選択
4. 一番下にある[拇印]を選択
5. 拇印を選択し、Ctrl-Cでクリップボードにコピー(右クリックメニューは出ない)

コピーした拇印からスペースを取り除き、すべて大文字にします。大文字しか受け付けないことはヘルプなどに記載されていないので注意してください。

PowerShellを使うことで、この作業を自動化できます。

【実行例】
$tp = "fc ff 52 c9 05 f9 ac b0 f0 86 6f f1 ad 4f ee ca ee 6b 0a 9b"
$tp = $tp.ToUpper().Replace(" ","")

赤字は実際の拇印に置き換えてください。

3. RDPファイルに署名

最後に、以下のコマンドを実行して、RDPファイルに署名を追加します(管理者権限が必要です)。

rdpsign /sha1 スペースを除いて大文字に変換した拇印 RDPファイル /v
(/vは詳細表示オプション)

【実行例】
rdpsign /sha1 FCFF<<中略>>0A9B  default.rdp /v

視力の単位ではなくて、Windows標準の拡大鏡

数年前の記事に加筆したものですが、時間的な経緯は変更していませんので、5年くらい足してお読みください。

---

視力の単位は「メガメートル 」っていう話ではなく、Windows 7以降の拡大鏡の話です 。

Windowsには以前から「拡大鏡」という機能があって、視力の弱い人でも使いやすいような工夫が行われています。

ただし、以前の拡大鏡は拡大エリアがウィンドウの一部に固定されていて非常に使いにくい物でした。

Windowsを使っている方は [Windows]キーを押しながらUキーを押してみてください。それが[コンピュータの簡単操作]を起動するショートカットです。

そこに[拡大鏡]があるはずですので起動してください。
マウスカーソルの周辺が、画面上部に拡大されるでしょう。

ですが、古いWindowsの拡大鏡は、マウスカーソルと画面上部を交互に見る必要があります。

一方、Windows 7の拡大鏡は画面全体が拡大され、その一部をディスプレイが切り取っているようなイメージで表示されます。

視線移動がないので使いやすいと思います(従来のモードも用意されています)。

残念ながら、(コア部分はWindows 7と同じはずの)Windows Server 2008 R2には、標準構成では従来モードしか装備されていません。しかし、[デスクトップエクスペリエンス]の機能を追加し、Themesサービスを起動することでWindows Vista以降と同じ拡大鏡が使えます。ウィンドウの角が取れたり、全体がWindows 7っぽくなってしまいますが。

Windows Server 2012以降は、標準構成で新しい拡大鏡が使えます。Windows 7の派手な画面(Aero)と違い、Windows Server 2012やWindows 8はグラデーションや半透明色を使わないフラットな画面になっていますが、基本的な機能はしっかりしています。

Windows 8が登場したとき、マイクロソフトは「こう見えて、GPUの機能をフルに使っている」という説明をしていました。Windows 7のAeroはGPUの機能を使っていることはよく知られていますが、Windows 8やWindows Server 2012は標準構成でGPUの機能を使ってるようです。

新しい拡大鏡はGPUの機能を使うため、デスクトップエクスペリエンスを必要としたのですが、Windows Server 2012では標準でGPU機能を使うため、標準構成で使えるようになったみたいです。

さて、こんな風に使いやすい拡大鏡が登場した背景には2つの理由があると想像しています。

1つは画面操作のデモなどで、拡大鏡の利用者が増えたこと、もう1つは開発者の平均年齢が上がったことです。

私が高校生くらいの時は「プログラマ定年30歳」という説がありました。
後に定年延長が行われたせいか「プログラマ定年35歳」説になりましたがが、実は米国のプログラマの平均年齢は40歳を超えているという話です。

その話を聞いたのが10年ほど前ですから、今ではもう少し上がっているかも知れません。

米国で「プログラマ」というのはSEを含む場合が多いので単純な比較はできませんが、日本でも40歳代のプログラマは結構増えています。

そこで問題になるのが肉体の衰えです。個人差はあるもののだいたい40歳代後半から「老眼」が始まります。
Windowsのプログラマも老眼の人が増えているのではないでしょうか。

だから「拡大鏡」は使いやすくなり、Internet Explorerは簡単に画面拡大ができるようになり、そしてWindowsの文字を大きくしても表示が乱れないようになったのだと思います。

---

さて、私の話です。

昨年秋、健康診断で異常に低い視力が測定されたので眼鏡屋に検眼に行きました。
検眼の結果

近視も乱視も(2年前と比べて)同じくらいですが、えーと、その...、手元が少し見えにくいようでいらっしゃいます...

いいから素直に「老眼」と言ってください。 気にしませんから。

2年前に作った遠近両用メガネだと少し疲れると言ったら、遠近両用初心者向けに手元部分(老眼部分)の領域を少し狭くしてあるからだろうということです(実際には中心を少し下げてカットしているらしい)。

そんなわけで、年末に交換レンズを発注し、年始に新しいレンズと交換してきました。

肝心のかけ心地ですが、新聞を読んだりメモを取ったりするのは楽になりました。
でも大型ディスプレイは見にくいままです。
老眼はレンズの下半分だけなので、原理的にしょうがないようです。
まさかゲーム喫茶のテーブルみたいにするわけにもいきませんから、長時間の画面作業をするときは、近視の度を全体に落としたメガネを使おうと思います。

ところで、所力の単位は、もちろん「メガメートル=目が見(め)えとる」ではなく、円が作る視角の逆数なんだそうです。

「メガメートル」の話を最初に聞いたのは、KBS京都のラジオ番組「サンマルコからボンジョルノ」の投稿ハガキでした。35年くらい前の話です。

詳しくは別の記事に書いていますので、よろしければどうぞ。

Microsoft Azureのエンドポイントアクセスログ

講義中に質問されてそのまま保留してるんですが、さすがにまずいので途中経過を書きます。

【質問】エンドポイントのアクセスログは取れますか?

【背景】エンドポイントとは

Microfoft Azureのエンドポイントは、インターネットからのアクセスポートのことです。

たとえば、Webサーバーを立てた場合はTCP/80でアクセスします(暗号化しない場合)。

Microsoft Azureの仮想マシンは、Azureが持つファイアウォールで守られていますから、そのままでは正常なアクセスもできません。

そこで、エンドポイントとしてTCP/80を指定することで、実際にアクセスができるようになります。

では、WebサーバーでもないのにTCP/80のアクセスが頻繁に発生しているとします。原因はさまざまですが、可能性の1つとして「不正にアクセスできるWebサーバーを探している」ことがあります。

つまり、外部からエンドポイントへのアクセスを調べることで、不正アクセスの可能性を推測できます。

【暫定回答】できません

できません。「できない」という回答をするのは難しいのですが、「できる」という文書は見つかりませんでした。

許可されたアクセスに対しては、アプリケーションや仮想マシン側でログを取ってください。許可されていないアクセスは、仮想マシンまで到達しませんから、ログも取れません。

問題は、エンドポイントでアクセスできなかった場合です。どうも、これはログを取る機能がないようです。

インターネットの不正アクセスは、数が多すぎてログを取ってられないので、機能がないのかもしれません。万一エンドポイントを不正に通過してしまっても、仮想マシン側のログに残るので、それで十分だと判断しているのでしょうか。

明確なことが分かれば、追ってお伝えします。

オリンピックと情報処理

あけましておめでとうございます。そして、何の脈絡もなくオリンピックの話です。

社会基盤の維持にコンピュータは欠かせません。もちろんオリンピックも例外ではありません。

選手や観客を運ぶ交通機関の制御、会場での動線予測と制御、各種セキュリティ、競技判定、競技データの集計、試合結果の公開、あるいはトレーニングサポートなど、適用範囲は多岐に渡ります。

今回は、その中で、過去のオリンピックを振り返り、特に重要な技術を紹介します。

1932年ロサンゼルス大会

初の開催国外へのラジオ中継。日本では現地で行った実況中継を録音し、後日放送されたそうです。これを「実感放送」と呼びます。

1936年ベルリン大会

写真電送が実現し、国際電話によるインタビューが一部で行われました(とても高価です)。またラジオの実況中継が実現し、水泳競技では有名な「前畑がんばれ」もこの時です。

国内向けテレビ放送もこの年から始まったそうです。

1960年スコーバレー冬季大会

いわゆるITが活用されたのがこの年で、IBMが競技データの処理を行いました。オリンピック史上初めて競技中に途中経過が分かるようになったということです。

ただし、処理内容は限定的で、最終結果の集計には長い時間を要したと聞いています。手作業の時代は、なんと数か月だったそうです。

なお、当時は夏季大会と冬季大会は同じ年に開催されていました。

1964年東京大会

日本IBMが初めてオンラインシステムを構築し、閉会式直前にデータ集計を間に合わせたということです。この成功により、銀行がコンピュータの価値を認め、第一次オンラインシステムにつながります。

しかし、もちろんそんなにスムーズに進んだわけではありません。

当初、日本IBMはIBM米国本社に打診したところ「無理だからやめろ」と言われたそうです。そこで、日本IBMは米国の上層部に直談判、当時の米国本社社長のトーマス・ワトソン・ジュニアが「IBMは、いつからチャレンジを恐れる会社になったのか」と逆転受注につながります。

今思えば、単なるデータ集計ですし、データ量も多くないので簡単と思うかもしれませんが、何しろ昔の話です。

• コンピュータのデータ処理は不正確なので、たとえばお金を扱うことはできない
• 複数の競技場のデータを集中管理するシステムはあまり例がない
• データ通信にはデータ通信専用の回線が必要で、音声回線は使えない

という問題がありました。

最後の問題は、今の人には分かりにくいかもしれません。

当時は、音声回線にデータを流すと、電気特性の違いから交換機を破損するリスクがあったそうです。そのため、データ専用の回線を敷設するのですが、音声回線すら満足に敷設できなかった時代、優先的にデータ通信回線を敷設するのは時間と費用がかかるだけではなく、音声回線の敷設を後回しにすることにもなります。そもそもオリンピック用システムの企画当時、電電公社(現在のNTT)はデータ通信をサービスとして全く提供していなかったのです。

結局、モデムを使うのであれば大きな問題はないだろう、ということで法改正をして音声回線を使ったデータ通信を行ったそうです。

ネットワークを使ったデータ集計は、米軍がミサイル防衛網の情報管理に使っていた「SAGE」、それを応用したアメリカン航空の「SABRE」、そして国鉄(現在のJR)が日立製作所と共同開発したMARSくらいしかありませんでした。

ちなみにSAGEは全米のレーダー基地からの情報を集計する仕組みで、レーダー基地の代わりに旅行代理店にしたのがSABREだということです。

SAGEもSABREもIBMが開発したため、分散データ処理が不可能だったわけではありません。日本IBMは、このノウハウが利用できると期待していたのかもしれません。

システムは完全なウォーターフォール型で、開発に2年半かかったと言われています。案の定、プロジェクトは遅れ、人員の追加と、米国からプロジェクトの支援があったそうです。「遅れているプロジェクトに人員を投入するとさらに遅れる」という言葉もありますが、この時は完璧なドキュメントがあったため、大きな遅れはなく、プロジェクト進行を早めることが出来たとか。

伝わっている資料では、詳細設計書はバインダー5冊、英文、流れ図・表を含む千数百ぺージに及んだということです(東京オリンピック情報システム関連資料リスト)。

ちなみに、この時に使われたのがセイコーのクォーツ時計です。

1996年アトランタ大会

IBMが、自社のテクノロジーのショーケースとしてクライアントサーバーシステムを全面採用し、通信社向けのデータ配信サービスを開始します。また、初めて公式Webが出来たのもこの時です。

1998年長野冬季大会

インターネット普及期と重なり、IBMが構築した公式Webサイトは、3万ページに及ぶコンテンツとなり、期間中に6億アクセスがあったそうです。

これだけのアクセスをさばくのは1台ではもちろん無理で、負荷分散装置が導入されました。負荷分散装置の本格採用は珍しい時代だったため、情報処理学会の学会誌にも

複数のコンピュータに単一のIPアドレスを割り当てる特殊な方法

と紹介されていました。

2014年ソチ冬季大会

全面的にクラウド(Microsoft Azure)が導入され、動画配信などに力を発揮しました。

システム構築期間は明らかにされていませんが、おそらくかなり短期間でしょう。

2020年東京大会

さて、2020年の東京大会では、どのような技術が投入されるのでしょう。ソーシャルメディアとの連携や、入場券などに埋め込まれたICタグによる交通制御などがあるのでしょうか。

ADMT 3.0でユーザー移行時にSIDヒストリ生成が失敗する

1日の教育コース「Windows環境マイグレーション実践」を実施していて気付いたことがあります。

ADMTで、アカウントを移行(複製)するとき、最後に移行元の管理者アカウントを聞いてきます。既に管理者権限があるのに、なんで聞いてくるのか分かりませんが、確認のためなのでしょう。

Windows Server 2003上でADMT 3.0を実行した場合、管理者パスワードを間違えても、その時はエラーにならず、以下のような現象が出ます。

• 移行時にエラーが出る
• ユーザーアカウントの複製は完了
• ただしSIDヒストリが生成されない(エラーメッセージはこれ)

ADMTのデータベースには「移行済み」マークが付くので、再移行はできませんし、SIDヒストリの更新もできないという状態になってしまいます。

ユーザーの権利やグループのメンバーシップ情報などは、更新もできるのですが、SIDヒストリは更新の対象になっていません。

しかし、ADMT 3.2 QFE をWindows Server 2012 R2上で実行した場合は、管理者アカウント情報を間違えた時点で適切なエラーが表示され、先には進めませんでした。

よかった。

なお、移行に失敗してしまった場合、以下の2つ解決方法がありそうですが、どちらも問題があります。

• 移行先のユーザーを削除し、別のマシンにADMTをインストールして再移行
  移行自体は成功しますが、ADMTのデータベーステーブルにある「移行先ユーザーの新SID」が適切な値にならず、セキュリティ変換などに支障をきたします。
• 移行先のユーザーを削除し、ADMTのデータベースを直接操作して、移行しなかったことにする
  これができればいいのですが、ADMTのデータベーススキーマが公開されていません。

ところで、先日、デモ中に、クライアントPCの移行に失敗したのですが、単にNT4互換の暗号化アルゴリズム指定が抜けていたためでした。テキストの手順通りに実行すれば問題なく移行できます。

▲マイグレーションと言えば、アフリカ大陸で毎年見られる「ヌーの大移動」
(写真は移動の時期ではありません)

Hyper-VのDHCPガードの意味

Windows Server 2012以降のHyper-Vには「DHCPガード」という機能があります。説明には「承認されていない仮想マシンからのDHCPサーバーメッセージを削除します」とあります。

実際に、このチェックボックスをオンにすると、DHCPパケットが仮想マシン外に飛びません(DHCPサーバーとして実用的な動作はしません)。

▲DHCPサーバーガードの構成は仮想マシン単位で行う

Windows ServerにはDHCPサーバーをActive Directoryで承認する機能があるため、この「承認」も何らかの操作を指すと思っている人が多いようです。

実は、ここでいう「承認」は「管理者が正しいと判断する」という意味です。つまり、管理者が、正しいDHCPサーバーを立てたと思ったらチェックを外すという手順を意味します。

存在しない機能を探すのは難しいのですが、一応、それらしいものがありました。英語版TechNet Forumの「How to configure DHCP guard in Hyper-V 2012?」では、モデレータのBrian Ehlertさんがこう答えています。

Unauthorized and Authorized is a procedural / process phrase. It is not a technical phrase or any setting that can be applied.  It is the business decision to call machine authorized or not.

意訳

「承認されていない/承認されている」は手続きの順序を意味しており、技術的な方法や設定手順を意味するものではありません。「承認されている/いない」は、仮想マシンを構成するときのビジネス的な判断(DHCPサーバーにするかしないかを管理者が決めること)を意味します。

Hyper-V管理者と、仮想マシン管理者が同一の場合は意味を持ちませんが、以下のような運用を想定しています。

1. Hyper-V管理者が仮想マシンVMを作成
2. VM管理者はDHCPサーバーでないことをHyper-V管理者に通知
3. Hyper-V管理者が仮想マシンVMのDHCPガードを有効化
4. 誤ってVMにDHCPサーバーをインストールしてもDHCPパケットは廃棄される

物理マシンの認証を仮想マシンのドメインコントローラーで行うには

マイクロソフト製品の多くは、Active Directoryドメインサービスを必要とします。しかし、ドメインコントローラーはIDとセキュリティ管理の要なので、構築や複製が何かと面倒です。

特にVDI環境を構築するときは、物理マシンをドメインのメンバーにする必要があり、通常は物理マシンを2台必要とします。

何とか1台でできないものでしょうか。

ksakakiさんのブログ「More Than One Way」の記事「世界のブログから - 「ドメイン コントローラーどうしよう」に、ドメインコントローラーを仮想マシンとして構成し、その仮想マシンホストをメンバーとする手順が掲載されています。

詳細はksakakiさんのブログを読んでいただくとして、要点だけを整理してみましょう。

1. ドメインコントローラー仮想マシン(DC)は自動起動
   既定値は[サービスが停止したときに実行されていた場合は自動起動する]
2. ドメインコントローラー仮想マシン(DC)は最初に起動
   既定値は0
3. ドメインコントローラー仮想マシン(DC)は自動シャットダウン
   既定値は[保存]
4. 万一に備えて物理マシンのローカル管理者アカウントを正しく構成
   ドメインコントローラーが動かないと、ドメインのユーザーでログオンできません。セキュリティ対策としてローカル管理者Administratorの名前を変えたり、無効化する場合もありますが、Hyper-Vホストには必ずローカル管理者としてログオンできるようにしておいてください。

上記1から3は、以下のPowerShellコマンドレットで構成できます(`は継続行の印)。

Set-VM -VMName 仮想マシン名  `
    -AutomaticStartAction Start   `
    -AutomaticStartDelay 0          `
    -AutomaticStopAction ShutDown

しかし、これだけでは起動時のタイミングによってはエラーが出ます。追加の設定が「世界のブログから - Hyper-Vとドメイン コントローラーに関してもう一つ」として公開されています。

1. 確実に認証させるため、資格情報のキャッシュを停止
   物理マシンで以下のようにレジストリを変更します(PowerShellの場合)。
   Set-ItemProperty `
       'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' '
        -Name cachedlogonscount –Value 0
   (`は継続行の印)
2. 起動時の待ち時間を回避するため、サービス起動順序を構成
   ドメインコントローラー(つまり仮想マシン)で以下のコマンドを実行
   sc config netlogon depend= LanmanWorkstation/LanmanServer/DNS
   (現在の依存関係は sc qc コマンドで表示できます)

以上の構成をしたら、あとは物理マシンの優先DNSに仮想マシンのDNSサーバーアドレスを指定し、通常どおりドメインに参加してください。

だいたいこれで大丈夫なのですが、VDIを構成する場合は以下のようなトラブルがありました。

• 仮想化ホストの構成時に警告が出る
  仮想化ホストの構成時に、ローカルグループの設定に失敗することがあります。管理ツールで見ると、ローカルグループは正しく構成されているようです。実際、そのままでも動作しましたが仮想化、念のためホストをVDIから削除して、再構成した方が無難です。
• 複数のNICがあると、クライアントOSの展開に失敗する
  仮想化ホスト(物理マシン)に、NICが2枚構成されていると(たとえば外部ネットワークと内部ネットワーク)、クライアントOSの展開に失敗しました。同じ構成で成功したこともあるので、詳細は分かりません。

前者はVDIの再構成で、後者は内部ネットワークをやめ、VLANで物理ネットワークを分離することで解決しました。ただ、そもそもなぜ複数NICで問題が発生したかは分かりませんので、もう少し調べてみます。