- - PR -
DCに外部向けDNS経由でアクセスすると認証ができない。
1
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-09-26 14:16
非常に状況が説明しにくいのですが、
aaa.co.jpというネットワークの中でそれぞれのPCに a1.xx.aaa.co.jp a2.xx.aaa.co.jp b1.yy.aaa.co.jp b2.yy.aaa.co.jp といった感じでホスト名が割り当てられています。 そして、一部の部署でbbb.localというActive Directoryが構築されています。 諸事情により、ドメイン名を同じにしなかったのには訳があります。 DCではもちろん内部用のDNSが稼働しています。 そのため、Active Directory内でみるとDCには dc.zz.aaa.co.jp dc.bbb.loal という2つの名前が割り当てられています。 DCのDNSはActive Directory内のレコードのみを持っているため、解決できない場合は外のDNSサーバにフォワードします。 以上の環境で、Active Directory内のPCからは \\dc.zz.aaa.co.jp \\dc.bbb.loal のどちらでもDCに接続できます。 ここまではいいですが、 DC自ら(DCにログオンして)このように行うと \\dc.zz.aaa.co.jpとやった場合のみ認証が要求されます。 そして、どんなアカウントをもってしても認証に失敗します。 たとえAdministratorのアカウントを使用してもだめでした。 一部の外部のPCからこのActive Directoryで構築されたDFSにアクセスしたいため、 ルートとなる部分に\\dc.zz.aaa.co.jpを使用したいのですが、 先ほどの現象によりウィザードで「アクセスが拒否されました」と出ます。 もちろん\\dc.bbb.loalでは成功します。 うまくいかない原因はなんなのでしょうか | ||||||||||||
|
投稿日時: 2006-09-26 23:23
こんばんわ．
良くわかりませんが，bbb.loal の Domain に dc.zz.aaa.co.jp という Domain Controller があるのですか？ それとも単に dc.zz.aaa.co.jp で名前解決ができるだけですか？
それは単に名前解決の結果だと思います．
dc.zz.aaa.co.jp は Active Directory で有効な名前ではないのでは？ Active Directory based なら dc.bbb.local でうまくいくのは当然でしょう． | ||||||||||||
|
投稿日時: 2006-09-27 10:01
kazさん、こんにちは。
状況説明が下手でしたね。 現在の環境では、aaa.co.jpの内部全体に1つずつIPアドレスを割り当てているDNSサーバと AD用のDNSサーバbbb.localがあります。 aaa.co.jpはADではなく、ただのDNSサーバです。 ADのDCではAD内のみを解決します。 なので、AD内のPCからは当然、どちらでも解決でき、接続できます。
ADで有効な名前でなければ、AD内のクライアントからもdc.zz.aaa.co.jpで接続できないってことですよね？ それならばわかるのですが、DCで行った場合「のみ」うまくいかないという原因がわからないです。 | ||||||||||||
|
投稿日時: 2006-09-27 10:40
その際のセキュリティのイベントログには、 どんなユーザで認証失敗したか記録されてるはずですので、 それを確認してください。 そんな特殊な環境で、かつADのDNSゾーン以外の名前を使うこと前提で 運用、ってこと自体、苦しむのは目に見えてるので、 素直にADのDNS名前体系でのみADの機能を利用するのが無難だと思います。 随時出てくる問題が解決したところで、新たな問題が出てくる可能性は 否定できませんし、それに対する実績ベースでの原因・解決策について 情報持ってる人は限られてるorいないと思います。 _________________ Mattun Microsoft MVP for Directory Services (Oct 2006-Sep 2007) | ||||||||||||
|
投稿日時: 2006-09-27 12:40
こんにちわ．
基本的には Mattun 様が指摘されているように手探りになるので， その「設計仕様」で運用されることは困難だと思います．
ここが「当然」なのが良くわかりません． client は AD_DNS と internal DNS をどのように参照しているのでしょうか？ 優先 -> AD_DNS，代替 -> internal DNS ですか？ それとも， 優先 -> AD_DNS だけで，AD_DNS が internal DNS に forward しているとか？ あるいは 優先 -> internal DNS で，internal DNS が AD_DNS に forward している？ ※そのほかに external な DNS server があるんですよね？
よくわかりませんが，「自分が DNS server」であることの違いは大きいのでは？ とくに Domain Controller の場合， Active Directory と密接に結びつくわけですから． clinet は Active Directory 用の DNS server がなくても 一応動いていしまいますし．．． ゴメンナサイ，単なる憶測です． | ||||||||||||
|
投稿日時: 2006-09-27 17:21
Mattunさん：
確認してみたら、以下のようなログが吐かれていました。(一部直してあります) なお、イベントIDは537です。 もちろん、パスワードが違うなんてことはしていません。 ログオンの失敗: 原因: ログオン時にエラーが発生しました。 ユーザー名: Administrator ドメイン: ZZZ ログオンの種類: 3 ログオン プロセス: , 認証パッケージ: NTLM ワークステーション名: DC 状態コード: 0xC000006D 副状態コード: 0x0 呼び出し側ユーザー名: - 呼び出し側ドメイン: - 呼び出し側ログオン ID: - 呼び出し側プロセス ID: - 移行されたサービス: - ソース ネットワーク アドレス: 172.19.1.150 ソース ポート: 0 調べてみたのですが、いまいちわかりませんでした。 kazさん：
この中の真ん中のやつです。 外部へはinternal DNSがフォワードしています。 さらに調べてみると、AD内のすべてのクライアント(DC含む)において〜.zz.aaa.co.jp形式での自分自身に対する接続のみがうまくいきません。 〜.bbb.local形式でのアクセスや、〜.zz.aaa.co.jp形式でも自分自身でなければすべて問題ありません。 ご指摘のように、設計がまずいのは承知です。 もしよろしければ、もう少しおつきあいください。 | ||||||||||||
|
投稿日時: 2006-09-27 17:52
上記部分を、接続成功してるクライアントのログと見比べてみては？
ドメイン って部分と、認証パッケージって部分、同じですか？ 認証パッケージが異なる(NTLMorKerberos)、 または名前解決内容(DNSだけじゃなくNetBIOSも込みで考える)が異なる、 などの要因で、意図しないドメイン名で認証されてる、 という可能性は考え付きましたが。 認証ダイアログが出た際、 <NetBIOSドメイン名>\<ユーザ名> <ユーザ名>@<ADのDNSドメイン名> を入力すれば、その辺が異なっても回避はできるかと思います。 _________________ Mattun Microsoft MVP for Directory Services (Oct 2006-Sep 2007) | ||||||||||||
|
投稿日時: 2006-09-29 13:49
Mattunさん：
遅くなり申し訳ございません。 NetBIOSドメイン名とADのDNSドメイン名は同じですが、念のため確認してみましたが どちらもうまくいきません。
確認してみたところ、認証に失敗するときだけNTLM認証になり、成功するときはKerberos認証になっていました。 ドメインはどちらも同じでした。 そして、失敗するときはログオン プロセスが文字化けしています。 成功時はKerberosが入っていました。 どうやらNTLM認証になってしまうのが問題なようですが、なぜそうなってしまうのかがわかりません。 解消法ってございますか？ | ||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。