環境構築

Windos x64 Edition で x86 専用の DCOM が見つからない

ちゃっぴ (tyappi@wankuma.com) — Thu, 23 Sep 2010 17:29:00 GMT

x64 の Windows を利用している場合、「コンポーネントサービス」で 32 bit (x86) の DCOM が見つからない現象が発生します。たとえば、初期状態では x86 専用の "Microsoft Excel Application" は見つかりません。

どうやれば x86 専用の DCOM を表示させるかというと MMC (Microsoft Management Console) を下記のように呼び出す必要があります。

>mmc.exe comexp.msc /32
>dcomcnfg.exe /32

MMC 3.0 のコマンドラインオプション

上記のように呼び出せば x86 の MMC が呼び出され x86 専用の DCOM も検索されます。

なお、一度 x86 で「コンポーネントサービス」を呼び出すとそれ以降は x64 の「コンポーネントサービス」を呼び出しても x86 専用の DCOM も合わせて表示されるようになります。

Windows の TLS chipher suites の順序を変更する方法

ちゃっぴ (tyappi@wankuma.com) — Sat, 31 Jul 2010 17:56:00 GMT

Web browser の TLS cipher suites を比較してみるのつづき。

Internet Explorer で AES 256 bit を使いたいのに順番が低いため使えね～。とお怒りの方ももしかするといらっしゃるかも知れませんが、これは Windows Vista 以降であれば group policy で変更できます。

[ファイル名を指定して実行] で「gpedit.msc」と入力。

[コンピューターの構成] - [管理用テンプレート] - [SSL 構成設定] と node を展開し、[SSL 暗号の順位] を double click。

Policy を有効化し、"," comma で区切ったcipher suites list を入力する。途中 space を含めることができないので注意。

普通の group policy であれば、gpupdate.exe /force で反映がかかるのですが、試してみた感じでは Windows を再起動するまで設定が反映されませんでした。

なお、この group policy を変更すると Chrome, Safari の cipher suites も IE と全く同じになります。Chrome, Opera の TLS (SSL) は IE と同じ API 使っているのは間違いないですね。Firefox や Opera は影響を受けません。こちらは独自のものを利用している模様。

<参考>

SQL Server で Kerberos 認証を有効にする

ちゃっぴ (tyappi@wankuma.com) — Mon, 03 May 2010 19:22:00 GMT

SQL Server で Windows 認証を利用する場合、認証に利用される protocol は Kerberos と NTLM から選択されます。いわゆる Negotiate というやつです。

既定の設定では Kerberos が利用可能な状態なら Kerberos が優先され、Kerberos が利用できない場合に NTLM が利用されます。

現在の接続がどちらの protocol を利用しているか調査するには下記 query を実行します。

SELECT [auth_scheme]
  FROM [master].[sys].[dm_exec_connections]
  WHERE [session_id] = @@SPID

[auth_scheme] は 'public' server role の member では選択できませんので上記は 'sysadmin' server role の member で実施してください。

意外に NTLM になっていること多いんじゃないでしょうか？

Kerberos が利用できない原因はいろいろ存在しますが、もっとも多いのが SPN (Service Principal Name) が登録されていないという状況です。

Remote から Kerberos を利用して接続を行うためには SPN の登録が必要です。SQL Server では service の起動時に SPN を登録しに行きます。Service account に Network Service account を利用している場合には、この自動登録で SPN が登録されます。しかし、domain account を利用している場合には失敗します。

というのは domain account の場合その domain account 自身の Service-Principal-Name attribute への書き込みが既定で許可されていないからです。

これを解消するためには SQL Server の service acount に指定した domain account の ACL で "Self" に対し "servicePrincipalName" への書き込みを許可します。Windows Server 2008 以降では「Active Directory ユーザーとコンピューター」からでも ACL の設定が可能ですが、"servicePrincipalName" は設定できません。そのため、作業は "ADSI エディター" から行ってください。

「ファイル名を指定して実行」から "adsiedit.msc"
「ADSI エディター」で SQL Server の service account を探し出し、[プロパティ]
[セキュリティ] tab で <詳細設定>
"SELF" (複数存在していてもどちらか一つで OK) を選択し、<編集>
[適用先] に「このオブジェクトのみ」で「servicePrincipalName の書き込み」を付与

上記設定が完了したら、SQL Server を再起動します。その後、下記 command を実行して SPN を確認します。

>setspn.exe -l Domain\Account

Domain, Account には SQL Server の service acount を入力してください。結果に下記が含まれれば OK です。

MSSQLSvc/DbServerName.FQDN:1433 MSSQLSvc/DbServerName

ここまで書きましたが、account の ACL を変更せずに setspn.exe を使って SPN を直接登録してしまってももちろん構いません。

これが完了したら、もう一度 query を投げて protocol を確認してみましょう。Kerberos になっていない場合には、firewall 等他の原因です。

なお、ここまでは SQL Server が Kerberos 認証を受け入れるための準備作業であり、Kerberos 委任を利用した multi-hop 許可の設定については説明していません。続きは次回。

SQL Server 2008 R2 Express Edition

ちゃっぴ (tyappi@wankuma.com) — Sat, 24 Apr 2010 04:18:00 GMT

Microsoft Download Center で提供されているようです。

Subscription の方にはまだ登録されていないようです。

Microsoft Office 2010 x64

ちゃっぴ (tyappi@wankuma.com) — Sat, 24 Apr 2010 04:11:00 GMT

