2013年7月30日火曜日

模擬問題 24 (MCP 70-640Windows Server 2008 Active Directory, Configuring)

問題:

あなたは、Windows Server 2008 R2を実行し、DNSサーバーとして構成されているドメインコントローラを持っている。
あなたは、サーバーへのすべての受信DNSクエリを記録する必要があります。
あなたは、DNS Managerコンソールで何を設定する必要がありますか？


A.　ロギングをデバッグ有効にします。
B.　単純なクエリのための自動テストを有効にします。
C.　設定イベントは、エラーと警告をログに記録するようにロギング。
D.　再帰的なクエリの自動テストを有効にします。


回答：
　A.　ロギングをデバッグ有効にします。


Explanation:

http://technet.microsoft.com/en-us/library/cc753579.aspx

DNS Tools

Event-monitoring utilities

The Windows Server 2008 family includes two options for monitoring DNS servers:
Default logging of DNS server event messages to the DNS server log.
DNS server event messages are separated and kept in their own system event log, the DNS server log,
which you can view using DNS Manager or Event Viewer.
The DNS server log contains events that are logged by the DNS Server service. For example, when the
DNS server starts or stops, a corresponding event message is written to this log. Most additional critical
DNS Server service events are also logged here, for example, when the server starts but cannot locate
initializing data and zones or boot information stored in the registry or (in some cases) Active Directory
Domain Services (AD DS).
You can use Event Viewer to view and monitor client-related DNS events. These events appear in the
System log, and they are written by the DNS Client service at any computers running Windows (all
versions).


Optional debug options for trace logging to a text file on the DNS server computer.
You can also use DNS Manager to selectively enable additional debug logging options for temporary
trace logging to a text-based file of DNS server activity. The file that is created and used for this feature,
Dns.log, is stored in the %systemroot%\System32\Dns folder.
http://technet.microsoft.com/en-us/library/cc776361%28v=ws.10%29.aspx

Using server debug logging options

The following DNS debug logging options are available:
Direction of packets
Send Packets sent by the DNS server are logged in the DNS server log file.
Receive Packets received by the DNS server are logged in the log file.
投稿者 時刻: 0 件のコメント:
ラベル:

2013年7月29日月曜日

模擬問題 22 (MCP 70-640Windows Server 2008 Active Directory, Configuring)

問題:
企業の管理者として貴方リモート場所にて読み取り専用ドメインコントローラ（RODC）サーバをインストールした
そこでサーバーに十分な物理的なセキュリティを提供しません。
読み取り専用ドメインコントローラに認証情報を複製できるように貴方は何をする必要があります？
A.RODCのグループから任意の管理者アカウントを削除する
B.ドメイン可RODCのパスワードレプリケーショングループに管理アカウントを追加
C.RODCコンピュータアカウントの管理者アカウントの権限として受信で拒否を設定
グループポリシーオブジェクト（GPO）のセキュリティタブ
D.アカウントロックアウトの設定を有効にして新しいグループポリシーオブジェクト（GPO）を設定します。 GPOのリンク
遠隔地へ。アクティブに読み取りを許可して、Applyをグループポリシーの権限を許可する
GPOの[セキュリティ]タブの管理者。
E.上記なし
回答：
B.ドメイン可RODCのパスワードレプリケーショングループに管理アカウントを追加
　 Add administrative accounts to the domain Allowed RODC Password Replication group
参考：
http://technet.microsoft.com/en-us/library/cc730883%28v=ws.10%29.aspx
Password Replication Policy
When you initially deploy an RODC, you must configure the Password Replication Policy on the writable
domain controller that will be its replication partner.
The Password Replication Policy acts as an access control list (ACL). It determines if an RODC should be
permitted to cache a password. After the RODC receives an authenticated user or computer logon request,
it refers to the Password Replication Policy to determine if the password for the account should be cached.
The same account can then perform subsequent logons more efficiently.
The Password Replication Policy lists the accounts that are permitted to be cached, and accounts that are
explicitly denied from being cached. The list of user and computer accounts that are permitted to be cached
does not imply that the RODC has necessarily cached the passwords for those accounts. An administrator
can, for example, specify in advance any accounts that an RODC will cache. This way, the RODC can
authenticate those accounts, even if the WAN link to the hub site is offline.
投稿者 時刻: 0 件のコメント:
ラベル:

模擬問題 21 (MCP 70-640Windows Server 2008 Active Directory, Configuring)

問題21：
あなたの会社では、すべてのサーバーはWindows Server 2008であり、単一のActive Directoryドメインを持っており、
エンタープライズ証明機関を使用しています。
ABC.comのセキュリティポリシーでは、取り消された証明書の情報を調べることが必要になります。
あなたは、取り消された証明書の情報が常に利用可能であることを確認する必要があります。
あなたは、これを実現するために何をすべきか？
A.新しいユーザーがピア証明書を受け入れるようになりGPO（グループポリシーオブジェクト）とを追加し、設定する
ドメインにGPOをリンクします。
B.構成およびドメインに信頼された証明機関のリストを公開するGPOを使用
C.ISASを通じてOCSP（オンライン証明書状態プロトコル）レスポンダ（インターネットの設定と公開
セキュリティとアクセラレータServer）配列。
D.ネットワーク負荷分散を使用して、OCSPレスポンダを公開します。
回答：
　D.ネットワーク負荷分散を使用して、OCSPレスポンダを公開します。
参考：
http://technet.microsoft.com/en-us/library/ee619754%28v=ws.10%29.aspx
How Certificate Revocation Works
投稿者 時刻: 0 件のコメント:
ラベル:

Active Directory Federation Services(AD FS)をインストールおよび構成する

適用対象: Windows Server 2008, Windows Server 2008 R2
フェデレーション サーバーとして使用するコンピュータの構成が終了したので、各コンピュータに Active Directory フェデレーション サービス (AD FS) コンポーネントをインストールするための準備が整いました。ここでは、次の手順について説明します。

ADFS-RESOURCE および ADFS-ACCOUNT 上にフェデレーション サービスをインストールする

組織の要件に応じて次のいずれかのセクションを使用し、ADFS-RESOURCE コンピュータおよび ADFS-ACCOUNT コンピュータ上に AD FS のフェデレーション サービス コンポーネントをインストールします。フェデレーション サービスがコンピュータ上にインストールされると、そのコンピュータはフェデレーション サーバーになります。

フェデレーション サービスを Windows Server 2003 R2 Enterprise Edition ベースのサーバーにインストールする

ADFS-RESOURCE および ADFS-ACCOUNT 上で Windows Server 2003 R2 Enterprise Edition を実行している場合は、次の手順に従ってフェデレーション サービスを追加します。フェデレーション サービスを追加する前に、Secure Sockets Layer (SSL) 証明書をコンピュータにインストールする必要があります。

