FSMO移行時の落とし穴？ パート①
ドメインコントローラの移行はハードウェアの保守切れ対応なんかでよく仕事でお目にかかるが、今回はFSMOだった。シングルフォレストシングルドメインのシンプルな環境だったが、信頼関係先が多くて環境的にはちょっと気持ち悪い。子会社間とか、セキュリティのためにドメインが組織単位が複数に分かれているのはあるとしても、システム部門が縦割りとなっているせいで同じ組織内で作る必要もないドメインを乱立させるのは果たしていかがなものか。
それはさておき、やっぱり一筋縄ではいかずはまりました。今回は更改理由が単純なハードウェアの保守切れ対応だったので、OSのバージョンやドメイン機能レベルなどの変更もなく余裕かと思っていましたが。
しかもはまったのはFSMOの機能を移行した元の古いサーバー側を停止したとき。信頼関係先のリソースが見事に使えなくなりました。。FSMO移行の事前確認作業として行うdcdiagやRepadminでは事前に気づくことができない。
原因は信頼関係先との名前解決方法にありました。条件付きフォワード設定なら問題なかったのだけど、ゾーン転送設定で_msdcs.xxxx.localゾーンを転送していなかったことが原因。Windows server2003以降は_msdcsゾーンが元のxxx.localゾーンを委任する形で個別に作られるのはAD統合ゾーンの仕様のようだ。_msdcsゾーンは通常ADのSRVレコードを格納するゾーンとして認識されている。だが実際にはSRVレコードだけでなくNSレコードなども格納されている。
今回問題となったのはこのゾーンが信頼関係先に転送されていなかったこと。xxx.localゾーンは転送されていたが、xxx.localゾーン内のNSレコードがFSMO転送後に新サーバーを向いてくれていなかった。。相手先のドメインはこちらのドメインのDNSサーバーがまだ古いサーバーを向いていると認識していたみたい。
よくわからないのはFSMOを変更したときに何故か元のxxx.localゾーンのNSレコードが自動で更新されないことだ。FSMO移行後も更改元のサーバー停止まではドメイン内も信頼関係先とのリソースアクセスも何も問題がなかったことから、_msdcsゾーンと元のゾーンのNSレコードに整合性がなくても問題ないようだ。
きちんとパケットキャプチャをとったわけではないのではっきりしたことは言えないが、ゾーン転送ではなく条件付きフォワーダーで名前解決を実装している信頼関係先のドメインには一切影響がなかったことを考慮すると、どうもDNSサーバーの位置は_msdcsゾーンのレコードを意識しているっぽい。
ADは奥が深い。なんでこんなに複雑なんだろうとはたまに思うけど。もっと学ぶことがありますね。
Office 2013のアカウント先進認証有効化
Office 2013のアカウント認証がエラーになるせいで、SharepointからOffice関連ファイルが開けなくなった。
理由は会社のメールアドレスでMSアカウントの組織IDと個人IDを共有してしまっており、Office2013はデフォルトで先進認証（パスワード認証以外の認証方法）を有効にしていないため。
Office2013のレジストリを変更して先進認証を有効にすることで、証明書認証を使用している組織IDでも無事に認証することができるようになった。
出典
