6

これが私の状況です...

シングル サインオン プロセスを必要とする Web アプリケーションの大規模なコレクション用の .Net/C# セキュリティ システム (承認と認証) を作成しています。私は Active Directory をデータ ストアとして使用しており、LDAP を介して AD と通信する非常に優れたプロトタイプを作成しました。このコンポーネントは、AD に保存したログイン ユーザーに関する情報を取得し、.Net フォーム認証でセキュリティ ロールを設定するために使用します。

1) すべて順調です。

システム管理者でもネットワーク エンジニアでもない私は、AD インスタンスのセットアップに関連するシステム管理の量に精通していませんでした。ドメインごとに個別のサーバーとドメイン コントローラーが必要であることを知りませんでした。結局のところ、AD にアクセスする予定のさまざまな環境すべてに対して、私のチームが設定する必要がある 9 つの異なるドメインがあることがわかりました...

  • env1.dev.mycompany.com
  • env1.qa.mycompany.com
  • env1.stage.mycompany.com
  • env2.dev.mycompany.com
  • 等

...そのため、これらのマシン (または VM) をすべて保守する必要があるため、管理上の頭痛の種が幾分か自分自身にかかっています。

2) すべてが良くない。

プロトタイプは非常にしっかりしており、AD はソリューションにとって非常に優れたデータベースになりますが、コードを破棄して、代わりに SQL Server データ プロバイダーを作成する必要があるかどうか疑問に思っています (.Net が既に提供していることは知っていますが、それはありません)。承認のための私のビジネス要件に適合するだけではありません)。

とにかく、私はこの問題を高いレベルの観点から考えようとしています。一般的に、サーバーのメンテナンスのために本当に良いソリューションを投げているという事実につまずきますか? ここにいる誰かがこのようなシナリオを経験したことがあるのだろうか、そしてあなたは正確に何をすることに決めたのだろうか.

AD に固有である必要はありません。優れたソフトウェア ソリューションとサーバー メンテナンスの制約との間で評価する必要がある状況にすぎません。

4

4 に答える 4

4

一般に、製品の使いやすさは、人々がその製品と類似の製品の間で選択する理由です。製品のユーザビリティが悪い場合、ユーザーはそのコードの品質を気にしません。ユーザーにとって重要なのは、それがどれほど簡単で効果的であるか、そしてどれだけユーザーのニーズを満たしているかということだけです。

メンテナンスはユーザビリティの 1 つの側面と考えることができます。メンテナンスが容易な製品を最優先します。長期的には、管理者の多くの時間を節約できます。

それについて考える 1 つの方法は、最初にエンド ユーザー/管理者の観点から最も使いやすいソリューションを設計し、次にその最適なソリューションを実際に実装することを知的課題にすることです。プログラマーはおそらくより多くの労力を必要とするでしょうが、最終結果はより良くなります。

たとえば、ZFSはメンテナンスが行き届いている製品の 1 つです (個人的には使用していませんが)。設計時に、ZFS のコマンド ライン ツールを使用してファイル システムを簡単に管理できるようにするために多大な努力が払われました。これらの設計上の決定は、ZFS のすべてのレベル (ストレージ プールなど) に影響します。

別の例として、私は最近、私の将来のプロジェクトである分散データベースとアプリケーション サーバーのメンテナンス方法を計画しています。典型的な管理タスク (アプリケーションのインストール/アップグレード、クラスター内のサーバーの追加/削除、ハードウェア障害の解決など) がどのように行われるかを考えると、いくつかの設計上の決定を整理するのに役立ちました。それらのいくつかは、システムのアーキテクチャに深く入り込んでいます (たとえば、実行時にアプリケーションと拡張機能がどのように読み込まれるか、サーバーがクラスター内の他のサーバーを見つける方法など)。

于 2009-04-22T22:49:42.717 に答える
1

Windows システム用のシングル サインオン システムをセットアップする場合、AD を使用する可能性が非常に高くなります。システム管理者として。単一ソースのデータ ポリシーに従うようにしています。AD は、既に Windows ユーザー/セキュリティ データの多くを保持しています。私は、2 つ目のシステムよりも、そこにすべてを搭載したいと考えています。

開発/テスト/本番環境をセットアップするとき、特に作業中の領域 (開発作業が行われている場所など) で、本番環境と厳密に一致するようにします。そのため、AD とのインターフェイスを開発するシステムをセットアップする場合、複数の AD サーバーを使用する可能性があります。

管理を簡素化できるオプションは何ですか?

標準的な方法で維持する 1 つのマスター サーバーを用意し、VMware コピー プロセスのようなものを使用して他のすべてまたはほとんどを維持できますか? 9 台のサーバーに何かをするのではなく、開発/テストをサポートするために加えられた変更を除いて、残りの 8 台をそのミラー マスターのコピーとして保持しますか?

1 つの AD サーバーから複数の開発またはテスト ドメインを実行できますか?

アクションのスクリプトを作成できますか?

特にテストのハイエンドで、環境の数を減らすことはできますか? たとえば、複数の開発環境を提供し、リリースを単一のテスト環境にロールアップしますか?

于 2009-04-22T22:39:58.370 に答える
1

テストの際に、個別のドメインではなく単純に OU を使用しないのはなぜですか? つまり、ドメインは 1 つですが、特定のバージョンのユーザーがそのドメイン内の特定の OU に存在する必要があることを指定します。ユーザーを検索するための検索機能で、ドメインのルートではなく、特定の OU を検索ルートとして指定します。各 OU には、環境を組み込んだ ID を設定して一意に保つことができます (例: 、、user_env1_dev... )。user_env2_devuser_env1_qa

私は自分のアプリに AD をよく使用しますが、開発/テスト用に別のドメインを設定することはありません。

于 2009-04-22T22:41:10.427 に答える
1

プロバイダー パターンを使用して、データソース呼び出しを抽象化します。

次に、その場で AD または SQL を使用するように構成できます。

public abstract SSODataProvider {
     public bool AuthenticateUser(string u, string p);
}

public ADSSODataProvider : SSODataProvider {
    public override AutheticateUser(string u, string p) {
       //do auth here
    }
}

public SQLSSODataProvider : SSODataProvider {
    public override AuthenticateUser(String u, string p) {
      //call DB
    }
}

public static SSODataProvider dataProvider;

if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL")
   dataProvider = new SQLSSODataProvider();
else
   dataProvider = new ADSSODataProvider();

....

dataProvider.AuthenticateUser("sss","sss");
于 2009-04-22T23:38:17.140 に答える