フェデレーション サービスを Windows Server 2003 R2 Enterprise Edition ベースのコンピュータにインストールするには

  1. CPANDL\ADFSADMIN アカウントを使用して ADFS-RESOURCE にログオンします。
  2. [スタート] ボタンをクリックし、[コントロール パネル] ポイントして、[プログラムの追加と削除] をクリックします。
  3. [プログラムの追加と削除] で、[Windows コンポーネントの追加と削除] をクリックします。
  4. Windows コンポーネント ウィザードで、[Active Directory サービス] をクリックしてから、[詳細] をクリックします。
  5. [Active Directory サービス] ダイアログ ボックスで、[Active Directory フェデレーション サービス (ADFS)] をクリックしてから、[詳細] をクリックします。
  6. [Active Directory フェデレーション サービス (ADFS)] ダイアログ ボックスで、[フェデレーション サービス] チェック ボックスをオンにして、[OK] をクリックします。Microsoft ASP.NET 2.0 がまだ有効になっていない場合は、[はい] をクリックして有効にし、[OK] をクリックします。
  7. [Active Directory サービス] ダイアログ ボックスで、[OK] をクリックします。
  8. Windows コンポーネント ウィザードで [次へ] をクリックします。
  9. [フェデレーション サービス] ページで、[トークン署名証明書を選択する] オプションをクリックし、トークン署名証明書として使用する証明書を選択します。
  10. [信頼ポリシー] で、[新しい信頼ポリシーを作成する] をクリックしてから、[次へ] をクリックします。
  11. インストール ファイルの場所を要求されたら、Windows Server 2003 R2 Enterprise Edition の製品ディスクを挿入して、[OK] をクリックします。
  12. [Windows コンポーネント ウィザードの完了] ページで、[完了] をクリックします。
  13. TREYRESEARCH\ADFSADMIN として ADFS-ACCOUNT にログオンします。
  14. TREYRESEARCH\ADFSADMIN ユーザー アカウントを使用して、ADFS-ACCOUNT コンピュータに対して、手順 2 ～ 12 を繰り返します。

フェデレーション サービス役割サービスを Windows Server 2008 Enterprise ベースのサーバーにインストールする

ADFS-RESOURCE および ADFS-ACCOUNT で Windows Server 2008 Enterprise を実行している場合は、次の手順に従い、サーバー マネージャを使用してフェデレーション サービス役割サービスを追加します。

フェデレーション サービス役割サービスを Windows Server 2008 Enterprise ベースのコンピュータに追加するには

  1. CPANDL\ADFSADMIN アカウントを使用して ADFS-RESOURCE にログオンします。
  2. [スタート] ボタンをクリックし、[管理ツール] をポイントして、[サーバー マネージャ] をクリックします。
  3. [ユーザー アカウント制御] ダイアログ ボックスが表示された場合、このボックスに希望する動作が表示されていることを確認し、[継続] をクリックします。
  4. [役割の追加] をクリックします。
  5. [開始する前に] ページで、[次へ] をクリックします。
  6. [サーバーの役割の選択] ページで、[Active Directory Rights Management サービス] チェック ボックスをオンにします。
  7. [次へ] をクリックします。
  8. [AD FS について] ページで、[次へ] をクリックします。
  9. [役割サービスの選択] ページで、[フェデレーション サービス] チェック ボックスをオンにします。追加の役割サービスをインストールすることを求めるメッセージが表示されたら、[必要な役割サービスを追加] をクリックして、[次へ] をクリックします。
  10. [SSL 暗号化の既存の証明書を選択する] をクリックし、適切な証明書をクリックして、[次へ] をクリックします。
  11. [トークン署名証明書を選択] ページで、[既存のトークン署名証明書を選択する] をクリックし、適切な証明書をクリックして、[次へ] をクリックします。
  12. [新しい信頼ポリシーを作成する] をクリックして、[次へ] をクリックします。
  13. [Web サーバー (IIS) について] ページの内容を読み、[次へ] をクリックします。
  14. Web サーバーの既定のチェック ボックスの選択内容をそのままにして、[次へ] をクリックします。
  15. [インストール] をクリックします。
  16. インストールが完了したら、[閉じる] をクリックします。
  17. TREYRESEARCH\ADFSADMIN として ADFS-ACCOUNT にログオンします。
  18. TREYRESEARCH\ADFSADMIN ユーザー アカウントを使用して、ADFS-ACCOUNT コンピュータに対して、手順 2 ～ 16 を繰り返します。

AD RMS と連携して動作する ADFS-ACCOUNT を構成する

ADFS-ACCOUNT コンピュータは TREYRESEARCH ドメインのメンバで、AD RMS 要求を CPANDL ドメインに転送します。ここでは、AD FS 信頼ポリシーを構成し、Active Directory の ProxyAddresses 属性に対するカスタム要求を作成し、Active Directory アカウント ストアを追加し、リソース パートナーを追加および構成します。
最初に、TREYRESEARCH ドメイン内に、フェデレーション サービスに対する ADFS-ACCOUNT コンピュータの信頼ポリシーを構成します。

AD FS アカウント パートナー (ADFS-ACCOUNT) 上で信頼ポリシーを構成するには

  1. TREYRESEARCH\ADFSADMIN アカウントまたはローカルの Administrators グループに属する別のユーザー アカウントを使用して、ADFS-ACCOUNT にログオンします。
  2. [スタート] ボタンをクリックし、[管理ツール] をポイントして、[Active Directory フェデレーション サービス] をクリックします。
  3. [フェデレーション サービス] を展開し、[信頼ポリシー] 右クリックして、[プロパティ] をクリックします。
  4. [フェデレーション サービスの URI] ボックスに、「urn:federation:treyresearch.net」と入力します。
    noteメモ
    フェデレーション サービスの URI 値では、大文字と小文字が区別されます。

  5. [フェデレーション サービス エンドポイントの URL] ボックスに、"https://ADFS-ACCOUNT.treyresearch.net/adfs/ls/" と表示されていることを確認してください。
  6. [表示名] タブで、[この信頼ポリシーの表示名] に「Trey Research」と入力して、[OK] をクリックします。
次に、AD RMS で使用されるカスタム要求を作成します。

カスタム要求を作成するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[自分の組織] の順に展開します。
  2. [組織の要求] を右クリックし、[新規作成] をポイントして、[組織の要求] をクリックします。
  3. [要求の名前] ボックスに、「ProxyAddresses」と入力します。
    noteメモ
    要求の名前の値では、大文字と小文字が区別されます。

  4. [カスタムの要求] をクリックして、[OK] をクリックします。
Important重要
フェデレーションの信頼を介したプロキシ アドレスの使用を許可する場合は、十分に注意してください。フェデレーションを介したプロキシ アドレスを許可すると、悪意のあるユーザーが承認されたユーザーの資格情報を偽装し、このユーザーの権利で保護されているコンテンツにアクセスする可能性があります。フェデレーションを介したプロキシ アドレスを組織が必要とする場合は、要求変換モジュールを実装してください。このモジュールは、フェデレーション ユーザーからのプロキシ アドレスを調べ、要求元のフォレストと一致しているかどうかを確認します。Active Directory Rights Management サービス コンソールでは、フェデレーション ユーザーからのプロキシ アドレスを許可するオプションは既定でオフになっています。

次に、TREYRESEARCH ドメインのフェデレーション サービスに Active Directory アカウント ストアを追加します。

