Microsoftアカウントのメールアドレス変更する前に 関連付けを削除しなければならない

Microsoftアカウント (旧 Windows Live ID) のメールアドレスを変更する際、次のように使用できませんという表示で変更できない場合がある。

自分の場合は、あらかじめ関連付けをしていたのが原因であった。この関連付けを削除することにより、メールアドレスを変更することができた。

セキュリティが関連する状況では、どこまで親切なメッセージを出すべきかというのはとても難しい。
今回は問い合わせをして調べてもらうことにより解決した。 http://answers.microsoft.com/ja-jp/windowslive/forum/liveid-signin/windows-live-id/2eec1190-4df8-4b4a-888f-4bbbef868e67

問い合わせに至るまでは結構悩んだ。その要因は http://www.microsoft.com/ja-jp/mscorp/liveid/faq.aspx#06 「以下のリンクよりお問い合わせフォームに記入いただき、MSN カスタマサポートへご連絡をお願いいたします。」の説明とは異なりそのようなフォームがなかったから。フォーラムが適切な解決策だとは想定外だった。

もういつからだったか忘れたが、これで長年の課題がやっと片付いた。

Single Sign On with Kerberos using Debian and Windows Server 2008 R2

http://blog.stefan-macke.com/2011/04/19/single-sign-on-with-kerberos-using-debian-and-windows-server-2008-r2/

Windows 2003 Server から 2008 R2 に移行するにあたって apache を kerberos 経由 ActiveDirectory で統合認証するためのドキュメント

Windows Vista または Windows Server 2008 と共に証明書サービス Web 登録ページを使用する方法

http://support.microsoft.com/kb/922706/ja

Windows Server 2003 で運用している 証明書サービス に対して、Vista/Windows Server 2008 のIE7から証明書を発行するための方法。

ポイントとしては

• Windows Server 2003 SP2 にする
• KBに掲載されているホットフィックスを適用する

KB内で若干日本語が変なところがあるがそのへんはスルーで

Identity Provider への道

パスワードによるログイン管理の陳腐化と 制度整備の検討

私もパスワードによるログイン管理をしているサイトとの関わりがある。当初強固なパスワードポリシーとして記号必須にしたら、日常的にパスワード忘れる人続出、サイトを移動して「パスワードを覚える」が効かない移行をした日にはそれはもう大量の「パスワード忘れました」問い合わせが…そんな嫌な経験。

以前は「パスワードはメモしないようにしましょう」とか言われていたけど、そんなことをしようとしたら明らかに複数サイトで同一パスワードを使うしかない。となれば21世紀においては、少なくともWebサイト利用のためのパスワードについて「できればランダムなパスワードを設定してメモしましょう」というのが戦略としては正しいだろう。その上でTPMの力などを借りつつブラウザにパスワードを覚えさせられればベスト。

さて、OpenIDのような仕組みで Identity Provider を作るというのは、そのIdentity Provider に設定したパスワードを「他のサイトでは使わない」というリテラシーが必要になる。…しかし専門家でない人にそんなことを徹底する方法はとても思いつかない。見た目でどう区別をつけるというのか。

今のテクノロジーで可能性があるとすると、EVSSL の証明書発行と Identity Provider の利用を一体化することかもしれない。でも EVSSL はすでに運用始まってるから、IdentityProvider専用SSL証明書を定義して、ブラウザを更新してもらって、アドレスバーが"青くなった時だけあなたの一番大事なパスワードを使いなさい" とか?

そんなことを考えると結局のところ CardSpace 頑張れと個人的には思う。CardSpace と OpenID の連携が自動的に行われるようになる日は近いと信じている。

KDDI Security Pass

Security Pass はドコモの First Pass 同様、初期費用無料、月額利用料無料 というサービス。

まあ要するに申込をするとCA証明書とCRLを提供してくれるというだけなので、CA証明書とCRLのURLを公表してくれりゃいいじゃん、という話のような気もするのだが。

ただ、すっかり au の機種にはうとくなってしまったので 「Security Pass」対応機種 がどの程度普及した端末群なのかは全く判断できない。

証明書の取得は端末内のメニューにはなくて http://au-spdl.kddi.jp/spdl/reception にアクセスする。発行すると2年間有効な証明書が入る。

 

ちなみにちょうど昨日、会社のサイボウズサイトに携帯(FirstPass認証)からアクセスできないという連絡があって調べたところ、週末からCRLダウンロードに失敗していてCRLの期限切れで接続遮断しているという状態であった。先週金曜日にネットワーク構成を変更したこともあって、ドコモからCRLがダウンロードできなかったのはこちらが悪いだけなのだが、ちゃんと証明書の検証が行われているのが確認できたという意味では安心できる。

