Microsoft ネットワーク 「？」のポイント
簡単に自己紹介
大川原 啓玄(おおかわら よしはる)
NT-Committee2 所属
数年前から新潟でときどき勉強会を開いています
新潟インターネット研究会と同じようなポリシーをもつ
非営利団体
あおい情報システム株式会社 代表取締役
半年前に設立しました。
そのまえは、マイクロソフト株式会社マーケティング本部
そのまえは、日立系列会社でSIをやってました
WindowsだけでなくSolarisやLinuxをつかってました
もくじ
Microsoft ネットワークは独自規格？
マイクロソフトはオープンソースが嫌い？
NetBEUI と NetBIOS
NetBIOS 名前解決
名前解決は二つある
ブラウジング機能
認証とSMB
パスワードハッキング
Sambaとの関係
Active Directory 機能紹介
Microsoftネットワークは独自規格？
いちおう RFC1001 と RFC1002に規定されています
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1001.html
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1002.html
RFC1001とRFC1002をマイクロソフトがさらに拡張し
たものが、現在のMicrosoft ネットワークです
この「さらに拡張した」という部分だけみれば Closed な仕様
問題はこの「拡張した」部分の基礎的な技術情報が提供さ
れていないということ
Microsoftネットワークは独自規格？
余談
マイクロソフトには生産的で画期的なアイデアはどんどん重
用される社内文化がある
技術やユーザビリティなどの観点から「イイ(・∀・)！」仕様は
どんどんインプリメントされる
たぶんいい方向になると思って作ってるうちに、こうなっ
ちゃったんじゃないかな？
なのでドキュメントもあとから作るから大変に・・・
それは イクナイ (・A・)／
なぜ仕様をオープンにしないのか？
ソフトウエアの仕様(設計やコードなど)も知的財産の
ひとつであり法的に守られるべき権利として考えてい
る
お金と手間をかけてつくったものを全部公開すると産業とし
てなりたたない
良心的に解釈すると、ITベンチャーを擁護すると言い換えら
れなくもない
マイクロソフトはオープンソースが嫌い？
マイクロソフトはオープンソースを否定しているわけで
はない
Shared Souce Codeプログラムなどで制限はあるが仕様は
公開している
一部のソフトウエアはオープンソース化している
MS.comで提供されている技術情報は他社に比べれば、か
なり開示しているほう
有効な開発手法であることは認めている
Internet Week 2004 1,dec マイクロソフト株式会社 法務・
政策企画本部 統括本部長 平野氏 講演
オープンソースって何？
「オープンソースとは単にソースコードを公開するとい
うだけではなく、ディストリビュータ・ハッカー・ユーザと
いう立場の異なる三者の利害を調整し、そのソフトウェ
アをより良くしていくものでなければならない 」
GNU・Debian 八田氏
八田氏「ライセンスに関しては、現在普及しているオー
プンソースライセンスでは、今後の状況に対応できな
いような限界があるのも事実 」
両者とも主張が数年前に比べて尐しずつ変わってきて
いる
マイクロソフト曰く「GPLが問題」
GPL第7条による特許などに認められなければ「無償、
自由な配布」
特許にならなければ、企業として研究開発資金は回収でき
ない
「特許やビジネスの構造を否定する発想」平野氏
余談
アイデア泥棒、仕様泥棒はホント腹が立つ
特許に守られることがない システムインテグレートは
提案資料からいいとこどりを、既存の業者に流されることも
多い
話をもどして・・・
とにもかくにも、ユーザとしては仕様が公開されている
かどうかよりも、閲覧できる基礎的資料がないってこと
が一番困る
前回、前々回のおさらいに補足しながら、
ActiveDirectoryの話などをしていきます
NetBEUI と NetBIOS
原型はDOS時代(1980年代の半ば)にできるだけ簡単
なアーキテクチャという方針で設計されたプロトコル
名前もなかった。
NetBIOSというプロトコルとインターフェースをかねた総称で
呼んでいた
ルーティング不可
Ethernetだけでなくトークンリングでも使っていた
実はもともとはIBMやマイクロソフトが共同で定めたベン
ダー独自規格
マイクロソフトはこの仕様をあとあとまで引きずることになる
NetBEUI と NetBIOS
原型をTCP/IPに対応させて、IPネットワーク上で使え
るようにとアーキテクチャを整理した
ここで NetBEUI (第2+3層)とNetBIOS over TCP/IP (NBT
第4層)、NetBIOSインターフェース (第4層と5層のインター
フェース)、SMB(第5層)が規定される
第5層
SMB
NetBEUIの原型 NBT 第4層
(広義のNetBIOS)
NetBEUI TCP/UDP
IP 第3層
Ethernet Ethernet 第1,2層
NetBEUI と NetBIOS
NetBIOSインターフェースをTCP/IP上で使うため
NetBIOS over TCP/IP (NBT)が規格化された
RFC1001、RFC1002 で規定
（ポート137、138、139 で通信を行うプロトコル）
あわせてNetBIOSは IPX/SPX上で使うこともできるように
なった
SMB
NetBIOSを上でファイル共有やプリンタサービスを共有する
ためのプロトコル
NetBIOS名前解決がされていないと使用できない
Hostname名前解決だけではダメ
NetBEUI/NetBIOSを使った通信
NetBEUI/NetBIOSベースのネットワークでは
NetBIOS名は一意であり、重複が許されない
IPアドレス の考え方と一緒
NetBIOS名 は host名みたいなものと思いがちだが
IPアドレスに変わるものと理解したほうがよい
NetBEUIでもNBT+TCP/IPでも本質は変わらない
よくみるポップアップ
「ネットワーク上に同じコンピュータ名が存在します。
～」
NetBIOS名 と コンピュータ名
NetBIOS名 = コンピュータ名 + 識別子
Ex. yoshihao01 = yoshihao01 +
ファイル・プリンタ共有クライアント機能 有効
ファイル・プリンタ共有サーバ機能 有効
Etc・・・
同様にNetBIOSグループ名 ＝ グループ名(ワークグ
ループまたはドメイン) + 識別子
NetBIOS名 と NetBIOSグループ名
NetBIOS名による通信 NetBIOSグループ名による
通信 GroupB に通信
ClientB へ通信
ServerA
ServerA
破棄 受信 GroupX
ClientA
破棄 受信
受信
GroupX
ClientB 破棄
ClientC
GroupZ
通信方式の違い
UNIXでの通信は TCP/IPベース (hostsname解決)
Hostname はIPのAllies
DNSやhostsで名前を解決して、IPベースで通信
マイクロソフト ネットワークの通信は NetBIOSベース
(NetBIOS名解決)
NetBIOSをIPにカプセル化して通信
IPアドレスがあっていても、宛先コンピュータ名があってない
と通信できない
何度も言うが 「NetBIOS名 は IPアドレスに変わるもの」
NetBIOS名前解決
NetBIOS名前解決の原則は
ブロードキャストによる名前解決
でも、それだとセグメント越えられないよね？
NetBEUIだとルーティングできないしね
じゃ、NetBEUIやめて、NBTにすればセグメント越えら
れるじゃん
セグメントを越えてのNetBIOS名前解決
LmhostsファイルによるNetBIOS名前解決
hostsファイルと同様な記述をする
192.168.0.100 computerA
192.168.1.200 computerB
セグメントを越えてのNetBIOS名前解決
WINSを使う場合はWINSサーバで管理する
Hostsと同じように、クライアントごとにlmhostを書いてたら
大変
サービスとしては ほぼダイナミックDNSと一緒
クライアント側でWINSサーバを設定すると、そのWINSサー
バに自分のNetBIOS名を書き込みに行く
クライアントはWINSサーバにNetBIOS名前解決を問い合
わせることにより、NetBIOS名に対するIPアドレスを取得で
きる
WINSの導入により、ブロードキャスト宛のトラフィックは削減
される
セグメントを越えてのNetBIOS名前解決
WINSを使う場合はWINSサーバで管理する
使用するポート番号は 42
WINS = Windows Internet Naming Server の略
こんな言い方をするから、ややこしくなるんだ！
実はNetBIOSの各種の問題を簡単に解決するためには
WINSサーバを立てるのが一番
NBTを使った通信
NBTを使うことで、コンピュータ名の代わりにIPアドレ
スが使える
Windows NT 3.1、Windows 98 SP1以降がNBTに対応
（だったはず）
「\\computerA\share」という共有名を
「\\192.168.0.100\share」と置き換えることができる
Windows 95のネットワークでは使えない
ただ基本的に
「コンピュータ名を通信のベースとして使う」
ことはかわらない」
どこまでいってもNetBIOS通信
「コンピュータ名を通信のベースとして使う」
ことはかわらない」
このことを実感するためには、わざと設定を間違えて
みるとわかる
間違えてみよう
コンピュータ名：ComputerA
コンピュータ名：ComputerB
IPアドレス ：192.168.0.100
IPアドレス ：192.168.1.200
Hostsファイル
192.168.1.200 computerB2
Lmhostsファイル ホスト名、コンピュータ名が
192.168.1.200 computerB2 間違ってる
IPベース通信
通信
コンピュータ名：ComputerB2
IPアドレス ：192.168.1.200
NetBIOS通信
コンピュータ名が間違ってる
IPベースでの通信はできても、NetBIOSでの通信ができない！
ここで重要なことは
Ping [IP Address] では Relay がある
でもファイル共有ができない
でも、ping [hostname] だとNGだ
そうか！名前解決ができていないんだ
そこまではいいんです。厄介なのは次の場合
罠
コンピュータ名：ComputerA
コンピュータ名：ComputerB
IPアドレス ：192.168.0.1
IPアドレス ：192.168.0.2
Hostsファイル
192.168.0.2 computerB
Lmhostsファイル
192.168.0.2 computerB2 コンピュータ名だけが間違ってる
IPベース通信
通信
コンピュータ名：ComputerB2
IPアドレス ：192.168.0.2
NetBIOS通信
罠と呼ばれる理由
Ping computerB では Relay がある
Hosts ファイルで名前解決してるからね
名前解決が完全にできていると思い込む
実は hostname名前解決だけで、NetBIOS名前解決はできていない
当然だが、IPベース通信の SMTPやPOP3 なども
Hostnameで通信可能
でもファイル共有だけができない
名前解決ができてるのに、どうして・・・・と悩む
ちょっとネットワークに詳しいと「 ポート137-139をどっかが
ブロックしてんじゃないの？」とか難しいほうにいってしまう
違うんです！
ファイル共有できないのは、NetBIOS名前解決ができ
てないからなんです
名前解決がhostname名前解決とNetBIOS名前解決
の二つがあって、それぞれ違うものだという理解がな
いと原因が見えてこない
悲しいかな、hostsもlmhostｓも正しく記述されてると、
名前解決が二つあるとは実感できない
そして、統合へ
名前解決が二つあるのは、やっぱりややこしい
ということでWindows 2000 Server 以降、
WINSとDNSを統合させた。
Active Directory 環境下ではDNSの名前解決を、WINSの
名前解決に使うことができる
Windows 2000以降のクライアントOSを
Active Directory に参加させると
DNSサフィックス名が自動で付加される
当然、hostnameとNetBIOS名は同一
統合しても
Hostname名前解決と、NetBIOS名前解決は
やっぱり違うものなんです！
便利になると本質を見失っちゃいますね
クルマについてるABSとかも一緒ですよねー
マイクロソフト心の叫び（たいんじゃないかと思う）
すべては歴史が悪いんです。。。。
下位互換性をもちながらVerUpするのは大変なんです
よぉ
もともとはIBMの独自規格なのに、マイクロソフトは
それに縛られ続ける。。。。
でも、IBMはNetBIOSを捨て さっさと Linuxへ（ヲイッ
こんなことなら FTPベースでのファイル共有を拡張し
たほうがよかったんじゃないの？
ここまでの内容
理解できました？
Microsoftネットワークを理解するうえでは
NetBEUI/NetBIOSを理解していないとダメなんです
これがわからないと次に進めません
つぎはやっとブラウザの話です・・・
ブラウジング機能
ブラウジングとは？
コンピュータ一覧を提供するサービスのことです
「ネットワークコンピュータ」をダブルクリックすると
他のコンピュータが見えますよね？あれです
表示されるコンピュータ一覧を「ブラウズリスト」といい
ます
ブラウズリストをもっているコンピュータを「ブラウザ」と
いいます
サーバーサービスですが「ブラウザ」です
ブラウジング機能
こまったことに、ここにもNetBIOSがでてきます
名前解決と同じようにWINSサーバを構築することで
ブラウジング機能を正しく簡単に運用することができま
す
ですが、名前解決と同様に理解するためには、
NetBIOSブロードキャストによるブラウジング機能の
手順を理解する必要があります
ブラウザの種類
ドメインマスタブラウザ
ドメイン環境下で、マスタブラウザを統合する
マスタブラウザ
ドメインマスタブラウザと区別する意味で、
ローカルマスタブラウザと呼ばれることもあります
バックアップブラウザ
マスタブラウザからコピーを受け取り、クライアントからのブ
ラウズリストの要求にこたえます
ポテンシャルブラウザ
ブラウザの機能は有しますが、現在はサービスを提供して
いない状態です
「ネットワークを参照できません」
ネットワークコンピュータをダブルクリックすると
「ベン！」という気に障る音と一緒に表示される
あの忌まわしいメッセージです
これはクライアントがマスタブラウザに接続できなくな
ると表示されるメッセージなんです
マスタブラウザからブラウズリストがもらえないと
このポップアップメッセージがでてきます
ブラウズリストの取得
OS起動後「ネットワークコンピュータ」をダブルクリック
すると NetBIOSグループ名に GroupB に通信
対して、「ブラウズリストを
もってる奴、応答せよ」と
ブロードキャストします ServerA
受信 GroupX
するとブラウザが「俺様だ」と
反応を返します 受信
GroupX
この時点ではレスポンスだけで 破棄
ブラウズリストは渡していません
GroupZ
ブラウズリストの取得
このリクエストにレスポンスするのは、マスタブラウザ
だけでなく、バックアップブラウザもレスポンスします
クライアントはそのレスポンスの中から、任意のブラウ
ザを選択して、ブラウザのアドレス(NetBIOS名)を
キャッシュします
クライアントはキャッシュしたブラウザに対して
「ブラウズリスト」を要求します
誰でもブラウザになれたんじゃ？
ブラウザに接続できないと「ネットワークを参照できま
せん」というメッセージが表示されます
でも「Microsoft ネットワーク共有サービス」をインス
トールしてるWindows OSは、優先順位があるものの
「ポテンシャルブラウザ」です
優先順位は前回お話があったとおりです
つまり、ブラウザに接続できず、自分がブラウザにな
れる場合は・・・
空っぽのネットワークコンピュータ
「誰もブラウザじゃないのか、じゃ俺様ブラウザ」
ということになり、自分自身がブラウザになります
これがWindows 98でよく発生してた、
ネットワークコンピュータを開いたら「空っぽ」
の正体です
マスタブラウザが同じNetBIOSグループ名の中に複
数できてしまう可能性が発生します
マスタブラウザの王様争い
マスタブラウザはNetBIOSグループに対して
12分ごと(Windows 9x系は 15分)に自分自身が
マスタブラウザであることを通知します
「俺が王様だ！」
ところがブラウザには優先順位があり、
自分より優先順位の高いマスタブラウザからの通知を
受け取ったマスタブラウザは、マスタブラウザであるこ
とをやめなくてはなりません
より強いマスタブラウザの傘下に収まるわけです
マスタブラウザの統一
こうして同一NetBIOSグループの中は時間をかけて
ひとつのマスタブラウザに集約されます
ブラウザの王様が決定されます
つまり勘違いしてマスタブラウザになってしまった
クライアントは最大12分間、ネットワークコンピュータ
が空っぽの状態になってしまいます
まさに裸の王様ですね
バックアップブラウザと優先マスタブラウザ
バックアップブラウザの決定の優先順位も
マスタブラウザと同様です
グループ内クライアント数によってバックアップブラウザの
台数がかわります(1台+ 32台につき1台追加)
リソースキットには 16台につき1台追加と書かれているらしい
プライマリドメインコントローラはブラウザの優先順位
が最も高く、バックアップドメインコントローラとあわせ
て優先マスタブラウザと呼ばれます
皇帝といった感じでしょうか
ブラウズリストの内容
ところで、ブラウズリストって何が書いてあるんでしょう
NetBIOS名
コメント(マイコンピュータのプロパティで記述するコメント)
コンピュータの属性
•ワークステーション機 • Macintoshサービス
能が稼動 が稼動
• サーバ機能が稼動 • Netwareサービスが
• SQL Serverが稼動 稼動
• PDC機能が稼動 • LAN Managerドメイ
• BDC機能が稼動 ンのメンバ
• Time サーバが稼動 • プリントサーバが稼
• スタンドアロンサーバ 動
である • RASサーバが稼動
• ポテンシャルブラウザ • UNIXサーバである
である • Windows NT系OSで
• バックアップブラウザ ある
である • Windows for
ブラウズリストへの登録
各クライアントは自分の情報をブラウズリストへ
登録する
そのタイミングは、
Windows NT系 Computer Browerサービス起動/停止
Windows 9x系 Microsoft ネットワーク共有サービス
起動/停止（実際はコンピュータの起動/停止）
定期 12分間隔
定期登録は自らが利用可能であることをアナウンスし
ます
ブラウズリストの更新
定期登録連絡が3回連続で来なかった場合は
ブラウズリストから削除されます
正常なシャットダウンが行われなかった場合が想定されます
最大で12分x3回=36分間ブラウズリストには残る
たまにシャットダウンしたPCがネットワークコンピュータに
残ってますねえ
最新のブラウズリストは、最長12分おきにクライアント
に配信される
36分+12分 = 最大48分 幽霊クライアントが
存在することになる
複数ワークグループのブラウジング
同一セグメント内に複数のワークグループがある場合
マスタブラウザはワークグループの数だけ
存在することになります
NetBIOSグループ名が違うので統合はされません
マスタブラウザが他のワークグループのブラウズリスト
を保持する
3つのワークグループがあれば、ひとつのマスタブラウザは
3つのブラウズリストをもつ
セグメントをまたいだワークグループ
ルータをまたいで構成されるワークグループは
ブロードキャストが届かない
NetBEUI はセグメントを越えられない
必然的に NBTによるネットワークになる
名前解決同様、ブラウジングが正しくできるよう設定す
れば難しいことはない
ただしLmhostsを使って名前解決やブラウジングを設定する
ことは管理上は大変
動作原理を理解したうえで、
WINSサーバの使用が推奨
気づきました？
NetBIOS名前解決とブラウジングは別物です
もちろん相互連携はあります
つまり「ファイル共有すること」と
「ネットワークコンピュータで共有パソコンが
みえること」は別な事象なんです
ネットワークコンピュータで見えなくても、
共有フォルダのパスを直接指定すれば
共有できるっていう理由がこれです
NTドメインの構成は必須ではない
NBTを使うことにより複数セグメント間で複数ワークグ
ループを構成することは不可能ではない
NetBIOS名前解決もブラジングもできますからねえ
一部の書籍では「セグメントをまたぐ場合はドメインが必須」
と書かれている場合もありますが・・・
ただ面倒です。楽なほうがいいですよねえ
Hostsファイルでhostname名前解決するよりDNSサーバ
LmhostsファイルでNetBIOS名前解決/ブラウジングするよりWINS
サーバ
あれ？NTドメインいらないんじゃない？
DNSサーバとWINSサーバがあれば
NTドメインいらないんじゃない？
その通り、必須ではありません
ワークグループレベルではユーザ管理や共有フォルダ管理
などはひとつひとつ設定する手間が発生します
しかも
WINSサーバは Windows Server OSについてる
だからServer OS 買ってね by マイクロソフト
Windows Client OSはライセンス上、リソース共有できる
他のPCは10台以下となっています
やっぱりServer OS 買ってね by マイクロソフト
せっかくだから、NTドメインにしよう
10台以下のネットワークでセグメントまたいで
使う環境って多くはないでしょう
10台以上のネットワークでWINSサーバが
必要なぐらいなら Server OSは必要なんじゃ
なんだよ、結局 Server OSが必要なら
NTドメインにしてWINSたてりゃいいんじゃねーかよ
ですから、マイクロソフトもSIベンダーも Server OSの導入を
進めています
で。NTドメイン環境下の話
ちょっとブラウジングの話にもどります
ドメインマスタブラウザ
NTドメイン環境下においてマスタブラウザのボスになる
機能的にはローカルマスタブラウザと一緒
マスタブラウザを統合する
セグメントをまたぐならNetBIOS名前解決が必要
認証とSMB
ここまでのお話で、大事なことが話されていません
そうだ！認証は？
NetBIOS名前解決もブラウジングも認証という
概念はありません
あれ？それを利用して共有名詐称できるんじゃ・・・
SMBセッションによって、はじめて認証が行われます
３WAY ハンドシェイクがあって、通信がはじまる
プロトコルネゴシエイト終了後、ユーザ名とパスワードの
送信が行われる
SMBセッション
SMBセッションでは、ログオンしているユーザ名と
パスワードが送出されます
Windows NT系はSMBセッション毎に変更することも可能
Windows 9x系は変更不可
マシン単位のSMBセッション
SMBセッションを複数同時に張った場合に1つは user1、
1つは user2 というセッションのはりかたはできません
User1 でSMBセッションを開始した場合、
すべてのSMBセッションの終了まで、user1の権限でのセッ
ションになります
NULLぽ
通常SMBセッションの認証時にはユーザ名と
パスワードの情報を送出します
が、NULLアカウント+空パスワードでの認証をする
ことも可能
これをNULLセッションと呼びます
これは認証情報自体の通信のための措置
ブラウズリストの交換もNULLセッションで行われる
NULLセッションが可能な共有は制限はされている
でも実際にはしばしばセキュリティホールになった
SAM
SAM (Security Account Manager)
認証用アカウントのデータベース
各マシンごとに持つ ローカル SAM と
NTドメインが持つ ドメインSAM がある
ワークグループ環境では 認証はそれぞれ
各マシンごとにローカルSAMを使って行われる
台数が多くなってくると管理が困難
ローカルパスワード変えたら、他マシンのSAMのアカウント
も変えたくなる
ドメインSAM
NTドメイン環境下では、それぞれのリソースへの
認証は ドメインSAMを使って行われる
管理がラクチン
どこのリソースを使っても同じアカウントとパスワードで
いける
もちろんローカルSAMも健在
ローカルログオンのときは ローカルSAMを使う
\\domainname\username ドメインログオン
\\computername\username ローカルログオン
NTドメインの信頼関係
複数のNTドメイン間で信頼関係を結ぶことができます
お互いのドメインSAM をつかえるようにする
それをもとにリソースを共有する
Windows NT までは NTドメイン同士は常に対等に
信頼関係を結んでいました
Windows 2000以降 Active Directoryでは、
NTドメイン内のユーザ名等をグループ化して
階層化することが可能になっています
内部が階層化されたドメインSAMを使います
SMBセッションの認証方式
チャレンジレスポンス方式
1. クライアントから認証要求
2. あらかじめ用意してあったハッシュから毎回違う
チャレンジ文字列を生成。クライアントに送信
3. クライアントはパスワードからハッシュを生成、
さらにチャレンジ文字列を使用し、レスポンスを生成する
4. サーバ側で 3.でつくられるレスポンスをあらかじめ
生成、クライアントから送信されたレスポンスと
同一であれば 認証成功
問題はハッシュの生成方式
チャレンジレスポンスは、ハッシュがすべて
パケットキャプチャされていると
チャレンジ文字列とレスポンスは見える
認証が成功している通信をキャプチャしている場合
ハッシュ生成アルゴリズムがわかるとパスワードがわかる
Microsoft ネットワークで使用するハッシュは
大きく3つに分かれる
LANMAN
NTLM
NTLMv2
下位互換とLANMANハッシュ
Window 9x系OSは LANMANハッシュしか使えない
Windows 9x系がネットワーククライアントとして
好ましくない技術的な理由
パスワードの最長は14文字
LANMANハッシュの手順
1. 入力された文字列を大文字化する
この時点で大文字小文字の区別は意味がない
2. パスワードが14バイト未満の場合は、14バイトまで
NULLで埋める
3. 7バイトずつ、2つに区切る
4. マジック値(固定 KGS!@#$%)を使って DESでハッシュ化
ちょっとわかりにくいかな
5. 8バイトのハッシュが2つできる
6. 8バイトのハッシュを再びあわせて、5バイトのNULLを追加
7. 8バイトx2 + 5バイト = 21バイトのハッシュ生成
8. 21バイトを7バイトずつ 3つにわける
9. 8バイトのチャレンジを使って、DESでハッシュ化
10. ハッシュ化された8バイトが３つ
11. これをまとめて 24バイトのレスポンスの完成
絵を描いてみるとわかりやすいかも。。。
結局、どこが脆弱性？
パスワードが7文字(7バイト)以下の場合
レスポンスの最後の8バイトは必ず同一になる
レスポンスの最後8バイトをみれば、パスワードが
7文字以下かどうかがわかる
中級クラスのハードウエアを使った場合
7バイトすべてのハッシュを生成するのに 56日
平均的に1/2 でHitするとすれば
ブルートフォースにかかる時間は 28日。
じゃ8文字以上にすりゃいいじゃん？
パスワードが最大14文字
はじめに7バイトずつわけけられる
ということは7バイトのブルートフォースを2回すりゃOK
最長112日 平均56日でブルートフォース成功
56日で成功するとわかってるブルートフォースなら
仕掛けて待ってますよね(^^;
Administartor (root) パスワードだったら・・・
((((； ﾟДﾟ)))
というわけで LANMAN → NTLM
NTLM
Windows NT 4.0 SP3以降 (え、じゃSP2は・・・ )
LANMANハッシュから生成されるLMレスポンスを
送出しない設定が可能
Windows 9x系とは通信できなくなります
MD4(だったかな？) でハッシュ生成
NTLMと NTLMv2
NTLMv2
Windows NT 4.0 SP4以降
LMレスポンス
NTLMハッシュから生成されるNTLMレスポンス
をそれぞれ送らない設定が可能
(NTLMv2ハッシュから生成されるNTLMv2レスポンス
だけ送る設定)
「受け取らない」設定も可能
LMレスポンスやNTLMレスポンスは受け取らず
NTLMv2レスポンスのみ受け付ける
これが現状の最強
NTLMv2 がいいのね
でもデフォルトは LMレスポンスも送っちゃいます
ちゃんと設定しましょう
たしかWindows Server 2003 は
「NTLMv2 のみ受け付ける」がデフォルトだったかも
じゃ、Windows 9xは捨てるしかないのね
Active Directoryクライアント、Winsock2.0などを
インストールすれば NTLMv2に対応します
ちょっと安心。
Sambaとの関係
これまではWindows ベースのお話でした
Sambaはこれらにどのように対応している
のでしょう？
名前解決機能
ほぼWindows と同等の機能を有しています
WINSクライアントにもなれます
WINSサーバにもなれます（すばらしい
ただWINSサーバの機能である WINS複製機能は
Samba 3.0からの実装
Sambaとの関係
ブラウジング機能
ほぼWindows と同等の機能を有しています
マスタブラウザはもちろん、ドメインマスタブラウザにも
なれます
ただ、バックアップブラウザにだけなれない
(仕様未公開のためらしい)
LM,NTLM,NTLMv2 対応
最強レベルの
「LMレスポンスやNTLMレスポンスは受け取らず
NTLMv2レスポンスのみ受け付ける」
だけ未対応
NetBIOSの呪縛を解け！
Dirct Hosting of SMB
ポート 445を使用する従来のSMBに変わる プロトコル
Windows 2000以降から実装
Direct Hosting of SMB over TCP/IPという
NBTを包括したプロトコルが NetBIOSの呪縛から開放してくれ
る呪文になるかも
http://support.microsoft.com/default.aspx?scid=kb;ja;31526
7
http://support.microsoft.com/default.aspx?scid=kb;ja;20427
9
もちろん使えるけど、仕様はまだ謎
Samba って対応してます？
実はここまでが復習と補足でした
たぶん、もう時間があんまりないはず
Active Directoryの狙いや機能、AD上で提供される
サービスの紹介ぐらいまで。
Active Directoryとは？
ここまで苦労して、構築する Active Directoryとは
そんなにいいものなのでしょうか？
単純なディレクトリサービス？？
Windows Server 2003 としてみると
Radius、LDAP、DNS、Web、SMTP、POP３、
DHCP 、WINS、CA などの機能を有しています
Active Directory の狙い
ディレクトリサービスとは
「あらゆる情報を一元管理し、アプリケーションに
対しての情報を参照し、更新するための
共通プログラムインターフェースを提供する」
グローバルナレッジ 横山氏
Active Directoryは Windows環境におけるディレクト
リーサービスを、サーバやクライアント、アプリケーショ
ンなどありとあらゆるものに、必要な情報を提供するも
の
概念的にはわかるが、具体的にちょっとわかりにくい
実現できる具体的な機能
統合ユーザ管理
権限のテンプレート化
Intellimirror
リモートインストールやフォルダ同期など
統合システム管理
Exchange や SharePoint との統合
ユーザの共通化、権限の共通化、アプリケーション間のデータ連携
DNSやWINS、DHCP との統合
Microsoft ネットワークをより簡単に
シングルサインオンの実現
ちょっとした機能
共有フォルダの位置
共有フォルダのUNCに対して、わかりやすい名前やキー
ワードを設定できる
共有フォルダ自体を検索することが可能
共有プリンタの位置
UNCに加え、両面印刷やホチキス機能などの有無などを検
索できる
拠点数が多いネットワークで、他サイトに訪問した際に
非常に便利
グループポリシー
クライアントの設定を一括管理する機能
ユーザインターフェースの制限や自動設定
コントロールパネルの非表示やプリンタ追加不可など
アプリケーションの自動インストール
IEやセキュリティパッチだけでなく、Notesクライアントなども
証明書の自動配布
ローカルアカウントへの制限
Administrator /guest 名強制変更
グループごとのログオン、ログオフスクリプト
Active Directoryって目新しい機能ないの？
「概念的にはどこにでもある機能」の集合体です
まさに集合しているところに意味があって、
それらの機能や情報などのスキームを自由に変化させるこ
とができる
それらを２次利用、３次利用することで管理コストを低減する
統合化することでネットワーク全体のユーザビリティを
向上させる
ネットワークリソースを集中管理し、検索できるようにする
だけでも、ユーザビリティは向上します
駆け足だったと思いますが
オープンソースとGPLに対するマイクロソフトの考え方
NetBIOS名前解決
ブラウジング機能
SMBと認証
認証方式と脆弱性
Sambaとの関係
Active Directoryとはどんなものなのか（のさわり
をお話してきました
が、一番大事なのは
「NetBIOS名前解決」「ブラウジング機能」です
できるUNIXerほどハマってしまうポイントです。
Microsoft ネットワークと UNIXネットワークの両方の知識を
得て快適なネットワークをつくりあげてください
今回、ちょっとマイクロソフトよりの立場でお話しましたが
私個人はWindowsでもUNIXでもLinuxでもホストでも
すべてのコンピューティングが切磋琢磨することで
かんたん便利で快適な サービスが提供されることが
理想だと思います