ADFS-ACCOUNT に Active Directory アカウント ストアを追加するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[自分の組織] の順に展開します。
  2. [アカウント ストア] を右クリックし、[新規作成] をポイントして、[アカウント ストア] をクリックします。
  3. [アカウント ストア追加のウィザードの開始] ページで、[次へ] をクリックします。
  4. [アカウント ストアの種類] ページで、[Active Directory ドメイン サービス] をクリックして、[次へ] をクリックします。
    noteメモ
    Windows Server 2003 R2 Enterprise Edition では、このオプションは [Active Directory] になっています。

  5. [このアカウント ストアを有効にする] ページで、[このアカウント ストアを有効にする] チェック ボックスをオンにして、[次へ] をクリックします。
  6. [アカウント ストア追加のウィザードの完了] ページで、[完了] をクリックします。
  7. 組織の要求の [電子メール] をダブルクリックし、[有効にする] チェック ボックスをオンにし、[LDAP 属性] ボックスに「mail」と入力して、[OK] をクリックします。
  8. [Active Directory] アカウント ストアを右クリックし、[新規作成] をポイントして、[カスタムの要求の抽出] をクリックします。
  9. [属性] ボックスに「ProxyAddresses」と入力して、[OK] をクリックします。
最後に、TREYRESEARCH ドメインのフェデレーション サービスにリソース パートナーを追加します。

TREYRESEARCH ドメインにリソース パートナーを追加するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[パートナーの組織] の順に展開します。
  2. [リソース パートナー] を右クリックし、[新規作成] をポイントして、[リソース パートナー] をクリックします。
  3. [リソース パートナー追加のウィザードの開始] ページで、[次へ] をクリックします。
  4. [ポリシー ファイルのインポート] ページで、[いいえ] をクリックして、[次へ] をクリックします。
  5. [リソース パートナーの詳細] ページで、[表示名] ボックスに「CP&L Enterprises」と入力します。
  6. [フェデレーション サービスの URI] ボックスに、「urn:federation:cpandl.com」と入力します。
    noteメモ
    フェデレーション サービスの URI 値では、大文字と小文字が区別されます。

  7. [フェデレーション サービス エンドポイントの URL] ボックスに、「https://adfs-resource.cpandl.com/adfs/ls/」と入力して、[次へ] をクリックします。
  8. [フェデレーションのシナリオ] ページで、[フェデレーション Web SSO] をクリックして、[次へ] をクリックします。
  9. [UPN 要求] および [電子メールの要求] チェック ボックスをオンにして、[次へ] をクリックします。
  10. [すべての UPN のサフィックスを変更しないで渡す] をクリックして、[次へ] をクリックします。
  11. [すべての電子メールのサフィックスを変更しないで渡す] をクリックして、[次へ] をクリックします。
  12. [このリソース パートナーを有効にする] チェック ボックスがオンになっていることを確認してから、[次へ] をクリックします。
  13. [完了] をクリックします。
  14. 新しく作成した CP&L Enterprises リソース パートナーを右クリックし、[新規作成] をポイントして、[出力方向のカスタム要求のマッピング] をクリックします。
  15. [出力方向のカスタム要求の名前] ボックスに「ProxyAddresses」と入力して、[OK] をクリックします。
  16. Active Directory フェデレーション サービス コンソールを閉じます。

AD RMS と連携して動作する ADFS-RESOURCE を構成する

ADFS-RESOURCE コンピュータは CPANDL ドメインのメンバで、TREYRESEARCH ドメインからの AD RMS 要求を受け取ります。ここでは、AD FS 信頼ポリシーを構成し、Active Directory の ProxyAddresses 属性に対するカスタム要求を作成し、Active Directory アカウント ストアを追加し、AD RMS を要求に対応するアプリケーションとして追加し、リソース パートナーを構成します。
最初に、CPANDL ドメイン内に、フェデレーション サービスに対する ADFS-RESOURCE コンピュータの信頼ポリシーを構成します。

AD FS リソース パートナー (ADFS-RESOURCE) 上で信頼ポリシーを構成するには

  1. CPANDL\ADFSADMIN アカウントまたはローカルの Administrators グループに属する別のユーザー アカウントを使用して、ADFS-RESOURCE にログオンします。
  2. [スタート] ボタンをクリックし、[管理ツール] をポイントして、[Active Directory フェデレーション サービス] をクリックします。
  3. [フェデレーション サービス] を展開し、[信頼ポリシー] 右クリックして、[プロパティ] をクリックします。
  4. [フェデレーション サービスの URI] ボックスに、「urn:federation:cpandl.com」と入力します。
    noteメモ
    フェデレーション サービスの URI 値では、大文字と小文字が区別されます。

  5. [フェデレーション サービス エンドポイントの URL] ボックスに、"https://ADFS-RESOURCE.cpandl.com/adfs/ls/" と表示されていることを確認してください。
  6. [表示名] タブで、[この信頼ポリシーの表示名] に「CP&L Enterprises」と入力して、[OK] をクリックします。
次に、AD RMS で使用されるカスタム要求を作成します。

カスタム要求を作成するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[自分の組織] の順に展開します。
  2. [組織の要求] を右クリックし、[新規作成] をポイントして、[組織の要求] をクリックします。
  3. [要求の名前] ボックスに、「ProxyAddresses」と入力します。
    noteメモ
    要求の名前の値では、大文字と小文字が区別されます。

  4. [カスタムの要求] をクリックして、[OK] をクリックします。
次に、CPANDL ドメインのフェデレーション サービスに Active Directory アカウント ストアを追加します。

ADFS-RESOURCE に Active Directory アカウント ストアを追加するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[自分の組織] の順に展開します。
  2. [アカウント ストア] を右クリックし、[新規作成] をポイントして、[アカウント ストア] をクリックします。
  3. [アカウント ストア追加のウィザードの開始] ページで、[次へ] をクリックします。
  4. [アカウント ストアの種類] ページで、[Active Directory ドメイン サービス] をクリックして、[次へ] をクリックします。
    noteメモ
    Windows Server 2003 R2 Enterprise Edition では、このオプションは [Active Directory] になっています。

  5. [このアカウント ストアを有効にする] ページで、[このアカウント ストアを有効にする] チェック ボックスをオンにして、[次へ] をクリックします。
  6. [アカウント ストア追加のウィザードの完了] ページで、[完了] をクリックします。
  7. 組織の要求の [電子メール] をダブルクリックし、[有効にする] チェック ボックスをオンにし、[LDAP 属性] ボックスに「mail」と入力して、[OK] をクリックします。
  8. [Active Directory] アカウント ストアを右クリックし、[新規作成] をポイントして、[カスタムの要求の抽出] をクリックします。
  9. [属性] ボックスに「ProxyAddresses」と入力して、[OK] をクリックします。
次に、要求に対応するアプリケーションとして AD RMS 証明パイプラインを追加します。

