- - PR -
Windows 2003 ServerにおけるWinsサーバを利用したログイン
投稿者 | 投稿内容 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-24 15:15
お世話になります。
NTからWindows2003Serverへのアップグレード移行を現在検討しております。 この件に関しては以前、質問させていただきました http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=17402&forum=8&7 ので大体のところは理解できたのですが、その後のクライアントの ログインについてお聞きしたいと思い、質問させていただきます。 アップグレード前の、クライアントの設定(IPアドレス等)は以下のとおりとします。 ・ipconfig /all の結果(仮) Dhcp Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 172.16.0.69 ・・・・固定 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 172.16.0.1 DNS Servers . . . . . . . . . . . : 192.168.1.1 ・・・・本来はDMZ上のDNS Primary WINS Server . . . . . . . : 192.168.1.71 Secondary WINS Server . . . . . . : 192.168.1.78 ここでPrimary WINS Server(IPアドレス:192.168.1.71)がPDCとし Secondary WINS Server(IPアドレス:192.168.1.78)がBDCとします。 ここでPDCおよびBDCをWindows2003Serverにアップグレードしたとします。 その後、クライアントは他のセグメント(サブネット)にいる場合でも設定を変更せずログインできる と思いますが(WINS上のドメインコントローラレコード <1Ch>を参照している?)、やはりクライアントの Primary DNSアドレスを変更すべきでしょうか? 質問をまとめさせていただきますと、 1.DNSサーバがなくてもWINSサーバさえあれば、ドメインにログインは可能なのでしょうか? 2.クライアントのPrimary DNSをADサーバ(Windows DNS サーバ)に変更しなかったときの弊害は どんなものがあるでしょうか?(LDAPが使えない等) 3.WINSサーバ上にドメインコントローラレコード<1Ch>が存在しない、もしくは存在したとして、 そのサーバが落ちている場合は、動的にもう一台のADサーバがドメインコントローラとしてWINS に登録されるのでしょうか? 4.IP:192.168.1.1にあるDNSサーバにSRVレコードを手動もしくは、動的更新にてドメインコントローラ の情報を書き込んでしまえば、WINSサーバがなくともログインできるのでしょうか? あまりまとまっていませんが、ご教授いただけたらと思います。よろしくお願いいたします。 | ||||||||||||||||||||
|
投稿日時: 2005-01-24 15:24
ActiveDirectory構築の資料を眺めてみれば分かるでしょうが、
DNSとの関連についてどれだけ深く触れられているか。 そして、WINSとの関連について触れてる資料がどれだけあるか。 出来る出来ない以前に、事例が少なく資料も少ない構成を選んだ場合、 トラブルシューティングを自力でやり切れる自信があるんでしょうか? 無いなら、即刻DNSの構成設計をやり始めた方がいいでしょう。 明日明後日ADへアップグレードしなきゃならない、ってわけでもないでしょうし、 1000台のクライアントが全部手動構成だったとしても、本腰入れれば 数ヶ月もあれば変更できるでしょう。DHCPを利用してるなら短期で変更できるでしょう。 イレギュラーな方法としては、DMZ上にもう一台DNSサーバを構築してしまい、 そちらでグローバルなDNZゾーン情報を提供、 元のDMZ上DNSサーバへのインターネットからの接続をふさいだ上で、 そいつをAD用のDNSサーバにしてしまう。 これならクライアントの構成は不要です。 | ||||||||||||||||||||
|
投稿日時: 2005-01-24 15:57
Mattunさん、ご回答ありがとうございます。
Mattunさんがいわれている通りではあると思います。 本来ですと、クライアントのPrimary およびSecondary DNSをActiveDirectoryの IPアドレスにしておきたいのですが、現在の顧客要望上、クライアントの設定変更は しないでほしいというのがあります。 もちろん、変更してもらうようにすすめたいとは思っておりますが、 とりあえずですが、クライアントのPrimary DNSサーバが 既存のもの(DMZ上のBIND)を参照した状態で、WINSを利用してログインが 可能かどうかを教えていただきたく思い質問させていただきました。
この内容からしますと、WINSを利用してのドメインログオンは不可能なのでしょうか? | ||||||||||||||||||||
|
投稿日時: 2005-01-24 17:29
再度書きますが、 > ActiveDirectory構築の資料を眺めてみれば分かるでしょうが、 > DNSとの関連についてどれだけ深く触れられているか。 > そして、WINSとの関連について触れてる資料がどれだけあるか。 > > 出来る出来ない以前に、事例が少なく資料も少ない構成を選んだ場合、 > トラブルシューティングを自力でやり切れる自信があるんでしょうか? がすべてです。 クライアントのDNS構成を変更しないで実現する例も挙げました。 WINSのみでどうにかしようという選択肢にこだわる理由がわかりません。 少なくともレガシクライアントはNTドメインと同様にNetBIOS名解決から始まる 認証が利用されてます。 ADネイティブクライアントが、AD用DNSを参照してない状態で、WINS環境は整備されている、 そんなADの設計からしたらイレギュラーな状況での動作検証は行ったことが無いです。 確かWINSだけでも認証できた気はするんですが、それだとしても、 そんな環境で問題が起きた際の情報をしっかり把握してる人なんて、ごく限られているでしょう。 それでもあくまでこだわるなら、少なくとも自分でしっかり検証してみるべきでしょう。 | ||||||||||||||||||||
|
投稿日時: 2005-01-24 21:24
こんばんわ.
WINS に拘るのは単に「お客様の要望」なのですよね? であれば,「OS を upgrade することで WINS だけでは機能しなくなる」 可能性が高いことをちゃんと説明するべきでは? それでも「WINS で」という話なら,それは「お客様の責任で」という話かと. 少なくとも Microsoft は「ActiveDirectory は一定の機能を持つ DNS が必要」 と説明しているわけで,それを無視して「WINS で」というのは, Microsoft の設定した仕様から大きく逸脱するのですから, 「検証した限りの内容しか保証し得ない」わけです. [quote]
Mattun 様の説明はあくまでも「WINS を利用して」でなく, 「client 側の設定変更なく」移行できるかもしれないことを説明しています. WINS に関する記述は見当たりません. 「できる」「できない」を論じる限りは「できる環境もある」と言えます. ですが,kita_pon 様の念頭に置かれている環境で出来るかどうかは, 全ての情報を突き詰めないと判断できないでしょう. 仮に全ての情報を入手できても,不測の事態はどこまでも「不測」なので, その際は「自力でどうにか出来ますか?」あるいは 「end user でどうにかなりますか?」というお話です. | ||||||||||||||||||||
|
投稿日時: 2005-01-25 11:31
Mattunさん、kazさん
いろいろとありがとうございます。 考えましたが、やはりクライアントのDNSサーバ設定を変更して もらうのが一番ですね。 ただ、現在利用しているエンドユーザがDomain User権限しかないため TCP/IP設定をエンドユーザが自由に変更できないので、どうにかならないかを 考えておりました。 WINSだけを利用するのが顧客要件ではなくクライアントの設定を変更しないが 要件でしたが、将来的なことも考えてクライアントのDNSの変更を提案しようと 思います。 | ||||||||||||||||||||
|
投稿日時: 2005-01-25 12:14
むしろ、DHCPサーバの導入を検討した方がいいと思うんだけど。 構成変更のたびに全端末のネットワーク設定を人海戦術で手動変更、 ってのもあれですし。 まあ、これだけの規模ですから、DHCPを採用しないことを決めた経緯があるのであれば、 その辺の事情を聞いてみるのも良いと思います。 DHCP環境が整備されれば、あとはDHCPサーバ管理者の設定ひとつで クライアントのDNS設定なんて変更できるんですから。 その辺を見越して考えた場合、今クライアントのDNS設定を変更するのがベストかどうかは 分かりません。すでに挙げた代替案(DMZ上のDNSをAD用DNSに)でADは導入して、 今後DHCP環境が整備されたときにLAN内にDNSを設置して、っていうのもありでしょう。 そうしないと、非DHCPクライアントのDNS設定変更と、非DHCPクライアントをDHCPクライアントへ 変更、っていう、大規模な作業が2つも発生することになっちゃいますから。 あとは、どちらの変更をするにしても、
をどうするかですね。 ・管理者が全端末を変更する ・各ドメインユーザに一時的に管理者権限を与えて変更させる あたりが誰でも思いつく発想。 あとは、netshを利用したバッチを利用することで、上記の作業を単純化したりするのもありでしょう。 実際に僕自身がやったことは無いですが、Windows用sudoコマンドとDomainAdminsの ユーザ名/パスワードを埋め込んだプログラムを作って、それをドメインユーザに 実行させた、って例も聞いたことはあります。 | ||||||||||||||||||||
|
投稿日時: 2005-01-25 12:39
まだ全体をきちんと眺めたわけではないので、わかりませんが おそらく導入されているセグメントもあると思いますので、確認してみようと思います。
ここで言われてるのは、既存のDNSサーバへのAD用のゾーンとそのSRVレコードの 追加という認識でいいのでしょうか。 (BINDのバージョンの問題もありますが)
できればまとめて、Network Configuration Operatorsに参加させることがいいのにな。 とは思いました。 |