SSL証明書同様 CRLの有効期限に関するエラーも hobbit で検出したいところだ。

mod_auth_kerb で Basic認証を有効にする (Active Directory を使ったシングルサインオン）

mod_auth_kerb の KrbVerifyKDC を on にできた を読んだところ、KrbVerifyKDC off を書いたら今まで Basic 認証が通らなかったところが通るようになった。IEを利用した統合認証だったら KrbVerifyKDC on のままでも問題なく動いている。

使っているバージョンは mod_auth_kerb 5.3 なのだがやはり off にするとBasic認証で通らない。ちなみに KrbVerifyKDC on の状態で ActiveDirectory ドメインコントローラのイベントログ(セキュリティ）を確認すると、1回失敗した後に2回目に成功しているログが確認できる。

Apache/認証にActiveDirectoryを使う方法 でも KrbVerifyKDC off するように書いてあるな。

ちなみに /etc/krb5.conf については、以下のように tcp を指定しないとudpで流しきれないデータ量になった時に通信できなくなってはまる現象が以前あった。（最新の環境だと改善している可能性はある)

[realms]
        AD.EXAMPLE.COM = {
                kdc = tcp/dc01.ad.example.com:88
        }

そういえばと確認したら1月に投げていた ports/119794: patch for www/mod_auth_kerb to fix on FreeBSD 7.0 は採用されてた。ちょっと嬉しい。

(追記）統合認証は由緒正しいKerberos認証なので、

1. Windowsクライアントがドメインログオンした時点でTGTを取得。このクライアントがWebブラウザを利用してサイトにアクセス
2. Webブラウザがサイトにアクセスするとチケットを要求される
3. WebブラウザはドメインコントローラにTGTを渡しつつ、今回アクセスしている先専用のサービスチケットをもらう
4. サイト(apache)は keytab にある鍵を使って サービスチケット を検証する。すなわち適用されるサービス名は http

一方Basic認証の場合、ブラウザ側がTGTを持っているわけではないので

1. Webブラウザがサイトにアクセス
2. apacheはドメインコントローラに向かってユーザ名とパスワードを渡して TGT を要求。適用されるサービス名は host
3. 返事がOKだったら認証したものとみなす

この「返事がOKだったら」の部分、これを検証するための鍵は通常 /etc/krb5.keytab に格納されていて、俺の管理しているマシンでは root でしか読み書きできないようにアクセス権が設定されている。これでは確かに KrbVerifyKDC on で検証するのは無理…

かと思ったが、「更にサービスチケットの発行を依頼してサービスチケットを検証すれぼOK」か。

で、1回 /etc/krb5.keytab を apache の実行ユーザが読めるように変更したら、アクセスできるようになってよしよしと思ってたら、元にもどして root でのみ読み書きできるようにしてもやっぱり KrbVerifyKDC on でBasic認証が通るようになってしまった。何が起きているんだ?

Identity Framework. “Zermatt”

Announcing the Beta release of “Zermatt” Developer Identity Framework より。WhitePaper をざっと読んだ。

ASP.NET に適用するには、Federated Access Module(FAM) と呼ばれる HttpModule を差し込むことで実現する。

FAMを利用した結果として取得したIdentityは、HttpContext.Current.User.Identity 経由でアクセスできる。

すでに自分も Global.asax の Application_AuthenticateRequest のところでフックして、HttpContext.Current.User.Identity の返すオブジェクトを拡張するようなことはしていて、ASP.NET における Identity へのアクセスへの方向性はこれで間違いないと確信。HttpModule の作り方についてはまだまだ勉強不足ではあるけれど。

Zermatt が素晴らしいのは、STS (Security Token Service) すなわちIdentityを管理するサービスを簡単に構築するための仕組みも提供してくれているところ。この1つのSTSを利用して、ASP.NET と WCF(Webサービス)の双方で認証を可能としているようだ。

また、あるIdentity が他のIdentityとして振る舞う権限がある (ActAs) かどうかを、サービスがSTSに問い合わせることができ、複数のサービスが呼び出されるような状況において途中のサービスのところでIdentityを遷移させるみたいな芸当も可能。

ユーザーインターフェースにおいても、CardSpace を利用することも可能、といったところで CardSpace 単体の行方には不安があったが、今後の展開に期待が出来そうだ。

.co.jp に向かってのクッキー発行

「Firefox 3」のセキュリティ機能について のエフェクティブ・トップ・レベル・ドメイン（eTLD）の話。

今まで domain=.co.jp を作れたってことか? これとクロスサイトスクリプティングを組み合わせるととても危険なことが簡単に出来そうな… FireFox 以外だとどうなってるのかしら。

iモードID

3月の発表時に提供されることだけ調べていて、技術仕様について調べていなかったので調査。

iモードセンタの各種情報 のページに記載してある。url内に "guid=ON" というパラメータをつけてアクセスさせると、遷移先のページへのアクセス時に "X-DCIMGUID""X-DCMGUID" というHTTPヘッダーにiモードID が付与して送信される。

iモードIDは 7桁の英数字(大文字小文字の区別あり)、iモードIDの再利用なし。

注意書きにある、「ユーザの名義変更、改番、iモード契約の解約によりiモードIDは変更となります」「iモードIDの再利用なし」というのはかなり重要。

従来公式サイトで利用されていた NULLGWDOCOMO 方式はFOMA以前から利用されていた都合により電話番号との紐付けになっていたようで、解約された電話番号を別の人が契約すると同じIDになっていたと思われる。(この部分想像)

utn 方式もFOMAカード製造番号なので、FOMAカードの譲渡に対しては同一IDとなり、やはり人を識別するIDとしては不適切。これはAU,SoftBank の携帯端末が保有している番号を送信する方式も同じ問題をかかえている。

というわけでユニークな人を識別する方式としては、今回作成された iモードID が最も適切な仕様となっている。DoCoMoは契約者シェア的にはジリ貧だけど技術的にはがんばってると思う。iモードIDはSSLで使えないとなっているが、SSLだったら FirstPass があるし。

また、この仕様を提示しているページがIPアドレス帯域と一緒になっているところがいい。HTTPヘッダーは偽装可能なので、この値を信用するためにはIPアドレス帯域チェックを同時に行う必要がある。

SQL Server 名前付きインスタンスに対してサービスプリンシパル名を設定する

SQLExpress などの名前付きインスタンスの場合、サービス名(MSSQLSvc)+FQDN では特定できない。ということで Registering a Service Principal Name を参照したところ、"MSSQLSvc/FQDN:port" という名称になる。

例えば ad01\SqlExpressMachine1 ユーザでMachine1上におけるSQLExpressサービスを稼働させている場合、手でSPNを登録するのであれば以下のようなコマンドとなる。

• setspn -A MSSQLSvc/machine1.ad01.example.com ad01\SQLExpressMachine1

実験している当初、ユーザアカウントではなくコンピュータアカウントを最後の引数として渡したために、SQL Express にSSMSからWindows統合認証で接続しようとした際に "SSPI コンテキストを生成できません" というエラーメッセージが発生するようになってしまった。とはいえこれにより "SSPI コンテキストを生成できません" エラー メッセージのトラブルシューティング方法 (KB 811889) ドキュメントにたどりついて少し先に進んだ。

このドキュメントによると、手でSPNを登録するのではなく、サービスを稼働させるためのユーザアカウントに対して "servicePrincipalName の書き込み" 権限を付与することによりSPNが自動で登録されるようになる。この際ドキュメント中「[SELF] が一覧に表示されていない場合は、[追加] をクリックし、SELF を追加します。」とある部分について、すでに[SELF]が複数存在していたのだが、既存の項目に対する変更が反映されなかったため、新規で追加する必要があった。(Windows 2008)

servicePrincipalName に対する読み書き権限付与の作業の様子を動画にしたものを以下に置いた。

SPNが登録されることの確認は、SQLExpress サービス起動後 setspn -L ad01\SQLExpressMachine1 コマンドによって確認することができる。ちなみに LocalSystem アカウントでサービスを稼働させている場合は特に何もしなくても自動で登録されるので、"setspn -L マシン名" コマンドによりSPN登録状況を確認できる。

 

ということで一歩進んだと思われるのだが、証明書ディレクトリマッピング から委譲に至らない状況はまだ解決していない。ダブルホップ問題の解決というのは、Kerberos用語で言えば「forwardable チケットの発行」のはず、ということで以下のドキュメントを読んでいる途中。

• Kerberos Protocol Transition and Constrained Delegation (TechNet)
• A .NET Developer’s Guide to Windows Security: Understanding Delegation

状況調査にあたっては Windows Server 2003 Resource Kit Tools をインストールして、klist.exe や kerbtray.exe でチケットの様子を見たり、Microsoft Network Monitor 3.1 で通信状況を見たりしている。ドキュメントを読む限りでは Active Directory ユーザとコンピュータ で、IISを実行しているコンピュータアカウントに対し委譲の許可にチェック入れるだけのように思えるのだが。

(追記)上記リンクのうち Kerberos Protocol Transition and Constrained Delegation (TechNet)  が今まで見た中でもっとも詳細でわかりやすいドキュメントだった。ただし、プログラム中で Impersonate() を呼ぶ場合の話であり、証明書のディレクトリマッピング + Web.config 中で impersonate="true" と記述した際の挙動については確証の持てるドキュメントは最後まで得られなかった。