このプロジェクト、.NETに関する深いノウハウを持ったメンバーがいませんでした（僕も然り）。その低レベルさときたら、以前に書いたインストーラの依存DLLに関するエントリが示すように、危うくライセンス違反を犯してしまう程ですが、もう1個、呆れてしまうようなものがあったのを最近思い出しました。その時の教訓です。
既存のWindows Server上にシステムを追加する場合、Active Directoryを利用しているかどうかを確認しておくこと
もうね、低レベルすぎて笑っちゃいます。ホントすいません。
＊
プロジェクトの概要は、既存のWindows Server 2003環境に、新たにC/S型のシステムを追加するというもの。プラットフォームは「.NET Framework 3.5」。クライアントアプリは「Visual Basic 2008」のWindowsフォームアプリで、データベースは「SQL Server 2008」。
実行環境のセットアップは僕が行う事になった。SQLServerのセットアップを、設定手順をメモしながら進めていく。すると、認証モードの設定の所にきた。「Windows認証モード」か、「混合モード」か。この辺は有名な話だし、昔.NETのお勉強で自宅にSQLServerの無償版インストールしたことがあったので、それぞれの意味や、MicrosoftはWindows認証を推奨している事等、僕はちゃんと把握していた。C/S型の場合、Active Directoryを使用しているのであれば、Windows認証を選択すべきという事も。
と言う訳で、顧客との窓口であるSEに聞いてみる。渡されたプロジェクト概要資料には、現在のサーバー環境のOS・利用アプリ等の情報があるが、Active Directoryの利用の有無が記載されていなかったので（この時点で駄目だよな・・・）。
僕「SQLServerの認証モードですけど、『Windows認証』か『SQLServer認証』か、どっちにします？」
SE「どう違うの？」
僕「（うわっ、ご存じないのか・・・）『Windows認証』というのは、・・（解説）・・という訳で、Active Directory利用しているなら、Windows認証の方がアカウント管理が楽ですし、セキュリティ的にも安心です。」
SE「Active Directoryの話は無かったから、『SQLServer認証』でいいよ」
「話は無かったから」てことなので、この遣り取りだけでは、利用の有無はハッキリしない。この時、ちゃんと確認を依頼しなかったのは僕の不覚・・・。ただ、顧客との打ち合わせには、.NET案件の経験が豊富なマネージャが一応同席していたので、その辺はちゃんと確認済で、「利用してれば明記する。してなければ明記しない。」というスタンスの資料なのかな？なんて結論づけてしまい、追求を止めてしまった・・・。ったく、無いなら無いで明記しなきゃいけないよな。クライアントアプリのコード・設定にも絡んでくるような事だから。
ちなみに実際はどうだったかであるが、「不覚」とか言ってることからもお分かりですね、実際はActive Directory利用されてました。発覚したのは、製造フェーズが7割程完了した時期。発覚の仕方がまた低レベルだった。このシステムではクライアントからReporting Servicesにアクセスするので、アクセスの際にサーバーのURL（IPアドレス）が必要になる。このURLはDBの環境変数テーブルに格納することにしたのだが、顧客環境と当社開発環境ではIPアドレス体系が全く異なるので、同一の値を設定することができなかった。これでは、納品時にIPアドレスの変更作業が生じる（別に大した作業では無いですが、納品作業を行うのは初めてだったので、少しでもリスクを減らしたかった・・・）。ところで、もし顧客環境のサーバーにDNSドメイン名が割り振られているのであれば、URLはドメイン表記で登録しておき、IPアドレスの違いは開発端末上のhostsファイルで吸収してあげることによって、納品時の変更作業が不要になる。僕はその旨をSEに伝え、DNSドメイン名の有無の確認を依頼した。・・・数日後、確認したとのメールが送られてきた。添付ファイルを開くと、「システムのプロパティ」ダイアログのハードコピーが。・・・すいません、これDNSドメインじゃなくて、Active Directoryドメインなんですけど！
添付ファイルのイメージ
※ちなみに、この程度の確認事項の返事に数日かかっているのは、SEが別の炎上プロジェクトに拉致されてしまったからです。こちらに帰ってくるのは、1～2週間に1回。実質、SE不在・・・
欲しい情報は手に入らないわ、前提条件が違うわ、踏んだり蹴ったり。アプリの方は、前述のSEとの会話があったので、SQLServer認証を行う形で実装してしまっている。しかし、DBアクセスに関しては、アクセスできなくなる訳ではないので、このままでも一応問題は無い。app.configにパスワードが丸見えだったり、管理するアカウントが増えたり、何より「最適」でない作りがエンジニアとして非常に歯痒いが・・・
それでも、Windows認証に変更する事で、SQLServerやReporting Servicesの設定・運用が楽になるので、SE宛に、Windows認証使用する方向に変更するかどうか・変更した際の長短所・追加作業等を記載したメールを送信。結果、返事無し。もう、知らんぞ！（この時もっと粘らなかった事も不覚・・・）。そしてこれが結局仇となった。
Reporting Servicesの設定で問題発生。発覚したのは納品作業中。恐らく、20代で一番焦った。
Active Directoryを使用してないという話だったので、Windowsサーバー上にReporting Servicesアクセス用のローカルアカウントを作成し、それで基本認証を行う作りとしていた。ところが納品時、Windowsサーバー上にアクセス用アカウントを作成しようとしたところで、手が止まった。ローカルユーザーを作成できない！そう、この時の僕は（というかプロジェクトメンバー全員が）、ドメインコントローラ上には、ローカルアカウントは作成できないことを知らなかった。焦りで手の平に汗が噴き出てきた。僕の作業の監視役を務めていたもう一人は「取り敢えずドメインアカウントを作って進めてみたら」と言うが、こういう時僕は妙に慎重になりすぎてしまう。頭を抱えて考える。仮にWindows認証の設定にした場合、正常に動くのか？いや、動かないと思う。VBのコードは基本認証用のクラス（NetworkCredential）を使ってしまっているから。どうする？どうする？・・・
結局、作成する予定だったローカルアカウントと同じ名称のドメインアカウントを作ってみたら正常に動いたので、「顧客に頭を下げて徹夜作業」という最悪の事態は回避できた。しかし、「ドメインアカウントで基本認証」という、何とも不細工なシステムとなってしまった。
0 件のコメント:
コメントを投稿