要求に対応するアプリケーションとして AD RMS 証明パイプラインを追加するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[自分の組織] の順に展開します。
  2. [アプリケーション] を右クリックし、[新規作成] をポイントして、[アプリケーション] をクリックします。
  3. [アプリケーションの追加ウィザードの開始] ページで、[次へ] をクリックします。
  4. [アプリケーションの種類] ページで、[要求に対応するアプリケーション] をクリックし、[次へ] をクリックします。
  5. [アプリケーション表示名] ボックスに、「AD RMS Certification」と入力します。
  6. [アプリケーションの URL] ボックスに、「https://adrms-srv.cpandl.com/_wmcs/certificationexternal/」と入力して、「次へ] をクリックします。
    noteメモ
    アプリケーションの URL では大文字と小文字が区別され、AD RMS エクストラネット クラスタの名前は、ADRMS-SRV コンピュータが返す URL 値と正確に一致する必要があります。値が一致しない場合、AD FS 機能は動作しません。

  7. [受け取る ID 要求] ページで、[ユーザー プリンシパル名 (UPN)] および [電子メール] チェック ボックスをオンにして、[次へ] をクリックします。
  8. [このアプリケーションを有効にする] ページで、[このアプリケーションを有効にする] チェック ボックスをオンにして、[次へ] をクリックします。
  9. [アプリケーションの追加ウィザードの完了] ページで、[完了] をクリックします。
  10. 作業ウィンドウで、[ProxyAddresses] をダブルクリックし、[有効にする] チェック ボックスをオンにして、[OK] をクリックします。
次の手順を使用して、要求に対応するアプリケーションとして AD RMS ライセンス パイプラインを追加します。

要求に対応するアプリケーションとして AD RMS ライセンス パイプラインを追加するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[自分の組織] の順に展開します。
  2. [アプリケーション] を右クリックし、[新規作成] をポイントして、[アプリケーション] をクリックします。
  3. [アプリケーションの追加ウィザードの開始] ページで、[次へ] をクリックします。
  4. [アプリケーションの種類] ページで、[要求に対応するアプリケーション] をクリックして、[次へ] をクリックします。
  5. [アプリケーション表示名] ボックスに、「AD RMS Licensing」と入力します。
  6. [アプリケーションの URL] ボックスに、「https://adrms-srv.cpandl.com/_wmcs/licensingexternal/」と入力して、「次へ] をクリックします。
    noteメモ
    アプリケーションの URL では大文字と小文字が区別され、URL 内のコンピュータ名は、ADRMS-SRV コンピュータが返す URL 値と正確に一致する必要があります。値が一致しない場合、AD FS 機能は動作しません。

  7. [受け取る ID 要求] ページで、[ユーザー プリンシパル名 (UPN)] および [電子メール] チェック ボックスをオンにして、[次へ] をクリックします。
  8. [このアプリケーションを有効にする] ページで、[このアプリケーションを有効にする] チェック ボックスをオンにして、[次へ] をクリックします。
  9. [アプリケーションの追加ウィザードの完了] ページで、[完了] をクリックします。
  10. 作業ウィンドウで、[ProxyAddresses] をダブルクリックし、[有効にする] チェック ボックスをオンにして、[OK] をクリックします。
次に、ADFS-RESOURCE にアカウント パートナーを追加します。このアカウント パートナーは、TREYRESEARCH ドメイン内の ADFS-ACCOUNT コンピュータから要求を受け取ります。

ADFS-RESOURCE にアカウント パートナーを追加するには

  1. Active Directory フェデレーション サービス コンソールで、[フェデレーション サービス]、[信頼ポリシー]、[パートナーの組織] の順に展開します。
  2. [アカウント パートナー] を右クリックし、[新規作成] をクリックして、[アカウント パートナー] をクリックします。
  3. [アカウント パートナー追加のウィザードの開始] ページで、[次へ] をクリックします。
  4. [ポリシー ファイルのインポート] ページで、[いいえ] をクリックして [次へ] をクリックします。
  5. [アカウント パートナーの詳細] ページで、[表示名] ボックスに「Trey Research」と入力します。
  6. [フェデレーション サービスの URI] ボックスに、「urn:federation:treyresearch.net」と入力します。
  7. [フェデレーション サービス エンドポイントの URL] ボックスに、「https://adfs-account.treyresearch.net/adfs/ls/」と入力して、[次へ] をクリックします。
  8. [アカウント パートナーの検証証明書] ページで、トークン署名証明書が格納されている場所へのパスを入力して、[次へ] をクリックします。
  9. [フェデレーション Web SSO] をクリックして、[次へ] をクリックします。
  10. [UPN 要求] および [電子メールの要求] チェック ボックスをオンにして、[次へ] をクリックします。
  11. [受け取る UPN のサフィックス] ページで、「treyresearch.net」と入力し、[追加] をクリックして、[次へ] をクリックします。
  12. [受け取る電子メールのサフィックス] ページで、「treyresearch.net」と入力し、[追加] をクリックして、[次へ] をクリックします。
  13. [このアカウント パートナーを有効にする] チェック ボックスがオンになっていることを確認してから、[次へ] をクリックします。
  14. [完了] をクリックします。
  15. [Trey Research] アカウント パートナーを右クリックし、[新規作成] をポイントして、[入力方向のカスタム要求のマッピング] をクリックします。
  16. [入力方向のカスタム要求の名前] ボックスに「ProxyAddresses」と入力して、[OK] をクリックします。
  17. Active Directory フェデレーション サービス コンソールを閉じます。
投稿者 時刻: 0 件のコメント:
ラベル:

2013年7月28日日曜日