入れてみようとしたんですが、x86 と共存できないと怒られた。

ようやく対応したと思ったら、x86 と x64 の Microsoft Office は共存できないとのこと。これだと結構厳しいですね。

x64 への道のりは長い道のりになりそうですな。

SilverLight 4.0 の x64 対応

ちゃっぴ (tyappi@wankuma.com) — Sat, 24 Apr 2010 03:53:00 GMT

Internet Explorer 8.0 x64 で使えるようになったかな～と思って試してみた。

結果

Microsoft Silverlight cannot be used in browsers running in 64 bit mode.

だそうです。これじゃ Adobe Flash x64 対応していないのも非難できないですねぇ。。。Microsoft がこれじゃ。。。

Web browser の x64 化は相当先になるんですかね。。。Office は x64 対応したというのに。。。

部分信頼は難しい

ちゃっぴ (tyappi@wankuma.com) — Sat, 26 Dec 2009 02:45:00 GMT

ASP.NET で event log へ出力する policy を調査していたんですが、結構厄介であることが判明しました。

「How To: ASP.NET 2.0 で中程度の信頼を使用する方法」を参考にして custom trust level を定義したんですが、これだけではうまくいかない現象が発生しました。

部分信頼はこんな感じで設定しました。

<IPermission class=EventLogPermission version="1">
  <Machine name="." access="Write" />
</IPermission>

上記は event log への出力を localhost への書き込みのみ制限しています。

Event log へ出力している source code はこんな感じです。

EventLog eventLog = new EventLog("Application", ".", "Test");
eventLog.WriteEntry("Test", EventLogEntryType.Information, 0);

上記 source code ではなぜか SecurityException が発生して失敗します。

いろいろ試した結果、下記 source code なら問題が無いことが判明しました。

EventLog eventLog = new EventLog();
eventLog.Log = "Application";
eventLog.MachineName = ".";
eventLog.Source = "Test";
eventLog.WriteEntry("Test", EventLogEntryType.Information, 0);

つまり、部分信頼の場合「EventLog(String, String, String)」は利用できないってことですね。こういうの refernce に書いといてもらわないと困りますね。ってゆうか、部分信頼でも「EventLog(String, String, String)」を利用できるようにするべきだと思うんですが。

なお、下記のように policy を作成して完全信頼を与えれば「EventLog(String, String, String)」は利用できます。

<IPermission class=EventLogPermission version="1" Unrestricted="true" />

当然ですが、event log に対するすべての操作を行えることになります。う～む。なんだかな～。

Windows Vista SP2

ちゃっぴ (tyappi@wankuma.com) — Sun, 03 May 2009 23:46:00 GMT

MSDN に上がっていたので当ててみました。

一日たったけど、特に問題ないです。Notable Changes ではろくな変更ないので当たり前といえば当たり前ですがね。

注意点を強いて挙げるなら、SP1 を当てないと適用できないことかな。ここが以前の service pack と違っているので注意しないとね。ちょっとめんどくさくなったかな？

日本語版は RC 時点の documents となっているので英語版を提示しています。
まあ、そのうち翻訳されるでしょう。

Hyper-V 上での Network Teaming

ちゃっぴ (tyappi@wankuma.com) — Wed, 25 Mar 2009 19:12:00 GMT

以前対応していないとのネタを以前から聴いていました。

Hyper-V 上での NICチーミングサポートについて、各社態度

ですが、ようやく対応する方向になってきているみたいですね。HP はすでに対応しているみたいです。

Server 用の NIC を提供している 2 大 vendor Intel と Broadcom は対応済ませたようなので、server を提供している vendor から公式に対応表明されるのも時間の問題でしょう。

検証はしていないのであしからず。

すべての user で初期設定を統一化する方法

ちゃっぴ (tyappi@wankuma.com) — Sun, 15 Mar 2009 17:06:00 GMT

Test でよくやることですが、新しい user を作っては試験しては壊し、作っては試験しては壊しってやりますよね。また、security 確保のため、一人で複数 account を使い分けるというのもありますね。その時、ガリガリ costomize していると、いちいち設定変更するのが面倒くさくてかないません。

というわけで、新しい user profile を作成したときでも costomize された状態にする方法を紹介します。

基本は下記で説明されている手順になります。

カスタマイズしたデフォルトのユーザープロファイルを作成する方法

Windows Vista 以降では default user profile の path が "%USERPROFILE%\Default" に変更になっている以外、大きな違いはありません。

この方法を使ってもいいのですが、user profile を丸ごと copy することになるため、不要な設定がいろいろ入ってしまいます。そこで、直接 default user profile の registry を編集する方法をとります。

Default user profile の hive は既定で読み込まれていないため、まずこれを load する必要があります。

Registry Editor (regedit.exe) を開き、tree から "HKEY_USERS" を選択し、[ファイル] - [ハイブの読み込み] を実行。

[ハイブの読み込み] dialog box にて default user profile hive の path を指定。

これで、default user profile の registry を好き勝手にいじる準備ができました。

後は、好きなように costomize してください。

ただ、忘れていけないのは作業が終わったら必ず hive を unload すること。ちゃんと unload しないといつまでたっても unload されずに警告が上がります。

GUI での操作方法を示しましたが、command からも可能です。Reg.exe に load, unload という option があるので、これを利用して batch file 等で自動化可能ですね。

まあ、そんなところで。