カゴヤVPSのcent os6サーバにてWeb サーバーの設定手順

  1. rootアカウントでログインします。
    [root@v0000 ~]#

    プロンプト表示に続けて次のコマンドを入力します。
    [root@v0000 ~]# vi /etc/httpd/conf/httpd.conf
    • ※ 「vi」と「/etc/httpd/conf/httpd.conf」の間はスペースが入ります。

    入力したらキーボードの Enterキーを押します。

  2. viエディタで[httpd.conf]の内容が表示されます。

    #
    # This is the main Apache server configuration file. It contains the
    # configuration directives that give the server its instructions.
    # See <URL:http://httpd.apache.org/docs/2.2/> for detailed information.
    # In particular, see
    # <URL:http://httpd.apache.org/docs/2.2/mod/directives.html>
    # for a discussion of each configuration directive.
    #
    #
    # Do NOT simply read the instructions in here without understanding
    # what they do. They're here only as hints or reminders. If you are unsure
    # consult the online docs. You have been warned.
    #
    # The configuration directives are grouped into three basic sections:
    #  1. Directives that control the operation of the Apache server process as a
    #     whole (the 'global environment').
    #  2. Directives that define the parameters of the 'main' or 'default' server,
    #     which responds to requests that aren't handled by a virtual host.
    #     These directives also provide default values for the settings
    #     of all virtual hosts.
    #  3. Settings for virtual hosts, which allow Web requests to be sent to
    #     different IP addresses or hostnames and have them handled by the
    #     same Apache server process.

    httpd.conf を編集することで、Apache の各種設定を行います。

  3. 例えば、「ServerAdmin root@localhost」という記述を探します。
    # ServerAdmin: Your address, where problems with the server should be
    # e-mailed. This address appears on some server-generated pages, such
    # as error documents. e.g. admin@your-domain.com
    #
    ServerAdmin root@localhost

    ServerAdmin ディレクティブでは、サーバー管理者のメールアドレスを設定します。
    ServerAdmin ディレクティブで設定したメールアドレスは、Webサイトでエラーメッセージが表示されるときなどに、問い合わせ先メールアドレスとして表示することができますが、メールアドレスを表示することで大量の迷惑メールが届くことが懸念されます。
    このため、ServerSignature ディレクティブをデフォルトの On から EMail に変更しなければ表示されることはありません。
    ■参考URL: Apache HTTP サーバ ドキュメント - ServerAdmin ディレクティブ
        http://httpd.apache.org/docs/2.2/ja/mod/core.html#serveradmin

    キーボードの「i」キーを押し、viエディタを入力モードにすると内容を編集できます。
    サーバー管理者のメールアドレスが、「webmaster@example.com」の場合、
    「ServerAdmin root@localhost」という記述を下記の通り編集します。
    # ServerAdmin: Your address, where problems with the server should be
    # e-mailed. This address appears on some server-generated pages, such
    # as error documents. e.g. admin@your-domain.com
    #
    ServerAdmin webmaster@example.com

    • root@localhost の部分を連絡先メールアドレスに書き換えます。


  4. 「#ServerName www.example.com:80」という記述を探します。
    # ServerName gives the name and port that the server uses to identify itself.
    # This can often be determined automatically, but we recommend you specify
    # it explicitly to prevent problems during startup.
    #
    # If this is not set to valid DNS name for your host, server-generated
    # redirections will not work. See also the UseCanonicalName directive.
    #
    # If your host doesn't have a registered DNS name, enter its IP address here.
    # You will have to access it by its address anyway, and this will make
    # redirections work in a sensible way.
    #
    #ServerName www.example.com:80

    ServerName ディレクティブでは、Web サーバーのホスト名を設定します。
    ServerName ディレクティブで設定したホスト名は、エラーメッセージなどで表示されたり、リダイレクトするときの URL にも利用されます。
    ■参考URL: Apache HTTP サーバ ドキュメント - ServerName ディレクティブ
        http://httpd.apache.org/docs/2.2/ja/mod/core.html#servername

    サーバーのホスト名を設定するには、「#ServerName www.example.com:80」という記述を下記の通り編集します。
    # ServerName gives the name and port that the server uses to identify itself.
    # This can often be determined automatically, but we recommend you specify
    # it explicitly to prevent problems during startup.
    #
    # If this is not set to valid DNS name for your host, server-generated
    # redirections will not work. See also the UseCanonicalName directive.
    #
    # If your host doesn't have a registered DNS name, enter its IP address here.
    # You will have to access it by its address anyway, and this will make
    # redirections work in a sensible way.
    #
    ServerName www.example.com:80

    • 行頭の「#」を削除します。
    • www.example.com の部分を Webサイトの URL に使用するホスト名に書き換えます。

    ここで設定するホスト名は、DNSサーバーに問い合わせることでホスト名からIPアドレスが名前解決できる必要があります。


  5. 「DocumentRoot "/var/www/html"」という記述を探します。
    # DocumentRoot: The directory out of which you will serve your
    # documents. By default, all requests are taken from this directory, but
    # symbolic links and aliases may be used to point to other locations.
    #
    DocumentRoot "/var/www/html"

    DocumentRoot ディレクティブでは、Webサイトのコンテンツ(HTMLファイルなど)を格納するディレクトリ(ドキュメントルート)を設定します。
    このマニュアルでは、初期設定のまま変更しませんが、必要に応じてご変更ください。
    「<Directory "/var/www/html">」という記述を探します。
    # This should be changed to whatever you set DocumentRoot to.
    #
    <Directory "/var/www/html">

    DocumentRoot ディレクティブでドキュメントルートを変更した場合は、ドキュメントルートに合わせて書き換えます。
    このマニュアルでは、初期設定のまま変更しませんが、必要に応じてご変更ください。
    DocumentRoot ディレクティブで設定したディレクトリに「index.html」を配置した場合、Webブラウザで ServerName ディレクティブで設定したホスト名(このマニュアルの例では、http://www.example.com/)にアクセスすると表示されます。
    ■参考URL: Apache HTTP サーバ ドキュメント - DocumentRoot ディレクティブ
        http://httpd.apache.org/docs/2.2/ja/mod/core.html#documentroot


  6. httpd.conf の編集が完了したら、キーボードの Escキーを押し、viエディタをコマンドモードに戻します。
    編集内容を保存するため、次のコマンドを入力します。
    :w

    入力したらキーボードの Enterキーを押します。

  7. viエディタを終了するため、次のコマンドを入力します。
    :q

    入力したらキーボードの Enterキーを押します。

  8. 設定ファイルの編集内容を反映させるため、httpdを再起動します。
    プロンプト表示に続けて次のコマンドを入力します。
    [root@v0000 ~]# vi /etc/httpd/conf/httpd.conf
    [root@v0000 ~]# /etc/rc.d/init.d/httpd restart
    • ※ 「/etc/rc.d/init.d/httpd」と「restart」の間はスペースが入ります。

    入力したらキーボードの Enterキーを押します。

  9. httpdの再起動が完了すると、下記のように表示されます。
    [root@v0000 ~]# vi /etc/httpd/conf/httpd.conf
    [root@v0000 ~]# /etc/rc.d/init.d/httpd restart
    httpd を停止中:                                            [  OK  ]
    httpd を起動中:                                            [  OK  ]
    [root@v0000 ~]#

    「httpd を起動中: [OK]」と表示されれば、正しく再読み込みできています。

  10. Webブラウザで、設定したホスト名(このマニュアルの例では、http://www.example.com/)にアクセスします。

    Apache の初期画面が表示されます。
投稿者 時刻: 0 件のコメント:
ラベル:

カゴヤVPSのcent os6サーバにてバーチャルホストの設定手順

1つのIPアドレスで、複数のサイトを別々のホスト名で公開するには、名前ベースのバーチャルホストの設定が必要です。
この手順では1つのIPアドレスで、www.example.com と www.example.co.jp の2つのサイトを公開する場合を例にご案内します。
  1. rootアカウントでログインします。
    [root@v0000 ~]#

    プロンプト表示に続けて次のコマンドを入力します。
    [root@v0000 ~]# vi /etc/httpd/conf/httpd.conf
    • ※ 「vi」と「/etc/httpd/conf/httpd.conf」の間はスペースが入ります。

    入力したらキーボードの Enterキーを押します。

  2. viエディタで[httpd.conf]の内容が表示されます。
    #
    # This is the main Apache server configuration file. It contains the
    # configuration directives that give the server its instructions.
    # See <URL:http://httpd.apache.org/docs/2.2/> for detailed information.
    # In particular, see
    # <URL:http://httpd.apache.org/docs/2.2/mod/directives.html>
    # for a discussion of each configuration directive.
    #
    #
    # Do NOT simply read the instructions in here without understanding
    # what they do. They're here only as hints or reminders. If you are unsure
    # consult the online docs. You have been warned.
    #
    # The configuration directives are grouped into three basic sections:
    #  1. Directives that control the operation of the Apache server process as a
    #     whole (the 'global environment').
    #  2. Directives that define the parameters of the 'main' or 'default' server,
    #     which responds to requests that aren't handled by a virtual host.
    #     These directives also provide default values for the settings
    #     of all virtual hosts.
    #  3. Settings for virtual hosts, which allow Web requests to be sent to
    #     different IP addresses or hostnames and have them handled by the
    #     same Apache server process.

    ファイルの最終行に移動するため、次のコマンドを入力します。
    :$

    入力したらキーボードの Enterキーを押します。

  3. [httpd.conf]の最終行に移動します。
    #
    # Use name-based virtual hosting.
    #
    #NameVirtualHost *:80
    #
    # NOTE: NameVirtualHost cannot be used without a port specifier
    # (e.g. :80) if mod_ssl is being used, due to the nature of the
    # SSL protocol.
    #

    #
    # VirtualHost example:
    # Almost any Apache directive may go into a VirtualHost container.
    # The first VirtualHost section is used for requests without a known
    # server name.
    #
    #<VirtualHost *:80>
    #    ServerAdmin webmaster@dummy-host.example.com
    #    DocumentRoot /www/docs/dummy-host.example.com
    #    ServerName dummy-host.example.com
    #    ErrorLog logs/dummy-host.example.com-error_log
    #    CustomLog logs/dummy-host.example.com-access_log common
    #</VirtualHost>

    「#NameVirtualHost *:80」という記述を探します。
    NameVirtualHost ディレクティブでは、名前ベースのバーチャルホストを利用してリクエストを受け付けるサーバのIPアドレスとポート番号を設定します。
    ■参考URL: Apache HTTP サーバ ドキュメント - NameVirtualHost ディレクティブ
        http://httpd.apache.org/docs/2.2/ja/mod/core.html#NameVirtualHost

    キーボードの「i」キーを押し、viエディタを入力モードにすると内容を編集できます。
    1つのIPアドレスと特定のポート番号(通常は80番)で複数サイトのアクセスを受け付ける場合、
    「#NameVirtualHost *:80」という記述を下記の通り編集します。
    # Use name-based virtual hosting.
    #
    NameVirtualHost *:80

    • 行頭の「#」を削除します。


  4. [httpd.conf]の最下部にサイトごとに、バーチャルホストを設定します。
    www.example.com と www.example.co.jp の2つのサイトのバーチャルホストを設定する場合は、下記の記述を追記します。
    #    ErrorLog logs/dummy-host.example.com-error_log
    #    CustomLog logs/dummy-host.example.com-access_log common
    #</VirtualHost>
    <VirtualHost *:80>
        ServerName www.example.com
        DocumentRoot /var/www/html
    </VirtualHost>
    <VirtualHost *:80>
        ServerName www.example.co.jp
        DocumentRoot /var/www/html/corp
    </VirtualHost>

    既にメインホストでサイトを公開していて、バーチャルホストを追加する場合、メインホストもバーチャルホストとして設定しなおす必要があります。
    ServerName ディレクティブとDocumentRoot ディレクティブで設定していたメインホストの設定内容と同じ内容を、バーチャルホストに設定します。

    • ホスト名ごとに、<VirtualHost> ブロックを作成します。
    • <VirtualHost> ディレクティブの引数は NameVirtualHost ディレクティブの引数と同じにします。
    • ホスト名ごとに ServerName ディレクティブを設定します。
    • ホスト名ごとに DocumentRoot ディレクティブを設定します。
    • ※ <VirtualHost> コンテナの中に他のディレクティブ(ErrorLog、CustomLog など)を追記することで、バーチャルホストごとに各種設定をすることもできます。

    ここで設定するホスト名は、DNSサーバーに問い合わせることでホスト名からIPアドレスが名前解決できる必要があります。

  5. httpd.conf の編集が完了したら、キーボードの Escキーを押し、viエディタをコマンドモードに戻します。
    編集内容を保存するため、次のコマンドを入力します。
    :w

    入力したらキーボードの Enterキーを押します。

  6. viエディタを終了するため、次のコマンドを入力します。
    :q

    入力したらキーボードの Enterキーを押します。

  7. 設定ファイルの編集内容を反映させるため、httpdを再起動します。
    プロンプト表示に続けて次のコマンドを入力します。
    [root@v0000 ~]# vi /etc/httpd/conf/httpd.conf
    [root@v0000 ~]# /etc/rc.d/init.d/httpd restart
    • ※ 「/etc/rc.d/init.d/httpd」と「restart」の間はスペースが入ります。

    入力したらキーボードの Enterキーを押します。

  8. httpdの再起動が完了すると、下記のように表示されます。
    [root@v0000 ~]# vi /etc/httpd/conf/httpd.conf
    [root@v0000 ~]# /etc/rc.d/init.d/httpd restart
    httpd を停止中:                                            [  OK  ]
    httpd を起動中:                                            [  OK  ]
    [root@v0000 ~]#

    「httpd を起動中: [OK]」と表示されれば、正しく再読み込みできています。
投稿者 時刻: 0 件のコメント:
ラベル:

カゴヤVPSのcent os6サーバにsendmailをインストールする手順

1．yum コマンドで sendmail-cf をインストールする
yum -y install sendmail-cf

2．sendmail.mc のバックアップを取る
cp /etc/mail/sendmail.mc /etc/mail/sendmail.mc.bak

3．sendmail.mc を編集
vi /etc/mail/sendmail.mc

変更(外部からの受信を許可)
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
↓
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl

変更(送信元アドレスの@以降をドメイン名にする)
dnl MASQUERADE_AS(`mydomain.com')dnl
↓MASQUERADE_AS(`(your domain)')dnl

変更(エンベロープFromも書き替える)
dnl FEATURE(masquerade_envelope)dnl
↓
FEATURE(masquerade_envelope)dnl

変更(送信元がrootの場合も書き替える)
EXPOSED_USER(`root')dnl
↓
dnl EXPOSED_USER(`root')dnl

行頭のdnlを削除(SMTP-Auth有効化)
dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')
↓
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')

最終行へ追加(受信メールサイズを10MB=10*1024*1024に制限)
define(`confMAX_MESSAGE_SIZE',`10485760')

4．sendmail.mcよりsendmail.cf作成
m4 /usr/share/sendmail-cf/m4/cf.m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

5．ホスト名を記述
vi /etc/mail/local-host-names
yourhostname

6．sendmailを再起動
/etc/rc.d/init.d/sendmail restart
投稿者 時刻: 0 件のコメント:
ラベル:

2013年7月26日金曜日

フォワーダーを使用するようにDNS サーバーを構成する(Configure a DNS Server to Use Forwarders )

フォワーダーとは、ネットワーク上にあるドメイン ネーム システム (DNS) サーバーの一種で、そのネットワーク外部の DNS サーバーに外部 DNS 名に関する DNS クエリを転送するために使用します。条件付きフォワーダーを使用して特定のドメイン名に基づいてクエリを転送するようにサーバーを構成することもできます。
ネットワーク内の DNS サーバーにローカルで解決できないクエリがあった際に、ネットワーク上の特定の DNS サーバーに転送するように設定すると、その DNS サーバーがフォワーダーとして指定されます。フォワーダーを使用することにより、インターネット上の名前など、ネットワーク外部にある名前の名前解決を行い、ネットワーク内のコンピューターによる名前解決の効率を上げることができます。フォワーダーと条件付きフォワーダーの詳細については、「フォワーダーとは」を参照してください。
この手順を実行するには、Administrators グループのメンバーシップ、またはそれと同等のメンバーシップが最低限必要となります。 適切なアカウントおよびグループ メンバーシップの使用の詳細については、http://go.microsoft.com/fwlink/?LinkId=83477 をご確認ください。

フォワーダーを使用するように DNS サーバーを構成する


Windows インターフェイスを使用してフォワーダーを使用するように DNS サーバーを構成するには
  1. DNS マネージャーを開きます。
  2. コンソール ツリーで、該当する DNS サーバーをクリックします。
    場所 :
    • DNS\該当する DNS サーバー
  3. [操作] メニューの [プロパティ] をクリックします。
  4. [フォワーダー] タブの [DNS ドメイン] ボックスで、ドメイン名をクリックします。
  5. [選択されたドメイン フォワーダーの IP アドレスの一覧] にフォワーダーの IP アドレスを入力し、[追加] をクリックします。

その他の考慮事項

  • DNS マネージャーを開くには、[スタート] ボタンをクリックして [管理ツール] をポイントし、[DNS] をクリックします。
  • 新しいドメイン名を作成するには、[新規作成] をクリックして、[DNS ドメイン] にドメイン名を入力します。
  • 条件付きフォワーダーを指定するときは、IP アドレスを入力する前に、DNS ドメイン名を選択します。
  • 既定では、DNS サーバーは、1 つのフォワーダー IP アドレスからの応答を 5 秒待ってから、別のフォワーダー IP アドレスを試みます。DNS サーバーの待ち時間 (秒数) は、[クエリ転送のタイム アウト (秒)] で変更できます。すべてのフォワーダーの試みが終了すると、サーバーは標準の再帰を実行します。
  • フォワーダーのみを使用し、フォワーダーが失敗しても再帰を実行しないように DNS サーバーを構成する場合は、[このドメインに再帰を使わない] チェック ボックスをオンにします。

    DNS サーバーでは、どのようなクエリに対しても再帰が実行されないように、再帰を無効にできます。DNS サーバーで再帰を無効にすると、その DNS サーバーではフォワーダーを使用できなくなります。
  • フォワーダーは信頼性があり、地理的に近い場所に設置されているサーバーであるため、DNS サーバーのフォワーダー一覧には、1 つのフォワーダーの IP アドレスを 2 回以上入力しないでください。あるフォワーダーを優先する場合は、そのフォワーダーを一連のフォワーダー IP アドレスの先頭に配置します。
  • DNS サーバーがドメイン名のプライマリ ゾーン、セカンダリ ゾーン、またはスタブ ゾーンをホストしている場合、条件付きフォワーダー内でそのドメイン名を使用することはできません。たとえば、DNS サーバーがドメイン名 corp.contoso.com に対して権限がある (そのドメイン名のプライマリ ゾーンをホストしている) 場合、corp.contoso.com に対して条件付きフォワーダーを使用してその DNS サーバーを構成することはできません。
  • フォワーダーに関する一般的な問題は、フォワーダーの過剰な使用を避けるよう DNS サーバーを構成することで回避できます。

コマンド ラインを使用してフォワーダーを使用するように DNS サーバーを構成するには
  1. コマンド プロンプトを開きます。
  2. 次のコマンドを入力して、Enter キーを押します。
    コピー
    dnscmd <ServerName> /ResetForwarders <MasterIPaddress ...> [/TimeOut <Time>] [/Slave]

パラメーター説明
dnscmdDNS サーバーの管理用コマンド ライン ツールの名前を指定します。
<サーバー名>必須です。DNS サーバーの DNS ホスト名を指定します。DNS サーバーの IP アドレスを入力することもできます。ローカル コンピューター上の DNS サーバーを指定するには、ピリオド (.) を入力することもできます。
/ResetForwarders必須です。フォワーダーを構成します。
<マスター IP アドレス...>必須です。クエリの転送先となる DNS サーバーの IP アドレスを 1 つ以上、スペースで区切った一覧として指定します。スペースで区切られた IP アドレス一覧を指定できます。
/TimeOutタイムアウト設定を指定します。タイムアウト設定は、失敗した転送クエリがタイムアウトになるまでの秒数です。
<時間>/TimeOut パラメーターの値を指定します。値は秒単位で指定します。既定のタイムアウトは 5 秒です。
/Slaveゾーン名で指定されたドメイン名についてクエリを実行する場合に、DNS サーバーが再帰を使用するかどうかを指定します。
このコマンドの完全な構文を表示するには、コマンド プロンプトで次のように入力し、Enter キーを押します。
コピー
dnscmd /ResetForwarders /help

その他の考慮事項

  • 高度なコマンド プロンプト ウィンドウを開くには、[スタート]、[すべてのプログラム]、[アクセサリ] の順にクリックし、[コマンド プロンプト] を右クリックして、[管理者として実行] をクリックします。
  • ゾーンに条件付きフォワーダーを設定するには、次のコマンドを使用します。

    コピー
    dnscmd <ServerName> /ZoneAdd <ZoneName> /Forwarder <MasterIPaddress ...> [/TimeOut <Time>] [/Slave]
    /ZoneAdd コマンドで、ゾーン名パラメーターで指定したゾーンが追加されます。IP アドレス パラメーターは、DNS サーバーが解決できない DNS クエリを転送する IP アドレスです。/Slave パラメーターは、DNS サーバーを下位サーバーとして設定します。/NoSlave パラメーター (既定の設定) は、DNS サーバーを非下位サーバーとして設定します。したがって、このサーバーは再帰を実行することになります。/Timeout および時間パラメーターについては、前の表を参照してください。
  • 条件付きフォワーダーのみとして追加したゾーンを表示するには、次のコマンドを使用します。

    コピー
    dnscmd <ServerName> /ZoneInfo <ZoneName>
  • 条件付きフォワーダー ドメイン名のフォワーダー IP アドレスをリセットするには、次のコマンドを使用します。

    コピー
    dnscmd <ServerName> /ZoneResetMasters <ZoneName> [/Local] [<ServerIPs>]
    /Local パラメーターは、Active Directory 統合フォワーダーのローカル マスター一覧を設定します。サーバー IP パラメーターは、ゾーンのマスター サーバーの IP アドレスの一覧を指定します。マスター サーバーには、ゾーンのプライマリまたはセカンダリ コピーをホストする DNS サーバーを含めることができますが、1 つのゾーンのコピーをホストする 2 台の DNS サーバーが、互いをマスター サーバーとして使用するような状況で DNS サーバー IP アドレスを含めることはできません。このような構成にすると、転送パスが循環することになります。
  • DNS サーバーがドメイン名のプライマリ ゾーン、セカンダリ ゾーン、またはスタブ ゾーンをホストしている場合、条件付きフォワーダー内でそのドメイン名を使用することはできません。たとえば、DNS サーバーがドメイン名 corp.contoso.com に対して権限がある (そのドメイン名のプライマリ ゾーンをホストしている) 場合、corp.contoso.com に対して条件付きフォワーダーを使用してその DNS サーバーを構成することはできません。
  • フォワーダーに関する一般的な問題は、フォワーダーの過剰な使用を避けるよう DNS サーバーを構成することで回避できます。
投稿者 時刻: 0 件のコメント:
ラベル:

2013年7月25日木曜日

AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide windows 2008

Applies To: Windows Server 2008, Windows Server 2008 R2
This step-by-step guide provides instructions for configuring and applying fine-grained password and account lockout policies for different sets of users in Windows Server® 2008 domains.
In Microsoft® Windows® 2000 and Windows Server 2003 Active Directory domains, you could apply only one password and account lockout policy, which is specified in the domain's Default Domain Policy, to all users in the domain. As a result, if you wanted different password and account lockout settings for different sets of users, you had to either create a password filter or deploy multiple domains. Both options were costly for different reasons.
In Windows Server 2008, you can use fine-grained password policies to specify multiple password policies and apply different password restrictions and account lockout policies to different sets of users within a single domain. For example, to increase the security of privileged accounts, you can apply stricter settings to the privileged accounts and then apply less strict settings to the accounts of other users. Or in some cases, you may want to apply a special password policy for accounts whose passwords are synchronized with other data sources.
To store fine-grained password policies, Windows Server 2008 includes two new object classes in the Active Directory Domain Services (AD DS) schema:
  • Password Settings Container
  • Password Settings
The Password Settings Container (PSC) object class is created by default under the System container in the domain. It stores the Password Settings objects (PSOs) for that domain. You cannot rename, move, or delete this container.
For more information, see Appendix A: Fine-Grained Password and Account Lockout Policy Review.
This guide is intended for the following audiences:
  • Information technology (IT) planners and analysts who are evaluating the product from a technical perspective
  • Enterprise IT planners and designers for organizations
  • Administrator or managers who are responsible for IT security
Before you configure fine-grained password and account lockout policies, define your organizational structure by creating necessary groups and adding or moving users to or between the groups. It is important to consider the unique nature of your organization when you plan for the most efficient use of the fine-grained password and account lockout policies feature. How many different password policies do you need? A typical scenario might include 3 to 10 PSOs and the following password policies:
  • An Administrator password policy with a strict setting (passwords expire, for example, every 14 days)
  • An average user password policy with a setting that is not strict (passwords expire, for example, every 90 days)
  • A service account password policy targeted at service accounts (minimum password length, for example, 32 characters)
Taking advantage of your existing group structure is equally important. What are its characteristics? Do you have existing Administrators or Users groups? The goal is to shape your group structure so that it maps directly to the desired application of the newly defined fine-grained password and account lockout policies.
PSOs cannot be applied to organizational units (OUs) directly. If your users are organized into OUs, consider creating global security groups that contain the users from these OUs and then applying the newly defined fine-grained password and account lockout policies to them. If you move a user from one OU to another, you must update user memberships in the corresponding global security groups.
Applying PSOs directly to global security groups, as opposed to directly to OUs, provides the following benefits:
  • Groups offer better flexibility for managing various sets of users than OUs.
  • Most Active Directory deployments use a systematic group structure to organize their users. Also, by default AD DS in Windows Server 2008 creates various groups for administrative accounts: Domain Admins, Enterprise Admins, Schema Admins, Server Operators, Backup Operators, and others.
  • Group structure offers easier deployment of fine-grained password policies, and you do not have to restructure your organizations’ directories by creating OUs. Modifying an OU hierarchy requires detailed planning, and it increases the risk of introducing unforced errors because it has a significant effect on Group Policy application and access control list (ACL) inheritance.
  • Domain functional level: The domain functional level must be set to Windows Server 2008 or higher.
  • Permissions: By default, only members of the Domain Admins group can create PSOs. Only members of this group have the Create Child and Delete Child permissions on the Password Settings Container object. In addition, only members of the Domain Admins group have Write Property permissions on the PSO by default. Therefore, only members of the Domain Admins group can apply a PSO to a group or user. You do not have to have permissions on the user object or group object to be able to apply a PSO to it. To apply a PSO to the user object or group object, you must have Write permissions on the PSO object.
  • Permissions delegation: You can delegate Read Property permissions on the default security descriptor of the PSO object in the schema to any other group (such as Help desk personnel or a management application) in the domain or forest. This can also prevent a user from seeing his or her password settings in the directory. The user can read the msDS-ResultantPSO or the msDS-PSOApplied attributes, but these attributes display only the distinguished name of the PSO that applies to the user. The user cannot see the settings within that PSO. For more information, see Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies.
  • Applying fine-grained password policies: Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups. They cannot be applied to Computer objects.

    noteNote
    Because fine-grained password policies apply only to user objects, they do not affect password reset intervals for managed service accounts. For more information about managed service accounts, see Service Accounts Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=134695).

  • Password filters: Fine-grained password policies do not interfere with custom password filters that you might use in the same domain. Organizations that have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 can continue to use those password filters to enforce additional restrictions for passwords.
  • Custom PSCs: In addition to the default PSC, administrators can create their own custom PSCs under the System container. However, this action is not recommended because the PSOs that are held in these custom PSCs are not taken into consideration by the Resultant Set of Policy logic.
  • Exceptional PSOs: If you want a certain group member to conform to a policy that is different from the policy that is assigned to the entire group, you can assign the exceptional PSO directly to that particular user. If you apply a PSO directly to the user, it takes precedence over all implicit PSOs that might be linked to it when msDS-ResultantPSO for that user is being determined. Although not recommended as a practice, if two or more exceptional PSOs are applied directly to the user object, the resultant exceptional PSO is determined in the same manner as any PSO:

  • Password complexity errors on Windows XP® client computers: When a user to whom an FGPP applies attempts to change his or her password on a client computer that is running the Windows XP operating system, an error message appears, informing the user that the new password does not conform to the settings that are defined in the domain policy, instead of informing the user that the new password does not conform to the settings that are defined in the FGPP. The following illustration describes this error message:

    e2eda066-d362-4b51-8517-2ca39c9a48a4
The recommended approach is to ignore this error message and to make sure that the new password matches the minimum password length, password complexity, and password history requirements that are defined in the FGPP.
When the group structure of your organization is defined and implemented, you can configure and apply fine-grained password and account lockout policies to users and global security groups. Configuring fine-grained password and account lockout policies involves the following steps:
ImportantImportant
You can also manage fine-grained password and account lockout policies by creating corresponding global security groups for all existing PSOs and by assigning (delegating) appropriate permissions on these global security group objects to the selected users or groups from your organization, for example, support personnel. For more information, see Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies

For more information, see
Source From : http://technet.microsoft.com/en-us/library/cc770842%28v=ws.10%29.aspx
投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)