Skip to content

/ azure-docs.ja-jp

Permalink
Browse files

commit translated contents

@olprod
olprod committed on Jul 17
1 parent 07251a2 commit f7a67ddaf89c36368e8cbe773ddb2c51593c7bfc
Unified Split
Showing 469 changed files with 17,596 additions and 7,013 deletions.
161 articles/active-directory-b2c/aad-sspr-technical-profile.md
View file
@@ -0,0 +1,161 @@
---
title: カスタム ポリシーでの Azure AD SSPR の技術プロファイル
titleSuffix: Azure AD B2C
description: Azure AD B2C での Azure AD SSPR 技術プロファイルのカスタム ポリシー リファレンス。
services: active-directory-b2c
author: msmimart
manager: celestedg
ms.service: active-directory
ms.workload: identity
ms.topic: reference
ms.date: 06/23/2020
ms.author: mimart
ms.subservice: B2C
ms.openlocfilehash: 3e6fcf956639d827a8654c5ee80e7cab8cadf930
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 07/02/2020
ms.locfileid: "85383599"
---
# <a name="define-an-azure-ad-sspr-technical-profile-in-an-azure-ad-b2c-custom-policy"></a>Azure AD B2C カスタム ポリシーで Azure AD SSPR 技術プロファイルを定義する

[!INCLUDE [active-directory-b2c-advanced-audience-warning](../../includes/active-directory-b2c-advanced-audience-warning.md)]

Azure Active Directory B2C (Azure AD B2C) では、セルフサービス パスワード リセット (SSPR) のメール アドレスの確認がサポートされています。 Azure AD SSPR 技術プロファイルを使用して、コードを生成し、メール アドレスに送信してから、コードを確認します。 Azure AD SSPR 技術プロファイルからは、エラー メッセージが返される場合もあります。 検証技術プロファイルでは、ユーザー体験を続ける前に、ユーザーが入力したデータを検証します。 検証技術プロファイルにより、エラー メッセージがセルフアサート ページに表示されます。

この技術プロファイル:

- ユーザーとやり取りするためのインターフェイスは用意していません。 代わりに、ユーザー インターフェイスは、[セルフアサート](self-asserted-technical-profile.md)技術プロファイルから、または[検証技術プロファイル](validation-technical-profile.md)としての[表示制御](display-controls.md)から呼び出されます。
- Azure AD SSPR サービスを使用して、コードを生成し、メール アドレスに送信してから、コードを確認します。
- 確認コードを使用してメール アドレスを検証します。

[!INCLUDE [b2c-public-preview-feature](../../includes/active-directory-b2c-public-preview.md)]

## <a name="protocol"></a>Protocol

**Protocol** 要素の **Name** 属性は `Proprietary` に設定する必要があります。 **handler** 属性には、Azure AD B2C により使用されるプロトコル ハンドラー アセンブリの完全修飾名が含まれる必要があります。

```
Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
```

次の例では、Azure AD SSPR の技術プロファイルを示します。

```XML
<TechnicalProfile Id="AadSspr-SendCode">
<DisplayName>Send Code</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
...
```

## <a name="send-email"></a>電子メールの送信

この技術プロファイルの最初のモードでは、コードが生成されて送信されます。 このモードに対しては、次のオプションを構成できます。

### <a name="input-claims"></a>入力クレーム

**InputClaims** 要素には、Azure AD SSPR に送信する要求の一覧が含まれます。 要求の名前を、SSPR 技術プロファイルで定義されている名前にマップすることもできます。

| ClaimReferenceId | 必須 | 説明 |
| --------- | -------- | ----------- |
| emailAddress | はい | メール アドレスを所有しているユーザーの識別子。 入力要求の `PartnerClaimType` プロパティを `emailAddress` に設定する必要があります。 |


**InputClaimsTransformations** 要素には、Azure AD SSPR サービスに送信する前に、入力要求の変更または新しい入力要求の生成に使用される、**InputClaimsTransformation** 要素のコレクションが含まれる場合があります。

### <a name="output-claims"></a>出力クレーム

Azure AD SSPR プロトコル プロバイダーでは **OutputClaims** は返されないため、出力要求を指定する必要はありません。 ただし、`DefaultValue` 属性を設定している限り、Azure AD SSPR プロトコル プロバイダーによって返されない要求を含めることができます。

**OutputClaimsTransformations** 要素には、出力要求を修正したり新しい要求を生成するために使用される、**OutputClaimsTransformation** 要素のコレクションが含まれている場合があります。

### <a name="metadata"></a>Metadata

| 属性 | Required | 説明 |
| --------- | -------- | ----------- |
| Operation | はい | **SendCode** である必要があります。 |

#### <a name="ui-elements"></a>UI 要素

次のメタデータを使用して、SMS 送信に失敗したときに表示されるエラー メッセージを構成できます。 メタデータは、[セルフアサート](self-asserted-technical-profile.md)技術プロファイルで構成する必要があります。 エラー メッセージは、[ローカライズ](localization-string-ids.md#azure-ad-sspr)できます。

| 属性 | Required | 説明 |
| --------- | -------- | ----------- |
| UserMessageIfInternalError | いいえ | サーバーで内部エラーが発生した場合のユーザー エラー メッセージ。 |
| UserMessageIfThrottled| いいえ | 要求が調整された場合のユーザー エラー メッセージ。|


### <a name="example-send-an-email"></a>例: メールの送信

次の例では、電子メールでコードを送信するために使用される Azure AD SSPR 技術プロファイルを示します。

```XML
<TechnicalProfile Id="AadSspr-SendCode">
<DisplayName>Send Code</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="Operation">SendCode</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress"/>
</InputClaims>
</TechnicalProfile>
```

## <a name="verify-code"></a>コードの確認

この技術プロファイルの 2 番目のモードでは、コードが検証されます。 このモードに対しては、次のオプションを構成できます。

### <a name="input-claims"></a>入力クレーム

**InputClaims** 要素には、Azure AD SSPR に送信する要求の一覧が含まれます。 要求の名前を、SSPR 技術プロファイルで定義されている名前にマップすることもできます。

| ClaimReferenceId | 必須 | 説明 |
| --------- | -------- | ----------- | ----------- |
| emailAddress| はい | 以前にコードを送信するために使用したのと同じメール アドレス。 また、電子メール検証セッションを探すためにも使用されます。 入力要求の `PartnerClaimType` プロパティを `emailAddress` に設定する必要があります。|
| verificationCode | はい | 確認のためにユーザーによって指定された確認コード。 入力要求の `PartnerClaimType` プロパティを `verificationCode` に設定する必要があります。 |

**InputClaimsTransformations** 要素には、Azure AD SSPR サービスの呼び出しの前に、入力要求の変更または新しい入力要求の生成に使用される、**InputClaimsTransformation** 要素のコレクションが含まれる場合があります。

### <a name="output-claims"></a>出力クレーム

Azure AD SSPR プロトコル プロバイダーでは **OutputClaims** は返されないため、出力要求を指定する必要はありません。 ただし、`DefaultValue` 属性を設定している限り、Azure AD SSPR プロトコル プロバイダーによって返されない要求を含めることができます。

**OutputClaimsTransformations** 要素には、出力要求を修正したり新しい要求を生成するために使用される、**OutputClaimsTransformation** 要素のコレクションが含まれている場合があります。

### <a name="metadata"></a>Metadata

| 属性 | Required | 説明 |
| --------- | -------- | ----------- |
| Operation | はい | **VerifyCode** になっている必要があります |

#### <a name="ui-elements"></a>UI 要素

次のメタデータを使用して、コード確認に失敗したときに表示されるエラー メッセージを構成できます。 メタデータは、[セルフアサート](self-asserted-technical-profile.md)技術プロファイルで構成する必要があります。 エラー メッセージは、[ローカライズ](localization-string-ids.md#azure-ad-sspr)できます。

| 属性 | Required | 説明 |
| --------- | -------- | ----------- |
|UserMessageIfChallengeExpired | コード確認セッションの有効期限が切れた場合にユーザーに表示するメッセージ。 コードの有効期限が切れているか、指定された識別子に対してコードが生成されたことがないかのいずれかです。|
|UserMessageIfInternalError | サーバーで内部エラーが発生した場合のユーザー エラー メッセージ。|
|UserMessageIfThrottled | 要求が調整された場合のユーザー エラー メッセージ。|
|UserMessageIfVerificationFailedNoRetry | 無効なコードを指定した場合にユーザーに表示するメッセージ。ユーザーは正しいコードを指定できません。|
|UserMessageIfVerificationFailedRetryAllowed | 無効なコードを指定した場合にユーザーに表示するメッセージ。ユーザーは正しいコードを指定できます。|

### <a name="example-verify-a-code"></a>例: コードを検証する

次の例では、コードの検証に使用される Azure AD SSPR の技術プロファイルを示します。

```XML
<TechnicalProfile Id="AadSspr-VerifyCode">
<DisplayName>Verify Code</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="Operation">VerifyCode</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="verificationCode" PartnerClaimType="verificationCode" />
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress"/>
</InputClaims>
</TechnicalProfile>
```
24 articles/active-directory-b2c/app-registrations-training-guide.md
View file
@@ -6,20 +6,20 @@ author: msmimart
manager: celestedg
ms.service: active-directory
ms.workload: identity
ms.topic: conceptual
ms.topic: reference
ms.date: 05/25/2020
ms.author: mimart
ms.subservice: B2C
ms.openlocfilehash: e60e8452b5cd3750a7b3478c860de95d8992528d
ms.sourcegitcommit: d118ad4fb2b66c759b70d4d8a18e6368760da3ad
ms.openlocfilehash: c89ed98d8100df270f09f1d2d1b621e71e326fe3
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 06/02/2020
ms.locfileid: "84302064"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85386302"
---
# <a name="the-new-app-registrations-experience-for-azure-active-directory-b2c"></a>Azure Active Directory B2C の新しいアプリの登録エクスペリエンス

Azure Active Directory Azure AD B2C (Azure AD B2C) の新しい **[アプリの登録](https://aka.ms/b2cappregistrations)** エクスペリエンスが一般提供されました。 アプリケーションを Azure AD B2C に登録するための**アプリケーション** エクスペリエンスに慣れている場合、ここでは「従来のエクスペリエンス」として触れられています。本ガイドは新しいエクスペリエンスの使用開始をサポートします。
Azure Active Directory B2C (Azure AD B2C) の新しい **[アプリの登録](https://aka.ms/b2cappregistrations)** エクスペリエンスが一般提供されました。 アプリケーションを Azure AD B2C に登録するための**アプリケーション** エクスペリエンスに慣れている場合、ここでは「従来のエクスペリエンス」として触れられています。本ガイドは新しいエクスペリエンスの使用開始をサポートします。

## <a name="overview"></a>概要
以前は、従来のエクスペリエンスを使用して、コンシューマー向けの Azure AD B2C アプリケーションを他のアプリとは別に管理する必要がありました。 これは、Azure のさまざまな場所で、さまざまなアプリ作成エクスペリエンスが存在していたことを意味します。
@@ -58,7 +58,7 @@ Azure AD B2C のアプリの登録エクスペリエンスは、すべての Azu

アカウントの種類の違いを理解するには、[作成] エクスペリエンスで **[選択に関する詳細]** を選択します。

従来のエクスペリエンスでは、アプリは常に顧客向けアプリケーションとして作成されていました。 これらのアプリの場合、アカウントの種類は、 **[任意の組織ディレクトリ内のアカウントまたは任意の ID プロバイダー。Azure AD B2C でユーザーを認証します。]** に設定されます。
従来のエクスペリエンスでは、アプリは常に顧客向けアプリケーションとして作成されていました。 これらのアプリの場合、アカウントの種類は、 **[任意の組織ディレクトリ内のアカウントまたは任意の ID プロバイダー。Azure AD B2C でユーザーを認証します。]** に設定されます。
> [!NOTE]
> このオプションは、このアプリケーション用にユーザーを認証するための Azure AD B2C ユーザー フローを実行できるようにするために必要です。 [ユーザー フローで使用するアプリケーションを登録する方法](tutorial-register-applications.md)を参照してください。
@@ -79,22 +79,22 @@ Azure AD B2C を使用してユーザーをアプリにサインインできる
## <a name="platformsauthentication-reply-urlsredirect-uris"></a>プラットフォーム/認証:応答 URL/リダイレクト URI
従来のエクスペリエンスでは、さまざまなプラットフォームの種類が **[プロパティ]** で管理されており、Web アプリや API の応答 URL として、またネイティブ クライアントのリダイレクト URI として使用されていました。 "ネイティブ クライアント" は "パブリック クライアント" とも呼ばれ、iOS、macOS、Android、およびその他の種類のモバイルおよびデスクトップ アプリケーション向けのアプリが含まれます。

新しいエクスペリエンスでは、応答 URL とリダイレクト URI は両方ともリダイレクト URI と呼ばれ、アプリの **[認証]** セクションにあります。 アプリの登録は、Web アプリや API、またはネイティブ アプリケーションのいずれかに制限されているわけではありません。 それぞれのリダイレクト URI を登録することで、これらすべてのプラットフォームの種類に対して、同じアプリの登録を使用できます。
新しいエクスペリエンスでは、応答 URL とリダイレクト URI は両方ともリダイレクト URI と呼ばれ、アプリの **[認証]** セクションにあります。 アプリの登録は、Web アプリまたはネイティブ アプリケーションのいずれかに制限されているわけではありません。 それぞれのリダイレクト URI を登録することで、これらすべてのプラットフォームの種類に対して、同じアプリの登録を使用できます。

リダイレクト URI は、Web またはパブリック (モバイルおよびデスクトップ) のアプリの種類のいずれかに関連付けられている必要があります。 [リダイレクト URI の詳細情報についてご確認ください](../active-directory/develop/quickstart-configure-app-access-web-apis.md#add-redirect-uris-to-your-application)

可能であれば、アプリケーションがパブリック クライアントとして扱われるかどうかは、実行時にリダイレクト URI プラットフォーム型から推論されます。 ROPC フローなどの、リダイレクト URI を使用しない可能性のあるフローに対しては、 **[Treat application as a public client]\(アプリケーションは、パブリック クライアントとして扱います\)** の設定を *[はい]* に設定する必要があります。
<!-- Whether an application should be treated as a public client is inferred at run-time from the Redirect URI platform type, if possible. The **Treat application as a public client** setting should be set to **Yes** for flows that might not use a redirect URI, such as ROPC flows. -->

**iOS/macOS** と **Android** プラットフォームは、パブリック クライアントの一種です。 これらでは、MSAL で使用するための対応するリダイレクト URI を使用して、iOS/macOS または Android アプリを簡単に構成できるようにする方法が提供されています。 [アプリケーション構成オプション](../active-directory/develop/msal-client-applications.md)の詳細をご確認ください。


## <a name="application-certificates--secrets"></a>アプリケーション証明書とシークレット

新しいエクスペリエンスでは、 **[キー]** ではなく **[証明書とシークレット]** ブレードを使用して、証明書とシークレットを管理します。 資格情報を使用すると、アプリケーションは Web アドレス指定可能な場所でトークンを受信するときに、認証サービスに対して身元を証明できます (HTTPS スキームを使用します)。 Azure AD に対して認証する場合は、クライアント シークレットではなく証明書をクライアントの資格情報シナリオに使用することをお勧めします。 Azure AD B2C に対しては、証明書を使用して認証を行うことはできません。
新しいエクスペリエンスでは、 **[キー]** ではなく **[証明書とシークレット]** ブレードを使用して、証明書とシークレットを管理します。 証明書とシークレットを使用すると、アプリケーションは Web アドレス指定可能な場所でトークンを受信するときに、認証サービスに対して身元を証明できます (HTTPS スキームを使用します)。 Azure AD に対して認証する場合は、クライアント シークレットではなく証明書をクライアントの資格情報シナリオに使用することをお勧めします。 Azure AD B2C に対しては、証明書を使用して認証を行うことはできません。


## <a name="features-not-available-in-azure-ad-b2c-tenants"></a>Azure AD B2C テナントでは利用できない機能
次の Azure AD アプリの登録機能は、Azure AD B2C テナントには適用されません。
## <a name="features-not-applicable-in-azure-ad-b2c-tenants"></a>Azure AD B2C テナントに適用されない機能
次の Azure AD アプリの登録機能は、Azure AD B2C テナントに適用されないか、テナントで利用できません。
- **役割と管理者** - これには、Azure AD B2C では現在使用できない Azure AD Premium P1 または P2 ライセンスが必要です。
- **ブランド** - UI や UX のカスタマイズは、**会社のブランド** エクスペリエンスまたはユーザー フローの一部として構成されます。 [Azure Active Directory B2C 内のユーザー インターフェイスをカスタマイズする](customize-ui-overview.md)方法を参照してください。
- **発行元ドメインの検証** - アプリは、検証済みのドメインではない *onmicrosoft.com* に登録されます。 また、発行元ドメインは主にユーザーの同意を与えるために使用され、ユーザー認証のために Azure AD B2C アプリに適用されるものではありません。 [発行元ドメインの詳細についてご確認ください](https://docs.microsoft.com/azure/active-directory/develop/howto-configure-publisher-domain)。
17 articles/active-directory-b2c/custom-policy-rest-api-intro.md
View file
@@ -7,16 +7,16 @@ author: msmimart
manager: celestedg
ms.service: active-directory
ms.workload: identity
ms.topic: conceptual
ms.topic: how-to
ms.date: 05/18/2020
ms.author: mimart
ms.subservice: B2C
ms.openlocfilehash: 0a62cd4ad6d992d8994fbd3e66bd0b90e45aa213
ms.sourcegitcommit: fdec8e8bdbddcce5b7a0c4ffc6842154220c8b90
ms.openlocfilehash: fe328de9460efb743037f697c7f564e2c628278d
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/19/2020
ms.locfileid: "83636999"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85388937"
---
# <a name="integrate-rest-api-claims-exchanges-in-your-azure-ad-b2c-custom-policy"></a>REST API 要求交換の Azure AD B2C カスタム ポリシーへの統合

@@ -33,6 +33,9 @@ Azure AD B2C を使用すると、自分の RESTful サービスを呼び出す

![RESTful サービスの要求交換の図](media/custom-policy-rest-api-intro/restful-service-claims-exchange.png)

> [!NOTE]
> RESTful サービスから Azure AD B2C への応答が遅い場合または応答がない場合、タイムアウトは 30 秒であり、再試行回数は 2 回です (つまり、合計 3 回試行されます)。 タイムアウトと再試行回数の設定は現在構成できません。
## <a name="calling-a-restful-service"></a>RESTful サービスの呼び出し

対話には REST API 要求と Azure AD B2C の間の情報の要求の交換が含まれています。 次の方法で、RESTful サービスとの統合を設計できます。
@@ -142,7 +145,7 @@ REST API は、セキュリティで保護され、[RESTful 技術プロファ
## <a name="localize-the-rest-api"></a>REST API をローカライズする
RESTful 技術プロファイルでは、現在のセッションの言語/ロケールを送信し、必要に応じて、ローカライズされたエラー メッセージを生成することができます。 [要求リゾルバー](claim-resolver-overview.md)を使用すると、ユーザー言語などのコンテキスト要求を送信できます。 このシナリオを示す RESTful 技術プロファイルの例を次に示します。

```XML
```xml
<TechnicalProfile Id="REST-ValidateUserData">
<DisplayName>Validate user input data</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -162,7 +165,7 @@ RESTful 技術プロファイルでは、現在のセッションの言語/ロ

## <a name="handling-error-messages"></a>エラー メッセージの処理

REST API は、「そのユーザーは CRM システムでは見つかりませんでした」などの、エラー メッセージを返す必要がある場合があります。 エラーが発生した場合、REST API は HTTP 409 エラー メッセージ (応答状態コードの競合) を返すことになります。 詳細については、「[RESTful 技術プロファイル](restful-technical-profile.md#returning-error-message)」を参照してください。
REST API は、「そのユーザーは CRM システムでは見つかりませんでした」などの、エラー メッセージを返す必要がある場合があります。 エラーが発生した場合、REST API は HTTP 409 エラー メッセージ (応答状態コードの競合) を返すことになります。 詳細については、「[RESTful 技術プロファイル](restful-technical-profile.md#returning-validation-error-message)」を参照してください。

これは、検証技術プロファイルから REST API 技術プロファイルを呼び出すことによってのみ実現できます。 これにより、ユーザーはページのデータを修正して、ページの送信時に検証を再度実行できます。

18 articles/active-directory-b2c/data-residency.md
View file
@@ -7,19 +7,19 @@ author: msmimart
manager: celestedg
ms.service: active-directory
ms.workload: identity
ms.topic: conceptual
ms.date: 09/26/2019
ms.topic: reference
ms.date: 06/06/2020
ms.author: mimart
ms.subservice: B2C
ms.custom: references_regions
ms.openlocfilehash: 46d8fb33c59fc5f0b6d844831e5ee1c937654afb
ms.sourcegitcommit: 1f48ad3c83467a6ffac4e23093ef288fea592eb5
ms.openlocfilehash: bb9c6dbf9984ec81fbd4b93a61552211928d0f0e
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/29/2020
ms.locfileid: "84193790"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85388716"
---
# <a name="azure-active-directory-b2c-region-availability--data-residency"></a>Azure Active Directory B2C: 利用可能なリージョンとデータの保存場所
# <a name="azure-active-directory-b2c-region-availability--data-residency"></a>Azure Active Directory B2C:利用可能なリージョンとデータの保存場所

利用可能なリージョンとデータの保存場所は、まったく異なる 2 つの概念です。また、Azure AD B2C とそれ以外の Azure サービスとでは、利用可能なリージョンとデータの保存場所との関係が異なります。 この記事では、これら 2 つの概念の違いについて説明するとともに、Azure と Azure AD B2C に対してそれらがどのように適用されるかを比較します。

@@ -41,7 +41,7 @@ Azure AD B2C では、ユーザー データが米国、ヨーロッパ、また

データの保存場所は、[Azure AD B2C のテナントを作成する](tutorial-create-tenant.md)ときに選択した国/地域によって決まります。

![プレビュー テナントのスクリーンショット](./media/data-residency/data-residency-b2c-tenant.png)
![[テナントの作成] フォームのスクリーンショット ([国またはリージョン] の選択)。](./media/data-residency/data-residency-b2c-tenant.png)

次の国/地域の場合、データは**米国**に保存されます。

@@ -69,4 +69,4 @@ Azure AD B2C のプレビュー期間中に B2C テナントを作成した場

プレビュー B2C テナントを削除し、同じドメイン名で運用スケール B2C テナントを作成する場合、既知の問題があります。 *運用スケール B2C テナントは異なるドメイン名で作成する必要があります*。

![プレビュー テナントのスクリーンショット](./media/data-residency/preview-b2c-tenant.png)
![[テナントの種類] (プレビュー テナント) のスクリーンショット。](./media/data-residency/preview-b2c-tenant.png)
20 articles/active-directory-b2c/one-time-password-technical-profile.md
View file
@@ -11,12 +11,12 @@ ms.topic: reference
ms.date: 03/26/2020
ms.author: mimart
ms.subservice: B2C
ms.openlocfilehash: 35497f978a1819f09411487e4bbc7eb1d05cc80d
ms.sourcegitcommit: 0fda81f271f1a668ed28c55dcc2d0ba2bb417edd
ms.openlocfilehash: 9592afbf74e65bcb2fe9319da764bf06d8d4eb6c
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/07/2020
ms.locfileid: "82900375"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85385724"
---
# <a name="define-a-one-time-password-technical-profile-in-an-azure-ad-b2c-custom-policy"></a>Azure AD B2C カスタム ポリシーでワンタイム パスワードの技術プロファイルを定義する

@@ -30,13 +30,13 @@ Azure Active Directory B2C (Azure AD B2C) では、ワンタイム パスワー

**Protocol** 要素の **Name** 属性は `Proprietary` に設定する必要があります。 **handler** 属性には、Azure AD B2C により使用される、プロトコル ハンドラー アセンブリの完全修飾名が含まれている必要があります。

```XML
```xml
Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
```

ワンタイム パスワードの技術プロファイルの例を次に示します。

```XML
```xml
<TechnicalProfile Id="VerifyCode">
<DisplayName>Validate user input verification code</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -77,14 +77,14 @@ Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.
| CodeLength | いいえ | コードの長さ。 既定値は `6` です。 |
| CharacterSet | いいえ | 正規表現で使用するように書式設定された、コードの文字セット。 たとえば、「 `a-z0-9A-Z` 」のように入力します。 既定値は `0-9` です。 文字セットには、指定したセット内の少なくとも 10 個の異なる文字を含める必要があります。 |
| NumRetryAttempts | いいえ | コードが無効と見なされるまでの確認の試行回数。 既定値は `5` です。 |
| Operation | はい | 実行する操作。 指定できる値: `GenerateCode`。 |
| 操作 | はい | 実行する操作。 指定できる値: `GenerateCode`。 |
| ReuseSameCode | いいえ | 指定されたコードの有効期限が切れておらず、まだ有効である場合に、新しいコードを生成するのではなく、重複するコードを指定する必要があるかどうか。 既定値は `false` です。 |

### <a name="example"></a>例

次の例の `TechnicalProfile` は、コードを生成するために使用されます。

```XML
```xml
<TechnicalProfile Id="GenerateCode">
<DisplayName>Generate Code</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -151,7 +151,7 @@ Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.

次の例の `TechnicalProfile` は、コードの確認に使用されます。

```XML
```xml
<TechnicalProfile Id="VerifyCode">
<DisplayName>Verify Code</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -169,5 +169,5 @@ Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.

カスタム メール確認でのワンタイム パスワードの技術プロファイルの使用例については、次の記事を参照してください。

- [Azure Active Directory B2C のカスタム メール確認](custom-email.md)
- Azure Active Directory B2C でのカスタム電子メール検証 ([Mailjet](custom-email-mailjet.md)、[SendGrid](custom-email-sendgrid.md))

46 articles/active-directory-b2c/partner-gallery.md
View file
@@ -0,0 +1,46 @@
---
title: Azure AD B2C のパートナー ギャラリー
titleSuffix: Azure AD B2C
description: パートナーと統合して、エンドユーザー エクスペリエンスをニーズに合わせて調整する方法について説明します。 Microsoft のパートナー ネットワークは、ソリューションの機能を拡張し、MFA、セキュリティで保護されたカスタマー認証、ロールベースのアクセス制御を有効にし、ID の検証と証明を通じて不正行為を防止します。
services: active-directory-b2c
author: msmimart
manager: celestedg
ms.service: active-directory
ms.workload: identity
ms.topic: how-to
ms.date: 06/08/2020
ms.author: mimart
ms.subservice: B2C
ms.openlocfilehash: 765deda747d46a9ee5b6913c192fa1a43c56d35d
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 07/02/2020
ms.locfileid: "85385903"
---
# <a name="azure-active-directory-b2c-partners"></a>Azure Active Directory B2C パートナー

Microsoft のパートナー ネットワークは、シームレスなエンドユーザー エクスペリエンスを構築するためにソリューション機能を拡張したものです。 Azure AD B2C を使用すると、パートナーと統合して、多要素認証方式を有効にしたり、セキュリティで保護されたカスタマー認証 (SCA) を有効にしたり、ロールベースのアクセス制御を実行したり、ID の検証と証明を通じて不正行為を防止したりすることができます。 詳細なチュートリアルを使用して、以下に一覧表示されているパートナーとアプリを統合する方法を学習してください。

>[!NOTE]
>[GitHub の Azure Active Directory B2C コミュニティ サイト](https://azure-ad-b2c.github.io/azureadb2ccommunity.io/)にも、コミュニティからのサンプル カスタム ポリシーが提供されています。
## <a name="integration-partners"></a>統合パートナー

| Partner | 説明と統合のチュートリアル |
| :--- | :--- |
| ![ロゴ](./media/partner-gallery/arkose-logo.png) | [Arkose Labs](./partner-arkose-labs.md) は、組織がボット攻撃、アカウント乗っ取り攻撃、および不正なアカウント開設を防ぐのに役立つ不正行為防止ソリューション プロバイダーです。
| ![ロゴ](./media/partner-gallery/idology-logo.png) | [IDology](./partner-idology.md) は、ID 検証ソリューション、不正行為防止ソリューション、コンプライアンス ソリューションなどを備えた ID の検証および証明プロバイダーです。|
| ![ロゴ](./media/partner-gallery/itsme-logo.png) | [itsme](./partner-itsme.md) は、ユーザーがカード リーダー、パスワード、2 要素認証、および複数の PIN コードを使用せずに安全にサインインできる、eiDAS (Electronic Identification, Authentication and Trust Services) に準拠したデジタル ID ソリューションです。 |
| ![ロゴ](./media/partner-gallery/trusona-logo.png) | [Trusona](./partner-trusona.md) 統合を使用すると、安全にサインインし、パスワードレス認証、多要素認証、およびデジタル ライセンス スキャンを有効にすることができます。|
| ![ロゴ](./media/partner-gallery/twilio-logo.png) | [Twilio Verify App](./partner-twilio.md) は、SMS ワンタイム パスワード (OTP)、時間ベースのワンタイム パスワード (TOTP)、およびプッシュ通知を使用して多要素認証 (MFA) を有効にし、PSD2 (Payment Services Directive 2) の SCA 要件に準拠するための複数のソリューションを提供しています。|
| ![ロゴ](./media/partner-gallery/typingdna-logo.png) | [TypingDNA](./partner-typingdna.md) は、ユーザー入力パターンに基づく ID 検証および証明プロバイダーであり、多要素認証を強制する ID 検証ソリューションを提供し、PSD2 (Payment Services Directive 2) の SCA 要件に準拠するのに役立ちます。 |

## <a name="next-steps"></a>次のステップ

上の表のパートナーを選択して、Azure AD B2C とソリューション統合する方法を確認してください。

追加情報:

- [GitHub の B2C コミュニティ サイト](https://azure-ad-b2c.github.io/azureadb2ccommunity.io/)
- [Azure AD B2C のカスタム ポリシー](custom-policy-overview.md)
12 articles/active-directory-b2c/tutorial-register-applications.md
View file
@@ -7,16 +7,16 @@ author: msmimart
manager: celestedg
ms.service: active-directory
ms.workload: identity
ms.topic: article
ms.topic: how-to
ms.date: 04/10/2020
ms.author: mimart
ms.subservice: B2C
ms.openlocfilehash: e97df60739b04884e8a9cd68679c23d4407e4947
ms.sourcegitcommit: d118ad4fb2b66c759b70d4d8a18e6368760da3ad
ms.openlocfilehash: a1af5fb7d0a1f8844016fcb6096e3a7ad9946f9f
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 06/02/2020
ms.locfileid: "84298804"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85384891"
---
# <a name="tutorial-register-a-web-application-in-azure-active-directory-b2c"></a>チュートリアル:Azure Active Directory B2C に Web アプリケーションを登録する

@@ -47,7 +47,7 @@ Azure サブスクリプションをお持ちでない場合は、開始する
1. Azure portal で、 **[Azure AD B2C]** を検索して選択します。
1. **[アプリの登録]** を選択し、 **[新規登録]** を選択します。
1. アプリケーションの**名前**を入力します。 たとえば、*webapp1* とします。
1. **[サポートされているアカウントの種類]** で、 **[Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)]\(任意の組織ディレクトリ内のアカウント (任意の Azure AD ディレクトリ - マルチテナント) と、個人用の Microsoft アカウント (Skype、Xbox など)\)** を選択します。
1. **[サポートされているアカウントの種類]** で、 **[任意の組織のディレクトリまたは任意の ID プロバイダーのアカウント] を選択します。ユーザーの認証には Azure AD B2C を選択します**。
1. **[リダイレクト URI]** で、 **[Web]** を選択し、URL テキスト ボックスに「`https://jwt.ms`」と入力します。

リダイレクト URI とは、ユーザーが承認サーバー (この場合は Azure AD B2C) とのやり取りが完了したときにユーザーが送信される、また承認が成功したときにアクセス トークンまたは認証コードが送信されるエンドポイントです。 実稼働アプリケーションでは、通常は `https://contoso.com/auth-response` などの、お使いのアプリが実行されているパブリック アクセスが可能なエンドポイントです。 このチュートリアルの場合のようなテスト目的では、トークンのデコードされたコンテンツを表示する Microsoft が所有する Web アプリケーションである `https://jwt.ms` に設定できます (トークンのコンテンツがお使いのブラウザー外に出ることはありません)。 アプリの開発時には、お使いのアプリケーションがローカルでリッスンする `https://localhost:5000` などのエンドポイントを追加する場合があります。 お使いの登録済みアプリケーションでは、いつでもリダイレクト URI を追加したり、変更したりすることができます。
30 articles/active-directory-b2c/user-migration.md
View file
@@ -1,35 +1,35 @@
---
title: ユーザーの移行方法
titleSuffix: Azure AD B2C
description: 一括インポートまたはシームレスな移行の方法を使用して、別の ID プロバイダーのユーザー アカウントを Azure AD B2C に移行します。
description: 事前移行またはシームレスな移行の方法を使用して、別の ID プロバイダーのユーザー アカウントを Azure AD B2C に移行します。
services: active-directory-b2c
author: msmimart
manager: celestedg
ms.service: active-directory
ms.workload: identity
ms.topic: conceptual
ms.topic: how-to
ms.date: 02/14/2020
ms.author: mimart
ms.subservice: B2C
ms.openlocfilehash: b3ee069985fd39288a562d3caafc50b12290c060
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 60dff717fbd86fa83821575ac90c9dac36dbc4d1
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/28/2020
ms.locfileid: "80332331"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85383973"
---
# <a name="migrate-users-to-azure-ad-b2c"></a>ユーザーを Azure AD B2C に移行する

別の ID プロバイダーから Azure Active Directory B2C (Azure AD B2C) に移行する場合、既存のユーザー アカウントの移行も必要になることがあります。 ここでは*一括インポート*と*シームレスな移行*という 2 つの移行方法について説明します。 どちらの方法でも、[Microsoft Graph API](manage-user-accounts-graph-api.md) を使用して Azure AD B2C にユーザー アカウントを作成するアプリケーションまたはスクリプトを記述する必要があります。
別の ID プロバイダーから Azure Active Directory B2C (Azure AD B2C) に移行する場合、既存のユーザー アカウントの移行も必要になることがあります。 ここでは*事前移行*と*シームレスな移行*という 2 つの移行方法について説明します。 どちらの方法でも、[Microsoft Graph API](manage-user-accounts-graph-api.md) を使用して Azure AD B2C にユーザー アカウントを作成するアプリケーションまたはスクリプトを記述する必要があります。

## <a name="bulk-import"></a>一括インポート
## <a name="pre-migration"></a>事前移行

一括インポート フローでは、移行アプリケーションはユーザー アカウントごとに次の手順を実行します。
事前移行フローでは、移行アプリケーションはユーザー アカウントごとに次の手順を実行します。

1. 古い ID プロバイダーから、現在の資格情報 (ユーザー名とパスワード) を含むユーザー アカウントを読み取ります。
1. 現在の資格情報を使用して、対応するアカウントを Azure AD B2C ディレクトリに作成します。

次の 2 つの状況のどちらでも、一括インポート フローを使用します。
事前移行フローは、次の 2 つの状況のいずれかで使用します。

- ユーザーのプレーンテキストの資格情報 (ユーザー名とパスワード) にアクセスできる。
- 資格情報が暗号化されているが、復号化できる。
@@ -43,18 +43,18 @@ ms.locfileid: "80332331"
- パスワードが (ハッシュ関数を使用した場合のように) 一方向の暗号化形式で格納されている。
- パスワードがレガシの ID プロバイダーによって、ユーザーがアクセスできない方法で格納されている。 たとえば、ID プロバイダーが Web サービスを呼び出して資格情報を検証している場合。

シームレスな移行フローではユーザー アカウントの一括移行がやはり必要ですが、その後、[カスタム ポリシー](custom-policy-get-started.md)を使用して [REST API](custom-policy-rest-api-intro.md) (ユーザーが作成したもの) へのクエリを実行し、最初のサインイン時に各ユーザーのパスワードを設定します。
シームレスな移行フローではユーザー アカウントの事前移行がやはり必要ですが、その後、[カスタム ポリシー](custom-policy-get-started.md)を使用して [REST API](custom-policy-rest-api-intro.md) (ユーザーが作成したもの) へのクエリを実行し、最初のサインイン時に各ユーザーのパスワードを設定します。

このため、シームレスな移行フローには、*一括インポート*と*資格情報の設定*の 2 つのフェーズがあります。
このため、シームレスな移行フローには、*事前移行*と*資格情報の設定*の 2 つのフェーズがあります。

### <a name="phase-1-bulk-import"></a>フェーズ 1:一括インポート
### <a name="phase-1-pre-migration"></a>フェーズ 1:事前移行

1. 移行アプリケーションは、古い ID プロバイダーからユーザー アカウントを読み取ります。
1. 移行アプリケーションは、Azure AD B2C ディレクトリに対応するユーザー アカウントを作成しますが、*パスワードは設定しません*。

### <a name="phase-2-set-credentials"></a>フェーズ 2:資格情報の設定

アカウントの一括移行が完了した後、カスタム ポリシーと REST API は、ユーザーがサインインしたときに次のことを実行します。
アカウントの事前移行が完了した後、カスタム ポリシーと REST API は、ユーザーがサインインしたときに次のことを実行します。

1. 入力した電子メール アドレスに対応する Azure AD B2C ユーザー アカウントを読み取ります。
1. ブール型の拡張属性を評価して、アカウントに移行のフラグが設定されているかどうかを確認します。
@@ -69,7 +69,7 @@ ms.locfileid: "80332331"

## <a name="best-practices"></a>ベスト プラクティス

### <a name="security"></a>Security
### <a name="security"></a>セキュリティ

シームレスな移行方法では、独自のカスタム REST API を使用して、レガシ ID プロバイダーに対してユーザーの資格情報を検証します。

16 articles/active-directory-domain-services/alert-ldaps.md
View file
@@ -11,12 +11,12 @@ ms.workload: identity
ms.topic: troubleshooting
ms.date: 09/18/2019
ms.author: iainfou
ms.openlocfilehash: 06b0fa1979f18981ec5cf78dc9a9dbad8b196394
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 68798cf98bf01697e5d854f5b539c1c381642c3c
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "71258044"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84735032"
---
# <a name="known-issues-secure-ldap-alerts-in-azure-active-directory-domain-services"></a>既知の問題:Azure Active Directory Domain Services の Secure LDAP アラート

@@ -30,9 +30,9 @@ ms.locfileid: "71258044"

"*マネージド ドメインに対してインターネット経由のセキュリティで Secure LDAP が有効になっています。ただし、ポート 636 へのアクセスはネットワーク セキュリティ グループを使用してロックダウンされていません。これにより、マネージド ドメインのユーザー アカウントがパスワードの総当り攻撃の対象になる可能性があります。* "

### <a name="resolution"></a>解像度
### <a name="resolution"></a>解決方法

Secure LDAP を有効にする場合は、特定の IP アドレスへの受信 LDAPS アクセスを制限する追加の規則を作成することをお勧めします。 これらの規則は、Azure AD DS マネージド ドメインをブルート フォース攻撃から保護します。 Secure LDAP への TCP ポート 636 アクセスを制限するようにネットワーク セキュリティ グループを更新するには、次の手順を実行します。
Secure LDAP を有効にする場合は、特定の IP アドレスへの受信 LDAPS アクセスを制限する追加の規則を作成することをお勧めします。 これらの規則は、マネージド ドメインをブルート フォース攻撃から保護します。 Secure LDAP への TCP ポート 636 アクセスを制限するようにネットワーク セキュリティ グループを更新するには、次の手順を実行します。

1. Azure portal で、**ネットワーク セキュリティ グループ**を検索して選択します。
1. マネージド ドメインに関連付けられているネットワーク セキュリティ グループ (*AADDS-contoso.com-NSG* など) を選択し、次に **[受信セキュリティ規則]** を選択します。
@@ -43,7 +43,7 @@ Secure LDAP を有効にする場合は、特定の IP アドレスへの受信
1. 規則の優先順位を指定し、名前 (*RestrictLDAPS* など) を入力します。
1. 準備ができたら、 **[追加]** を選択して規則を作成します。

Azure AD DS マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。
マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。

> [!TIP]
> Azure AD DS を円滑に実行するために必要な規則は、TCP ポート 636 だけではありません。 詳細については、[Azure AD DS ネットワーク セキュリティ グループと必要なポート](network-considerations.md#network-security-groups-and-required-ports)に関するページを参照してください。
@@ -54,7 +54,7 @@ Azure AD DS マネージド ドメインの正常性が 2 時間以内に自動

*マネージド ドメインのセキュリティで保護された LDAP 証明は[日付] に有効期限が切れます。*

### <a name="resolution"></a>解像度
### <a name="resolution"></a>解決方法

交換用の Secure LDAP 証明書を作成するには、「[Secure LDAP 用の証明書を作成する](tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap)」の手順を実行してください。 交換用の証明書を Azure AD DS に適用し、Secure LDAP を使用して接続するすべてのクライアントにその証明書を配布します。

24 articles/active-directory-domain-services/alert-service-principal.md
View file
@@ -11,16 +11,16 @@ ms.workload: identity
ms.topic: troubleshooting
ms.date: 09/20/2019
ms.author: iainfou
ms.openlocfilehash: f72e98213977a09b97cab9966ec69194cd8439e8
ms.sourcegitcommit: 1f25aa993c38b37472cf8a0359bc6f0bf97b6784
ms.openlocfilehash: 991bb3e296f18ef6d5182048d8ce4601c0fc09c9
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/26/2020
ms.locfileid: "83845969"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84734998"
---
# <a name="known-issues-service-principal-alerts-in-azure-active-directory-domain-services"></a>既知の問題:Azure Active Directory Domain Services のサービス プリンシパル アラート

[サービス プリンシパル](../active-directory/develop/app-objects-and-service-principals.md)は、Azure プラットフォームが Azure AD DS マネージド ドメインを管理、更新、および維持するために使用するアプリケーションです。 サービス プリンシパルが削除されると、Azure AD DS マネージド ドメインの機能に影響します。
[サービス プリンシパル](../active-directory/develop/app-objects-and-service-principals.md)は、Azure プラットフォームが Azure Active Directory Domain Services (Azure AD DS) マネージド ドメインを管理、更新、および維持するために使用するアプリケーションです。 サービス プリンシパルが削除されると、マネージド ドメインの機能に影響します。

この記事は、サービス プリンシパルに関連した構成アラートのトラブルシューティングと解決に役立ちます。

@@ -30,7 +30,7 @@ ms.locfileid: "83845969"

"*Azure AD Domain Services が正常に機能するために必要なサービス プリンシパルが Azure AD ディレクトリから削除されています。この構成は、マネージド ドメインに対する監視、管理、修正のプログラム適用、および同期を行うための Microsoft の能力に影響します。* "

必要なサービス プリンシパルが削除された場合、Azure プラットフォームは自動化された管理タスクを実行できません。 Azure AD DS マネージド ドメインで、更新プログラムの適用およびバックアップの実行が正しく行われない可能性があります。
必要なサービス プリンシパルが削除された場合、Azure プラットフォームは自動化された管理タスクを実行できません。 マネージド ドメインで、更新プログラムの適用およびバックアップの実行が正しく行われない可能性があります。

### <a name="check-for-missing-service-principals"></a>不足しているサービス プリンシパルを確認する

@@ -40,7 +40,7 @@ ms.locfileid: "83845969"
1. **[エンタープライズ アプリケーション]** を選択します。 **[アプリケーションの種類]** ドロップダウン メニューの *[すべてのアプリケーション]* を選択し、 **[適用]** を選択します。
1. 各アプリケーション ID を検索します。 既存のアプリケーションが見つからない場合は、*解決策*の手順に従ってサービス プリンシパルを作成するか、名前空間を再登録します。

| アプリケーション ID | 解像度 |
| アプリケーション ID | 解決方法 |
| :--- | :--- |
| 2565bd9d-da50-47d4-8b85-4c97f669dc36 | [不足しているサービス プリンシパルを再作成する](#recreate-a-missing-service-principal) |
| 443155a6-77f3-45e3-882b-22b3a8d431fb | [Microsoft.AAD 名前空間を再登録する](#re-register-the-microsoft-aad-namespace) |
@@ -64,18 +64,18 @@ ms.locfileid: "83845969"
New-AzureAdServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"
```

Azure AD DS マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。
マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。

### <a name="re-register-the-microsoft-aad-namespace"></a>Microsoft.AAD 名前空間を再登録する

アプリケーション ID *443155a6-77f3-45e3-882b-22b3a8d431fb*、*abba844e-bc0e-44b0-947a-dc74e5d09022*、または *d87dcbc6-a371-462e-88e3-28ad15ec4e64* が Azure AD ディレクトリにない場合は、次の手順を実行して *Microsoft.AAD* リソース プロバイダーを再登録します。

1. Azure portal で、**サブスクリプション**を検索して選択します。
1. Azure AD DS マネージド ドメインに関連付けられているサブスクリプションを選択します。
1. マネージド ドメインに関連付けられているサブスクリプションを選択します。
1. 左側のナビゲーションから、 **[リソース プロバイダー]** を選択します。
1. *Microsoft.AAD* を検索し、 **[再登録]** を選択します。

Azure AD DS マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。
マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。

## <a name="alert-aadds105-password-synchronization-application-is-out-of-date"></a>アラート AADDS105: Password synchronization application is out of date (パスワード同期アプリケーションの期限が切れています)

@@ -85,7 +85,7 @@ Azure AD DS マネージド ドメインの正常性が 2 時間以内に自動

Azure AD DS は、Azure AD からユーザー アカウントと資格情報を自動的に同期します。 このプロセスで使用されている Azure AD アプリケーションに問題がある場合、Azure AD DS と Azure AD 間の資格情報の同期は失敗します。

### <a name="resolution"></a>解像度
### <a name="resolution"></a>解決方法

資格情報の同期に使用する Azure AD アプリケーションを再作成するには、Azure AD PowerShell を使用して次の手順を実行します。 詳細については、[Azure AD PowerShell のインストール](/powershell/azure/active-directory/install-adv2)に関するページを参照してください。

@@ -105,7 +105,7 @@ Azure AD DS は、Azure AD からユーザー アカウントと資格情報を
Remove-AzureADServicePrincipal -ObjectId $spObject
```

両方のアプリケーションを削除した後、Azure プラットフォームによってそれらが自動的に再作成され、パスワード同期の再開が試行されます。 Azure AD DS マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。
両方のアプリケーションを削除した後、Azure プラットフォームによってそれらが自動的に再作成され、パスワード同期の再開が試行されます。 マネージド ドメインの正常性が 2 時間以内に自動的に更新され、アラートが削除されます。

## <a name="next-steps"></a>次のステップ

12 articles/active-directory-domain-services/csp.md
View file
@@ -10,12 +10,12 @@ ms.workload: identity
ms.topic: conceptual
ms.date: 03/31/2020
ms.author: iainfou
ms.openlocfilehash: e7276dcfca6ba033942d62f347ac3a799524cac4
ms.sourcegitcommit: b0ff9c9d760a0426fd1226b909ab943e13ade330
ms.openlocfilehash: c8cdb75c821f45fe7fcf0f455145beb2b9be2a55
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/01/2020
ms.locfileid: "80519099"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84734862"
---
# <a name="azure-active-directory-domain-services-deployment-and-management-for-azure-cloud-solution-providers"></a>Azure クラウド ソリューション プロバイダー向けの Azure Active Directory Domain Services のデプロイと管理

@@ -78,11 +78,11 @@ Azure CSP サブスクリプションで Azure AD DS を使用する方法は 2

Azure CSP サブスクリプションでマネージド ドメインを管理する場合、次の重要な考慮事項が適用されます。

* **CSP 管理エージェントは、その資格情報を使用してマネージド ドメインをプロビジョニングできる。** Azure AD DS では、Azure CSP サブスクリプションがサポートされています。 CSP パートナーの管理エージェント グループに属するユーザーは、新しい Azure AD DS マネージド ドメインをプロビジョニングできます。
* **CSP 管理エージェントは、その資格情報を使用してマネージド ドメインをプロビジョニングできる。** Azure AD DS では、Azure CSP サブスクリプションがサポートされています。 CSP パートナーの管理エージェント グループに属するユーザーは、新しいマネージド ドメインをプロビジョニングできます。

* **CSP は PowerShell を使用して、その顧客に対する新しいマネージド ドメインの作成をスクリプト化できる。** 詳細については、[PowerShell を使用して Azure AD DS を有効にする方法](powershell-create-instance.md)に関するページを参照してください。

* **CSP 管理エージェントは、その資格情報を使用してマネージド ドメインで継続的な管理タスクを実行することができない。** CSP 管理者ユーザーは、その資格情報を使用してマネージド ドメイン内で日常的な管理タスクを実行することができません。 これらのユーザーは顧客の Azure AD テナントの外部にいるため、顧客の Azure AD テナント内ではその資格情報を使用できません。 Azure AD DS は、これらのユーザーの Kerberos/NTLM パスワード ハッシュにアクセスできないため、Azure AD DS マネージド ドメインではユーザーを認証できません。
* **CSP 管理エージェントは、その資格情報を使用してマネージド ドメインで継続的な管理タスクを実行することができない。** CSP 管理者ユーザーは、その資格情報を使用してマネージド ドメイン内で日常的な管理タスクを実行することができません。 これらのユーザーは顧客の Azure AD テナントの外部にいるため、顧客の Azure AD テナント内ではその資格情報を使用できません。 Azure AD DS は、これらのユーザーの Kerberos/NTLM パスワード ハッシュにアクセスできないため、マネージド ドメインではユーザーを認証できません。

> [!WARNING]
> マネージド ドメインで継続的な管理タスクを実行するには、顧客のディレクトリ内にユーザー アカウントを作成する必要があります。
24 articles/active-directory-domain-services/deploy-azure-app-proxy.md
View file
@@ -11,20 +11,20 @@ ms.workload: identity
ms.topic: how-to
ms.date: 03/31/2020
ms.author: iainfou
ms.openlocfilehash: c1dc5216f758c2dda263e2f61b043dbde5f76604
ms.sourcegitcommit: 62c5557ff3b2247dafc8bb482256fef58ab41c17
ms.openlocfilehash: 285f5aabe32013a629eebb150e55ba343150f589
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/03/2020
ms.locfileid: "80655499"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84734845"
---
# <a name="deploy-azure-ad-application-proxy-for-secure-access-to-internal-applications-in-an-azure-ad-domain-services-managed-domain"></a>Azure AD Domain Services マネージド ドメイン内の内部アプリケーションに安全にアクセスするために Azure AD アプリケーション プロキシをデプロイする
# <a name="deploy-azure-ad-application-proxy-for-secure-access-to-internal-applications-in-an-azure-active-directory-domain-services-managed-domain"></a>Azure Active Directory Domain Services マネージド ドメイン内の内部アプリケーションに安全にアクセスするために Azure AD アプリケーション プロキシをデプロイする

Azure AD Domain Services (Azure AD DS) を使用して、オンプレミスで実行されているレガシ アプリケーションを Azure にリフトアンドシフトすることができます。 その後、Azure Active Directory (AD) アプリケーション プロキシにより、インターネット経由でアクセスできるように、Azure AD DS マネージド ドメインの一部として内部アプリケーションを安全に公開することで、リモート ワーカーをサポートできます。

Azure AD アプリケーション プロキシを使用したことがなく、詳細を確認したい場合は、[内部アプリケーションに安全なリモート アクセスを提供する方法](../active-directory/manage-apps/application-proxy.md)に関する記事を参照してください。

この記事では、Azure AD アプリケーション プロキシ コネクタを作成および構成して、Azure AD DS マネージド ドメイン内のアプリケーションへの安全なアクセスを提供する方法について説明します。
この記事では、Azure AD アプリケーション プロキシ コネクタを作成および構成して、マネージド ドメイン内のアプリケーションへの安全なアクセスを提供する方法について説明します。

## <a name="before-you-begin"></a>開始する前に

@@ -36,18 +36,18 @@ Azure AD アプリケーション プロキシを使用したことがなく、
* 必要に応じて、[Azure Active Directory テナントを作成][create-azure-ad-tenant]するか、[ご利用のアカウントに Azure サブスクリプションを関連付け][associate-azure-ad-tenant]ます。
* Azure AD アプリケーション プロキシを使用するには、**Azure AD Premium のライセンス**が必要です。
* Azure AD テナントで有効化され、構成された Azure Active Directory Domain Services のマネージド ドメイン。
* 必要であれば、[Azure Active Directory Domain Services インスタンスを作成して構成][create-azure-ad-ds-instance]してください。
* 必要に応じて、[Azure Active Directory Domain Services のマネージド ドメインを作成して構成][create-azure-ad-ds-instance]します。

## <a name="create-a-domain-joined-windows-vm"></a>ドメインに参加している Windows VM を作成する

環境内で実行されているアプリケーションにトラフィックをルーティングするには、Azure AD アプリケーション プロキシ コネクタ コンポーネントをインストールします。 この Azure AD アプリケーション プロキシ コネクタは、Azure AD DS マネージド ドメインに参加している Windows Server 仮想マシン (VM) にインストールする必要があります。 アプリケーションによっては、それぞれにコネクタがインストールされている複数のサーバーをデプロイできます。 このデプロイ オプションにより、可用性が向上し、負荷の高い認証を処理できます。
環境内で実行されているアプリケーションにトラフィックをルーティングするには、Azure AD アプリケーション プロキシ コネクタ コンポーネントをインストールします。 この Azure AD アプリケーション プロキシ コネクタは、マネージド ドメインに参加している Windows Server 仮想マシン (VM) にインストールする必要があります。 アプリケーションによっては、それぞれにコネクタがインストールされている複数のサーバーをデプロイできます。 このデプロイ オプションにより、可用性が向上し、負荷の高い認証を処理できます。

Azure AD アプリケーション プロキシ コネクタを実行する VM は、Azure AD DS を有効にしたのと同じ、またはピアリングされた仮想ネットワーク上にある必要があります。 アプリケーション プロキシを使用して発行するアプリケーションをホストする VM も、同じ Azure 仮想ネットワークにデプロイする必要があります。

Azure AD アプリケーション プロキシ コネクタ用の VM を作成するには、次の手順を実行します。

1. [カスタム OU を作成します](create-ou.md)。 このカスタム OU を管理するアクセス許可を、Azure AD DS マネージド ドメイン内のユーザーに委任できます。 Azure AD アプリケーション プロキシ用の VM とアプリケーションを実行する VM は、既定の *AAD DC Computers* OU ではなく、カスタム OU の一部である必要があります。
1. [仮想マシンをドメインに参加させます][create-join-windows-vm]。Azure AD アプリケーション プロキシ コネクタを実行しているものと、アプリケーションを実行しているものの両方を Azure AD DS マネージド ドメインに参加させます。 前の手順のカスタム OU 内に、これらのコンピューター アカウントを作成します。
1. [カスタム OU を作成します](create-ou.md)。 このカスタム OU を管理する権限を、マネージド ドメイン内のユーザーに委任できます。 Azure AD アプリケーション プロキシ用の VM とアプリケーションを実行する VM は、既定の *AAD DC Computers* OU ではなく、カスタム OU の一部である必要があります。
1. [仮想マシンをドメインに参加させます][create-join-windows-vm]。Azure AD アプリケーション プロキシ コネクタを実行しているものと、アプリケーションを実行しているものの両方をマネージド ドメインに参加させます。 前の手順のカスタム OU 内に、これらのコンピューター アカウントを作成します。

## <a name="download-the-azure-ad-application-proxy-connector"></a>Azure AD アプリケーション プロキシ コネクタをダウンロードする

@@ -82,11 +82,11 @@ VM を Azure AD アプリケーション プロキシ コネクタとして使
![Azure portal でアクティブと表示されている新しい Azure AD アプリケーション プロキシ コネクタ](./media/app-proxy/connected-app-proxy.png)

> [!NOTE]
> Azure AD アプリケーション プロキシを介して認証を行うアプリケーションの高可用性を実現するために、複数の VM にコネクタをインストールできます。 前のセクションと同じ手順を繰り返して、Azure AD DS マネージド ドメインに参加している他のサーバーにコネクタをインストールします。
> Azure AD アプリケーション プロキシを介して認証を行うアプリケーションの高可用性を実現するために、複数の VM にコネクタをインストールできます。 前のセクションと同じ手順を繰り返して、マネージド ドメインに参加している他のサーバーにコネクタをインストールします。
## <a name="enable-resource-based-kerberos-constrained-delegation"></a>リソースベースの Kerberos の制約付き委任を有効にする

統合 Windows 認証 (IWA) を使用してアプリケーションへのシングル サインオンを使用するには、Azure AD アプリケーション プロキシ コネクタに、ユーザーに偽装して代理でトークンを送受信するためのアクセス許可を付与します。 これらのアクセス許可を付与するには、コネクタに対して Azure AD DS マネージド ドメインのリソースにアクセスするための Kerberos の制約付き委任 (KCD) を構成します。 Azure AD DS マネージド ドメインのドメイン管理者特権がないため、マネージド ドメインに従来のアカウントレベルの KCD を構成することはできません。 代わりに、リソースベースの KCD を使用します。
統合 Windows 認証 (IWA) を使用してアプリケーションへのシングル サインオンを使用するには、Azure AD アプリケーション プロキシ コネクタに、ユーザーに偽装して代理でトークンを送受信するためのアクセス許可を付与します。 これらのアクセス許可を付与するには、コネクタに対してマネージド ドメインのリソースにアクセスするための Kerberos の制約付き委任 (KCD) を構成します。 マネージド ドメインのドメイン管理者特権がないため、マネージド ドメインに従来のアカウントレベルの KCD を構成することはできません。 代わりに、リソースベースの KCD を使用します。

詳細については、「[Azure Active Directory Domain Services で Kerberos の制約付き委任 (KCD) を構成する](deploy-kcd.md)」を参照してください。

18 articles/active-directory-domain-services/faqs.md
View file
@@ -9,14 +9,14 @@ ms.service: active-directory
ms.subservice: domain-services
ms.workload: identity
ms.topic: how-to
ms.date: 03/09/2020
ms.date: 06/05/2020
ms.author: iainfou
ms.openlocfilehash: 92b3fd2453a4fb121c97f8f25f1d3ca129826092
ms.sourcegitcommit: a6d477eb3cb9faebb15ed1bf7334ed0611c72053
ms.openlocfilehash: 4a9081b3d3c1c925efb4cc80201e6154752dc628
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/08/2020
ms.locfileid: "82926971"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84734777"
---
# <a name="frequently-asked-questions-faqs"></a>よく寄せられる質問 (FAQ)

@@ -58,6 +58,8 @@ ms.locfileid: "82926971"
### <a name="can-i-enable-azure-ad-domain-services-in-a-federated-azure-ad-directory-i-do-not-synchronize-password-hashes-to-azure-ad-can-i-enable-azure-ad-domain-services-for-this-directory"></a>フェデレーション Azure AD ディレクトリの Azure AD Domain Services を有効にすることはできますか。 Azure AD にパスワード ハッシュを同期していません。 このディレクトリの Azure AD Domain Services を有効にすることはできますか。
いいえ。 NTLM または Kerberos を使用してユーザーを認証するには、Azure AD Domain Services でユーザー アカウントのパスワード ハッシュへのアクセスが必要です。 フェデレーション ディレクトリでは、パスワード ハッシュは Azure AD ディレクトリに格納されません。 そのため、Azure AD Domain Services は、このような Azure AD ディレクトリでは機能しません。

ただし、パスワード ハッシュの同期に Azure AD Connect を使用している場合は、パスワード ハッシュ値が Azure AD に格納されているため、Azure AD Domain Services を使用できます。

### <a name="can-i-make-azure-ad-domain-services-available-in-multiple-virtual-networks-within-my-subscription"></a>Azure AD Domain Services をサブスクリプション内の複数の仮想ネットワークで利用できますか。
サービス自体は、このシナリオを直接サポートしていません。 マネージド ドメインは一度に 1 つの仮想ネットワークでのみ利用できます。 ただし、複数の仮想ネットワーク間で接続を構成して、Azure AD Domain Services を他の仮想ネットワークに公開することができます。 詳細については、[VPN ゲートウェイを使用して Azure の仮想ネットワークを接続する方法](../vpn-gateway/virtual-networks-configure-vnet-to-vnet-connection.md)または[仮想ネットワーク ピアリング](../virtual-network/virtual-network-peering-overview.md)に関する記事を参照してください。

@@ -74,7 +76,7 @@ ms.locfileid: "82926971"
いいえ。 [Azure AD B2B](../active-directory/active-directory-b2b-what-is-azure-ad-b2b.md) 招待プロセスを使用して Azure AD ディレクトリに招待されたゲスト ユーザーは、Azure AD Domain Services の管理対象ドメインに同期されます。 ただし、これらのユーザーのパスワードは Azure AD ディレクトリに格納されません。 そのため、Azure AD Domain Services では、これらのユーザーの NTLM と Kerberos のハッシュをマネージド ドメインに同期することはできません。 このようなユーザーは、サインインすることも、マネージド ドメインにコンピューターを参加させることもできません。

### <a name="can-i-move-an-existing-azure-ad-domain-services-managed-domain-to-a-different-subscription-resource-group-region-or-virtual-network"></a>既存の Azure AD Domain Services マネージド ドメインを別のサブスクリプション、リソース グループ、リージョン、または仮想ネットワークに移動できますか。
いいえ。 Azure AD Domain Services マネージド ドメインを作成した後は、そのインスタンスを別のリソース グループ、仮想ネットワーク、サブスクリプションなどに移動することはできません。Azure AD DS インスタンスをデプロイするときに、最適なサブスクリプション、リソース グループ、リージョン、および仮想ネットワークを慎重に選択してください。
いいえ。 Azure AD Domain Services マネージド ドメインを作成した後は、そのマネージド ドメインを別のリソース グループ、仮想ネットワーク、サブスクリプションなどに移動することはできません。マネージド ドメインをデプロイするときに、最適なサブスクリプション、リソース グループ、リージョン、仮想ネットワークを慎重に選択してください。

### <a name="does-azure-ad-domain-services-include-high-availability-options"></a>Azure AD Domain Services には高可用性オプションが含まれていますか。

@@ -97,7 +99,7 @@ ms.locfileid: "82926971"
いいえ。 リモート デスクトップを使用してマネージド ドメインのドメイン コントローラーに接続する権限はありません。 "*AAD DC 管理者*" グループのメンバーは、Active Directory 管理センター (ADAC) や AD PowerShell などの AD 管理ツールを使用して、マネージド ドメインを管理できます。 これらのツールは、"*リモート サーバー管理ツール*" 機能を使用して、マネージド ドメインに参加している Windows サーバーにインストールされます。 詳細については、「[チュートリアル:Azure Active Directory Domain Services のマネージド ドメインを構成および管理するための管理 VM を作成する](tutorial-create-management-vm.md)」を参照してください。

### <a name="ive-enabled-azure-ad-domain-services-what-user-account-do-i-use-to-domain-join-machines-to-this-domain"></a>Azure AD Domain Services を有効にしています。 このドメインに参加しているドメイン コンピューターでは、どのユーザー アカウントを使用できますか。
Azure AD DS のマネージド ドメインの一部であるすべてのユーザー アカウントを VM に参加させることができます。 "*AAD DC 管理者*" グループのメンバーには、マネージド ドメインに参加しているマシンへのリモート デスクトップ アクセス権が付与されます。
マネージド ドメインの一部であるすべてのユーザー アカウントを VM に参加させることができます。 "*AAD DC 管理者*" グループのメンバーには、マネージド ドメインに参加しているマシンへのリモート デスクトップ アクセス権が付与されます。

### <a name="do-i-have-domain-administrator-privileges-for-the-managed-domain-provided-by-azure-ad-domain-services"></a>Azure AD Domain Services によって提供されるマネージド ドメインにドメイン管理者特権はありますか。
いいえ。 マネージド ドメインの管理特権は付与されません。 "*ドメイン管理者*" 特権と "*エンタープライズ管理者*" 特権は、ドメイン内では使用できません。 また、オンプレミスの Active Directory 内のドメイン管理者グループまたはエンタープライズ管理者グループのメンバーにも、マネージド ドメインのドメイン/エンタープライズ管理者特権は付与されません。
@@ -158,4 +160,4 @@ Azure ADドメイン サービスを 構成するか、または管理する際

Azure AD Domain Services の詳細については、「[Azure Active Directory Domain Services とは](overview.md)」を参照してください。

作業を開始するには、「[チュートリアル:Azure Active Directory Domain Services インスタンスを作成して構成する](tutorial-create-instance.md)」を参照してください。
作業を開始するには、「[Azure Active Directory Domain Services のマネージド ドメインを作成して構成する](tutorial-create-instance.md)」を参照してください。
56 articles/active-directory-domain-services/join-centos-linux-vm.md
View file

Large diffs are not rendered by default.

46 articles/active-directory-domain-services/join-windows-vm-template.md
View file
@@ -11,12 +11,12 @@ ms.workload: identity
ms.topic: how-to
ms.date: 03/31/2020
ms.author: iainfou
ms.openlocfilehash: d2108b4c6b81675e2df6789d412dbd7d36f58a4d
ms.sourcegitcommit: 62c5557ff3b2247dafc8bb482256fef58ab41c17
ms.openlocfilehash: 1e725fb483afed0f126248737c2e9121ce823a45
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/03/2020
ms.locfileid: "80655105"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84734692"
---
# <a name="join-a-windows-server-virtual-machine-to-an-azure-active-directory-domain-services-managed-domain-using-a-resource-manager-template"></a>Resource Manager テンプレートを使用して Azure Active Directory Domain Services マネージド ドメインに Windows Server 仮想マシンを参加させる

@@ -33,14 +33,14 @@ Azure 仮想マシン (VM) のデプロイと構成を自動化するには、Re
* ご利用のサブスクリプションに関連付けられた Azure Active Directory テナント (オンプレミス ディレクトリまたはクラウド専用ディレクトリと同期されていること)。
* 必要に応じて、[Azure Active Directory テナントを作成][create-azure-ad-tenant]するか、[ご利用のアカウントに Azure サブスクリプションを関連付け][associate-azure-ad-tenant]ます。
* Azure AD テナントで有効化され、構成された Azure Active Directory Domain Services のマネージド ドメイン。
* 必要であれば、1 つ目のチュートリアルで [Azure Active Directory Domain Services インスタンスを作成して構成][create-azure-ad-ds-instance]します。
* Azure AD DS のマネージド ドメインの一部であるユーザー アカウント。
* 必要であれば、1 つ目のチュートリアルで [Azure Active Directory Domain Services のマネージド ドメインを作成して構成][create-azure-ad-ds-instance]します。
* マネージド ドメインの一部であるユーザー アカウント。

## <a name="azure-resource-manager-template-overview"></a>Azure Resource Manager テンプレートの概要

Resource Manager テンプレートを使用すると、コード内で Azure インフラストラクチャを定義できます。 必要なリソース、ネットワーク接続、または VM の構成はすべて、テンプレート内に定義できます。 これらのテンプレートによって、一貫性のある再現可能なデプロイが毎回作成され、変更を行う際にバージョン管理することができます。 詳細については、[Azure Resource Manager のテンプレートの概要][template-overview]に関するページをご覧ください。

各リソースは、JavaScript Object Notation (JSON) を使用してテンプレートで定義されます。 次の JSON の例では、*Microsoft.Compute/virtualMachines/extensions* のリソースの種類を使用して、Active Directory ドメイン参加の拡張機能をインストールしています。 デプロイ時に指定されたパラメーターが、使用されます。 拡張機能がデプロイされると、指定した Azure AD DS のマネージド ドメインに VM が参加します。
各リソースは、JavaScript Object Notation (JSON) を使用してテンプレートで定義されます。 次の JSON の例では、*Microsoft.Compute/virtualMachines/extensions* のリソースの種類を使用して、Active Directory ドメイン参加の拡張機能をインストールしています。 デプロイ時に指定されたパラメーターが、使用されます。 拡張機能がデプロイされると、指定したマネージド ドメインに VM が参加します。

```json
{
@@ -77,12 +77,12 @@ Resource Manager テンプレートを使用すると、コード内で Azure

## <a name="create-a-windows-server-vm-and-join-to-a-managed-domain"></a>Windows Server VM を作成してマネージド ドメインに参加させる

Windows Server VM が必要な場合は、Resource Manager テンプレートを使用して、作成および構成することが可能です。 VM をデプロイすると、VM を Azure AD DS マネージド ドメインに参加させるための拡張機能がインストールされます。 Azure AD DS マネージド ドメインへの参加を検討している VM が既にある場合は、「[既存の Windows Server VM をマネージド ドメインに参加させる](#join-an-existing-windows-server-vm-to-a-managed-domain)」に進んでください。
Windows Server VM が必要な場合は、Resource Manager テンプレートを使用して、作成および構成することが可能です。 VM をデプロイすると、VM をマネージド ドメインに参加させるための拡張機能がインストールされます。 マネージド ドメインへの参加を検討している VM が既にある場合は、「[既存の Windows Server VM をマネージド ドメインに参加させる](#join-an-existing-windows-server-vm-to-a-managed-domain)」に進んでください。

Windows Server VM を作成して、それを Azure AD DS マネージド ドメインに参加させるには、次の手順を完了します。
Windows Server VM を作成して、それをマネージド ドメインに参加させるには、次の手順を完了します。

1. [クイックスタート テンプレート](https://azure.microsoft.com/resources/templates/201-vm-domain-join/)に移動します。 **[Azure に配置する]** を選択します。
1. **[カスタム デプロイ]** ページ上で、次の情報を入力してWindows Server VM を作成し、Azure AD DS マネージド ドメインに参加させます。
1. **[カスタム デプロイ]** ページ上で、次の情報を入力して Windows Server VM を作成し、マネージド ドメインに参加させます。

| 設定 | 値 |
|---------------------------|-------|
@@ -93,47 +93,47 @@ Windows Server VM を作成して、それを Azure AD DS マネージド ドメ
| 既存のサブネットの名前 | 既存の仮想ネットワーク サブネットの名前 (*Workloads* など)。 |
| DNS ラベル プレフィックス | VM に使用する DNS 名を入力します (*myvm* など)。 |
| VM サイズ | VM サイズを指定します (*Standard_DS2_v2* など)。 |
| 参加するドメイン | Azure AD DS マネージド ドメインの DNS 名 (*aaddscontoso.com* など)。 |
| ドメイン ユーザー名 | `contosoadmin@aaddscontoso.com` など、VM をマネージド ドメインに参加させるために使用する必要がある、Azure AD DS マネージド ドメインでのユーザー アカウント。 このアカウントは、Azure AD DS のマネージド ドメインの一部である必要があります。 |
| 参加するドメイン | マネージド ドメインの DNS 名 (*aaddscontoso.com* など)。 |
| ドメイン ユーザー名 | `contosoadmin@aaddscontoso.com` など、VM をマネージド ドメインに参加させるために使用する必要がある、マネージド ドメインでのユーザー アカウント。 このアカウントは、マネージド ドメインの一部である必要があります。 |
| ドメイン パスワード | 前の設定で指定したユーザー アカウントのパスワード。 |
| オプションの OU パス | VM を追加するカスタム OU。 このパラメーターに値を指定しない場合、VM は既定の *[AAD DC Computers]\(AAD DC コンピューター\)* の OU に追加されます。 |
| VM 管理者のユーザー名 | VM 上に作成するためのローカル管理者アカウントを指定します。 |
| VM 管理者のパスワード | VM 用のローカル管理者のパスワードを指定します。 パスワードのブルート フォース攻撃から保護するために、強力なローカル管理者パスワードを作成してください。 |

1. 使用条件を確認して、 **[上記の使用条件に同意する]** チェック ボックスをオンにします。 準備ができたら、 **[購入]** を選択し、VM を作成して Azure AD DS マネージド ドメインに参加させます。
1. 使用条件を確認して、 **[上記の使用条件に同意する]** チェック ボックスをオンにします。 準備ができたら、 **[購入]** を選択し、VM を作成してマネージド ドメインに参加させます。

> [!WARNING]
> **パスワードの取り扱いには注意してください。**
> テンプレート パラメーター ファイルでは、Azure AD DS のマネージド ドメインの一部であるユーザー アカウントのパスワードが要求されます。 このファイルに値を手動で入力して、ファイル共有やその他の共有の場所上でアクセス可能なままにしておくことはできません。
> テンプレート パラメーター ファイルでは、マネージド ドメインの一部であるユーザー アカウントのパスワードが要求されます。 このファイルに値を手動で入力して、ファイル共有やその他の共有の場所上でアクセス可能なままにしておくことはできません。
デプロイが正常に完了するまでには、数分かかります。 完了すると、Windows VM が作成されて、Azure AD DS マネージド ドメインに参加します。 VM は、ドメイン アカウントを使用して、管理やサインインを行うことができます。
デプロイが正常に完了するまでには、数分かかります。 完了すると、Windows VM が作成されて、マネージド ドメインに参加します。 VM は、ドメイン アカウントを使用して、管理やサインインを行うことができます。

## <a name="join-an-existing-windows-server-vm-to-a-managed-domain"></a>既存の Windows Server VM をマネージド ドメインに参加させる

Azure AD DS マネージド ドメインへの参加を検討している既存の VM または VM グループがある場合は、単にVM 拡張機能をデプロイするために、Resource Manager テンプレートを使用できます。
マネージド ドメインへの参加を検討している既存の VM または VM グループがある場合は、単に VM 拡張機能をデプロイするために、Resource Manager テンプレートを使用できます。

既存の Windows Server VM を Azure AD DS マネージド ドメインに参加させるには、次の手順を完了します。
既存の Windows Server VM をマネージド ドメインに参加させるには、次の手順を完了します。

1. [クイックスタート テンプレート](https://azure.microsoft.com/resources/templates/201-vm-domain-join-existing/)に移動します。 **[Azure に配置する]** を選択します。
1. **[カスタム デプロイ]** ページ上で、次の情報を入力して、VM を Azure AD DS マネージド ドメインに参加させます。
1. **[カスタム デプロイ]** ページ上で、次の情報を入力して、VM をマネージド ドメインに参加させます。

| 設定 | 値 |
|---------------------------|-------|
| サブスクリプション | Azure AD Domain Services を有効にしたのと同じ Azure サブスクリプションを選択してください。 |
| Resource group | 既存の VM に使用するリソース グループを選択します。 |
| 場所 | 既存の VM の場所を選択します。 |
| VM リスト | Azure AD DS マネージド ドメインに参加させるために、*MyVM1,myVM2* のように、既存の VM のコンマ区切りリストを入力します。 |
| ドメイン参加ユーザー名 | `contosoadmin@aaddscontoso.com` など、VM をマネージド ドメインに参加させるために使用する必要がある、Azure AD DS マネージド ドメインでのユーザー アカウント。 このアカウントは、Azure AD DS のマネージド ドメインの一部である必要があります。 |
| VM リスト | マネージド ドメインに参加させるために、*MyVM1,myVM2* のように、既存の VM のコンマ区切りリストを入力します。 |
| ドメイン参加ユーザー名 | `contosoadmin@aaddscontoso.com` など、VM をマネージド ドメインに参加させるために使用する必要がある、マネージド ドメインでのユーザー アカウント。 このアカウントは、マネージド ドメインの一部である必要があります。 |
| ドメイン参加ユーザー パスワード | 前の設定で指定したユーザー アカウントのパスワード。 |
| オプションの OU パス | VM を追加するカスタム OU。 このパラメーターに値を指定しない場合、VM は既定の *[AAD DC Computers]\(AAD DC コンピューター\)* の OU に追加されます。 |

1. 使用条件を確認して、 **[上記の使用条件に同意する]** チェック ボックスをオンにします。 準備ができたら、 **[購入]** を選択し、VM を Azure AD DS マネージド ドメインに参加させます。
1. 使用条件を確認して、 **[上記の使用条件に同意する]** チェック ボックスをオンにします。 準備ができたら、 **[購入]** を選択し、VM をマネージド ドメインに参加させます。

> [!WARNING]
> **パスワードの取り扱いには注意してください。**
> テンプレート パラメーター ファイルでは、Azure AD DS のマネージド ドメインの一部であるユーザー アカウントのパスワードが要求されます。 このファイルに値を手動で入力して、ファイル共有やその他の共有の場所上でアクセス可能なままにしておくことはできません。
> テンプレート パラメーター ファイルでは、マネージド ドメインの一部であるユーザー アカウントのパスワードが要求されます。 このファイルに値を手動で入力して、ファイル共有やその他の共有の場所上でアクセス可能なままにしておくことはできません。
デプロイが正常に完了するまでには、しばらくかかります。 完了すると、指定した Windows VM が Azure AD DS マネージド ドメインに参加し、ドメイン アカウントを使用して管理やサインインができるようになります。
デプロイが正常に完了するまでには、しばらくかかります。 完了すると、指定した Windows VM がマネージド ドメインに参加し、ドメイン アカウントを使用して管理やサインインができるようになります。

## <a name="next-steps"></a>次のステップ

82 articles/active-directory-domain-services/network-considerations.md
View file

Large diffs are not rendered by default.

22 articles/active-directory-domain-services/secure-remote-vm-access.md
View file
@@ -10,12 +10,12 @@ ms.workload: identity
ms.topic: how-to
ms.date: 03/30/2020
ms.author: iainfou
ms.openlocfilehash: a17f27831dd0a674c1d55cde6974aba5e1bfcfc3
ms.sourcegitcommit: 849bb1729b89d075eed579aa36395bf4d29f3bd9
ms.openlocfilehash: 8a9382af630d80480e5bec50d629451ebe49bf73
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/28/2020
ms.locfileid: "82105728"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84734471"
---
# <a name="secure-remote-access-to-virtual-machines-in-azure-active-directory-domain-services"></a>Azure Active Directory Domain Services の仮想マシンへのリモートアクセスをセキュリティで保護する

@@ -41,7 +41,7 @@ Azure Active Directory Domain Services (Azure AD DS) マネージド ドメイ
* ご利用のサブスクリプションに関連付けられた Azure Active Directory テナント (オンプレミス ディレクトリまたはクラウド専用ディレクトリと同期されていること)。
* 必要に応じて、[Azure Active Directory テナントを作成][create-azure-ad-tenant]するか、[ご利用のアカウントに Azure サブスクリプションを関連付け][associate-azure-ad-tenant]ます。
* Azure AD テナントで有効化され、構成された Azure Active Directory Domain Services のマネージド ドメイン。
* 必要であれば、[Azure Active Directory Domain Services インスタンスを作成して構成][create-azure-ad-ds-instance]してください。
* 必要に応じて、[Azure Active Directory Domain Services のマネージド ドメインを作成して構成][create-azure-ad-ds-instance]します。
* Azure Active Directory Domain Services 仮想ネットワーク内に作成された*ワークロード* サブネット。
* 必要に応じて、[Azure Active Directory Domain Services マネージド ドメイン用の仮想ネットワークを構成します][configure-azureadds-vnet]。
* Azure AD テナントの *Azure AD DC administrators* グループのメンバーであるユーザー アカウント。
@@ -55,16 +55,16 @@ Azure Active Directory Domain Services (Azure AD DS) マネージド ドメイ
* *RDGVM01* - RD 接続ブローカー サーバー、RD Web アクセス サーバー、および RD ゲートウェイ サーバーを実行します。
* *RDSHVM01* - RD セッション ホスト サーバーを実行します。

VM が Azure AD DS 仮想ネットワークの*ワークロード* サブネットにデプロイされていることを確認してから、VM を Azure AD DS マネージド ドメインに参加させます。 詳細については、[Windows Server VM を作成し Azure AD DS マネージド ドメインに参加させる方法][tutorial-create-join-vm]についての記事を参照してください。
VM が Azure AD DS 仮想ネットワークの*ワークロード* サブネットにデプロイされていることを確認してから、VM をマネージド ドメインに参加させます。 詳細については、[Windows Server VM を作成してマネージド ドメインに参加させる方法][tutorial-create-join-vm]についての記事を参照してください。

RD 環境をデプロイするには、いくつかの手順が必要です。 既存の RD デプロイ ガイドは、Azure AD DS マネージド ドメインでは、特定の変更を使用しなくても使用できます。
RD 環境をデプロイするには、いくつかの手順が必要です。 既存の RD デプロイ ガイドは、特に変更することなくマネージド ドメインで使用できます。

1. *contosoadmin* などの *Azure AD DC 管理者*グループの一部であるアカウントを使用して、RD 環境用に作成された VM にサインインします。
1. RDS を作成および構成するには、既存の[リモート デスクトップ環境のデプロイ ガイド][deploy-remote-desktop]を参照してください。 必要に応じて、Azure VM 全体に RD サーバー コンポーネントを配布します。
* Azure AD DS に固有 - RD ライセンスを構成するときは、導入ガイドに記載されているように、 **[ユーザー単位]** ではなく、 **[Per Device]\(デバイス単位\)** モードに設定します。
1. Web ブラウザーを使用してアクセスを提供する場合は、[ユーザーのリモート デスクトップ Web クライアントを設定します][rd-web-client]。

RD を Azure AD DS マネージド ドメインにデプロイすると、オンプレミスの AD DS ドメインの場合と同様に、サービスを管理および使用できます。
RD をマネージド ドメインにデプロイすると、オンプレミスの AD DS ドメインの場合と同様に、サービスを管理および使用できます。

## <a name="deploy-and-configure-nps-and-the-azure-mfa-nps-extension"></a>NPS と Azure MFA NPS 拡張機能をデプロイして構成する

@@ -76,7 +76,7 @@ RD を Azure AD DS マネージド ドメインにデプロイすると、オン

Azure Multi-Factor Authentication を Azure AD DS リモート デスクトップ環境に統合するには、NPS サーバーを作成し、拡張機能をインストールします。

1. Azure AD DS 仮想ネットワーク内の*ワークロード* サブネットに接続されている、追加の Windows Server 2016 または 2019 VM (*NPSVM01* など) を作成します。 VM を Azure AD DS マネージド ドメインに参加させます。
1. Azure AD DS 仮想ネットワーク内の*ワークロード* サブネットに接続されている、追加の Windows Server 2016 または 2019 VM (*NPSVM01* など) を作成します。 VM をマネージド ドメインに参加させます。
1. *contosoadmin* などの *Azure AD DC 管理者*グループの一部であるアカウントとして、NPS VM にサインインします。
1. **サーバー マネージャー**で、 **[役割と機能の追加]** を選択し、 *[ネットワーク ポリシーとアクセス サービス]* ロールをインストールします。
1. [Azure MFA NPS 拡張機能のインストールと構成][nps-extension]については、既存のハウツー記事を参照してください。
@@ -87,9 +87,9 @@ NPS サーバーと Azure Multi-Factor Authentication NPS 拡張機能をイン

Azure Multi-Factor Authentication NPS 拡張機能を統合するには、[ネットワーク ポリシー サーバー (NPS) 拡張機能と Azure AD を使用してリモート デスクトップ ゲートウェイ インフラストラクチャを統合する方法][azure-mfa-nps-integration]に関する既存のハウツー記事を使用してください。

Azure AD DS マネージド ドメインと統合するには、次の追加の構成オプションが必要です。
マネージド ドメインと統合するには、次の追加の構成オプションが必要です。

1. [Active Directory に NPS サーバーを登録][register-nps-ad]しないでください。 Azure AD DS マネージド ドメインでは、この手順は失敗します。
1. [Active Directory に NPS サーバーを登録][register-nps-ad]しないでください。 マネージド ドメインでは、この手順は失敗します。
1. [ネットワーク ポリシーを構成した手順 4][create-nps-policy] で、 **[ユーザー アカウントのダイヤルイン プロパティを無視する]** チェック ボックスもオンにします。
1. NPS サーバーと Azure Multi-Factor Authentication NPS 拡張機能に Windows Server 2019 を使用する場合は、次のコマンドを実行して、NPS サーバーが正常に通信できるようにセキュリティで保護されたチャネルを更新します。

21 ...active-directory/app-provisioning/application-provisioning-quarantine-status.md
View file
@@ -2,21 +2,21 @@
title: 検疫のアプリケーション プロビジョニング状態 | Microsoft Docs
description: 自動ユーザー プロビジョニング用にアプリケーションを構成したら、検疫のプロビジョニング状態とクリアする方法について説明します。
services: active-directory
author: msmimart
manager: CelesteDG
author: kenwith
manager: celestedg
ms.service: active-directory
ms.subservice: app-provisioning
ms.workload: identity
ms.topic: conceptual
ms.topic: troubleshooting
ms.date: 04/28/2020
ms.author: mimart
ms.author: kenwith
ms.reviewer: arvinh
ms.openlocfilehash: c1e0039133b7f9a7ae827e348640f6379b7f10ac
ms.sourcegitcommit: 3abadafcff7f28a83a3462b7630ee3d1e3189a0e
ms.openlocfilehash: e5c0b00873cd97b255eff7e001f8b54cf0397462
ms.sourcegitcommit: 0100d26b1cac3e55016724c30d59408ee052a9ab
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/30/2020
ms.locfileid: "82593932"
ms.lasthandoff: 07/07/2020
ms.locfileid: "86024572"
---
# <a name="application-provisioning-in-quarantine-status"></a>検疫状態のアプリケーションのプロビジョニング

@@ -48,7 +48,7 @@ Azure AD プロビジョニング サービスは、構成の正常性を監視

|説明|推奨される操作|
|---|---|
|**SCIM へのコンプライアンスの問題:** 予期される HTTP/200 OK 応答ではなく、HTTP/404 Not Found 応答が返されました。 この場合、Azure AD プロビジョニング サービスによってターゲット アプリケーションへの要求が行われ、予期しない応答を受け取りました。|管理者資格情報のセクションを調べて、アプリケーションでテナントの URL を指定する必要があるかどうか、および URL が正しいことを確認します。 問題が見つからない場合は、アプリケーションの開発者に連絡し、サービスが SCIM に準拠していることを確認してください。 [https://github.com/mysqljs/mysql/](https://tools.ietf.org/html/rfc7644#section-3.4.2 ) |
|**SCIM へのコンプライアンスの問題:** 予期される HTTP/200 OK 応答ではなく、HTTP/404 Not Found 応答が返されました。 この場合、Azure AD プロビジョニング サービスによってターゲット アプリケーションへの要求が行われ、予期しない応答を受け取りました。|管理者資格情報のセクションを調べて、アプリケーションでテナントの URL を指定する必要があるかどうか、および URL が正しいことを確認します。 問題が見つからない場合は、アプリケーションの開発者に連絡し、サービスが SCIM に準拠していることを確認してください。 https://tools.ietf.org/html/rfc7644#section-3.4.2 |
|**無効な資格情報:** ターゲット アプリケーションへのアクセスの承認を試みたとき、指定された資格情報が無効であることを示す応答をターゲット アプリケーションから受け取りました。|プロビジョニング構成 UI の管理者資格情報のセクションに移動し、有効な資格情報で再度アクセスを承認してください。 アプリケーションがギャラリーにある場合は、アプリケーション構成のチュートリアルで必要な追加の手順を確認してください。|
|**重複したロール:** Salesforce や Zendesk などの特定のアプリケーションからインポートされるロールは、一意である必要があります。 |Azure portal でアプリケーションの[マニフェスト](https://docs.microsoft.com/azure/active-directory/develop/reference-app-manifest)に移動し、重複するロールを削除します。|

@@ -75,3 +75,6 @@ Azure AD プロビジョニング サービスは、構成の正常性を監視
- Microsoft Graph を使用して、[プロビジョニング ジョブを再起動します](https://docs.microsoft.com/graph/api/synchronization-synchronizationjob-restart?view=graph-rest-beta&tabs=http)。 再起動する対象は完全に制御できます。 エスクローをクリアするか (検疫状態と判定されるためのエスクロー カウンターを再起動するため)、検疫をオフにするか (検疫からアプリケーションを削除するため)、または透かしをクリアするかを選択できます。 次の要求を使用します。

`POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart`

"{Id}" をアプリケーション ID の値に置き換え、"{jobId}" を[同期ジョブの ID](https://docs.microsoft.com/graph/api/resources/synchronization-configure-with-directory-extension-attributes?view=graph-rest-beta&tabs=http#list-synchronization-jobs-in-the-context-of-the-service-principal) に置き換えます。

24 articles/active-directory/app-provisioning/skip-out-of-scope-deletions.md
View file
@@ -2,31 +2,31 @@
title: スコープ外のユーザーの削除をスキップする
description: スコープ外のユーザーのプロビジョニングを解除する既定の動作をオーバーライドする方法について説明します。
services: active-directory
author: cmmdesai
manager: CelesteDG
author: kenwith
manager: celestedg
ms.service: active-directory
ms.subservice: app-provisioning
ms.topic: article
ms.topic: how-to
ms.workload: identity
ms.date: 12/10/2019
ms.author: chmutali
ms.author: kenwith
ms.reviewer: celested
ms.openlocfilehash: 5f17886736efb87cf44bc54c82ccca794482a093
ms.sourcegitcommit: 3abadafcff7f28a83a3462b7630ee3d1e3189a0e
ms.openlocfilehash: 719258933dfadf34b8678bf03ee07ee6cc76e331
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/30/2020
ms.locfileid: "82593269"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84789907"
---
# <a name="skip-deletion-of-user-accounts-that-go-out-of-scope"></a>スコープ外に出るユーザー アカウントの削除をスキップする

既定では、Azure AD プロビジョニング エンジンは、スコープ外に出るユーザーを論理的に削除または無効化します。 ただし、Workday to AD User Inbound Provisioning などの特定のシナリオでは、この動作が予期されていない場合があり、この既定の動作をオーバーライドしたいことがあります。

このガイドでは、Microsoft Graph API と Microsoft Graph API エクスプローラーを使用して、スコープ外に出るアカウントの処理を制御するフラグ ***SkipOutOfScopeDeletions*** を設定する方法について説明します。
* ***SkipOutOfScopeDeletions*** が 0 (false) に設定されている場合、スコープ外に出たアカウントはターゲットで無効になります
* ***SkipOutOfScopeDeletions*** が 1 (true) に設定されている場合、スコープ外に出るアカウントはターゲットで無効になりません。このフラグは "*プロビジョニング アプリ*" レベルで設定され、Graph API を使用して構成できます。
この記事では、Microsoft Graph API と Microsoft Graph API エクスプローラーを使用して、スコープ外に出るアカウントの処理を制御するフラグ ***SkipOutOfScopeDeletions*** を設定する方法について説明します。
* ***SkipOutOfScopeDeletions*** が 0 (false) に設定されている場合、スコープ外に出たアカウントはターゲットで無効になります。
* ***SkipOutOfScopeDeletions*** が 1 (true) に設定されている場合、スコープ外に出たアカウントはターゲットで無効になりません。 このフラグは、*プロビジョニング アプリ*のレベルで設定され、Graph API を使用して構成できます。

この構成は *Workday to Active Directory User Provisioning* アプリで広く使用されているため、次の手順には Workday アプリケーションのスクリーンショットが含まれています。 ただし、これは **他のすべてのアプリ**（ServiceNow、Salesforce、Dropboxなど）でも使用できます。
この構成は *Workday to Active Directory User Provisioning* アプリで広く使用されているため、次の手順には Workday アプリケーションのスクリーンショットが含まれています。 ただし、この構成は*他のすべてのアプリ* (ServiceNow、Salesforce、Dropbox など) でも使用できます。

## <a name="step-1-retrieve-your-provisioning-app-service-principal-id-object-id"></a>手順 1:プロビジョニング アプリのサービス プリンシパル ID (オブジェクト ID) を取得します

16 articles/active-directory/authentication/howto-mfa-userstates.md
View file
@@ -11,21 +11,21 @@ author: iainfoulds
manager: daveba
ms.reviewer: michmcla
ms.collection: M365-identity-device-management
ms.openlocfilehash: 0db72e30fbced17665c112ad56510d7c2ca23d12
ms.sourcegitcommit: fdec8e8bdbddcce5b7a0c4ffc6842154220c8b90
ms.openlocfilehash: e8ef25df8fdb11715ebba954e31a97939d6ac0e1
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/19/2020
ms.locfileid: "83639622"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85476837"
---
# <a name="enable-per-user-azure-multi-factor-authentication-to-secure-sign-in-events"></a>ユーザーごとの Azure Multi-Factor Authentication を有効にしてサインイン イベントのセキュリティを確保する

Azure AD で多要素認証を要求することによってユーザーのサインイン イベントのセキュリティを確保するには、2 つの方法があります。 推奨される最初のオプションは、特定の条件下で多要素認証を要求する条件付きアクセス ポリシーを設定することです。 2 つ目のオプションは、個々のユーザーに Azure Multi-Factor Authentication を有効にする方法です。 ユーザーを個別に有効にした場合は、サインインするたびに多要素認証が実行されます (信頼できる IP アドレスからサインインするときや、_記憶されたデバイス_の機能が有効なときなど、一部例外があります)。

> [!NOTE]
> 条件付きアクセス ポリシーを使って Azure Multi-Factor Authentication を有効にするのが推奨されるアプローチです。 ライセンスに条件付きアクセスが含まれていない場合 (この場合、ユーザーはサインインするたびに MFA を実行する必要があります) を除き、ユーザーの状態を変更することは推奨されなくなりました。
> 条件付きアクセス ポリシーを使って Azure Multi-Factor Authentication を有効にするのが推奨されるアプローチです。 ライセンスに条件付きアクセスが含まれていない場合 (この場合、ユーザーはサインインするたびに MFA を実行する必要があります) を除き、ユーザーの状態を変更することは推奨されなくなりました。 条件付きアクセスの使用を開始するには、「[チュートリアル:Azure Multi-Factor Authentication を使用してユーザーのサインイン イベントのセキュリティを確保する](tutorial-enable-azure-mfa.md)」を参照してください。
>
> 条件付きアクセスの使用を開始するには、「[チュートリアル: Azure Multi-Factor Authentication を使用してユーザーのサインイン イベントのセキュリティを確保する](tutorial-enable-azure-mfa.md)」を参照してください。
> 条件付きアクセスを使用しない Azure AD 無料テナントについては、[セキュリティの既定値を使用してユーザーを保護](../fundamentals/concept-fundamentals-security-defaults.md)できます。
## <a name="azure-multi-factor-authentication-user-states"></a>Azure Multi-Factor Authentication におけるユーザーの状態

@@ -39,7 +39,7 @@ Azure Multi-factor Authentication のユーザー アカウントには、次の
| Status | 説明 | 非ブラウザー アプリに影響があるか | ブラウザー アプリに影響があるか | 影響を受ける先進認証 |
|:---:| --- |:---:|:--:|:--:|
| 無効 | Azure Multi-Factor Authentication に登録されていない、新しいユーザーの既定の状態です。 | いいえ | いいえ | いいえ |
| Enabled | ユーザーは多要素認証に登録されていますが、まだ登録されていません。 次回のサインイン時に登録することを求められます。 | いいえ。 これらは登録プロセスが完了するまで機能し続けます。 | はい。 セッションの有効期限が切れると、Azure Multi-Factor Authentication の登録が必要になります。| はい。 アクセス トークンの有効期限が切れると、Azure Multi-Factor Authentication の登録が必要になります。 |
| Enabled | ユーザーは Azure Multi-Factor Authentication に登録されていますが、認証方法を登録していません。 次回のサインイン時に登録することを求められます。 | いいえ。 これらは登録プロセスが完了するまで機能し続けます。 | はい。 セッションの有効期限が切れると、Azure Multi-Factor Authentication の登録が必要になります。| はい。 アクセス トークンの有効期限が切れると、Azure Multi-Factor Authentication の登録が必要になります。 |
| 強制 | ユーザーは登録されており、Azure Multi-Factor Authentication の登録プロセスが完了しています。 | はい。 アプリはアプリ パスワードを必要とします。 | はい。 ログイン時に Azure Multi-Factor Authentication が必要です。 | はい。 ログイン時に Azure Multi-Factor Authentication が必要です。 |

ユーザーの状態には、管理者がユーザーを Azure Multi-Factor Authentication に登録したかどうか、およびユーザーが登録プロセスを完了したかどうかが反映されます。
@@ -84,7 +84,7 @@ Azure Multi-factor Authentication のユーザー アカウントには、次の
* *Enforced (強制)*
* *Disabled*

ユーザーを直接 "*適用*" の状態に移さないでください。 そのようにしても、ユーザーは Azure Multi-Factor Authentication の登録を終えておらず、[アプリのパスワード](howto-mfa-mfasettings.md#app-passwords)を取得していないため、ブラウザーベースでないアプリは動作を停止します。
ユーザーを直接 "*適用*" の状態に移さないでください。 そのようにしても、ユーザーは Azure Multi-Factor Authentication の登録を終えておらず、[アプリのパスワード](howto-mfa-app-passwords.md)を取得していないため、ブラウザーベースでないアプリは動作を停止します。

使用を開始するには、以下のように [Install-Module](/powershell/module/powershellget/install-module) を使用して *MSOnline* モジュールをインストールします。

11 articles/active-directory/authentication/howto-registration-mfa-sspr-combined.md
View file
@@ -11,12 +11,12 @@ author: iainfoulds
manager: daveba
ms.reviewer: rhicock
ms.collection: M365-identity-device-management
ms.openlocfilehash: 40266f1b340ebe0ab665c576ff3be0e62ba7c705
ms.sourcegitcommit: cf7caaf1e42f1420e1491e3616cc989d504f0902
ms.openlocfilehash: 7feb69b2ea53794b780a983ed8ab4ba5874ac022
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/22/2020
ms.locfileid: "83798272"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85260850"
---
# <a name="enable-combined-security-information-registration-in-azure-active-directory"></a>Azure Active Directory での統合されたセキュリティ情報の登録の有効化

@@ -49,6 +49,9 @@ Internet Explorer でサイトとゾーンの割り当て一覧を構成した

Azure Multi-Factor Authentication とセルフサービス パスワード リセット の登録をユーザーがいつどのように行うかについてのセキュリティ保護が、条件付きアクセス ポリシーのユーザー アクションを使用して可能になりました。 この機能は、[統合登録機能](../authentication/concept-registration-mfa-sspr-combined.md)を有効にしている組織で使用できます。 この機能は、HR オンボード中に信頼できるネットワークの場所などの一元化された場所から Azure Multi-Factor Authentication および SSPR の登録をユーザーに行わせたい組織で有効にすることができます。

> [!NOTE]
> このポリシーは、ユーザーが統合登録ページにアクセスした場合にのみ適用されます。 このポリシーは、ユーザーが他のアプリケーションにアクセスしたときに MFA 登録を強制しません。 MFA 登録ポリシーを作成するには、[Azure Identity Protection - MFA ポリシーの構成](../identity-protection/howto-identity-protection-configure-mfa-policy.md)を使用します。
条件付きアクセスでの信頼できる場所の作成について詳しくは、[Azure Active Directory 条件付きアクセスの場所の条件の概要](../conditional-access/location-condition.md#named-locations)に関する記事をご覧ください。

### <a name="create-a-policy-to-require-registration-from-a-trusted-location"></a>信頼できる場所からの登録を要求するポリシーを作成する
12 articles/active-directory/b2b/add-users-information-worker.md
View file
@@ -4,20 +4,20 @@ description: B2B コラボレーションを利用して、インフォメーシ
services: active-directory
ms.service: active-directory
ms.subservice: B2B
ms.topic: conceptual
ms.topic: how-to
ms.date: 12/19/2018
ms.author: mimart
author: msmimart
manager: celestedg
ms.reviewer: mal
ms.custom: it-pro, seo-update-azuread-jan
ms.collection: M365-identity-device-management
ms.openlocfilehash: abb5c6939d8c88db35a776aa8f2c075a4bdcc609
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 9bc3175017e5b26251d1a12d0d1e2c51c4e5f9c9
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "77565419"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85387390"
---
# <a name="how-users-in-your-organization-can-invite-guest-users-to-an-app"></a>組織内のユーザーがゲスト ユーザーをアプリに招待する方法

@@ -28,7 +28,7 @@ ms.locfileid: "77565419"
- セルフサービス用にアプリを構成して、グループをアプリに割り当てる

> [!NOTE]
> この記事では、Azure AD テナントに追加したギャラリーおよび SAML ベースのアプリのセルフサービス管理を設定する方法について説明します。 ユーザーが自身の Office 365 グループへのアクセスを管理できるように[セルフサービス Office 365 グループを設定する](https://docs.microsoft.com/azure/active-directory/users-groups-roles/groups-self-service-management)こともできます。 ユーザーが Office ファイルとアプリをゲスト ユーザーと共有できるその他の方法については、「[Office 365 グループでのゲスト アクセス](https://support.office.com/article/guest-access-in-office-365-groups-bfc7a840-868f-4fd6-a390-f347bf51aff6)」と「[SharePoint ファイルまたはフォルダーの共有](https://support.office.com/article/share-sharepoint-files-or-folders-1fe37332-0f9a-4719-970e-d2578da4941c)」をご覧ください。
> この記事では、Azure AD テナントに追加したギャラリーおよび SAML ベースのアプリのセルフサービス管理を設定する方法について説明します。 ユーザーが自身の Microsoft 365 グループへのアクセスを管理できるように、[Microsoft 365 のセルフサービス グループを設定する](https://docs.microsoft.com/azure/active-directory/users-groups-roles/groups-self-service-management)こともできます。 ユーザーが Office ファイルとアプリをゲスト ユーザーと共有できるその他の方法については、[Microsoft 365 グループでのゲスト アクセス](https://support.office.com/article/guest-access-in-office-365-groups-bfc7a840-868f-4fd6-a390-f347bf51aff6)に関するページと、「[SharePoint ファイルまたはフォルダーの共有](https://support.office.com/article/share-sharepoint-files-or-folders-1fe37332-0f9a-4719-970e-d2578da4941c)」を参照してください。
## <a name="invite-a-guest-user-to-an-app-from-the-access-panel"></a>アクセス パネルからアプリにゲスト ユーザーを招待する

23 articles/active-directory/b2b/direct-federation.md
View file
@@ -4,26 +4,25 @@ description: ご自身の Azure AD アプリにゲストがサインインでき
services: active-directory
ms.service: active-directory
ms.subservice: B2B
ms.topic: conceptual
ms.date: 05/11/2020
ms.topic: how-to
ms.date: 06/24/2020
ms.author: mimart
author: msmimart
manager: celestedg
ms.reviewer: mal
ms.custom: it-pro
ms.collection: M365-identity-device-management
ms.openlocfilehash: 299b0a677e7ca7bea9481d94ecf98c993af0a6ed
ms.sourcegitcommit: bb0afd0df5563cc53f76a642fd8fc709e366568b
ms.openlocfilehash: 78ad8761d3a4ff3e3cdab9dee5f50b469ff840fd
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/19/2020
ms.locfileid: "83591218"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85551536"
---
# <a name="direct-federation-with-ad-fs-and-third-party-providers-for-guest-users-preview"></a>ゲスト ユーザーのための AD FS およびサード パーティ プロバイダーとの直接フェデレーション (プレビュー)
| |
| --- |
| 直接フェデレーションは、Azure Active Directory のパブリック プレビュー機能です。 詳細については、「[Microsoft Azure プレビューの追加使用条件](https://azure.microsoft.com/support/legal/preview-supplemental-terms/)」を参照してください。|
| |

> [!NOTE]
> 直接フェデレーションは、Azure Active Directory のパブリック プレビュー機能です。 詳細については、「[Microsoft Azure プレビューの追加使用条件](https://azure.microsoft.com/support/legal/preview-supplemental-terms/)」を参照してください。
この記事では、B2B コラボレーションのために別の組織との直接フェデレーションを設定する方法について説明します。 任意の組織の ID プロバイダー (IdP) が SAML 2.0 または WS-Fed プロトコルをサポートしていれば、その組織との直接フェデレーションを設定することができます。
パートナーの IdP との直接フェデレーションを設定すると、そのドメインに属する新しいゲスト ユーザーがご自身の Azure AD テナントに、そのユーザー自身の組織アカウント (IdP が管理する) を使用してサインインし、コラボレーションを開始できます。 ゲスト ユーザーが別個の Azure AD アカウントを作成する必要はありません。
@@ -221,3 +220,7 @@ PowerShell を使用して ID プロバイダーとの直接フェデレーシ
```powershell
Remove-AzureADExternalDomainFederation -ExternalDomainName $domainName
```

## <a name="next-steps"></a>次のステップ

外部ユーザーがさまざまな ID プロバイダーでサインインするときの[招待の利用エクスペリエンス](redemption-experience.md)を確認します。
377 articles/active-directory/b2b/self-service-sign-up-add-approvals.md
View file

Large diffs are not rendered by default.

18 articles/active-directory/b2b/user-properties.md
View file
@@ -4,20 +4,20 @@ description: 招待に応じる前と後の Azure Active Directory B2B ゲスト
services: active-directory
ms.service: active-directory
ms.subservice: B2B
ms.topic: conceptual
ms.date: 03/19/2020
ms.topic: how-to
ms.date: 06/19/2020
ms.author: mimart
author: msmimart
manager: celestedg
ms.reviewer: mal
ms.custom: it-pro, seo-update-azuread-jan, seoapril2019
ms.collection: M365-identity-device-management
ms.openlocfilehash: 40f5002e361653614c966dc43301afa83eb7b200
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: e7271c4de6d5c186c9e561aa37a140eaa04cbc0a
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/28/2020
ms.locfileid: "80050804"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85386625"
---
# <a name="properties-of-an-azure-active-directory-b2b-collaboration-user"></a>Azure Active Directory B2B コラボレーション ユーザーのプロパティ

@@ -104,7 +104,11 @@ PowerShell を使用して、UserType をメンバーからゲストに、また
![ユーザー設定の [外部ユーザー] オプションを示すスクリーンショット](media/user-properties/remove-guest-limitations.png)

## <a name="can-i-make-guest-users-visible-in-the-exchange-global-address-list"></a>Exchange のグローバル アドレス一覧にゲスト ユーザーを表示できますか。
はい。 既定では、ゲスト オブジェクトは組織のグローバル アドレス一覧には表示されませんが、Azure Active Directory PowerShell を使用してそれらを表示できます。 詳細については、「[Office 365 グループでゲスト アクセスを管理する](https://docs.microsoft.com/office365/admin/create-groups/manage-guest-access-in-groups?redirectSourcePath=%252fen-us%252farticle%252fmanage-guest-access-in-office-365-groups-9de497a9-2f5c-43d6-ae18-767f2e6fe6e0&view=o365-worldwide#add-guests-to-the-global-address-list)」の「**グローバル アドレス一覧にゲスト オブジェクトを表示できますか?** 」を参照してください。
はい。 既定では、ゲスト オブジェクトは組織のグローバル アドレス一覧には表示されませんが、Azure Active Directory PowerShell を使用してそれらを表示できます。 詳細については、「[Office 365 グループでゲスト アクセスを管理する](https://docs.microsoft.com/office365/admin/create-groups/manage-guest-access-in-groups)」の「**グローバル アドレス一覧にゲスト オブジェクトを表示できますか?** 」を参照してください。

## <a name="can-i-update-a-guest-users-email-address"></a>ゲスト ユーザーのメール アドレスを更新できますか。

ゲスト ユーザーが招待を承諾し、その後メール アドレスを変更した場合、新しいメールはディレクトリ内のゲスト ユーザー オブジェクトに自動的に同期されません。 メールのプロパティは、[Microsoft Graph API](https://docs.microsoft.com/graph/api/resources/user?view=graph-rest-1.0) を介して作成されます。 メールのプロパティは、Exchange 管理センターまたは [Exchange Online PowerShell](https://docs.microsoft.com/powershell/module/exchange/users-and-groups/set-mailuser?view=exchange-ps) を介して更新できます。そしてこの変更が、Azure AD のゲスト ユーザー オブジェクトに反映されます。

## <a name="next-steps"></a>次のステップ

80 ...les/active-directory/conditional-access/howto-conditional-access-policy-risk.md
View file
@@ -1,89 +1,73 @@
---
title: 条件付きアクセス - リスクベースの条件付きアクセス - Azure Active Directory
description: 条件付きアクセス ポリシーを作成して、ポリシーに対する ID 保護強化を有効にします
title: サインイン リスクベースの条件付きアクセス - Azure Active Directory
description: Identity Protection サインイン リスクを使用して条件付きアクセス ポリシーを作成する
services: active-directory
ms.service: active-directory
ms.subservice: conditional-access
ms.topic: how-to
ms.date: 05/26/2020
ms.date: 07/02/2020
ms.author: joflore
author: MicrosoftGuyJFlo
manager: daveba
ms.reviewer: calebb, rogoya
ms.collection: M365-identity-device-management
ms.openlocfilehash: b9cfba377aba30d4687bab4ba7c5a311c70c4905
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.openlocfilehash: ce687ae1f47b20bb5fff3827e7bcbd5d7edf2d83
ms.sourcegitcommit: 0100d26b1cac3e55016724c30d59408ee052a9ab
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 07/02/2020
ms.locfileid: "83995158"
ms.lasthandoff: 07/07/2020
ms.locfileid: "86024362"
---
# <a name="conditional-access-risk-based-conditional-access"></a>条件付きアクセス:リスクベースの条件付きアクセス
# <a name="conditional-access-sign-in-risk-based-conditional-access"></a>条件付きアクセス:サインイン リスクベースの条件付きアクセス

Azure AD Premium P2 のライセンスを所持する組織では、Azure AD Identity Protection の検出を組み込んだ条件付きアクセス ポリシーを作成できます。 最初から有効にできる 3 つの既定のポリシーがあります。
ほとんどのユーザーは、追跡できる正常な動作をしています。この規範から外れた場合は、そのユーザーにサインインを許可すると危険であることがあります。 そのユーザーをブロックしたり、多要素認証を実行してユーザーが本人であることを証明するように求めたりすることが必要な場合もあります。

* すべてのユーザーに対して Azure Multi-Factor Authentication への登録を必須にする。
* リスクの高いユーザーに対してパスワードの変更を必須にする。
* サインインのリスクが中以上のユーザーに対して多要素認証を必須にする。
サインイン リスクは、特定の認証要求が ID 所有者によって承認されていない可能性があることを表します。 Azure AD Premium P2 のライセンスを所持する組織では、[Azure AD Identity Protection のサインイン リスク検出](../identity-protection/concept-identity-protection-risks.md#sign-in-risk)を組み込んだ条件付きアクセス ポリシーを作成できます。

## <a name="require-all-users-to-register-for-azure-multi-factor-authentication"></a>すべてのユーザーに対して Azure Multi-Factor Authentication への登録を必須にする
このポリシーを割り当てることができる場所は 2 つあります。 組織は、セキュリティで保護されたパスワードの変更を必要とするサインイン リスクベースの条件付きアクセス ポリシーを有効にするために、次のいずれかのオプションを選択する必要があります。

このポリシーを有効にすると、すべてのユーザーが 14 日以内に Azure Multi-Factor Authentication に登録することを求められます。
## <a name="enable-with-conditional-access-policy"></a>条件付きアクセス ポリシーを有効にする

1. **Azure portal** にサインインします。
1. **[すべてのサービス]** をクリックし、 **[Azure AD Identity Protection]** に移動します。
1. **[MFA 登録]** をクリックします。
1. **[割り当て]** で、 **[ユーザー]** を選択します。
1. **Azure portal** にグローバル管理者、セキュリティ管理者、または条件付きアクセス管理者としてサインインします。
1. **[Azure Active Directory]** > **[セキュリティ]** > **[条件付きアクセス]** の順に移動します。
1. **[新しいポリシー]** を選択します。
1. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
1. **[割り当て]** で、 **[ユーザーとグループ]** を選択します。
1. **[Include]\(含める\)** で、 **[すべてのユーザー]** を選択します。
1. **[除外]** で、 **[対象外とするユーザーの選択]** を選択し、組織の緊急アクセス用または非常用アカウントを選択して、 **[選択]** を選びます。
1. **[除外]** で、 **[ユーザーとグループ]** を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
1. **[Done]** を選択します。
1. **[ポリシーの適用]** を **[オン]** に設定します。
1. **[保存]** をクリックします。

## <a name="require-a-password-change-high-risk-users"></a>リスクの高いユーザーに対してパスワードの変更を必須にする

Microsoft では、研究者、法執行機関、Microsoft のさまざまなセキュリティ チーム、その他の信頼できる情報源と協力して、ユーザー名とパスワードのペアを調査しています。 それらのペアのいずれかが環境内のアカウントに一致すると、次のポリシーを使用して、リスクベースのパスワード変更がトリガーされます。

1. **Azure portal** にサインインします。
1. **[すべてのサービス]** をクリックし、 **[Azure AD Identity Protection]** に移動します。
1. **[ユーザーのリスク ポリシー]** をクリックします。
1. **[割り当て]** で、 **[ユーザー]** を選択します。
1. **[Include]\(含める\)** で、 **[すべてのユーザー]** を選択します。
1. **[除外]** で、 **[対象外とするユーザーの選択]** を選択し、組織の緊急アクセス用または非常用アカウントを選択して、 **[選択]** を選びます。
1. **[Cloud apps or actions]\(クラウド アプリまたはアクション\)** > **[Include]\(含める\)** で、 **[すべてのクラウド アプリ]** を選択します。
1. **[条件]** > **[ユーザー リスク]** で、 **[構成]** を **[はい]** に設定します。 **[このポリシーを適用するサインイン リスク レベルを選択します]** で、以下の操作を実行します。
1. **[高]** と **[中]** を選択します。
1. **[Done]** を選択します。
1. **[条件]** の下の **[ユーザーのリスク]** を選択し、 **[高]** を選択します。
1. **[選択]** 、 **[完了]** の順にクリックします。
1. **[Controls]\(制御\)** > **[アクセス]** で、 **[アクセスを許可]** を選択し、 **[パスワードの変更を必須とする]** を選択します。
1. **[選択]** をクリックします。
1. **[ポリシーの適用]** を **[オン]** に設定します。
1. **[保存]** をクリックします。
1. **[アクセス制御]** > **[許可]** で、 **[アクセス権の付与]** 、 **[Require multi-factor authentication]\(多要素認証を要求する\)** の順に選択し、 **[Select]\(選択する\)** を選択します。
1. 設定を確認し、 **[Enable policy]\(ポリシーの有効化\)** を **[オン]** に設定します。
1. **[作成]** を選択して、ポリシーを作成および有効化します。

## <a name="require-mfa-medium-or-high-sign-in-risk-users"></a>サインインのリスクが中以上のユーザーに対して MFA を必須にする

ほとんどのユーザーは、追跡できる正常な動作をしています。この規範から外れた場合は、そのユーザーにサインインを許可すると危険であることがあります。 そのユーザーをブロックしたり、多要素認証を実行してユーザーが本人であることを証明するように求めたりすることが必要な場合もあります。 危険なサインインが検出されたときに MFA を必要とするポリシーを有効にするには、次のポリシーを有効にします。
## <a name="enable-through-identity-protection"></a>Identity Protection を有効にする

1. **Azure portal** にサインインします。
1. **[すべてのサービス]** をクリックし、 **[Azure AD Identity Protection]** に移動します。
1. **[サインインのリスク ポリシー]** をクリックします。
1. **[すべてのサービス]** を選択し、 **[Azure AD Identity Protection]** に移動します。
1. **[サインインのリスク ポリシー]** を選択します。
1. **[割り当て]** で、 **[ユーザー]** を選択します。
1. **[Include]\(含める\)** で、 **[すべてのユーザー]** を選択します。
1. **[除外]** で、 **[対象外とするユーザーの選択]** を選択し、組織の緊急アクセス用または非常用アカウントを選択して、 **[選択]** を選びます。
1. **[Done]** を選択します。
1. **[条件]** の下の **[Sign-in risk]\(サインインのリスク\)** を選択し、 **[中以上]** を選択します。
1. **[選択]** 、 **[完了]** の順にクリックします。
1. **[選択]** 、 **[完了]** の順に選択します。
1. **[Controls]\(制御\)** > **[アクセス]** で、 **[アクセスを許可]** を選択し、 **[Require multi-factor authentication]\(多要素認証を要求する\)** を選択します。
1. **[選択]** をクリックします。
1. **[選択]** を選択します。
1. **[ポリシーの適用]** を **[オン]** に設定します。
1. **[保存]** をクリックします。
1. **[保存]** を選択します。

## <a name="next-steps"></a>次のステップ

[Conditional Access common policies](concept-conditional-access-policy-common.md) (条件付きアクセスの一般的なポリシー)

[ユーザー リスクベースの条件付きアクセス](howto-conditional-access-policy-risk-user.md)

[条件付きアクセスのレポート専用モードを使用した影響を判断する](howto-conditional-access-report-only.md)

[Simulate sign in behavior using the Conditional Access What If tool](troubleshoot-conditional-access-what-if.md) (条件付きアクセスの What If ツールを使用したサインイン動作のシミュレート)

[動作のしくみ: Azure Multi-Factor Authentication](../authentication/concept-mfa-howitworks.md)」を参照してください。

[Azure Active Directory Identity Protection とは](../identity-protection/overview.md)
16 ...ctive-directory/conditional-access/howto-conditional-access-session-lifetime.md
View file
@@ -4,19 +4,19 @@ description: ユーザー サインインの頻度やブラウザー セッシ
services: active-directory
ms.service: active-directory
ms.subservice: conditional-access
ms.topic: conceptual
ms.date: 05/26/2020
ms.topic: how-to
ms.date: 06/29/2020
ms.author: joflore
author: MicrosoftGuyJFlo
manager: daveba
ms.reviewer: jlu, calebb
ms.collection: M365-identity-device-management
ms.openlocfilehash: cc75b300704ef7f8218134c9d384b0718fca1e97
ms.sourcegitcommit: 12f23307f8fedc02cd6f736121a2a9cea72e9454
ms.openlocfilehash: 2cf89864eb6e52baf925f82aa590619d7cfeabb2
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/30/2020
ms.locfileid: "84220697"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85552114"
---
# <a name="configure-authentication-session-management-with-conditional-access"></a>条件付きアクセスを使用して認証セッション管理を構成する

@@ -51,10 +51,14 @@ ms.locfileid: "84220697"
- Dynamics CRM Online
- Azure portal

サインイン頻度設定は、独自の Cookie が削除されず、定期的に認証のために Azure AD にリダイレクトされる限り、SAML アプリケーションでも機能します。

### <a name="user-sign-in-frequency-and-multi-factor-authentication"></a>ユーザーのサインイン頻度と多要素認証

以前は、サインイン頻度は、Azure AD 参加済み、Hybrid Azure AD 参加済み、Azure AD 登録済みのデバイス上での第一要素認証のみに適用されていました。 お客様がこれらのデバイスに対して多要素認証 (MFA) を再適用する簡単な方法はありませんでした。 お客様からのフィードバックに基づいて、サインイン頻度が MFA にも適用されるようになります。

[![サインインの頻度と MFA](media/howto-conditional-access-session-lifetime/conditional-access-flow-chart-small.png)](media/howto-conditional-access-session-lifetime/conditional-access-flow-chart.png#lightbox)

### <a name="user-sign-in-frequency-and-device-identities"></a>ユーザーサインインの頻度とデバイス ID

Azure AD 参加済み、ハイブリッド Azure AD 参加済み、または Azure AD 登録済みデバイスがある場合、ユーザーがデバイスのロックを解除するか、対話形式でサインインすると、このイベントはサインイン頻度ポリシーも満たします。 次の 2 つの例では、ユーザーのサインイン頻度が 1 時間に設定されています。
11 articles/active-directory/develop/active-directory-claims-mapping.md
View file
@@ -9,16 +9,16 @@ ms.service: active-directory
ms.subservice: develop
ms.custom: aaddev
ms.workload: identity
ms.topic: conceptual
ms.topic: how-to
ms.date: 10/22/2019
ms.author: ryanwi
ms.reviewer: paulgarn, hirsin, jeedes, luleon
ms.openlocfilehash: 7c462f25703b581c0882582d57fa8e5d2902dc4f
ms.sourcegitcommit: 493b27fbfd7917c3823a1e4c313d07331d1b732f
ms.openlocfilehash: d9c46368b42cac1d06f7d78d5e0d03ad2de0bada
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/21/2020
ms.locfileid: "83737505"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85478401"
---
# <a name="how-to-customize-claims-emitted-in-tokens-for-a-specific-app-in-a-tenant-preview"></a>方法:テナントの特定のアプリケーションに対するトークンに出力された要求のカスタマイズ (プレビュー)

@@ -325,6 +325,7 @@ ID 要素により、ソースのどのプロパティが要求の値を提供
| User | jobtitle | 役職 |
| User | employeeid | 従業員 ID |
| User | facsimiletelephonenumber | ファックスの電話番号 |
| User | assignedroles | ユーザーに割り当てられたアプリ ロールの一覧|
| アプリケーション、リソース、対象ユーザー | displayName | 表示名 |
| アプリケーション、リソース、対象ユーザー | objected | ObjectID |
| アプリケーション、リソース、対象ユーザー | tags | サービス プリンシパル タグ |
14 articles/active-directory/develop/msal-configuration.md
View file
@@ -7,18 +7,18 @@ author: shoatman
manager: CelesteDG
ms.service: active-directory
ms.subservice: develop
ms.topic: conceptual
ms.topic: reference
ms.workload: identity
ms.date: 09/12/2019
ms.author: shoatman
ms.custom: aaddev
ms.reviewer: shoatman
ms.openlocfilehash: 9e35ba5a3f3705a52e80262da9bbfbfda489bf83
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: f6816da35aad51e88449361d2a80542c4349ffac
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/28/2020
ms.locfileid: "80050373"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85479421"
---
# <a name="android-microsoft-authentication-library-configuration-file"></a>Android Microsoft Authentication Library 構成ファイル

@@ -34,7 +34,7 @@ Android Microsoft Authentication Library (MSAL) には[既定の構成の JSON
|-----------|------------|-------------|-------|
| `client_id` | String | はい | [アプリケーション登録ページ](https://ms.portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade)からのアプリのクライアント ID |
| `redirect_uri` | String | はい | [アプリケーション登録ページ](https://ms.portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade)からのアプリのリダイレクト URI |
| `authorities` | List\<機関> | いいえ | アプリに必要な機関の一覧 |
| `authorities` | リスト\<Authority> | いいえ | アプリに必要な機関の一覧 |
| `authorization_user_agent` | AuthorizationAgent (列挙型) | いいえ | 指定できる値: `DEFAULT`、`BROWSER`、`WEBVIEW` |
| `http` | HttpConfiguration | いいえ | `HttpUrlConnection` `connect_timeout` と `read_timeout` を構成します |
| `logging` | LoggingConfiguration | いいえ | ログ記録の詳細レベルを指定します。 オプションの構成には次のものが含まれます: `pii_enabled` (ブール値を取ります)、`log_level` (`ERROR`、`WARNING`、`INFO`、または `VERBOSE` を取ります)。 |
@@ -150,7 +150,7 @@ HTTP タイムアウトのグローバル設定を構成します。次に例を
| プロパティ | データ型 | 必須 | Notes |
| ----------|-------------|-----------|---------|
| `pii_enabled` | boolean | いいえ | 個人データを出力するかどうか |
| `log_level` | boolean | いいえ | どのログ メッセージを出力するか |
| `log_level` | string | いいえ | どのログ メッセージを出力するか。 サポートされているログレベルには、`ERROR`、`WARNING`、`INFO`、および `VERBOSE` があります。 |
| `logcat_enabled` | boolean | いいえ | ログ記録のインターフェイスに加えて、ログ cat にも出力するかどうか |

### <a name="account_mode"></a>account_mode
66 articles/active-directory/develop/msal-migration.md
View file
@@ -9,33 +9,71 @@ ms.service: active-directory
ms.subservice: develop
ms.topic: conceptual
ms.workload: identity
ms.date: 02/27/2020
ms.date: 06/16/2020
ms.author: jmprieur
ms.reviewer: saeeda
ms.custom: aaddev
ms.openlocfilehash: 3af18eb09fd9906a0caaebda0b786795400467f3
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 52a4a7131c85231107a2a23a1916016776b219fd
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/28/2020
ms.locfileid: "78165397"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85367429"
---
# <a name="migrate-applications-to-microsoft-authentication-library-msal"></a>Microsoft Authentication Library (MSAL) へのアプリケーションの移行

Azure AD エンティティを認証し、Azure AD からのトークンを要求する場合、Microsoft Authentication Library (MSAL) と Azure AD Authentication Library (ADAL) の両方が使用されます。 これまで、ほとんどの開発者は、開発者プラットフォーム用の Azure AD (v1.0) で、Azure AD Authentication Library (ADAL) を使用してトークンを要求することで、Azure AD ID (職場と学校のアカウント) を認証していました。 MSAL を使用すると、次のようになります。
多くの開発者は、Azure Active Directory Authentication Library (ADAL) を使用してアプリケーションをビルドおよびデプロイしてきました。 今後は、Azure AD エンティティの認証と承認には、Microsoft Authentication Library (MSAL) を使用することをお勧めします。

- Microsoft ID プラットフォーム エンドポイントを使用するため、より広範な Microsoft ID (Azure AD の ID と Microsoft アカウント、および Azure AD B2C 経由のソーシャル アカウントとローカル アカウント) を認証できます。
ADAL ではなく MSAL を使用することで、以下が可能になります。

- より広範な、次のような一連の ID を認証できます。
- Azure AD ID
- Microsoft アカウント
- ソーシャルおよびローカル アカウント (Azure AD B2C を使用)
- ユーザーは、最高のシングル サインオン エクスペリエンスを得られます。
- アプリケーションでは、増分同意を有効にできるほか、 Conditional Access のサポートがより簡単になります。
- イノベーションを活用できます。
- アプリケーションで、増分同意を有効にすることができます。
- 条件付きアクセスのサポートが簡単になります。
- イノベーションを活用できます。 現在、Microsoft のすべての開発の取り組みは MSAL に重点を置いているため、ADAL に新しい機能は実装されません。

**MSAL は、Microsoft ID プラットフォームと併せて使用する場合にお勧めの認証ライブラリです**。 ADAL には新しい機能は実装されません。 この取り組みは、MSAL の改良に重点を置いています。
**MSAL は、Microsoft ID プラットフォームと併せて使用する際にお勧めの認証ライブラリです**。

## <a name="migration-guidance"></a>移行ガイダンス

次の記事は、MSAL への移行に役立ちます。

次のアーティクルでは、MSAL ライブラリと ADAL ライブラリの違いについて説明し、MSAL への移行を支援します。
- [MSAL.NET への移行](msal-net-migration.md)
- [MSAL.js への移行](msal-compare-msal-js-and-adal-js.md)
- [MSAL.Android への移行](migrate-android-adal-msal.md)
- [MSAL.iOS / macOS への移行](migrate-objc-adal-msal.md)
- [MSAL Java への移行](migrate-adal-msal-java.md)
- [MSAL.js への移行](msal-compare-msal-js-and-adal-js.md)
- [MSAL.NET への移行](msal-net-migration.md)
- [MSAL Python への移行](migrate-python-adal-msal.md)
- [MSAL for Java への移行](migrate-adal-msal-java.md)
- [ブローカーを使用する Xamarin アプリの MSAL.NET への移行](msal-net-migration-ios-broker.md)

## <a name="frequently-asked-questions-faq"></a>よく寄せられる質問 (FAQ)

__Q:ADAL は非推奨となる予定ですか?__
A:はい。 2020 年 6 月 30 日以降、ADAL に新機能は追加されなくなります。 2022 年 6 月 30 日までは、引き続き ADAL の重要なセキュリティ修正プログラムを追加します。

__Q:どのアプリで ADAL を使用しているかを知る方法はありますか?__
A:アプリケーションのソース コードがある場合は、上記の移行ガイドを参照して、アプリで使用しているライブラリを判別し、それを MSAL に移行する方法を確認できます。 アプリケーションのソース コードにアクセスできない場合は、[サポート リクエストを開いて](developer-support-help-options.md#open-a-support-request)、登録されているアプリケーションと各アプリケーションで使用されているライブラリの一覧を取得することができます。

__Q:既存の ADAL アプリは引き続き動作しますか。__
A:既存のアプリは、変更せずとも引き続き動作します。 2022 年 6 月 30 日以降も運用する予定がある場合は、その安全性を確保するために MSAL に更新することを検討してください。ただし、既存の機能を維持する上で、MSAL への移行は必須ではありません。

__Q:MSAL への移行に投資すべき理由を教えてください。__
A:MSAL には、増分同意、シングル サインオン、トークン キャッシュ管理など、ADAL には含まれない新機能が含まれています。 また、ADAL とは異なり、MSAL は 2022 年 6 月 30 日以降のセキュリティ更新プログラムを引き続き受けることができます。 [詳細については、こちらを参照してください](msal-overview.md)。

__Q:ADAL から MSAL にアプリを移行するのに役立つツールはリリースされますか?__
A:いいえ。 ライブラリ間の違いにより、そのようなツールの開発やメンテナンスには、MSAL の改良に当てられるリソースをつぎ込む必要があります。 ただし、アプリケーションで必要な変更を行うための、前述の一連の移行ガイドを提供致します。

__Q:MSAL と AD FS の連携方法について教えてください。__
A:MSAL.NET では、AD FS 2019 に対して認証する特定のシナリオがサポートされています。 アプリで以前のバージョンの AD FS から直接トークンを取得する必要がある場合は、ADAL 上に残す必要があります。 [詳細については、こちらを参照してください](msal-net-adfs-support.md)。

__Q:アプリケーションの移行に関するヘルプを受けるにはどうすればよいですか?__
A:この記事の「[移行ガイダンス](#migration-guidance)」を参照してください。 アプリのプラットフォームに関するこのガイドを読んだ後も、さらに質問がある場合は、タグ `[adal-deprecation]` を使用して Stack Overflow に投稿するか、ライブラリの GitHub リポジトリで問題を開いてください。 各ライブラリのリポジトリへのリンクについては、MSAL の概要に関する記事の「[言語とフレームワーク](msal-overview.md#languages-and-frameworks)」セクションを参照してください。

## <a name="next-steps"></a>次のステップ

- [Microsoft 認証ライブラリと Microsoft Graph API を使用するようにアプリケーションを更新する](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/update-your-applications-to-use-microsoft-authentication-library/ba-p/1257363)
- [Microsoft ID プラットフォーム (MSAL) の詳細を確認する](https://docs.microsoft.com/azure/active-directory/develop/v2-overview)
- [MSAL コード サンプルを確認する](https://docs.microsoft.com/azure/active-directory/develop/sample-v2-code)
16 articles/active-directory/develop/single-sign-on-saml-protocol.md
View file
@@ -14,12 +14,12 @@ ms.date: 05/18/2020
ms.author: ryanwi
ms.custom: aaddev
ms.reviewer: hirsin
ms.openlocfilehash: 155816a9cd171b42e1def5cafa09cb9e310d5ee7
ms.sourcegitcommit: 318d1bafa70510ea6cdcfa1c3d698b843385c0f6
ms.openlocfilehash: a68c0248ce364be486610c406388586b69cbb3f4
ms.sourcegitcommit: 124f7f699b6a43314e63af0101cd788db995d1cb
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/21/2020
ms.locfileid: "83771674"
ms.lasthandoff: 07/08/2020
ms.locfileid: "86076948"
---
# <a name="single-sign-on-saml-protocol"></a>シングル サインオンの SAML プロトコル

@@ -46,7 +46,7 @@ xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
</samlp:AuthnRequest>
```

| パラメーター | | 説明 |
| パラメーター | Type | 説明 |
| --- | --- | --- |
| id | 必須 | Azure AD はこの属性を使用して、返される応答の `InResponseTo` 属性を設定します。 ID の 1 文字目に数字を使用することはできないので、一般的な方法としては、GUID の文字列表現の前に "id" のような文字列を付加します。 たとえば、 `id6c1c178c166d486687be4aaf5e482730` は有効な ID です。 |
| Version | 必須 | このパラメーターは **2.0** に設定する必要があります。 |
@@ -86,6 +86,8 @@ Azure AD は、`AuthnRequest` の `Conditions` 要素も無視します。
* `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`:この値は、Azure Active Directory が要求の形式を選択することを許可します。 Azure Active Directory は、一対の識別子として NameID 要求を発行します。
* `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`:Azure Active Directory は、現在の SSO 操作に固有となる無作為に生成された値として NameID 要求を発行します。 つまり、値は一時的であり、認証ユーザーの識別に使うことはできません。

`SPNameQualifier` が指定されている場合は、Azure AD により、応答に同じ `SPNameQualifier` が含められます。

Azure AD は `AllowCreate` 属性を無視します。

### <a name="requestauthncontext"></a>RequestAuthnContext
@@ -97,7 +99,7 @@ ID プロバイダーのリストが含まれる `Scoping` 要素は、Azure AD
指定する場合は、`ProxyCount` 属性、`IDPListOption` 要素、または `RequesterID` 要素を使用しないでください。これらはサポートされていません。

### <a name="signature"></a>署名
`AuthnRequest` 要素に `Signature` 要素を含めないでください。 Azure AD は、署名された認証要求を検証しません。 要求元の検証は、登録されている Assertion Consumer Service の URL に応答することによってのみ提供されます。
`AuthnRequest` 要素内の `Signature` 要素は省略可能です。 Azure AD では、署名がある場合は署名済みの認証要求の検証を行いません。 要求元の検証は、登録されている Assertion Consumer Service の URL に応答することによってのみ提供されます。

### <a name="subject"></a>サブジェクト
`Subject` 要素を含めないでください。 Azure AD は、要求のサブジェクトの指定をサポートしていません。指定した場合は、エラーが返されます。
@@ -157,7 +159,7 @@ ID プロバイダーのリストが含まれる `Scoping` 要素は、Azure AD

### <a name="issuer"></a>発行者

Azure AD は、`Issuer` 要素を `https://sts.windows.net/<TenantIDGUID>/` に設定します。\<TenantIDGUID> は、Azure AD テナントのテナント ID です。
Azure AD は、`Issuer` 要素を `https://sts.windows.net/<TenantIDGUID>/` に設定します。\<TenantIDGUID> は、Azure AD テナントのテナント ID です。

たとえば、Issuer 要素を含む応答の例は次のようになります。

11 articles/active-directory/fundamentals/active-directory-deployment-plans.md
View file
@@ -12,12 +12,12 @@ ms.date: 08/20/2019
ms.author: ajburnle
ms.custom: it-pro, seodec18
ms.collection: M365-identity-device-management
ms.openlocfilehash: d7a596454a48a1d6fcee77634363dd38f34a4d58
ms.sourcegitcommit: 849bb1729b89d075eed579aa36395bf4d29f3bd9
ms.openlocfilehash: c439bbded7fe55f1edd5eb1597f98b339e340956
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/28/2020
ms.locfileid: "81603346"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85386336"
---
# <a name="azure-active-directory-deployment-plans"></a>Azure Active Directory のデプロイ計画
ここでは、Azure Active Directory (Azure AD) の機能のデプロイについてのエンド ツー エンドのガイダンスを紹介しています。 Azure AD のデプロイ計画では、Azure AD の代表的な機能について、そのビジネス上の価値や計画の考慮事項、正しくデプロイするうえで必要な運用手順をひととおり説明しています。
@@ -66,12 +66,13 @@ ms.locfileid: "81603346"
| [セルフサービス パスワード リセット](../authentication/howto-sspr-deployment.md)| セルフサービス パスワード リセット により、ユーザーは、必要に応じていつでも、どこでも、管理者の介入なしでパスワードをリセットできます。 |
| [パスワードレス](../authentication/howto-authentication-passwordless-deployment.md) | 組織内の Microsoft Authenticator アプリまたは FIDO2 セキュリティ キーを使用してパスワードレス認証を実装します。 |

## <a name="deploy-application-management"></a>アプリケーション管理のデプロイ
## <a name="deploy-application-and-device-management"></a>アプリケーションおよびデバイス管理のデプロイ

| 機能 | 説明|
| -| - |
| [シングル サインオン](../manage-apps/plan-sso-deployment.md)| シングル サインオンは、ユーザーが 1 回サインインするだけで作業に必要なアプリとリソースにアクセスできる機能です。 サインインすると、資格情報をもう一度入力する必要なしに、Microsoft Office から SalesForce、Box、さらには内部アプリケーションにアクセスできるようになります。 |
| [アクセス パネル](../manage-apps/access-panel-deployment-plan.md)| すべてのアプリケーションを検出し、それにアクセスするための単純なハブをユーザーに提供します。 ユーザーが、アプリやグループへのアクセスを要求したり、他のユーザーに代わってリソースへのアクセスを管理したりするなどのセルフサービス機能を使用して生産性を向上できるようにします。 |
| [デバイス](../devices/plan-device-deployment.md) | この記事は、デバイスを Azure AD と統合する方法を評価し、実装計画を選択するのに役立ちます。また、サポートされているデバイス管理ツールへの主要なリンクを提供します。 |


## <a name="deploy-hybrid-scenarios"></a>ハイブリッド シナリオのデプロイ
11 ...ive-directory/fundamentals/concept-fundamentals-continuous-access-evaluation.md
View file
@@ -11,12 +11,12 @@ author: MicrosoftGuyJFlo
manager: daveba
ms.reviewer: jlu
ms.collection: M365-identity-device-management
ms.openlocfilehash: bdf904bb2c0d133ea07cd32274fad5b6601da5d9
ms.sourcegitcommit: 2721b8d1ffe203226829958bee5c52699e1d2116
ms.openlocfilehash: f0cb402741163c657b3e7961eb5a4f9c8e18dafd
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/28/2020
ms.locfileid: "84148125"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84673022"
---
# <a name="continuous-access-evaluation"></a>継続的アクセス評価

@@ -40,6 +40,7 @@ Microsoft では、継続的アクセス評価の最初の実装について、E

- ユーザーアカウントが削除または無効化された
- ユーザーのパスワードが変更またはリセットされた
- MFA がユーザーに対して有効になっている
- 管理者が、ユーザーのすべての更新トークンを明示的に取り消した
- Azure AD Identity Protection によって管理者特権のユーザー リスクが検出された

@@ -76,7 +77,7 @@ CAE セッションでは、アクセス トークンの有効期間が 24 時
1. リソース プロバイダーにアクセス トークンが提示されます。 リソース プロバイダーは、トークンの有効性を評価し、ユーザーの失効イベントがあるかどうかを確認します。 リソース プロバイダーは、この情報を使用して、リソースへのアクセスを許可するかどうかを決定します。
1. この場合、リソース プロバイダーはアクセスを拒否し、401+ 要求チャレンジをクライアントに送り返します
1. CAE 対応クライアントは、401+ 要求チャレンジを認識します。 キャッシュをバイパスし、手順 1 に戻り、要求チャレンジと共に更新トークンを Azure AD に送り返します。 その後、Azure AD ですべての条件が再評価され、この場合はユーザーに再認証を求めるメッセージが表示されます。
 

## <a name="faqs"></a>FAQ

### <a name="what-is-the-lifetime-of-my-access-token"></a>アクセス トークンの有効期間はどれくらいですか。
27 articles/active-directory/hybrid/how-to-connect-install-automatic-upgrade.md
View file
@@ -9,19 +9,19 @@ editor: ''
ms.assetid: 6b395e8f-fa3c-4e55-be54-392dd303c472
ms.service: active-directory
ms.devlang: na
ms.topic: conceptual
ms.topic: how-to
ms.tgt_pltfrm: na
ms.workload: identity
ms.date: 05/18/2020
ms.date: 06/09/2020
ms.subservice: hybrid
ms.author: billmath
ms.collection: M365-identity-device-management
ms.openlocfilehash: a05de8bf6a6e4ab79e63d6634ddb1b79fae6045f
ms.sourcegitcommit: 50673ecc5bf8b443491b763b5f287dde046fdd31
ms.openlocfilehash: 749c97549661f2b2d647f8f7ba718d7696ef8355
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/20/2020
ms.locfileid: "83680223"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85359009"
---
# <a name="azure-ad-connect-automatic-upgrade"></a>Azure AD Connect:自動アップグレード
この機能は、ビルド [ 1.1.105.0 (2016 年 2 月リリース) で導入されました](reference-connect-version-history.md#111050)。 この機能は[ビルド 1.1.561](reference-connect-version-history.md#115610) で更新され、以前サポートされていなかった追加のシナリオがサポートされています。
@@ -57,6 +57,10 @@ Azure AD Connect のインストールを常に最新の状態に保つことは

問題が生じていると思われる場合は、最初に `Get-ADSyncAutoUpgrade` を実行して、自動アップグレードが有効になっていることを確認してください。

状態が中断になっている場合は、`Get-ADSyncAutoUpgrade -Detail` を使用して理由を表示できます。 中断の理由には任意の文字列値を含めることができますが、通常は UpgradeResult の文字列値 (つまり、`UpgradeNotSupportedNonLocalDbInstall` または `UpgradeAbortedAdSyncExeInUse`) が格納されます。 `UpgradeFailedRollbackSuccess-GetPasswordHashSyncStateFailed` などの複合値が返される場合もあります。

また、UpgradeResult ではない結果 (つまり、"AADHealthEndpointNotDefined" または "DirSyncInPlaceUpgradeNonLocalDb") を取得する場合もあります。

その後、プロキシまたはファイアウォールで必要な URL を開いていることを確認してください。 自動更新では、「 [概要](#overview)」で説明されているように、Azure AD Connect Health が使用されています。 プロキシを使用する場合は、 [プロキシ サーバー](how-to-connect-health-agent-install.md#configure-azure-ad-connect-health-agents-to-use-http-proxy)を使用するよう Health が構成されていることを確認します。 また、Azure AD に対する [Health の接続](how-to-connect-health-agent-install.md#test-connectivity-to-azure-ad-connect-health-service) もテストします。

Azure AD への接続が確認されたら、イベント ログを調査します。 イベント ビューアーを起動し、 **[アプリケーション]** イベントログを確認します。 ソースとして **[Azure AD Connect Upgrade (Azure AD Connect のアップグレード)]** を選択し、イベント ID 範囲に「**300-399**」を指定したイベント ログ フィルターを追加します。
@@ -89,18 +93,11 @@ Azure AD への接続が確認されたら、イベント ログを調査しま
| UpgradeAbortedSyncExeInUse |サーバーで [Sychronization Service Manager UI](how-to-connect-sync-service-manager-ui.md) が開いています。 |
| UpgradeAbortedSyncOrConfigurationInProgress |インストール ウィザードが実行されているか、同期がスケジューラ以外の場所でスケジュールされました。 |
| **UpgradeNotSupported** | |
| UpgradeNotSupportedAdfsSignInMethod | ユーザーがサインイン方法として Adfs を選択しました。 |
| UpgradeNotSupportedCustomizedSyncRules |ユーザーが構成に独自のカスタム ルールを追加しました。 |
| UpgradeNotSupportedDeviceWritebackEnabled |ユーザーが [デバイスの書き戻し](how-to-connect-device-writeback.md) 機能を有効にしました。 |
| UpgradeNotSupportedGroupWritebackEnabled |グループの書き戻し機能を有効にしました。 |
| UpgradeNotSupportedInvalidPersistedState |インストールが簡単設定でも DirSync のアップグレードでもありません。 |
| UpgradeNotSupportedMetaverseSizeExceeeded |メタバース内のオブジェクトが 100,000 を超えています。 |
| UpgradeNotSupportedMultiForestSetup |現在、複数のフォレストに接続しています。 高速セットアップで接続するフォレストは 1 つのみです。 |
| UpgradeNotSupportedNonLocalDbInstall |SQL Server Express LocalDB データベースが使用されていません。 |
| UpgradeNotSupportedNonMsolAccount |[AD DS Connector アカウント](reference-connect-accounts-permissions.md#ad-ds-connector-account)は、既定の MSOL_ アカウントではなくなりました。 |
| UpgradeNotSupportedNotConfiguredSignInMethod | AAD Connect を設定する場合は、サインオン方法の選択時に *[構成しない]* を選択します。 |
| UpgradeNotSupportedStagingModeEnabled |サーバーが [ステージング モード](how-to-connect-sync-staging-server.md)に設定されています。 |
| UpgradeNotSupportedUserWritebackEnabled |ユーザーが [ユーザーの書き戻し](how-to-connect-preview.md#user-writeback) 機能を有効にしました。 |
|UpgradeNotSupportedLocalDbSizeExceeded|ローカル DB のサイズが 8 GB 以上です。|
|UpgradeNotSupportedAADHealthUploadDisabled|正常性データのアップロードがポータルから無効になっています。|

## <a name="next-steps"></a>次のステップ
「 [オンプレミス ID と Azure Active Directory の統合](whatis-hybrid-identity.md)」をご覧ください。
27 articles/active-directory/hybrid/howto-troubleshoot-upn-changes.md
View file
@@ -11,21 +11,22 @@ author: barbaraselden
manager: daveba
ms.reviewer: jsimmons
ms.collection: M365-identity-device-management
ms.openlocfilehash: d11be1d971922095d4a1ace1c81c763134b4e58c
ms.sourcegitcommit: bd5fee5c56f2cbe74aa8569a1a5bce12a3b3efa6
ms.openlocfilehash: 885d30305ba2b186052e17b9b455b2248bca541b
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/06/2020
ms.locfileid: "80743321"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85608519"
---
# <a name="plan-and-troubleshoot-user-principal-name-changes-in-azure-active-directory"></a>Azure Active Directory でのユーザー プリンシパル名の変更の計画とトラブルシューティング

ユーザー プリンシパル名 (UPN) は、ユーザー アカウントのインターネット通信標準である属性です。 UPN は、UPN プレフィックス (ユーザー アカウント名) と UPN サフィックス (DNS ドメイン名) とから成ります。 プレフィックスとサフィックスは、"@" 記号を使用して結合されます。 たとえば、「 someone@example.com 」のように入力します。 UPN は、ディレクトリ フォレスト内のすべてのセキュリティ プリンシパル オブジェクトの中で一意であることが必要です。

**この記事では、ユーザー識別子として UPN を使用していることを前提としています。UPN の変更の計画と、UPN の変更によって発生する可能性がある問題からの復旧について説明します。**

> [!NOTE]
> 開発者には、変更不可の識別子として、UPN ではなくユーザーの objectID を使用することをお勧めします。 アプリケーションで現在 UPN を使用している場合は、エクスペリエンスを向上させるため、ユーザーのプライマリ電子メール アドレスと一致するように UPN を設定することをお勧めします。<br> **ハイブリッド環境では、ユーザーの UPN がオンプレミスのディレクトリと Azure Active Directory で同一であることが重要です**。
> UPN またはメール アドレスは値が変更される可能性があるため、開発者には変更不可の識別子としてユーザーの objectID を使用することをお勧めします。
**この記事では、ユーザー識別子として UPN を使用していることを前提としています。UPN の変更の計画と、UPN の変更によって発生する可能性がある問題からの復旧について説明します。**

## <a name="learn-about-upns-and-upn-changes"></a>UPN と UPN の変更について理解する
サインイン ページでは、必要な値が実際には UPN であるときに、ユーザーにメール アドレスの入力を求めることがよくあります。 そのため、プライマリ メール アドレスが変更されるたびに、ユーザーの UPN を変更する必要があります。
@@ -60,7 +61,7 @@ ms.locfileid: "80743321"
または<br>
* Britta.Simon@labs.contoso.com に対して Britta.Simon@corp.contoso.com を行います

ユーザーのプライマリ メール アドレスが更新されるたびに、ユーザーの UPN を変更します。 メール アドレスの変更の理由に関係なく、UPN は常に一致するように更新する必要があります。
プライマリ メール アドレスが更新されるたびに、ユーザーの UPN を変更することをお勧めします。

Active Directory から Azure AD への初期同期中に、ユーザーのメール アドレスが UPN と同じであることを確認します。

@@ -74,10 +75,10 @@ username@contoso.com

たとえば、labs.contoso.com を追加し、ユーザーの UPN とメール アドレスにそれを反映させることができます。 この場合、次のようになります

username@labs.contoso.com
username@labs.contoso.com.

>[!IMPORTANT]
> Active Directory と Azure Active Directory の UPN が一致しない場合、問題が発生します。 [Active Directory でサフィックスを変更](https://docs.microsoft.com/azure/active-directory/fundamentals/add-custom-domain)した場合は、一致するカスタム ドメイン名を [Azure AD に追加して検証する](https://docs.microsoft.com/azure/active-directory/fundamentals/add-custom-domain)必要があります。
> [Active Directory でサフィックスを変更](https://docs.microsoft.com/azure/active-directory/fundamentals/add-custom-domain)した場合は、一致するカスタム ドメイン名を [Azure AD に追加して検証する](https://docs.microsoft.com/azure/active-directory/fundamentals/add-custom-domain)必要があります。
![検証済みドメインのスクリーンショット](./media/howto-troubleshoot-upn-changes/custom-domains.png)

@@ -130,11 +131,15 @@ UPN の一括変更については、[パイロットのベスト プラクテ
**既知の問題** <br>
認証を Azure AD に依存するアプリケーションで、シングル サインオンに関する問題が発生する可能性があります。

**解決策** <br>
この項で説明した問題は、2020 年 5 月の Windows 10 更新プログラム (2004) で修正されました。

**回避策** <br>
UPN の変更が Azure AD に同期されるのに十分な時間を確保します。 新しい UPN が Azure AD ポータルに反映されたことを確認した後、[その他のユーザー] タイルを選択して新しい UPN でサインインするようにユーザーに依頼します。 [PowerShell](https://docs.microsoft.com/powershell/module/azuread/get-azureaduser?view=azureadps-2.0) を使用して確認することもできます。 新しい UPN でサインインした後も、古い UPN への参照により、[職場または学校へのアクセス] という Windows の設定が表示される場合があります。

![検証済みドメインのスクリーンショット](./media/howto-troubleshoot-upn-changes/other-user.png)


### <a name="hybrid-azure-ad-joined-devices"></a>ハイブリッド Azure AD 参加済みデバイス

[ハイブリッド Azure AD 参加済み](https://docs.microsoft.com/azure/active-directory/devices/concept-azure-ad-join-hybrid)デバイスは、Active Directory と Azure AD に参加しています。 環境にオンプレミスの Active Directory フットプリントがあり、Azure AD によって提供される機能も利用したい場合は、Hybrid Azure AD 参加済みデバイスを実装できます。
@@ -149,6 +154,9 @@ Windows 10 の Hybrid Azure AD 参加済みデバイスでは、予期しない

"PC は 1 分で自動的に再起動されます。 Windows で問題が発生したため、再起動する必要があります。 今すぐこのメッセージを閉じて、作業中のデータを保存してください。"

**解決策** <br>
この項で説明した問題は、2020 年 5 月の Windows 10 更新プログラム (2004) で修正されました。

**回避策**

デバイスの Azure AD への参加を解除し、再起動する必要があります。 再起動後、デバイスは自動的に Azure AD に再び参加します。ユーザーは、[その他のユーザー] タイルを選択し、新しい UPN を使用してサインインする必要があります。 デバイスの Azure AD への参加を解除するには、コマンド プロンプトで次のコマンドを実行します。
@@ -157,6 +165,7 @@ Windows 10 の Hybrid Azure AD 参加済みデバイスでは、予期しない

Windows Hello for Business が使用されている場合、ユーザーは[再登録する](https://docs.microsoft.com/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision)必要があります。 Windows 7 および8.1 のデバイスは、UPN 変更後のこの問題による影響を受けません。


## <a name="microsoft-authenticator-known-issues-and-workarounds"></a>Microsoft Authenticator に関する既知の問題と回避策

組織では、組織のアプリケーションやデータへのサインインとアクセスに、[Microsoft Authenticator アプリ](https://docs.microsoft.com/azure/active-directory/user-help/user-help-auth-app-overview)の使用が要求されている場合があります。 アプリにユーザー名が表示される場合でも、ユーザーが登録プロセスを完了するまで、アカウントは検証方法として機能するように設定されません。
52 articles/active-directory/manage-apps/add-non-gallery-app.md
View file
@@ -2,22 +2,22 @@
title: ギャラリー以外のアプリケーションの追加 - Microsoft ID プラットフォーム | Microsoft Docs
description: Azure AD テナントにギャラリー以外のアプリケーションを追加します。
services: active-directory
author: msmimart
manager: CelesteDG
author: kenwith
manager: celestedg
ms.service: active-directory
ms.subservice: app-mgmt
ms.topic: article
ms.topic: how-to
ms.workload: identity
ms.date: 10/24/2019
ms.author: mimart
ms.author: kenwith
ms.reviewer: arvinh,luleon
ms.collection: M365-identity-device-management
ms.openlocfilehash: bd5a5f100dbe09c3b82f58183a118ee3bf455f70
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: cbefcec884fcf179c182cd50efeb58a0fc357378
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "77063613"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85555132"
---
# <a name="add-an-unlisted-non-gallery-application-to-your-azure-ad-organization"></a>一覧にない (ギャラリー以外の) アプリケーションを Azure AD 組織に追加する

@@ -54,7 +54,7 @@ ms.locfileid: "77063613"
>* **[オンプレミスのアプリケーションへのセキュリティで保護されたリモート アクセス用のアプリケーション プロキシを構成します]** を選択すると、Azure AD アプリケーション プロキシとコネクタの構成ページが開きます。
>* **[操作中のアプリケーションを登録して Azure AD と統合します]** を選択すると、 **[アプリの登録]** ページが開きます。 このオプションは、通常、OpenID Connect アプリケーションに対して使用します。
7. **作成** を選択します。 アプリケーションの **[概要]** ページが開きます。
7. **［作成］** を選択します アプリケーションの **[概要]** ページが開きます。

## <a name="configure-user-sign-in-properties"></a>ユーザーのサインイン プロパティを構成する

@@ -70,31 +70,31 @@ ms.locfileid: "77063613"

**割り当てられている**ユーザーの動作:

| アプリケーション プロパティの設定 | | | 割り当てられているユーザーのエクスペリエンス | |
| アプリケーション プロパティ | アプリケーション プロパティ | アプリケーション プロパティ | 割り当てられているユーザーのエクスペリエンス | 割り当てられているユーザーのエクスペリエンス |
|---|---|---|---|---|
| ユーザーのサインインが有効になっていますか? | ユーザーの割り当てが必要ですか? | ユーザーに表示しますか? | 割り当てられているユーザーはサインインできますか? | 割り当てられているユーザーにアプリケーションが表示されますか?* |
| はい | はい | はい | はい | はい |
| はい | はい | いいえ | はい | いいえ |
| はい | いいえ | はい | はい | はい |
| はい | いいえ | いいえ | はい | いいえ |
| いいえ | はい | はい | いいえ | いいえ |
| いいえ | はい | いいえ | いいえ | いいえ |
| いいえ | いいえ | はい | いいえ | いいえ |
| いいえ | いいえ | いいえ | いいえ | いいえ |
| はい | はい | no | はい | no |
| はい | no | はい | はい | はい |
| はい | no | no | はい | no |
| no | はい | はい | no | no |
| no | はい | no | no | no |
| no | no | はい | no | no |
| no | no | no | no | no |

**割り当てられていない**ユーザーの動作:

| アプリケーション プロパティの設定 | | | 割り当てられていないユーザーのエクスペリエンス | |
| アプリケーション プロパティ | アプリケーション プロパティ | アプリケーション プロパティ | 割り当てられていないユーザーのエクスペリエンス | 割り当てられていないユーザーのエクスペリエンス |
|---|---|---|---|---|
| ユーザーのサインインが有効になっていますか? | ユーザーの割り当てが必要ですか? | ユーザーに表示しますか? | 割り当てられていないユーザーはサインインできますか? | 割り当てられていないユーザーにアプリケーションが表示されますか?* |
| はい | はい | はい | いいえ | いいえ |
| はい | はい | いいえ | いいえ | いいえ |
| はい | いいえ | はい | はい | いいえ |
| はい | いいえ | いいえ | はい | いいえ |
| いいえ | はい | はい | いいえ | いいえ |
| いいえ | はい | いいえ | いいえ | いいえ |
| いいえ | いいえ | はい | いいえ | いいえ |
| いいえ | いいえ | いいえ | いいえ | いいえ |
| はい | はい | はい | no | no |
| はい | はい | no | no | no |
| はい | no | はい | はい | no |
| はい | no | no | はい | no |
| no | はい | はい | no | no |
| no | はい | no | no | no |
| no | no | はい | no | no |
| no | no | no | no | no |

\* ユーザーのアクセス パネルと Office 365 アプリ ランチャーにアプリケーションが表示されますか?

12 ...e-directory/managed-identities-azure-resources/how-to-manage-ua-identity-arm.md
View file
@@ -9,18 +9,18 @@ editor: ''
ms.service: active-directory
ms.subservice: msi
ms.devlang: na
ms.topic: conceptual
ms.topic: how-to
ms.tgt_pltfrm: na
ms.workload: identity
ms.date: 12/10/2019
ms.author: markvi
ms.collection: M365-identity-device-management
ms.openlocfilehash: 244965da4e22c0808fd1ea9088aa182b27eaf484
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 466b0853648fab078af89f01a9aea157205e81d1
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/28/2020
ms.locfileid: "79227747"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85608485"
---
# <a name="create-list-and-delete-a-user-assigned-managed-identity-using-azure-resource-manager"></a>Azure Resource Manager を使用してユーザー割り当てマネージド ID を作成、一覧表示、削除する

@@ -35,7 +35,7 @@ Azure Resource Manager テンプレートを使用して、ユーザー割り当
- [ユーザー割り当てマネージド ID を削除する](how-to-manage-ua-identity-cli.md#delete-a-user-assigned-managed-identity)
## <a name="prerequisites"></a>前提条件

- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#how-does-the-managed-identities-for-azure-resources-work)を必ず確認してください**。
- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#managed-identity-types)を必ず確認してください**。
- まだ Azure アカウントを持っていない場合は、[無料のアカウントにサインアップ](https://azure.microsoft.com/free/)してから先に進んでください。

## <a name="template-creation-and-editing"></a>テンプレートの作成と編集
16 ...-directory/managed-identities-azure-resources/how-to-manage-ua-identity-rest.md
View file
@@ -1,6 +1,6 @@
---
title: REST を使用してユーザー割り当てマネージド ID を管理する - Azure AD
description: REST API 呼び出すためのユーザー割り当てマネージド ID を作成、一覧表示、削除する詳細な手順。
description: REST API を呼び出すためのユーザー割り当てマネージド ID を作成、一覧表示、削除する詳細な手順。
services: active-directory
documentationcenter: ''
author: MarkusVi
@@ -9,18 +9,18 @@ editor: ''
ms.service: active-directory
ms.subservice: msi
ms.devlang: na
ms.topic: conceptual
ms.topic: how-to
ms.tgt_pltfrm: na
ms.workload: identity
ms.date: 06/26/2018
ms.author: markvi
ms.collection: M365-identity-device-management
ms.openlocfilehash: 39e108451e4c19e77e01b5bcc5d8dd21e86ad73a
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 2c342359b015085804b127ef8c58aca8a4b13dcf
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "74547426"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85608468"
---
# <a name="create-list-or-delete-a-user-assigned-managed-identity-using-rest-api-calls"></a>REST API 呼び出しを使用して、ユーザー割り当てマネージド ID を作成、一覧表示、削除する

@@ -32,7 +32,7 @@ Azure リソースのマネージド ID を使用すれば、Azure サービス

## <a name="prerequisites"></a>前提条件

- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#how-does-the-managed-identities-for-azure-resources-work)を必ず確認してください**。
- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#managed-identity-types)を必ず確認してください**。
- まだ Azure アカウントを持っていない場合は、[無料のアカウントにサインアップ](https://azure.microsoft.com/free/)してから先に進んでください。
- Windows を使用している場合は、[Windows Subsystem for Linux](https://msdn.microsoft.com/commandline/wsl/about) をインストールするか、Azure Portal で [Azure Cloud Shell](../../cloud-shell/overview.md) を使用します。
- [Windows Subsystem for Linux](https://msdn.microsoft.com/commandline/wsl/about) または [Linux ディストリビューション OS](/cli/azure/install-azure-cli-apt?view=azure-cli-latest) を使用する場合は、[Azure CLI ローカル コンソール](/cli/azure/install-azure-cli)をインストールします。
@@ -67,7 +67,7 @@ s/<RESOURCE GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<U

**要求本文**

|Name |説明 |
|名前 |説明 |
|---------|---------|
|location | 必須。 リソースの場所。 |

14 ...es/active-directory/managed-identities-azure-resources/how-to-use-vm-sign-in.md
View file
@@ -1,5 +1,5 @@
---
title: Azure VM 上でマネージド ID を使用してサインインする - Azure AD
title: Azure VM 上でマネージド ID を使用してサインインする - Azure ADV
description: Azure リソース サービス プリンシパルの Azure VM マネージド ID を使用して、スクリプト クライアントのサインインとリソースへのアクセスを行うための手順を追った説明と例。
services: active-directory
documentationcenter: ''
@@ -9,18 +9,18 @@ editor: ''
ms.service: active-directory
ms.subservice: msi
ms.devlang: na
ms.topic: conceptual
ms.topic: how-to
ms.tgt_pltfrm: na
ms.workload: identity
ms.date: 12/01/2017
ms.author: markvi
ms.collection: M365-identity-device-management
ms.openlocfilehash: 34f4dc749c0254b5aa4e9ff018d2a869832de3f0
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 1380562cfc073d906ea4cfc0d6d849e9ca2a70d3
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "74547389"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85608417"
---
# <a name="how-to-use-managed-identities-for-azure-resources-on-an-azure-vm-for-sign-in"></a>Azure VM 上の Azure リソースのマネージド ID を使用してサインインする方法

@@ -41,7 +41,7 @@ ms.locfileid: "74547389"
## <a name="overview"></a>概要

Azure リソースのマネージド ID は、[サービス プリンシパル オブジェクト](../develop/developer-glossary.md#service-principal-object)を提供します。これは、VM 上で [Azure リソースのマネージド ID を有効にしたときに作成](overview.md#how-does-the-managed-identities-for-azure-resources-work)されます。 サービス プリンシパルに Azure のリソースへのアクセス権を付与し、スクリプトまたはコマンドライン クライアントがサインインおよびリソースにアクセスするための ID として使用できます。 従来では、独自の ID でセキュリティで保護されたリソースにアクセスするには、スクリプト クライアントは以下を実行する必要がありました。
Azure リソースのマネージド ID は、[サービス プリンシパル オブジェクト](../develop/developer-glossary.md#service-principal-object)を提供します。これは、VM 上で [Azure リソースのマネージド ID を有効にしたときに作成](overview.md)されます。 サービス プリンシパルに Azure のリソースへのアクセス権を付与し、スクリプトまたはコマンドライン クライアントがサインインおよびリソースにアクセスするための ID として使用できます。 従来では、独自の ID でセキュリティで保護されたリソースにアクセスするには、スクリプト クライアントは以下を実行する必要がありました。

- Azure AD で機密/Web クライアント アプリケーションとして登録し合意されている
- (多くの場合、スクリプトに埋め込まれている) アプリの資格情報を使用して、そのサービス プリンシパルを使ってサインインする。
14 ...tive-directory/managed-identities-azure-resources/howto-assign-access-portal.md
View file
@@ -9,18 +9,18 @@ editor: ''
ms.service: active-directory
ms.subservice: msi
ms.devlang: na
ms.topic: article
ms.topic: how-to
ms.tgt_pltfrm: na
ms.workload: identity
ms.date: 09/14/2017
ms.author: markvi
ms.collection: M365-identity-device-management
ms.openlocfilehash: e24c97909870c4d76b07ec837e5f624a509bd1f2
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: e2af718c3555176167eb154b0a718218c42e93dc
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "74547287"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85608298"
---
# <a name="assign-a-managed-identity-access-to-a-resource-by-using-the-azure-portal"></a>Azure portal を使用してリソースにマネージド ID アクセスを割り当てる

@@ -30,12 +30,12 @@ ms.locfileid: "74547287"

## <a name="prerequisites"></a>前提条件

- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#how-does-the-managed-identities-for-azure-resources-work)を必ず確認してください**。
- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#managed-identity-types)を必ず確認してください**。
- まだ Azure アカウントを持っていない場合は、[無料のアカウントにサインアップ](https://azure.microsoft.com/free/)してから先に進んでください。

## <a name="use-rbac-to-assign-a-managed-identity-access-to-another-resource"></a>RBAC を使用して他のリソースにマネージド ID アクセスを割り当てる

[Azure VM](qs-configure-portal-windows-vm.md) または [Azure VMSS](qs-configure-portal-windows-vmss.md) などの Azure リソース上でマネージド ID を有効にした後、次の手順を実行します。
[Azure VM](qs-configure-portal-windows-vm.md)、[Azure 仮想マシン スケール セット](qs-configure-portal-windows-vmss.md)などの Azure リソースでマネージド ID を有効にした後、次の手順を実行します。

1. マネージド ID を構成した Azure サブスクリプションに関連付けられているアカウントを使用して、[Azure portal](https://portal.azure.com) にサインインします。

12 ...-directory/managed-identities-azure-resources/howto-assign-access-powershell.md
View file
@@ -9,18 +9,18 @@ editor: ''
ms.service: active-directory
ms.subservice: msi
ms.devlang: na
ms.topic: article
ms.topic: how-to
ms.tgt_pltfrm: na
ms.workload: identity
ms.date: 12/06/2018
ms.author: markvi
ms.collection: M365-identity-device-management
ms.openlocfilehash: a2283ac076ef761fd098d75e7120e6557a959574
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: a9fcca72234340a6284dbba5443ae6fb735d4a04
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "74547259"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85608281"
---
# <a name="assign-a-managed-identity-access-to-a-resource-using-powershell"></a>PowerShell を使用して、リソースにマネージド ID アクセスを割り当てる

@@ -32,7 +32,7 @@ ms.locfileid: "74547259"

## <a name="prerequisites"></a>前提条件

- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#how-does-the-managed-identities-for-azure-resources-work)を必ず確認してください**。
- Azure リソースのマネージド ID の基本点な事柄については、[概要](overview.md)に関するセクションを参照してください。 **[システム割り当てマネージド ID とユーザー割り当てマネージド ID の違い](overview.md#managed-identity-types)を必ず確認してください**。
- まだ Azure アカウントを持っていない場合は、[無料のアカウントにサインアップ](https://azure.microsoft.com/free/)してから先に進んでください。
- [最新バージョンの Azure PowerShell](/powershell/azure/install-az-ps) をインストールします (まだインストールしていない場合)。

147 articles/active-directory/saas-apps/atlassian-cloud-provisioning-tutorial.md
View file

Large diffs are not rendered by default.

29 articles/active-directory/saas-apps/servicenow-provisioning-tutorial.md
View file
@@ -15,12 +15,12 @@ ms.devlang: na
ms.topic: article
ms.date: 12/10/2019
ms.author: jeedes
ms.openlocfilehash: e3d4ca6f8e67f069bffcd27563d7f32b55f6591e
ms.sourcegitcommit: a9784a3fd208f19c8814fe22da9e70fcf1da9c93
ms.openlocfilehash: da62efff5db5c71b087657b0eec93f8dd4702665
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/22/2020
ms.locfileid: "83780507"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84751499"
---
# <a name="tutorial-configure-servicenow-for-automatic-user-provisioning"></a>チュートリアル:自動ユーザー プロビジョニングのために ServiceNow を構成する

@@ -54,12 +54,19 @@ ms.locfileid: "83780507"

1. ServiceNow インスタンス名を指定します。 インスタンス名は、ServiceNow にアクセスするために使用する URL で確認できます。 次の例では、インスタンス名は dev35214 です。

![ServiceNow インスタンス](media/servicenow-provisioning-tutorial/servicenow_instance.png)
![ServiceNow インスタンス](media/servicenow-provisioning-tutorial/servicenow_instance.png)


2. ServiceNow で管理者の資格情報を取得します。 ServiceNow のユーザー プロファイルに移動し、ユーザーが管理者ロールを持っていることを確認します。

![ServiceNow 管理者ロール](media/servicenow-provisioning-tutorial/servicenow-admin-role.png)
![ServiceNow 管理者ロール](media/servicenow-provisioning-tutorial/servicenow-admin-role.png)

3. 以下の設定が ServiceNow で**無効**になっていることを確認します。

1. **[System Security] (システム セキュリティ)** > **[High security settings] (高セキュリティ設定)** > **[Require basic authentication for incoming SCHEMA requests] (受信 SCHEMA 要求で基本認証を要求する)** と選択します。
2. **[System Properties] (システム プロパティ)** > **[Web サービス]** > **[Require basic authorization for incoming SOAP requests] (受信 SOAP 要求で基本認証を要求する)** と選択します。

> [!IMPORTANT]
> これらの設定が*有効*になっている場合、プロビジョニング エンジンは ServiceNow との通信に失敗します。
## <a name="step-3-add-servicenow-from-the-azure-ad-application-gallery"></a>手順 3. Azure AD アプリケーション ギャラリーから ServiceNow を追加する

@@ -142,6 +149,14 @@ Azure AD プロビジョニング サービスを使用すると、アプリケ
* **EntryJoiningPropertyValueIsMissing:** [属性マッピング](https://docs.microsoft.com/azure/active-directory/manage-apps/customize-application-attributes)を確認して、一致する属性を特定します。 この値は、プロビジョニング対象のユーザーまたはグループに存在する必要があります。
* [ServiceNow SOAP API](https://docs.servicenow.com/bundle/newyork-application-development/page/integrate/web-services-apis/reference/r_DirectWebServiceAPIFunctions.html) を確認して、要件や制限事項 (たとえば、ユーザーの国番号を指定するための形式) を理解してください。
* プロビジョニング要求は、既定では https://{your-instance-name}.service-now.com/{table-name} に送信されます。 カスタム テナント URL が必要な場合は、[インスタンス名] フィールドに URL 全体を指定できます。
* **ServiceNowInstanceInvalid**

`Details: Your ServiceNow instance name appears to be invalid. Please provide a current ServiceNow administrative user name and password along with the name of a valid ServiceNow instance.`

このエラーは、ServiceNow インスタンスとの通信の問題を示しています。 ダブルクリックして、以下の設定が ServiceNow で*無効*になっていることを確認します。

1. **[System Security] (システム セキュリティ)** > **[High security settings] (高セキュリティ設定)** > **[Require basic authentication for incoming SCHEMA requests] (受信 SCHEMA 要求で基本認証を要求する)** と選択します。
2. **[System Properties] (システム プロパティ)** > **[Web サービス]** > **[Require basic authorization for incoming SOAP requests] (受信 SOAP 要求で基本認証を要求する)** と選択します。

## <a name="additional-resources"></a>その他のリソース

167 articles/active-directory/saas-apps/slack-provisioning-tutorial.md
View file

Large diffs are not rendered by default.

101 articles/active-directory/saas-apps/snowflake-provisioning-tutorial.md
View file

Large diffs are not rendered by default.

16 articles/aks/cluster-container-registry-integration.md
View file
@@ -5,16 +5,16 @@ services: container-service
manager: gwallace
ms.topic: article
ms.date: 02/25/2020
ms.openlocfilehash: 70c36f9a18a85b90bb3a66d4083a71a00f61f14e
ms.sourcegitcommit: 053e5e7103ab666454faf26ed51b0dfcd7661996
ms.openlocfilehash: aa2b82e70b1a1372076483c7405c32b66da377af
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/27/2020
ms.locfileid: "84016374"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84974434"
---
# <a name="authenticate-with-azure-container-registry-from-azure-kubernetes-service"></a>Azure Kubernetes Service から Azure Container Registry の認証を受ける

Azure Kubernetes Service (AKS) で Azure Container Registry (ACR) を使用する場合は、認証メカニズムを確立する必要があります。 この記事では、これら 2 つの Azure サービス間の認証を構成する例を示します。
Azure Kubernetes Service (AKS) で Azure Container Registry (ACR) を使用する場合は、認証メカニズムを確立する必要があります。 この操作は、必要なアクセス許可を ACR に付与することで、CLI とポータルのエクスペリエンスの一部として実装されます。 この記事では、これら 2 つの Azure サービス間の認証を構成する例を示します。

Azure CLI を使用して、いくつかの単純なコマンドで AKS から ACR への統合を設定できます。 この統合により、AKS クラスターに関連付けられているサービス プリンシパルに AcrPull ロールが割り当てられます。

@@ -23,7 +23,7 @@ Azure CLI を使用して、いくつかの単純なコマンドで AKS から A
これらの例には以下のものが必要です。

* **Azure サブスクリプション**上の**所有者**または **Azure アカウント管理者**ロール。
* Azure CLI バージョン 2.0.73 以降
* Azure CLI バージョン 2.7.0 以降

**所有者** または **Azure アカウント管理者** の役割を必要としないようにするには、サービス プリンシパルを手動で構成するか、既存のサービス プリンシパルを使用して AKS から ACR を認証します。 詳細については、[サービス プリンシパルによる ACR 認証](../container-registry/container-registry-auth-service-principal.md)または[プル シークレットを使用した Kubernetes からの認証](../container-registry/container-registry-auth-kubernetes.md)に関するページをご参照ください。

@@ -143,5 +143,9 @@ nginx0-deployment-669dfc4d4b-x74kr 1/1 Running 0 20s
nginx0-deployment-669dfc4d4b-xdpd6 1/1 Running 0 20s
```

### <a name="troubleshooting"></a>トラブルシューティング
* ACR 診断の詳細については、[こちら](../container-registry/container-registry-diagnostics-audit-logs.md)を参照してください。
* ACR の正常性の詳細については、[こちら](../container-registry/container-registry-check-health.md)を参照してください。

<!-- LINKS - external -->
[AKS AKS CLI]: https://docs.microsoft.com/cli/azure/aks?view=azure-cli-latest#az-aks-create
18 articles/aks/concepts-clusters-workloads.md
View file
@@ -4,12 +4,12 @@ description: Kubernetes の基本のクラスターおよびワークロード
services: container-service
ms.topic: conceptual
ms.date: 06/03/2019
ms.openlocfilehash: 13169628aff2fe4bff64fed36db54d18d4f830b8
ms.sourcegitcommit: 34a6fa5fc66b1cfdfbf8178ef5cdb151c97c721c
ms.openlocfilehash: 9b54bdbfcbc37d3863d4e6b86ae6fe5522bb5be9
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/28/2020
ms.locfileid: "82208161"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85336637"
---
# <a name="kubernetes-core-concepts-for-azure-kubernetes-service-aks"></a>Azure Kubernetes Services (AKS) における Kubernetes の中心概念

@@ -105,9 +105,9 @@ kubectl describe node [NODE_NAME]

メモリと CPU の割り当てに関する上記の規則は、クラスターの正常性に不可欠ないくつかのホスティング システム ポッドを含むエージェント ノードを正常な状態に保つために使用されます。 これらの割り当て規則により、ノードが報告する割り当て可能なメモリと CPU は、Kubernetes クラスターに含まれていない場合よりも少なくなります。 上記のリソースの予約を変更することはできません。

たとえば、ノードで 7 GB が提供される場合、750Mi のハード削除しきい値に加えて、メモリの 34% を割り当て不可として報告されます。
たとえば、ノードで 7 GB が提供される場合、750Mi のハード削除しきい値を含めて、メモリの 34% が割り当て不可として報告されます。

`(0.25*4) + (0.20*3) = + 1 GB + 0.6GB = 1.6GB / 7GB = 22.86% reserved`
`0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved`

Kubernetes 自体の予約に加えて、基になるノード OS も OS 機能を維持するための CPU とメモリ リソースの量を予約します。

@@ -204,11 +204,7 @@ YAML マニフェスト内にロード バランサーなどのサービスも

Kubernetes のアプリケーションを管理する一般的な方法としては、[Helm][helm] を使用します。 アプリケーション コードのパッケージ化されたバージョンと、Kubernetes YAML マニフェストを含む既存のパブリック Helm *Chart* を構築して使用し、リソースをデプロイできます。 これらの Helm Chart はローカルに保存したり、多くの場合、[Azure Container Registry の Helm Chart リポジトリ][acr-helm]などのリモート リポジトリ内に保存したりできます。

Helm を使用するために、Kubernetes クラスターに *Tiller* と呼ばれるサーバー コンポーネントがインストールされます。 Tiller では、クラスター内のチャートのインストールを管理します。 Helm クライアント自体は、お使いのコンピューターにローカルにインストールするか、または [Azure Cloud Shell][azure-cloud-shell] 内で使用できます。 クライアントの Helm Chart を検索または作成して、お使いの Kubernetes クラスターにインストールできます。

![Helm には、クライアント コンポーネントと Kubernetes クラスター内にリソースを作成するサーバー側の Tiller コンポーネントが含まれます。](media/concepts-clusters-workloads/use-helm.png)

詳細については、「[Azure Kubernetes Service (AKS) での Helm を使用したアプリケーションのインストール][aks-helm]」を参照してください。
Helm を使用するには、コンピューターに Helm クライアントをインストールするか、[Azure Cloud Shell][azure-cloud-shell] で Helm クライアントを使用します。 クライアントの Helm Chart を検索または作成して、お使いの Kubernetes クラスターにインストールできます。 詳細については、「[AKS で Helm を使用して既存のアプリケーションをインストールする][aks-helm]」を参照してください。

## <a name="statefulsets-and-daemonsets"></a>StatefulSet と DaemonSet

13 articles/aks/concepts-network.md
View file
@@ -2,14 +2,14 @@
title: 概念 - Azure Kubernetes サービス (AKS) におけるネットワーク
description: Azure Kubernetes Service (AKS) におけるネットワークについて説明します。kubenet と Azure CNI ネットワーク、イングレス コントローラー、ロード バランサー、静的 IP アドレスの説明が含まれます。
ms.topic: conceptual
ms.date: 02/28/2019
ms.date: 06/11/2020
ms.custom: fasttrack-edit
ms.openlocfilehash: 51773a46b77cb1e9a89b9c85a5f62c4a6b7af3be
ms.sourcegitcommit: 849bb1729b89d075eed579aa36395bf4d29f3bd9
ms.openlocfilehash: ae1c2b95a948f2344119af234539b6fab4edaaac
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/28/2020
ms.locfileid: "82146057"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84789499"
---
# <a name="network-concepts-for-applications-in-azure-kubernetes-service-aks"></a>チュートリアル: Azure Kubernetes Service (AKS) でのアプリケーションに対するネットワークの概念

@@ -129,6 +129,8 @@ LoadBalancer 型のサービスを作成すると、基になる Azure ロード

AKS では、NGINX などを使用してイングレス リソースを作成するか、AKS の HTTP アプリケーションのルーティング機能を使用できます。 AKS クラスターで HTTP アプリケーションのルーティングを有効にすると、Azure プラットフォームがイングレス コントローラーと*External-DNS* コントローラーを作成します。 新しいイングレス リソースが Kubernetes に作成されると、必要な DNS A レコードがクラスター固有のDNS ゾーンに作成されます。 詳細については、「[HTTP アプリケーション ルーティング][aks-http-routing]」を参照してください。

Application Gateway イングレス コントローラー (AGIC) アドオンを使用すると、AKS のお客様は、Azure のネイティブ Application Gateway レベル 7 ロード バランサーを活用してクラウド ソフトウェアをインターネットに公開できます。 AGIC では、ホストされている Kubernetes クラスターを監視し、Application Gateway を継続的に更新して、選択されたサービスがインターネットに公開されるようにします。 AKS 用の AGIC アドオンの詳細については、「[Application Gateway イングレス コントローラーとは][agic-overview]」を参照してください。

イングレスのもう 1 つの一般的な機能は、SSL/TLS 終端です。 HTTPS 経由でアクセスされる大規模な Web アプリケーションでは、アプリケーション自体の中ではなく、イングレス リソースによって TLS 終端を処理できます。 TLS 証明書の自動生成と構成を提供することで、Let's Encrypt などのプロバイダーを使用するイングレス リソースを構成できます。 Let's Encrypt を使用した NGINX イングレス コントローラーの構成の詳細については、[イングレスと TLS][aks-ingress-tls] に関する記事を参照してください。

イングレス コントローラーを構成して、クライアント ソース IP を AKS クラスター内のコンテナーへの要求上で保持することもできます。 クライアントの要求が、イングレス コントローラー経由で AKS クラスター内のコントローラーにルーティングされている場合、その要求の元のソース IP は、ターゲット コンテナーに対しては利用できません。 *クライアント ソース IP の保持*を有効にすると、クライアントに対するソース IP は、*X-Forwarded-For* 下にある要求ヘッダー内で利用できます。 クライアント ソース IP の保持機能をイングレス コントローラー上で使用している場合は、TLS パススルーを使用できません。 クライアント ソース IP の保持と TLS パススルーは、*LoadBalancer* 型など、他のサービスによって使用できます。
@@ -180,6 +182,7 @@ Kubernetes と AKS の中心概念の追加情報については、次の記事
[aks-concepts-scale]: concepts-scale.md
[aks-concepts-storage]: concepts-storage.md
[aks-concepts-identity]: concepts-identity.md
[agic-overview]: ../application-gateway/ingress-controller-overview.md
[use-network-policies]: use-network-policies.md
[operator-best-practices-network]: operator-best-practices-network.md
[support-policies]: support-policies.md
47 articles/aks/configure-kubenet.md
View file
@@ -5,12 +5,12 @@ services: container-service
ms.topic: article
ms.date: 06/02/2020
ms.reviewer: nieberts, jomore
ms.openlocfilehash: a393e87963eabf2e3cf41148233c0e350dc6e380
ms.sourcegitcommit: 69156ae3c1e22cc570dda7f7234145c8226cc162
ms.openlocfilehash: 983005e815061f65907fc54aa6a3dfec1771b3f0
ms.sourcegitcommit: bcb962e74ee5302d0b9242b1ee006f769a94cfb8
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 06/03/2020
ms.locfileid: "84309670"
ms.lasthandoff: 07/07/2020
ms.locfileid: "86055496"
---
# <a name="use-kubenet-networking-with-your-own-ip-address-ranges-in-azure-kubernetes-service-aks"></a>Azure Kubernetes Service (AKS) の独自の IP アドレス範囲で kubenet ネットワークを使用する

@@ -40,7 +40,7 @@ Azure CLI バージョン 2.0.65 以降がインストールされて構成さ

多くの環境では、割り当て済みの IP アドレス範囲を使用して仮想ネットワークとサブネットを定義します。 これらの仮想ネットワーク リソースは、複数のサービスとアプリケーションをサポートするために使用されます。 ネットワーク接続を提供するため、AKS クラスターでは *kubenet* (基本的なネットワーク) または Azure CNI ("*高度なネットワーク*) を使用できます。

*kubenet* では、ノードだけが仮想ネットワーク サブネットの IP アドレスを受け取ります。 ポッドが相互に直接通信することはできません。 代わりに、複数のノードにまたがるポッド間の接続には、ユーザー定義ルーティング (UDR) と IP 転送が使用されます。 割り当て済み IP アドレスを受け取ってアプリケーションに対するトラフィックを負荷分散するサービスの背後に、ポッドをデプロイすることもできます。 次の図では、ポッドではなく AKS ノードが仮想ネットワーク サブネットの IP アドレスを受け取る方法を示します。
*kubenet* では、ノードだけが仮想ネットワーク サブネットの IP アドレスを受け取ります。 ポッドが相互に直接通信することはできません。 代わりに、複数のノードにまたがるポッド間の接続には、ユーザー定義ルーティング (UDR) と IP 転送が使用されます。 既定では、UDR と IP 転送の構成は AKS サービスによって作成および管理されますが、[カスタム ルート管理用に独自のルートテーブルを用意する][byo-subnet-route-table]オプションがあります。 割り当て済み IP アドレスを受け取ってアプリケーションに対するトラフィックを負荷分散するサービスの背後に、ポッドをデプロイすることもできます。 次の図では、ポッドではなく AKS ノードが仮想ネットワーク サブネットの IP アドレスを受け取る方法を示します。

![AKS クラスターでの kubenet ネットワーク モデル](media/use-kubenet/kubenet-overview.png)

@@ -84,7 +84,7 @@ Azure でサポートされる UDR のルート数は最大 400 なので、AKS

- 使用可能な IP アドレス空間が十分にある。
- ポッドの通信のほとんどが、クラスターの外部にあるリソースに対するものである。
- UDR を管理したくない。
- ポッド接続用にユーザー定義ルートを管理したくない。
- 仮想ノードや Azure ネットワーク ポリシーなどの高度な AKS 機能を使用する必要がある。 [Calico ネットワーク ポリシー][calico-network-policies] を使用している。

どのネットワーク モデルを使用するかの決定に役立つ詳細については、[ネットワーク モデルとそのサポート範囲の比較][network-comparisons]に関するページを参照してください。
@@ -139,10 +139,10 @@ VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet
SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
```

次に、[az role assignment create][az-role-assignment-create] コマンドを使用して、AKS クラスターのサービス プリンシパルに、仮想ネットワークでの "*共同作成者*" アクセス許可を割り当てます。 前のサービス プリンシパル作成コマンドの出力で示されている独自の *\<appId>* を指定します。
次に、[az role assignment create][az-role-assignment-create] コマンドを使用して、AKS クラスターのサービス プリンシパルに、仮想ネットワークでの "*ネットワーク共同作成者*" アクセス許可を割り当てます。 前のサービス プリンシパル作成コマンドの出力で示されている独自の *\<appId>* を指定します。

```azurecli-interactive
az role assignment create --assignee <appId> --scope $VNET_ID --role Contributor
az role assignment create --assignee <appId> --scope $VNET_ID --role "Network Contributor"
```

## <a name="create-an-aks-cluster-in-the-virtual-network"></a>仮想ネットワークに AKS クラスターを作成する
@@ -201,16 +201,37 @@ AKS クラスターを作成すると、ネットワーク セキュリティ

kubenet では、ルート テーブルがクラスター サブネット上に存在している必要があります。 AKS では、独自の既存のサブネットとルート テーブルを使用することがサポートされています。

カスタム サブネットにルート テーブルが含まれていない場合は、AKS によって作成され、それにルールが追加されます。 クラスターを作成するときにカスタム サブネットにルートテーブルが含まれている場合、クラスターの操作中に既存のルート テーブルが AKS で認識され、クラウド プロバイダーの操作に応じて規則が更新されます。
カスタム サブネットにルート テーブルが含まれていない場合は、AKS によって作成され、クラスターのライフサイクル全体にわたってそれにルールが追加されます。 クラスターを作成するときにカスタム サブネットにルートテーブルが含まれている場合、クラスターの操作中に既存のルート テーブルが AKS で認識され、クラウド プロバイダーの操作に応じてルールが追加または更新されます。

> [!WARNING]
> カスタム ルールをカスタム ルート テーブルに追加し、更新することができます。 ただし、Kubernetes クラウド プロバイダーによって追加されたルールは、更新または削除してはなりません。 0\.0.0.0/0 などのルールは、特定のルート テーブルに常に存在し、NVA や他のエグレス ゲートウェイなどのインターネット ゲートウェイのターゲットにマップされている必要があります。 ルールの更新でカスタム ルールのみが変更されている場合は注意が必要です。
[カスタム ルート テーブル][custom-route-table]のセットアップに関する詳細を参照してください。

Kubernet ネットワークで要求を正常にルーティングするには、整理されたルート テーブル ルールが必要です。 この設計のため、ルート テーブルはそれに依存するクラスターごとに慎重に保守する必要があります。 異なるクラスターからのポッド CIDR が重複し、予期しないルーティングや壊れたルーティングが発生する可能性があるため、複数のクラスターでルート テーブルを共有することはできません。 同じ仮想ネットワークで複数のクラスターを構成する場合、または仮想ネットワークを各クラスター専用にする場合は、次の制限事項を考慮してください。

制限事項:

* クラスターを作成する前にアクセス許可を割り当てる必要があります。対象のカスタム サブネットおよびカスタム ルート テーブルへの書き込みアクセス許可を持つサービス プリンシパルを使用していることを確認してください。
* マネージド ID は、kubenet のカスタム ルート テーブルでは現在サポートされていません。
* AKS クラスターを作成する前に、カスタム ルート テーブルをサブネットに関連付ける必要があります。 このルート テーブルを更新することはできません。また、AKS クラスターを作成する前に、初期ルート テーブルに対してすべてのルーティング規則を追加または削除する必要があります。
* AKS 仮想ネットワーク内のすべてのサブネットは、同じルート テーブルに関連付けられている必要があります。
* すべての AKS クラスターは、一意のルート テーブルを使用する必要があります。 複数のクラスターでルート テーブルを再利用することはできません。
* AKS クラスターを作成する前に、カスタム ルート テーブルをサブネットに関連付ける必要があります。
* クラスターを作成した後で、関連付けられているルート テーブル リソースを更新することはできません。 ルート テーブル リソースは更新できませんが、カスタム ルールはルート テーブルで変更できます。
* 各 AKS クラスターでは、クラスターに関連付けられているすべてのサブネットに対して、一意のルート テーブルを 1 つだけ使用する必要があります。 ポッドの CIDR が重複してルーティング規則が競合する可能性があるため、複数のクラスターでルート テーブルを再利用することはできません。

カスタム ルート テーブルを作成し、仮想ネットワーク内のサブネットにそれを関連付けた後は、ルート テーブルを使用する新しい AKS クラスターを作成できます。
AKS クラスターをデプロイする予定の場所に対するサブネット ID を使用する必要があります。 このサブネットは、カスタム ルート テーブルに関連付けられている必要もあります。

```azurecli-interactive
# Find your subnet ID
az network vnet subnet list --resource-group
--vnet-name
[--subscription]
```

```azurecli-interactive
# Create a kubernetes cluster with with a custom subnet preconfigured with a route table
az aks create -g MyResourceGroup -n MyManagedCluster --vnet-subnet-id MySubnetID
```

## <a name="next-steps"></a>次のステップ

@@ -232,9 +253,11 @@ kubenet では、ルート テーブルがクラスター サブネット上に
[az-network-vnet-subnet-show]: /cli/azure/network/vnet/subnet#az-network-vnet-subnet-show
[az-role-assignment-create]: /cli/azure/role/assignment#az-role-assignment-create
[az-aks-create]: /cli/azure/aks#az-aks-create
[byo-subnet-route-table]: #bring-your-own-subnet-and-route-table-with-kubenet
[develop-helm]: quickstart-helm.md
[use-helm]: kubernetes-helm.md
[virtual-nodes]: virtual-nodes-cli.md
[vnet-peering]: ../virtual-network/virtual-network-peering-overview.md
[express-route]: ../expressroute/expressroute-introduction.md
[network-comparisons]: concepts-network.md#compare-network-models
[custom-route-table]: ../virtual-network/manage-route-table.md
222 articles/aks/kubernetes-helm.md
View file

Large diffs are not rendered by default.

29 articles/aks/node-auto-repair.md
View file
@@ -3,27 +3,27 @@ title: Azure Kubernetes Service (AKS) ノードの自動修復
description: ノードの自動修復機能と壊れたワーカー ノードを AKS で修復するしくみについて説明します。
services: container-service
ms.topic: conceptual
ms.date: 03/10/2020
ms.openlocfilehash: 9bf9df69a0a6bfa4d9f4029278d2a146811980c8
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.date: 06/02/2020
ms.openlocfilehash: 91384461567634faabaaa1dd588d6e7ec6ece60e
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/28/2020
ms.locfileid: "80284842"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84735627"
---
# <a name="azure-kubernetes-service-aks-node-auto-repair"></a>Azure Kubernetes Service (AKS) ノードの自動修復

AKS によってワーカー ノードの正常性状態が継続的に確認され、正常ではなくなった場合、ノードが自動修復されます。 このドキュメントでは、Azure Kubernetes Service (AKS) でワーカー ノードを監視し、正常ではないワーカー ノードを修復するしくみについて説明します。 このドキュメントは、ノード修復機能の動作を AKS オペレーターに伝えるためのものです。 Azure プラットフォームでは、問題が発生した[仮想マシンが保守される][vm-updates]ことにも留意しておくことが重要です。 AKS と Azure が連携し、クラスターのサービス中断が最小限に抑えられます。
AKS によってワーカー ノードの正常性状態が継続的に確認され、正常ではなくなった場合、ノードが自動修復されます。 このドキュメントでは、ノードの自動修復機能の動作についてオペレーターに説明します。 AKS の修復に加えて、Azure プラットフォームでは、問題が発生した[仮想マシンに対してメンテナンスが実行されます][vm-updates]。 AKS と Azure VM が連携し、クラスターのサービス中断が最小限に抑えられます。

> [!Important]
> Windows Server ノード プールには現在、ノードの自動修復機能はサポートされていません。
> 現在、ノードの自動修復機能は Windows Server ノード プールではサポートされません。
## <a name="how-aks-checks-for-unhealthy-nodes"></a>正常ではないノードを AKS で確認する方法

> [!Note]
> AKS では、ユーザー アカウント **aks-remediator** を利用してノードが修復されます。
AKS では、ノードが正常な状態ではなく、修復が必要かどうかを、ルールを利用して決定します。 AKS では、自動修復が必要かどうかを、次のルールで決定します。
AKS では、ノードが正常ではなく、修復が必要かどうかを、ルールを利用して判断します。 AKS では、自動修復が必要かどうかを、次のルールで決定します。

* 10 分という時間枠内で連続して確認した結果、**NotReady** という状態がノードから報告されます
* ノードから、10 分以内に状態が報告されません
@@ -37,16 +37,11 @@ kubectl get nodes
## <a name="how-automatic-repair-works"></a>自動修復のしくみ

> [!Note]
> AKS では、ユーザー アカウント **aks-remediator** を利用してノードが修復されます。
この動作は**仮想マシン スケール セット**の場合です。 自動修復では、数回の手順を踏んで壊れたノードが修復されます。 ノードが正常ではないと判断された場合、AKS によっていくつかの修復手順が試行されます。 手順は次の順序で実行されます。
> AKS が、ユーザー アカウント **AKS-remediator** を使用して修復操作を開始します。
1. コンテナー ランタイムが 10 分間応答しないとき、失敗したランタイム サービスがノード上で再起動されます。
2. ノードの用意が 10 分以内に整わない場合、ノードが再起動されます。
3. ノードの用意が 30 分以内に整わない場合、ノードが再イメージ化されます。

> [!Note]
> 複数のノードが正常ではない場合、1 つずつ修復されます。
VM セットの種類が **Virtual Machine Scale Sets** のクラスターでは、自動修復が既定でサポートされます。 上記のルールに基づいてノードが異常であると判断された場合、AKS は異常が 10 分間継続した後にノードを再起動します。 初期修復操作が実行されてもノードが異常な状態のままである場合は、AKS エンジニアが追加の修復について調査します。

正常性チェック中に複数のノードで異常が検出された場合は、各ノードを個別に修復してから、別の修復が開始されます。

## <a name="next-steps"></a>次のステップ

12 articles/aks/operator-best-practices-cluster-isolation.md
View file
@@ -5,18 +5,18 @@ description: Azure Kubernetes Service (AKS) での分離に関するクラスタ
services: container-service
ms.topic: conceptual
ms.date: 11/26/2018
ms.openlocfilehash: 00643dc1699d1cbd47efd271738015ea05e895e2
ms.sourcegitcommit: 67addb783644bafce5713e3ed10b7599a1d5c151
ms.openlocfilehash: 12c65f3b4241d3e732c51acb6ffa95ff314efb50
ms.sourcegitcommit: 124f7f699b6a43314e63af0101cd788db995d1cb
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/05/2020
ms.locfileid: "80668354"
ms.lasthandoff: 07/08/2020
ms.locfileid: "86077767"
---
# <a name="best-practices-for-cluster-isolation-in-azure-kubernetes-service-aks"></a>Azure Kubernetes Services (AKS) でのクラスターの分離に関するベスト プラクティス

Azure Kubernetes Service (AKS) でクラスターを管理する際は、多くの場合、チームとワークロードを分離する必要があります。 AKS では、柔軟にマルチ テナント クラスターを実行してリソースを分離することができます。 Kubernetes への投資を最大限に活用するには、これらのマルチ テナントおよび分離機能を理解して実装する必要があります。

このベスト プラクティスの記事では、クラスター オペレーターを対象とした分離に重点を置いています。 この記事では、次のことについて説明します。
このベスト プラクティスの記事では、クラスター オペレーターを対象とした分離に重点を置いています。 この記事では、次の方法について説明します。

> [!div class="checklist"]
> * マルチ テナント クラスターとリソースの分離の計画
@@ -30,7 +30,7 @@ Kubernetes では、同じクラスター内のチームとワークロードを
* スケジューラのより高度な機能には、テイントと容認、ノード セレクター、およびノードとポッドのアフィニティまたは非アフィニティが含まれます。 これらの機能の詳細については、[AKS の高度なスケジューラ機能のベスト プラクティス][aks-best-practices-advanced-scheduler]に関するページを参照してください。
* **ネットワーク**には、ポッド内外のトラフィックのフローを制御するためのネットワーク ポリシーの使用が含まれます。
* **認証と承認**には、ロールベースのアクセス制御 (RBAC) と Azure Active Directory (AD) の統合、ポッド ID、および Azure Key Vault のシークレットの使用が含まれます。 これらの機能の詳細については、[AKS の認証と承認のベスト プラクティス][aks-best-practices-identity]に関するページを参照してください。
* **コンテナー**には、ポッドのセキュリティ ポリシー、ポッドのセキュリティ コンテキスト、脆弱性に関するイメージとランタイムのスキャンが含まれます。 また、基になるノードへのコンテナー アクセスを制限するための App Armor や Seccomp (セキュア コンピューティング) の使用も含まれます。
* **コンテナー**には、ポッド セキュリティを適用するための AKS 用の Azure Policy アドオン、ポッドのセキュリティ コンテキストの使用、および脆弱性に関するイメージとランタイムの両方のスキャンが含まれています。 また、基になるノードへのコンテナー アクセスを制限するための App Armor や Seccomp (セキュア コンピューティング) の使用も含まれます。

## <a name="logically-isolate-clusters"></a>クラスターを論理的に分離する

90 articles/aks/uptime-sla.md
View file
@@ -3,14 +3,14 @@ title: Azure Kubernetes Service (AKS) とアップタイム SLA
description: Azure Kubernetes Service (AKS) API サーバーのオプションのアップタイム SLA オファリングについて説明します。
services: container-service
ms.topic: conceptual
ms.date: 05/19/2020
ms.date: 06/24/2020
ms.custom: references_regions
ms.openlocfilehash: 2df0ad675f03b25363ab0f5b13dceb762a657ed7
ms.sourcegitcommit: d118ad4fb2b66c759b70d4d8a18e6368760da3ad
ms.openlocfilehash: 9f8b0cc5a80853542b15d1993713d8a97f5371b9
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 06/02/2020
ms.locfileid: "84299555"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85361576"
---
# <a name="azure-kubernetes-service-aks-uptime-sla"></a>Azure Kubernetes Service (AKS) のアップタイム SLA

@@ -23,27 +23,43 @@ ms.locfileid: "84299555"
> [!Important]
> エグレス ロックダウンを使用するクラスターの場合、[エグレス トラフィックの制限](limit-egress-traffic.md)に関するページを参照して、適切なポートを開きます。
## <a name="region-availability"></a>利用可能なリージョン

アップタイム SLA は、[AKS がサポートされている](https://azure.microsoft.com/global-infrastructure/services/?products=kubernetes-service)パブリック リージョンで利用できます。

* Azure Government は現在サポートされていません。
* Azure China 21Vianet は現在サポートされていません。

## <a name="limitations"></a>制限事項

* プライベート クラスターは現時点ではサポートされていません。

## <a name="sla-terms-and-conditions"></a>SLA の使用条件

アップタイム SLA は有料の機能であり、クラスターごとに有効化されます。 アップタイム SLA の価格は、個々のクラスターのサイズではなく、個別のクラスターの数によって決まります。 詳細については、[アップタイム SLA の価格の詳細](https://azure.microsoft.com/pricing/details/kubernetes-service/)に関するページを参照してください。

## <a name="before-you-begin"></a>開始する前に

* Azure CLI バージョン 2.7.0 以降
* [Azure CLI](https://docs.microsoft.com/cli/azure/install-azure-cli?view=azure-cli-latest) バージョン 2.8.0 以降をインストールします

## <a name="creating-a-new-cluster-with-uptime-sla"></a>アップタイム SLA を使用した新しいクラスターの作成

## <a name="creating-a-cluster-with-uptime-sla"></a>アップタイム SLA を使用したクラスターの作成
> [!NOTE]
> 現時点では、アップタイム SLA を有効にした場合、これをクラスターから削除することはできません。
アップタイム SLA を使用して新しいクラスターを作成するには、Azure CLI を使用します。

次の例では、*myResourceGroup* という名前のリソース グループを *eastus* に作成します。

```azurecli-interactive
# Create a resource group
az group create --name myResourceGroup --location eastus
```
AKS クラスターを作成するには、[az aks create][az-aks-create] コマンドを使用します。 次の例では、*myAKSCluster* という名前のクラスターを 1 つのノードで作成します。 コンテナーの Azure Monitor は、 *--enable-addons monitoring* パラメーターを使用して有効にすることもできます。 この操作は、完了するまでに数分かかります。
AKS クラスターを作成するには、[`az aks create`][az-aks-create] コマンドを使用します。 次の例では、*myAKSCluster* という名前のクラスターを 1 つのノードで作成します。 この操作は、完了するまでに数分かかります。

```azurecli-interactive
az aks create --resource-group myResourceGroup --name myAKSCluster --uptime-sla --node-count 1 --enable-addons monitoring --generate-ssh-keys
# Create an AKS cluster with uptime SLA
az aks create --resource-group myResourceGroup --name myAKSCluster --uptime-sla --node-count 1
```
数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。 次の JSON スニペットは SKU の有料レベルを示し、クラスターでアップタイム SLA が有効になっていることを示します。

@@ -55,15 +71,61 @@ az aks create --resource-group myResourceGroup --name myAKSCluster --uptime-sla
},
```

## <a name="limitations"></a>制限事項
## <a name="modify-an-existing-cluster-to-use-uptime-sla"></a>既存のクラスターを変更してアップタイム SLA を使用する

必要に応じて、既存のクラスターを更新してアップタイム SLA を使用することもできます。

前の手順で AKS クラスターを作成した場合は、リソース グループを削除します。

```azurecli-interactive
# Delete the existing cluster by deleting the resource group
az group delete --name myResourceGroup --yes --no-wait
```

新しいリソース グループを作成します。

```azurecli-interactive
# Create a resource group
az group create --name myResourceGroup --location eastus
```

新しいクラスターを作成します。アップタイム SLA は使用しません。

```azurecli-interactive
# Create a new cluster without uptime SLA
az aks create --resource-group myResourceGroup --name myAKSCluster--node-count 1
```

[`az aks update`][az-aks-nodepool-update] コマンドを使用して、既存のクラスターを更新します。

```azurecli-interactive
# Update an existing cluster to use Uptime SLA
az aks update --resource-group myResourceGroup --name myAKSCluster --uptime-sla
```

次の JSON スニペットは SKU の有料レベルを示し、クラスターでアップタイム SLA が有効になっていることを示します。

```output
},
"sku": {
"name": "Basic",
"tier": "Paid"
},
```

## <a name="clean-up"></a>クリーンアップ

課金されないようにするために、作成したすべてのリソースをクリーンアップします。 クラスターを削除するには、[`az group delete`][az-group-delete] コマンドを使用して AKS リソース グループを削除します。

```azurecli-interactive
az group delete --name myResourceGroup --yes --no-wait
```

* 現時点では、アップタイム SLA を有効にするために既存のクラスターとして変換することはできません。
* 現時点では、アップタイム SLA を有効にして作成した後で AKS クラスターからアップタイム SLA を解除する方法はありません。
* プライベート クラスターは現時点ではサポートされていません。

## <a name="next-steps"></a>次のステップ

[Availability Zones][availability-zones] を使用し、AKS クラスター ワークロードで高可用性を上げます。

[エグレス トラフィックを制限する](limit-egress-traffic.md)ようにクラスターを構成します。

<!-- LINKS - External -->
@@ -79,3 +141,5 @@ az aks create --resource-group myResourceGroup --name myAKSCluster --uptime-sla
[limit-egress-traffic]: ./limit-egress-traffic.md
[az-extension-add]: /cli/azure/extension#az-extension-add
[az-extension-update]: /cli/azure/extension#az-extension-update
[az-aks-nodepool-update]: /cli/azure/aks/nodepool?view=azure-cli-latest#az-aks-nodepool-update
[az-group-delete]: /cli/azure/group#az-group-delete
85 articles/aks/use-managed-identity.md
View file
@@ -2,37 +2,56 @@
title: Azure Kubernetes Service でマネージド ID を使用する
description: Azure Kubernetes Service (AKS) でマネージド ID を使用する方法について説明します。
services: container-service
author: saudas
manager: saudas
author: mlearned
ms.topic: article
ms.date: 04/02/2020
ms.author: saudas
ms.openlocfilehash: 00ecc077ba55ab9f91fc58f8a47fcdf7440deea6
ms.sourcegitcommit: 849bb1729b89d075eed579aa36395bf4d29f3bd9
ms.date: 06/30/2020
ms.author: mlearned
ms.openlocfilehash: 30d1290f9eb7b2750f09e5e256d4dd212c7e4607
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/28/2020
ms.locfileid: "82112968"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85610287"
---
# <a name="use-managed-identities-in-azure-kubernetes-service"></a>Azure Kubernetes Service でマネージド ID を使用する

現在、Azure Kubernetes Service (AKS) クラスター (具体的には Kubernetes クラウド プロバイダー) で Azure 内にロード バランサーやマネージド ディスクなどの追加リソースを作成するには、"*マネージド ID*" または "*サービス プリンシパル*" のいずれかの ID が必要です。 [サービス プリンシパル](kubernetes-service-principal.md)を使用する場合、それを 1 つ指定する必要があります。指定しない場合、AKS によって代理で作成されます。 マネージド ID を使用する場合は、AKS によってこれが自動作成されます。 サービス プリンシパルを使用するクラスターでは、やがてサービス プリンシパルを更新しないと、そのクラスターを動作させ続けることができない状態になります。 サービス プリンシパルを管理しなければならない場合、複雑さが増すので、代わりにマネージ ID を使用した方が簡単です。 アクセス許可の要件は、サービス プリンシパルにおいてもマネージド ID においても同じです。
現在、Azure Kubernetes Service (AKS) クラスター (具体的には Kubernetes クラウド プロバイダー) で Azure 内にロード バランサーやマネージド ディスクなどの追加リソースを作成するには、ID が必要です。 この ID には、*マネージド ID* または*サービス プリンシパル*を指定できます。 [サービス プリンシパル](kubernetes-service-principal.md)を使用する場合、それを 1 つ指定する必要があります。指定しない場合、AKS によって代理で作成されます。 マネージド ID を使用する場合は、AKS によってこれが自動作成されます。 サービス プリンシパルを使用するクラスターでは、やがてサービス プリンシパルを更新しないと、そのクラスターを動作させ続けることができない状態になります。 サービス プリンシパルを管理しなければならない場合、複雑さが増すので、代わりにマネージ ID を使用した方が簡単です。 アクセス許可の要件は、サービス プリンシパルにおいてもマネージド ID においても同じです。

*マネージド ID* は、本質的にサービス プリンシパルのラッパーであり、管理がより簡単になります。 詳細については、[Azure リソースのマネージド ID](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) について確認してください。

AKS は 2 つのマネージド ID を作成します。

- **システム割り当てマネージド ID**:Kubernetes クラウド プロバイダーがユーザーに代わって Azure リソースを作成するために使用する ID。 このシステム割り当ての ID のライフ サイクルは、クラスターのそれに関連付けられます。 この ID は、クラスターが削除されると削除されます。
- **ユーザー割り当てマネージド ID**:クラスターでの承認に使用される ID。 たとえば、ユーザーが割り当てた ID を使用して、Azure Container Registry (ACR) を使用するように AKS を承認したり、kubelet が Azure からメタデータを取得することを承認したりします。

マネージド ID を使用してアドオンを認証することもできます。 アドオンごとに、AKS によってマネージド ID が作成され、アドオンの期限が切れるまで存続します。
*マネージド ID* は、本質的にサービス プリンシパルのラッパーであり、管理がより簡単になります。 MI の資格情報のローテーションは、Azure Active Directory の既定に従って 46 日ごとに自動的に行われます。 AKS では、システム割り当てとユーザー割り当ての両方の種類のマネージド ID が使用されます。 これらの ID は、現在変更できません。 詳細については、[Azure リソースのマネージド ID](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) について確認してください。

## <a name="before-you-begin"></a>開始する前に

次のリソースがインストールされている必要があります。

- Azure CLI バージョン 2.2.0 以降

## <a name="limitations"></a>制限事項

* 独自のマネージド ID を使用することは現在サポートされていません。
* マネージド ID を指定した AKS クラスターは、クラスターの作成時にのみ有効にすることができます。
* 既存の AKS クラスターを更新またはアップグレードしてマネージド ID を有効にすることはできません。
* クラスターの**アップグレード**操作中は、マネージド ID が一時的に使用できなくなります。

## <a name="summary-of-managed-identities"></a>マネージド ID の概要

AKS では、組み込みのサービスとアドオンに対して複数のマネージド ID が使用されます。

| ID | 名前 | 使用事例 | 既定のアクセス許可 | 独自の ID を使用する
|----------------------------|-----------|----------|
| コントロール プレーン | 非表示 | AKS がネットワーク リソースを管理するために使用します。たとえば、イングレスやパブリック IP などのロード バランサーを作成します| ノード リソース グループの共同作成者ロール | 現在、サポートされていません
| kubelet | AKS クラスター名 - agentpool | Azure Container Registry (ACR) を使用した認証 | ノード リソース グループの閲覧者ロール | 現在、サポートされていません
| アドオン | AzureNPM | ID は必要ありません | NA | いいえ
| アドオン | AzureCNI ネットワーク監視 | ID は必要ありません | NA | いいえ
| アドオン | azurepolicy (ゲートキーパー) | ID は必要ありません | NA | いいえ
| アドオン | azurepolicy | ID は必要ありません | NA | いいえ
| アドオン | Calico | ID は必要ありません | NA | いいえ
| アドオン | ダッシュボード | ID は必要ありません | NA | いいえ
| アドオン | HTTPApplicationRouting | 必要なネットワーク リソースを管理します | ノード リソース グループの閲覧者ロール、DNS ゾーンの共同作成者ロール | いいえ
| アドオン | イングレス アプリケーション ゲートウェイ | 必要なネットワーク リソースを管理します| ノード リソース グループの共同作成者ロール | いいえ
| アドオン | omsagent | AKS メトリックを Azure Monitor に送信するために使用されます | 監視メトリック パブリッシャー ロール | いいえ
| アドオン | 仮想ノード (ACIConnector) | Azure Container Instances (ACI) のために必要なネットワーク リソースを管理します | ノード リソース グループの共同作成者ロール | いいえ


## <a name="create-an-aks-cluster-with-managed-identities"></a>マネージド ID を指定して AKS クラスターを作成する

次の CLI コマンドを使用し、マネージド ID を指定して AKS クラスターを作成できるようになりました。
@@ -47,20 +66,35 @@ az group create --name myResourceGroup --location westus2
次に、AKS クラスターを作成します。

```azurecli-interactive
az aks create -g MyResourceGroup -n MyManagedCluster --enable-managed-identity
az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity
```

マネージド ID を使用して正常にクラスターが作成されると、次のサービス プリンシパル プロファイル情報が含まれます。

```json
"servicePrincipalProfile": {
"clientId": "msi",
"secret": null
"clientId": "msi"
}
```

次のコマンドを使用して、コントロール プレーン マネージド ID の objectid を照会します。

```azurecli-interactive
az aks show -g myResourceGroup -n MyManagedCluster --query "identity"
```

結果は次のようになります。

```json
{
"principalId": "<object_id>",
"tenantId": "<tenant_id>",
"type": "SystemAssigned"
}
```

> [!NOTE]
> 独自の VNet、静的 IP アドレス、またはアタッチされた Azure ディスク (リソースは MC_* リソース グループの外部にある) を作成および使用するには、クラスター System Assigned Managed Identity の PrincipalID を使用してロールの割り当てを実行します。 ロールの割り当ての詳細については、[他の Azure リソースへのアクセスの委任](kubernetes-service-principal.md#delegate-access-to-other-azure-resources)に関する記事を参照してください。
> 独自の VNet、静的 IP アドレス、またはアタッチされた Azure ディスク (リソースはワーカー ノード リソース グループの外部にある) を作成および使用するには、クラスター System Assigned Managed Identity の PrincipalID を使用してロールの割り当てを実行します。 ロールの割り当ての詳細については、[他の Azure リソースへのアクセスの委任](kubernetes-service-principal.md#delegate-access-to-other-azure-resources)に関する記事を参照してください。
>
> Azure クラウド プロバイダーによって使用されるクラスター マネージド ID へのアクセス許可が付与されるまでに最大 60 分かかる場合があります。
@@ -72,7 +106,8 @@ az aks get-credentials --resource-group myResourceGroup --name MyManagedCluster

クラスターは数分で作成されます。 その後、新しいクラスターにアプリケーションのワークロードをデプロイし、サービス プリンシパル ベースの AKS クラスターの場合と同様に対話することができます。

> [!IMPORTANT]
>
> - マネージド ID を指定した AKS クラスターは、クラスターの作成時にのみ有効にすることができます。
> - 既存の AKS クラスターを更新またはアップグレードしてマネージド ID を有効にすることはできません。
## <a name="next-steps"></a>次のステップ
* マネージド ID が有効になっているクラスターを作成するには、[Azure Resource Manager (ARM) テンプレート][aks-arm-template]を使用します。

<!-- LINKS - external -->
[aks-arm-template]: https://docs.microsoft.com/azure/templates/microsoft.containerservice/managedclusters
41 articles/aks/use-multiple-node-pools.md
View file
@@ -4,12 +4,12 @@ description: Azure Kubernetes Service (AKS) のクラスターで複数のノー
services: container-service
ms.topic: article
ms.date: 04/08/2020
ms.openlocfilehash: bf7e767f1a7b0c657c744c96b308160393e3f326
ms.sourcegitcommit: 50ef5c2798da04cf746181fbfa3253fca366feaa
ms.openlocfilehash: 64eaa3fd38a9f3de7e2032ef7ff7a18924353a1d
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/30/2020
ms.locfileid: "82610923"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85318438"
---
# <a name="create-and-manage-multiple-node-pools-for-a-cluster-in-azure-kubernetes-service-aks"></a>Azure Kubernetes Service (AKS) のクラスターで複数のノード プールを作成および管理する

@@ -42,7 +42,7 @@ Azure CLI バージョン 2.2.0 以降がインストールされて構成され
> [!Important]
> 運用環境内のお使いの AKS クラスターで 1 つのシステム ノード プールを実行する場合、そのノード プールには少なくとも 3 つのノードを使用することをお勧めします。
まず、1 つのノード プールで AKS クラスターを作成開始します。 次の例では、[az group create][az-group-create] コマンドを使用して、*myResourceGroup* という名前のリソース グループを *eastus* リージョンに作成しています。 次いで、*myAKSCluster* という名前の AKS クラスターを [az aks create][az-aks-create] コマンドを使用して作成しています。 次の手順では、*1.15.7* の *--kubernetes-version* を使用してノード プールを更新する方法を示しています。 [Kubernetes のサポートされている任意のバージョン][supported-versions]を指定できます。
まず、1 つのノード プールで AKS クラスターを作成開始します。 次の例では、[az group create][az-group-create] コマンドを使用して、*myResourceGroup* という名前のリソース グループを *eastus* リージョンに作成しています。 次いで、*myAKSCluster* という名前の AKS クラスターを [az aks create][az-aks-create] コマンドを使用して作成しています。

> [!NOTE]
> 複数のノード プールを使用する場合、*Basic* ロード バランサー SKU は**サポートされません**。 既定では、AKS クラスターが、Azure CLI および Azure portal から *Standard* ロード バランサー SKU で作成されます。
@@ -58,7 +58,6 @@ az aks create \
--vm-set-type VirtualMachineScaleSets \
--node-count 2 \
--generate-ssh-keys \
--kubernetes-version 1.15.7 \
--load-balancer-sku standard
```

@@ -82,8 +81,7 @@ az aks nodepool add \
--resource-group myResourceGroup \
--cluster-name myAKSCluster \
--name mynodepool \
--node-count 3 \
--kubernetes-version 1.15.5
--node-count 3
```

> [!NOTE]
@@ -104,7 +102,7 @@ az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluste
"count": 3,
...
"name": "mynodepool",
"orchestratorVersion": "1.15.5",
"orchestratorVersion": "1.15.7",
...
"vmSize": "Standard_DS2_v2",
...
@@ -123,7 +121,7 @@ az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluste
```

> [!TIP]
> ノード プールを追加するときに *VmSize* を指定しなかった場合、既定のサイズは、Windows ノード プールの場合は *Standard_DS2_v3*、Linux ノード プールの場合は *Standard_DS2_v2* になります。 *OrchestratorVersion* が指定されていない場合、コントロール プレーンと同じバージョンが既定値になります。
> ノード プールを追加するときに *VmSize* を指定しなかった場合、既定のサイズは、Windows ノード プールの場合は *Standard_D2s_v3*、Linux ノード プールの場合は *Standard_DS2_v2* になります。 *OrchestratorVersion* が指定されていない場合、コントロール プレーンと同じバージョンが既定値になります。
### <a name="add-a-node-pool-with-a-unique-subnet-preview"></a>一意なサブネットを持つノード プールを追加する (プレビュー)

@@ -144,7 +142,6 @@ az aks nodepool add \
--cluster-name myAKSCluster \
--name mynodepool \
--node-count 3 \
--kubernetes-version 1.15.5
--vnet-subnet-id <YOUR_SUBNET_RESOURCE_ID>
```

@@ -153,25 +150,29 @@ az aks nodepool add \
> [!NOTE]
> クラスターまたはノード プールでは、アップグレードやスケーリングの操作を同時に実行することはできず、実行を試みた場合には、エラーが返されます。 代わりに、ターゲット リソースに対する次の要求を行う前に、各操作の種類をその同じリソースで完了する必要があります。 詳細については、[トラブルシューティング ガイド](https://aka.ms/aks-pending-upgrade)を参照してください。
最初の手順で AKS クラスターを初回作成したとき、`--kubernetes-version` として *1.15.7* を指定しました。 これにより、コントロール プレーンと既定ノード プールの両方の Kubernetes バージョンが設定されます。 このセクションのコマンドからは、1 つの特定のノード プールをアップグレードする方法が説明されます。

コントロール プレーンとノード プールの Kubernetes バージョンをアップグレードするとき、両者の関係については、[下のセクション](#upgrade-a-cluster-control-plane-with-multiple-node-pools)で説明します。
このセクションのコマンドからは、1 つの特定のノード プールをアップグレードする方法が説明されます。 コントロール プレーンとノード プールの Kubernetes バージョンをアップグレードするとき、両者の関係については、[下のセクション](#upgrade-a-cluster-control-plane-with-multiple-node-pools)で説明します。

> [!NOTE]
> ノード プールの OS イメージのバージョンは、クラスターの Kubernetes バージョンに関連付けられています。 OS イメージは、クラスターのアップグレードの後でのみアップグレードされます。
この例には 2 つのノード プールがあるため、[az aks nodepool upgrade][az-aks-nodepool-upgrade] を使用してノード プールをアップグレードする必要があります。 *mynodepool* を Kubernetes *1.15.7* にアップグレードしましょう。 次の例のように、[az aks node pool upgrade][az-aks-nodepool-upgrade] コマンドを使用してノード プールをアップグレードします。
この例には 2 つのノード プールがあるため、[az aks nodepool upgrade][az-aks-nodepool-upgrade] を使用してノード プールをアップグレードする必要があります。 使用可能なアップグレードを確認するには、[az aks get-upgrades][az-aks-get-upgrades] を使用します。

```azurecli-interactive
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster
```

*mynodepool* をアップグレードしましょう。 次の例のように、[az aks node pool upgrade][az-aks-nodepool-upgrade] コマンドを使用してノード プールをアップグレードします。

```azurecli-interactive
az aks nodepool upgrade \
--resource-group myResourceGroup \
--cluster-name myAKSCluster \
--name mynodepool \
--kubernetes-version 1.15.7 \
--kubernetes-version KUBERNETES_VERSION \
--no-wait
```

[az aks node pool list][az-aks-nodepool-list] コマンドを使用し、再度お使いのノード プールの状態を一覧表示します。 次の例では、*mynodepool* が *1.15.7* への *Upgrading* 状態であることを示しています。
[az aks node pool list][az-aks-nodepool-list] コマンドを使用し、再度お使いのノード プールの状態を一覧表示します。 次の例では、*mynodepool* が *KUBERNETES_VERSION* への *Upgrading* 状態であることを示しています。

```azurecli
az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
@@ -184,7 +185,7 @@ az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
"count": 3,
...
"name": "mynodepool",
"orchestratorVersion": "1.15.7",
"orchestratorVersion": "KUBERNETES_VERSION",
...
"provisioningState": "Upgrading",
...
@@ -812,6 +813,8 @@ az group delete --name myResourceGroup2 --yes --no-wait

Windows Server コンテナー ノード プールを作成して使用するには、[AKS での Windows Server コンテナーの作成][aks-windows]に関する記事を参照してください。

[近接配置グループ][reduce-latency-ppg]を使用して、AKS アプリケーションの待機時間を短縮します。

<!-- EXTERNAL LINKS -->
[kubernetes-drain]: https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/
[kubectl-get]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get
@@ -824,6 +827,7 @@ Windows Server コンテナー ノード プールを作成して使用するに
[aks-windows]: windows-container-cli.md
[az-aks-get-credentials]: /cli/azure/aks#az-aks-get-credentials
[az-aks-create]: /cli/azure/aks#az-aks-create
[az-aks-get-upgrades]: /cli/azure/aks?view=azure-cli-latest#az-aks-get-upgrades
[az-aks-nodepool-add]: /cli/azure/aks/nodepool?view=azure-cli-latest#az-aks-nodepool-add
[az-aks-nodepool-list]: /cli/azure/aks/nodepool?view=azure-cli-latest#az-aks-nodepool-list
[az-aks-nodepool-update]: /cli/azure/aks/nodepool?view=azure-cli-latest#az-aks-nodepool-update
@@ -848,3 +852,4 @@ Windows Server コンテナー ノード プールを作成して使用するに
[node-resource-group]: faq.md#why-are-two-resource-groups-created-with-aks
[vmss-commands]: ../virtual-machine-scale-sets/virtual-machine-scale-sets-networking.md#public-ipv4-per-virtual-machine
[az-list-ips]: /cli/azure/vmss?view=azure-cli-latest.md#az-vmss-list-instance-public-ips
[reduce-latency-ppg]: reduce-latency-ppg.md
31 articles/aks/use-pod-security-policies.md
View file
@@ -3,16 +3,24 @@ title: Azure Kubernetes Service (AKS) でポッド セキュリティ ポリシ
description: Azure Kubernetes Service (AKS) で PodSecurityPolicy を使用してポッドのアドミッションを制御する方法について学習する
services: container-service
ms.topic: article
ms.date: 04/08/2020
ms.openlocfilehash: 9e3a17e4775150247ef7924dffec68cc86a0bcac
ms.sourcegitcommit: 25490467e43cbc3139a0df60125687e2b1c73c09
ms.date: 06/30/2020
ms.openlocfilehash: eb2e7fca3a808a1e2c4f7d1f81b8dc1d64deeee7
ms.sourcegitcommit: 124f7f699b6a43314e63af0101cd788db995d1cb
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 04/09/2020
ms.locfileid: "80998353"
ms.lasthandoff: 07/08/2020
ms.locfileid: "86077628"
---
# <a name="preview---secure-your-cluster-using-pod-security-policies-in-azure-kubernetes-service-aks"></a>プレビュー - Azure Kubernetes Service (AKS) でポッド セキュリティ ポリシーを使用してクラスターのセキュリティを保護する

<!--
> [!WARNING]
> **The pod security policy feature on AKS is set for deprecation** in favor of [Azure Policy for AKS](use-pod-security-on-azure-policy.md). The feature described in this document is not moving to general availability and is set for removal in September 2020.
> It is highly recommended to begin testing with the Azure Policy Add-on which offers unique policies which support scenarios captured by pod security policy.
**This document and feature are set for deprecation.**
-->

AKS クラスターのセキュリティを向上させるには、どのポッドをスケジュールできるかを制限することができます。 許可しないリソースを要求するポッドは、AKS クラスターで実行できません。 ポッド セキュリティ ポリシーを使用してこのアクセスを定義します。 この記事では、ポッド セキュリティ ポリシーを使用して AKS でのポッドのデプロイを制限する方法について説明します。

> [!IMPORTANT]
@@ -43,9 +51,6 @@ az extension update --name aks-preview

ポッド セキュリティ ポリシーを使用するために AKS クラスターを作成または更新するには、まず自分のサブスクリプションで機能フラグを有効にします。 *PodSecurityPolicyPreview* 機能フラグを登録するには、次の例に示すように [az feature register][az-feature-register] コマンドを使用します。

> [!CAUTION]
> サブスクリプションで機能を登録する場合、現時点ではその機能を登録解除することはできません。 一部のプレビュー機能を有効にした後、すべての AKS クラスターに対して既定値が使用され、サブスクリプション内に作成されます。 運用サブスクリプションではプレビュー機能を有効にしないでください。 プレビュー機能をテストし、フィードバックを集めるには、別のサブスクリプションを使用してください。
```azurecli-interactive
az feature register --name PodSecurityPolicyPreview --namespace Microsoft.ContainerService
```
@@ -109,7 +114,7 @@ privileged true * RunAsAny RunAsAny RunAsAny RunAsAny
kubectl get rolebindings default:privileged -n kube-system -o yaml
```

次の縮約された出力に示されているように、*psp:restricted* ClusterRole は、すべての *system:authenticated* ユーザーに割り当てられます。 この機能により、独自のポリシーが定義されていなくても基本レベルの制限が提供されます。
次の縮約された出力に示されているように、*psp:privileged* ClusterRole は、すべての *system:authenticated* ユーザーに割り当てられます。 この機能により、独自のポリシーが定義されていなくても基本レベルの特権が提供されます。

```
apiVersion: rbac.authorization.k8s.io/v1
@@ -167,7 +172,7 @@ alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-

## <a name="test-the-creation-of-a-privileged-pod"></a>特権のあるポッドの作成をテストする

まず、`privileged: true` のセキュリティ コンテキストを持つポッドをスケジュールしたときに何が起こるかをテストしてみましょう。 このセキュリティ コンテキストは、ポッドの特権をエスカレートします。 既定の AKS ポッド セキュリティ ポリシーを示した前のセクションでは、*restricted* ポリシーがこの要求を拒否するはずです。
まず、`privileged: true` のセキュリティ コンテキストを持つポッドをスケジュールしたときに何が起こるかをテストしてみましょう。 このセキュリティ コンテキストは、ポッドの特権をエスカレートします。 既定の AKS ポッド セキュリティ ポリシーを示した前のセクションでは、*privilege* ポリシーがこの要求を拒否するはずです。

`nginx-privileged.yaml` という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

@@ -202,7 +207,7 @@ Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods

## <a name="test-creation-of-an-unprivileged-pod"></a>特権のないポッドの作成をテストする

前の例で、ポッド仕様は特権のエスカレーションを要求しました。 この要求は既定の *restricted* ポッド セキュリティ ポリシーによって拒否されるため、ポッドはスケジュールできません。 次に、特権エスカレーション要求なしでその同じ NGINX ポッドを実行してみましょう。
前の例で、ポッド仕様は特権のエスカレーションを要求しました。 この要求は既定の *privilege* ポッド セキュリティ ポリシーによって拒否されるため、ポッドはスケジュールできません。 次に、特権エスカレーション要求なしでその同じ NGINX ポッドを実行してみましょう。

`nginx-unprivileged.yaml` という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

@@ -235,7 +240,7 @@ Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": po

## <a name="test-creation-of-a-pod-with-a-specific-user-context"></a>特定のユーザー コンテキストでのポッドの作成をテストする

前の例では、コンテナー イメージは、自動的に root を使用して NGINX をポート 80 にバインドしようとしました。 この要求は既定の *restricted* ポッド セキュリティ ポリシーによって拒否されたため、ポッドは開始できません。 次に、`runAsUser: 2000` などの特定のユーザー コンテキストを使用して、その同じ NGINX ポッドを実行してみましょう。
前の例では、コンテナー イメージは、自動的に root を使用して NGINX をポート 80 にバインドしようとしました。 この要求は既定の *privilege* ポッド セキュリティ ポリシーによって拒否されたため、ポッドは開始できません。 次に、`runAsUser: 2000` などの特定のユーザー コンテキストを使用して、その同じ NGINX ポッドを実行してみましょう。

`nginx-unprivileged-nonroot.yaml` という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

@@ -301,7 +306,7 @@ spec:
kubectl apply -f psp-deny-privileged.yaml
```

使用可能なポリシーを表示するには、次の例に示すように [kubectl get psp][kubectl-get] コマンドを使用します。 *psp-deny-privileged* ポリシーを、前述のポッドを作成する例で適用されていた既定の *restricted* ポリシーと比較します。 *PRIV* エスカレーションの使用のみがポリシーによって拒否されます。 *psp-deny-privileged* ポリシーには、ユーザーまたはグループの制限はありません。
使用可能なポリシーを表示するには、次の例に示すように [kubectl get psp][kubectl-get] コマンドを使用します。 *psp-deny-privileged* ポリシーを、前述のポッドを作成する例で適用されていた既定の *privilege* ポリシーと比較します。 *PRIV* エスカレーションの使用のみがポリシーによって拒否されます。 *psp-deny-privileged* ポリシーには、ユーザーまたはグループの制限はありません。

```console
$ kubectl get psp
12 articles/aks/virtual-nodes-portal.md
View file
@@ -5,12 +5,12 @@ services: container-service
ms.topic: conceptual
ms.date: 05/06/2019
ms.custom: references_regions
ms.openlocfilehash: e27a920aea18affd78f840d3063b8082f716745b
ms.sourcegitcommit: 1f48ad3c83467a6ffac4e23093ef288fea592eb5
ms.openlocfilehash: 6706d9c1c683cdf46fe42822cad67a49a69843a9
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/29/2020
ms.locfileid: "84193949"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85389821"
---
# <a name="create-and-configure-an-azure-kubernetes-services-aks-cluster-to-use-virtual-nodes-in-the-azure-portal"></a>Azure portal で仮想ノードを使用する Azure Kubernetes Service (AKS) クラスターを作成して構成する

@@ -59,15 +59,15 @@ az provider register --namespace Microsoft.ContainerInstance
* 米国西部 2 (westus2)

## <a name="known-limitations"></a>既知の制限事項
仮想ノードの機能は、ACI の機能セットに大きく依存します。 次のシナリオは、仮想ノードではまだサポートされていません
仮想ノードの機能は、ACI の機能セットに大きく依存します。 [Azure Container Instances のクォータと制限](../container-instances/container-instances-quotas.md)に加えて、次のシナリオは仮想ノードではまだサポートされていません。

* サービス プリンシパルを使用した ACR イメージのプル。 [対処法](https://github.com/virtual-kubelet/azure-aci/blob/master/README.md#private-registry)は、[Kubernetes シークレット](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-secret-by-providing-credentials-on-the-command-line)を使用することです
* [仮想ネットワークの制限事項](../container-instances/container-instances-vnet.md) (VNet ピアリング、Kubernetes ネットワーク ポリシー、およびネットワーク セキュリティ グループを使用したインターネットへの送信トラフィックなど)。
* Init コンテナー
* [ホストのエイリアス](https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/)
* ACI の exec の[引数](../container-instances/container-instances-exec.md#restrictions)
* [DaemonSets](concepts-clusters-workloads.md#statefulsets-and-daemonsets) ではポッドは仮想ノードにデプロイされません
* 仮想ノードでは、Linux ポッドのスケジュール設定がサポートされています。 オープンソースの [Virtual Kubelet ACI](https://github.com/virtual-kubelet/azure-aci) プロバイダーを手動でインストールして、Windows Server のコンテナーを ACI にスケジュールすることができます。
* 仮想ノードでは、Linux ポッドのスケジュール設定がサポートされています。 オープンソースの [Virtual Kubelet ACI](https://github.com/virtual-kubelet/azure-aci) プロバイダーを手動でインストールして、Windows Server のコンテナーを ACI にスケジュールすることができます。

## <a name="sign-in-to-azure"></a>Azure へのサインイン

18 articles/analysis-services/analysis-services-refresh-azure-automation.md
View file
@@ -6,31 +6,27 @@ ms.service: analysis-services
ms.topic: conceptual
ms.date: 05/07/2020
ms.author: chlound
ms.openlocfilehash: bbbc2863e06b4602a4175d46bbe21414041583ba
ms.sourcegitcommit: a6d477eb3cb9faebb15ed1bf7334ed0611c72053
ms.openlocfilehash: c3c9827814b7d638745761dbb5f3c7d2e581491b
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/08/2020
ms.locfileid: "82926563"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85389974"
---
# <a name="refresh-with-azure-automation"></a>Azure Automation を使用した更新

Azure Automation および PowerShell Runbook を使用して、Azure Analysis 表形式モデルに対する自動データ更新操作を行うことができます。

この記事の例では、[PowerShell SqlServer モジュール](https://docs.microsoft.com/powershell/module/sqlserver/?view=sqlserver-ps)を使用します。

モデルの更新方法を示す PowerShell Runbook のサンプルは、この記事の後半で提供されます。
この記事の例では、[SqlServer PowerShell モジュール](https://docs.microsoft.com/powershell/module/sqlserver/?view=sqlserver-ps)を使用します。 モデルの更新方法を示す PowerShell Runbook のサンプルは、この記事の後半で提供されます。

## <a name="authentication"></a>認証

すべての呼び出しを、有効な Azure Active Directory (OAuth 2) トークンで認証する必要があります。 この記事の例では、サービス プリンシパル (SPN) を使用して Azure Analysis Services を認証します。

サービス プリンシパルの作成の詳細については、[Azure portal を使用したサービス プリンシパルの作成](../active-directory/develop/howto-create-service-principal-portal.md)に関する記事を参照してください。
すべての呼び出しを、有効な Azure Active Directory (OAuth 2) トークンで認証する必要があります。 この記事の例では、サービス プリンシパル (SPN) を使用して Azure Analysis Services を認証します。 詳細については、[Azure portal を使用したサービス プリンシパルの作成](../active-directory/develop/howto-create-service-principal-portal.md)に関する記事を参照してください。

## <a name="prerequisites"></a>前提条件

> [!IMPORTANT]
> 次の例では、Azure Analysis Services ファイアウォールが無効になっていることを前提としています。 ファイアウォールが有効になっている場合は、要求イニシエーターのパブリック IP アドレスが、ファイアウォールでホワイトリストに登録されている必要があります。
> 次の例では、Azure Analysis Services ファイアウォールが無効になっていることを前提としています。 ファイアウォールが有効になっている場合は、要求イニシエーターのパブリック IP アドレスがファイアウォール規則に含まれている必要があります。
### <a name="install-sqlserver-modules-from-powershell-gallery"></a>PowerShell ギャラリーから SqlServer モジュールをインストールします。

16 articles/analysis-services/analysis-services-server-alias.md
View file
@@ -4,15 +4,15 @@ description: Azure Analysis Services サーバー名エイリアスを作成す
author: minewiskan
ms.service: azure-analysis-services
ms.topic: conceptual
ms.date: 05/19/2020
ms.date: 06/16/2020
ms.author: owend
ms.reviewer: minewiskan
ms.openlocfilehash: 4b416a25fd0befa91076fed5f9bf5df23ea30844
ms.sourcegitcommit: 595cde417684e3672e36f09fd4691fb6aa739733
ms.openlocfilehash: 435649c5431ff14461245fee88cebe4a2c571663
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/20/2020
ms.locfileid: "83698989"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85361440"
---
# <a name="alias-server-names"></a>サーバー名のエイリアス

@@ -37,7 +37,7 @@ ms.locfileid: "83698989"

エイリアス エンドポイントを作成するには、有効な Azure Analysis Services サーバー名を返す任意のメソッドを使用できます。 たとえば、実際のサーバー名が含まれた Azure Blob Storage 内のファイルを参照したり、ASP.NET Web フォーム アプリケーションを作成して発行したりできます。

この例では、ASP.NET Web フォーム アプリケーションが Visual Studio で作成されています。 マスター ページの参照およびユーザー コントロールは、Default.aspx ページから削除されています。 Default.aspx の内容は、次の Page ディレクティブだけです。
この例では、ASP.NET Web フォーム アプリケーションが Visual Studio で作成されています。 ページの参照とユーザー コントロールは、Default.aspx ページから削除されています。 Default.aspx の内容は、次の Page ディレクティブだけです。

```
<%@ Page Title="Home Page" Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="FriendlyRedirect._Default" %>
@@ -52,7 +52,7 @@ protected void Page_Load(object sender, EventArgs e)
}
```

## <a name="see-also"></a>参照
## <a name="see-also"></a>関連項目

[クライアント ライブラリ](analysis-services-data-providers.md)
[クライアント ライブラリ](https://docs.microsoft.com/analysis-services/client-libraries?view=azure-analysis-services-current)
[Power BI Desktop からの接続](analysis-services-connect-pbi.md)
16 articles/analysis-services/analysis-services-service-principal.md
View file
@@ -4,23 +4,23 @@ description: Azure Analysis Services 管理タスクを自動化するための
author: minewiskan
ms.service: azure-analysis-services
ms.topic: conceptual
ms.date: 05/26/2020
ms.date: 07/07/2020
ms.author: owend
ms.reviewer: minewiskan
ms.openlocfilehash: 9797b4c8f8059f9cfefbb70672aa202c7a3f4825
ms.sourcegitcommit: 1692e86772217fcd36d34914e4fb4868d145687b
ms.openlocfilehash: 28947d1fa4ece5d6285651ef07342cae06ad8bc8
ms.sourcegitcommit: 124f7f699b6a43314e63af0101cd788db995d1cb
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/29/2020
ms.locfileid: "84168337"
ms.lasthandoff: 07/08/2020
ms.locfileid: "86077373"
---
# <a name="automation-with-service-principals"></a>サービス プリンシパルによる自動化

サービス プリンシパルは、リソース/サービス レベルの無人操作を実行する目的でテナント内で作成する Azure Active Directory アプリケーション リソースです。 アプリケーション ID とパスワードまたは証明書が与えられた、独自の*ユーザー ID* です。 サービス プリンシパルには、割り当てられたロールとアクセス許可によって定義されるタスクを実行するために必要な権限のみが与えられます。

Analysis Services では、サービス プリンシパルは Azure Automation、PowerShell 無人モード、カスタム クライアント アプリケーション、Web アプリと共に使用し、共通タスクを自動化します。 たとえば、サーバーのプロビジョニング、モデルのデプロイ、データ更新、拡大縮小、一時停止/再開をすべて、サービス プリンシパルを利用することで自動化できます。 権限は、通常の Azure AD UPN アカウントとほぼ同じように、ロール メンバーシップを介してサービス プリンシパルに割り当てられます。

Analysis Services では、サービス プリンシパルを使用してマネージド ID によって実行される操作もサポートされます。 詳細については、[Azure リソースのマネージド ID に関するページ](../active-directory/managed-identities-azure-resources/overview.md) と [Azure AD 認証をサポートする Azure サービスに関するページ](../active-directory/managed-identities-azure-resources/services-support-managed-identities.md#azure-analysis-services)を参照してください。
Analysis Services では、サービス プリンシパルを使用してマネージド ID によって実行される操作もサポートされます。 詳細については、[Azure リソースのマネージド ID に関するページ](../active-directory/managed-identities-azure-resources/overview.md) と [Azure AD 認証をサポートする Azure サービスに関するページ](../active-directory/managed-identities-azure-resources/services-support-managed-identities.md#azure-analysis-services)を参照してください。

## <a name="create-service-principals"></a>サービス プリンシパルの作成

@@ -38,7 +38,7 @@ Runbook 操作のために、サービス プリンシパルの資格情報と

## <a name="add-service-principals-to-server-admin-role"></a>サービス プリンシパルをサーバー管理者ロールに追加する

Analysis Services サーバー管理操作のためにサービス プリンシパルを使用するには、最初にサービス プリンシパルをサーバー管理者ロールに追加する必要があります。 詳細については、「[サーバー管理者ロールへのサービス プリンシパルの追加](analysis-services-addservprinc-admins.md)」を参照してください。
Analysis Services サーバー管理操作のためにサービス プリンシパルを使用するには、最初にサービス プリンシパルをサーバー管理者ロールに追加する必要があります。 サービス プリンシパルは、サーバー管理者ロールに直接追加する必要があります。 サービス プリンシパルをセキュリティ グループに追加してから、そのセキュリティ グループをサーバー管理者ロールに追加することはサポートされていません。 詳細については、「[サーバー管理者ロールへのサービス プリンシパルの追加](analysis-services-addservprinc-admins.md)」を参照してください。

## <a name="service-principals-in-connection-strings"></a>接続文字列のサービス プリンシパル

@@ -92,7 +92,7 @@ Invoke-ProcessTable -Server "asazure://westcentralus.asazure.windows.net/myserve

### <a name="amo-and-adomd"></a>AMO と ADOMD

クライアント アプリケーションや Web アプリと接続するとき、[AMO と ADOMD のクライアント ライブラリ](analysis-services-data-providers.md) バージョン 15.0.2 以降の、NuGet からインストールできるパッケージでは、接続文字列にサービス プリンシパルを指定できます。構文 `app:AppID` とパスワードまたは `cert:thumbprint` を利用します。
クライアント アプリケーションや Web アプリと接続するとき、[AMO と ADOMD のクライアント ライブラリ](https://docs.microsoft.com/analysis-services/client-libraries?view=azure-analysis-services-current) バージョン 15.0.2 以降の、NuGet からインストールできるパッケージでは、接続文字列にサービス プリンシパルを指定できます。構文 `app:AppID` とパスワードまたは `cert:thumbprint` を利用します。

次の例では、`appID` と `password` を使用し、モデル データベース更新操作を実行します。

42 articles/api-management/api-management-authentication-policies.md
View file
@@ -11,14 +11,14 @@ ms.service: api-management
ms.workload: mobile
ms.tgt_pltfrm: na
ms.topic: article
ms.date: 11/27/2017
ms.date: 06/12/2020
ms.author: apimpm
ms.openlocfilehash: 70f124a498ff4aa45b5d90f6221fe3d0121e804a
ms.sourcegitcommit: 12f23307f8fedc02cd6f736121a2a9cea72e9454
ms.openlocfilehash: 70f1e4414888ceb8fb04fd92dc954d1a7c06dcb4
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 05/30/2020
ms.locfileid: "84221041"
ms.lasthandoff: 07/02/2020
ms.locfileid: "85557986"
---
# <a name="api-management-authentication-policies"></a>API Management の認証ポリシー
このトピックでは、次の API Management ポリシーについて説明します。 ポリシーを追加および構成する方法については、「 [Azure API Management のポリシー](https://go.microsoft.com/fwlink/?LinkID=398186)」をご覧ください。
@@ -77,14 +77,23 @@ ms.locfileid: "84221041"

### <a name="examples"></a>例

この例では、クライアントの証明書は拇印によって識別されます。
この例では、クライアント証明書はサムプリントによって識別されます。

```xml
<authentication-certificate thumbprint="CA06F56B258B7A0D4F2B05470939478651151984" />
```
この例では、クライアントの証明書はリソース名によって識別されます。

この例では、クライアント証明書はリソース名によって識別されます。

```xml
<authentication-certificate certificate-id="544fe9ddf3b8f30fb490d90f" />
```
```

この例では、クライアント証明書は、組み込みの証明書ストアから取得されるのではなく、ポリシーで設定されています。

```xml
<authentication-certificate body="@(context.Variables.GetValueOrDefault<byte[]>("byteCertificate"))" password="optional-certificate-password" />
```

### <a name="elements"></a>要素

@@ -96,8 +105,10 @@ ms.locfileid: "84221041"

|名前|説明|必須|Default|
|----------|-----------------|--------------|-------------|
|thumbprint|クライアント証明書のサムプリント。|`thumbprint` または `certificate-id` のいずれかが存在しなければなりません。|該当なし|
|証明書 ID|証明書リソースの名前。|`thumbprint` または `certificate-id` のいずれかが存在しなければなりません。|該当なし|
|thumbprint|クライアント証明書のサムプリント。|`thumbprint` または `certificate-id` のいずれかが存在しなければなりません。|該当なし|
|証明書 ID|証明書リソースの名前。|`thumbprint` または `certificate-id` のいずれかが存在しなければなりません。|該当なし|
|body|バイト配列としてのクライアント証明書。|いいえ|該当なし|
|password|クライアント証明書のパスワード。|`body` で指定された証明書がパスワードで保護されている場合に使用されます。|該当なし|

### <a name="usage"></a>使用法
このポリシーは、次のポリシー [セクション](https://azure.microsoft.com/documentation/articles/api-management-howto-policies/#sections)と[スコープ](https://azure.microsoft.com/documentation/articles/api-management-howto-policies/#scopes)で使用できます。
@@ -107,12 +118,14 @@ ms.locfileid: "84221041"
- **ポリシー スコープ:** すべてのスコープ

## <a name="authenticate-with-managed-identity"></a><a name="ManagedIdentity"></a> マネージド ID による認証
`authentication-managed-identity` ポリシーを使用して、API Management サービスのマネージド ID を利用したバックエンド サービスによる認証を行います。 このポリシーでは、指定されたリソースにアクセスするためのアクセス トークンを Azure Active Directory から取得するために、基本的にマネージド ID を利用します。 トークンが正常に取得されると、ポリシーは、`Bearer` スキームを使用してトークンの値を `Authorization` ヘッダーに設定します。
`authentication-managed-identity` ポリシーを使用して、マネージド ID を利用するバックエンド サービスで認証します。 このポリシーでは、指定されたリソースにアクセスするためのアクセス トークンを Azure Active Directory から取得するために、基本的にマネージド ID を利用します。 トークンが正常に取得されると、ポリシーは、`Bearer` スキームを使用してトークンの値を `Authorization` ヘッダーに設定します。

システムによって割り当てられた ID と、ユーザーが割り当てた複数の ID のいずれかの、どちらを使用してもトークンを要求できます。 `client-id` が指定されていない場合、システムによって割り当てられた ID が指定されたと見なされます。 `client-id` 変数が指定されている場合、そのユーザー割り当て ID のトークンが Azure Active Directory に要求されます

### <a name="policy-statement"></a>ポリシー ステートメント

```xml
<authentication-managed-identity resource="resource" output-token-variable-name="token-variable" ignore-error="true|false"/>
<authentication-managed-identity resource="resource" client-id="clientid of user-assigned identity" output-token-variable-name="token-variable" ignore-error="true|false"/>
```

### <a name="example"></a>例
@@ -127,7 +140,7 @@ ms.locfileid: "84221041"
<authentication-managed-identity resource="https://vault.azure.net"/> <!--Azure Key Vault-->
```
```xml
<authentication-managed-identity resource="https://servicebus.azure.net/"/> <!--Azure Service Busr-->
<authentication-managed-identity resource="https://servicebus.azure.net/"/> <!--Azure Service Bus-->
```
```xml
<authentication-managed-identity resource="https://storage.azure.com/"/> <!--Azure Blob Storage-->
@@ -169,7 +182,8 @@ ms.locfileid: "84221041"

|名前|説明|必須|Default|
|----------|-----------------|--------------|-------------|
|resource|文字列 をオンにします。 Azure Active Directory におけるターゲット Web API のアプリ ID (セキュリティで保護されたリソース)。|はい|該当なし|
|resource|文字列 をオンにします。 Azure Active Directory におけるターゲット Web API のアプリ ID (セキュリティで保護されたリソース)。|はい|該当なし|
|client-id|文字列 をオンにします。 Azure Active Directory のユーザー割り当て ID のアプリ ID。|いいえ|システム割り当て ID|
|output-token-variable-name|文字列 をオンにします。 オブジェクトの種類 `string` としてトークン値を受け取るコンテキスト変数の名前。 |いいえ|該当なし|
|ignore-error|Boolean です。 `true` に設定された場合、アクセス トークンが取得されなかったとしても、ポリシー パイプラインは引き続き実行されます。|いいえ|false|

14 articles/api-management/api-management-error-handling-policies.md
View file
@@ -13,12 +13,12 @@ ms.tgt_pltfrm: na
ms.topic: article
ms.date: 01/10/2020
ms.author: apimpm
ms.openlocfilehash: 2c021a6d10c95b58ac444de8ea895ca01371a2b0
ms.sourcegitcommit: 2ec4b3d0bad7dc0071400c2a2264399e4fe34897
ms.openlocfilehash: 0bc4792b44ccff23a141460c3521d684801c4567
ms.sourcegitcommit: 877491bd46921c11dd478bd25fc718ceee2dcc08
ms.translationtype: HT
ms.contentlocale: ja-JP
ms.lasthandoff: 03/27/2020
ms.locfileid: "75902454"
ms.lasthandoff: 07/02/2020
ms.locfileid: "84674263"
---
# <a name="error-handling-in-api-management-policies"></a>API Management のポリシーにおけるエラー処理

@@ -71,12 +71,16 @@ Azure API Management のポリシーは、次の例で示すとおり、`inbound
- [log-to-eventhub](api-management-advanced-policies.md#log-to-eventhub)
- [json-to-xml](api-management-transformation-policies.md#ConvertJSONtoXML)
- [xml-to-json](api-management-transformation-policies.md#ConvertXMLtoJSON)
- [limit-concurrency](api-management-advanced-policies.md#LimitConcurrency)
- [mock-response](api-management-advanced-policies.md#mock-response)
- [retry](api-management-advanced-policies.md#Retry)
- [trace](api-management-advanced-policies.md#Trace)

## <a name="lasterror"></a>lastError

エラーが発生し、コントロールが `on-error` ポリシー セクションにジャンプすると、エラーは [context.LastError](api-management-policy-expressions.md#ContextVariables) プロパティ内に格納されます。これには、`on-error` セクションにあるポリシーがアクセス可能です。 LastError のプロパティは次のとおりです。

| Name | 種類 | 説明 | 必須 |
| 名前 | Type | 説明 | 必須 |
| ---------- | ------ | --------------------------------------------------------------------------------------------------------- | -------- |
| `Source` | string | エラーが発生した要素を指定します。 ポリシーまたは組み込みパイプライン ステップ名のいずれかになります。 | はい |
| `Reason` | string | エラー処理に使用できる、マシンに適したエラー コード。 | いいえ |
25 articles/api-management/api-management-using-with-vnet.md
View file
10 articles/app-service/configure-common.md
View file
110 articles/app-service/configure-language-dotnet-framework.md
View file
90 articles/app-service/manage-disaster-recovery.md
View file
71 articles/app-service/networking/private-endpoint.md
View file
12 articles/app-service/troubleshoot-intermittent-outbound-connection-errors.md
View file
20 articles/application-gateway/certificates-for-backend-authentication.md
View file
21 articles/automation/automation-remove-vms-from-update-management.md
View file
12 articles/azure-cache-for-redis/cache-aspnet-session-state-provider.md
View file
20 articles/azure-functions/functions-bindings-cosmosdb-v2.md
View file
11 articles/azure-functions/functions-bindings-expressions-patterns.md
View file
12 articles/azure-functions/functions-bindings-service-bus-trigger.md
View file
12 articles/azure-functions/functions-bindings-service-bus.md
View file
180 articles/azure-functions/functions-create-maven-intellij.md
View file
19 articles/azure-functions/functions-host-json.md
View file
12 articles/azure-functions/functions-reliable-event-processing.md
View file
59 articles/azure-maps/create-data-source-web-sdk.md
View file
18 articles/azure-maps/drawing-error-visualizer.md
View file
70 articles/azure-maps/drawing-requirements.md
View file
40 articles/azure-maps/geographic-coverage.md
View file
10 articles/azure-monitor/app/console.md
View file
14 articles/azure-monitor/app/java-in-process-agent.md
View file
15 articles/azure-monitor/app/monitor-functions.md
View file
14 articles/azure-monitor/app/profiler.md
View file
10 articles/azure-monitor/app/sampling.md
View file
24 articles/azure-monitor/app/sdk-connection-string.md
View file
243 articles/azure-monitor/insights/container-insights-enable-arc-enabled-clusters.md
View file
12 articles/azure-monitor/insights/cosmosdb-insights-overview.md
View file
34 articles/azure-monitor/insights/key-vault-insights-overview.md
View file
12 articles/azure-monitor/insights/redis-cache-insights-overview.md
View file
75 articles/azure-monitor/insights/troubleshoot-workbooks.md
View file
57 articles/azure-monitor/platform/activity-log-schema.md
View file
11 articles/azure-monitor/platform/custom-fields.md
View file
69 articles/azure-monitor/platform/diagnostic-settings.md
View file
37 articles/azure-monitor/platform/platform-logs-overview.md
View file
207 articles/azure-monitor/platform/resource-logs.md
View file
19 articles/azure-netapp-files/azure-netapp-files-sdk-cli.md
View file
105 articles/azure-netapp-files/azure-netapp-files-solution-architectures.md
View file
22 ...source-manager/management/move-limitations/virtual-machines-move-limitations.md
View file
18 articles/azure-resource-manager/management/resource-name-rules.md
View file
315 articles/azure-resource-manager/management/tag-support.md
View file
304 articles/azure-resource-manager/templates/complete-mode-deletion.md
View file
12 articles/azure-resource-manager/templates/deployment-quota-exceeded.md
View file
27 articles/azure-resource-manager/templates/template-best-practices.md
View file
119 articles/azure-resource-manager/templates/view-resources.md
View file
14 articles/azure-sql/database/active-geo-replication-overview.md
View file
24 articles/azure-sql/database/audit-write-storage-account-behind-vnet-firewall.md
View file
10 articles/azure-sql/database/elastic-jobs-overview.md
View file
10 articles/azure-sql/database/elastic-query-overview.md
View file
10 articles/azure-sql/database/failover-group-add-elastic-pool-tutorial.md
View file
44 articles/azure-sql/database/gateway-migration.md
View file
12 articles/azure-sql/database/saas-dbpertenant-performance-monitoring.md
View file
10 articles/azure-sql/database/saas-multitenantdb-adhoc-reporting.md
View file
14 articles/azure-sql/managed-instance/management-endpoint-find-ip-address.md
View file
71 articles/azure-sql/managed-instance/migrate-to-instance-from-sql-server.md
View file
10 articles/azure-sql/managed-instance/minimal-tls-version-configure.md
View file
176 articles/azure-sql/managed-instance/sql-managed-instance-paas-overview.md
View file
57 articles/azure-sql/virtual-machines/windows/create-sql-vm-powershell.md
View file
59 articles/azure-vmware/concepts-api-management.md
View file
283 articles/backup/backup-azure-backup-server-vmware.md
View file
83 articles/backup/backup-azure-delete-vault.md
View file
29 articles/backup/backup-azure-manage-mars.md
View file
121 articles/backup/backup-mabs-protection-matrix.md
View file
10 articles/blockchain/service/configure-aad.md
View file
10 articles/blockchain/service/configure-transaction-nodes.md
View file
12 articles/blockchain/service/manage-consortium-powershell.md
View file
86 articles/cloud-services/cloud-services-guestos-msrc-releases.md
View file
10 articles/cognitive-services/Bing-Web-Search/bing-web-upgrade-guide-v5-to-v7.md
View file
44 ...les/cognitive-services/Face/Face-API-How-to-Topics/specify-recognition-model.md
View file
12 articles/cognitive-services/LUIS/developer-reference-resource.md
View file
173 articles/cognitive-services/LUIS/luis-concept-feature.md
View file
20 articles/cognitive-services/LUIS/luis-container-howto.md
View file
10 articles/cognitive-services/Speech-Service/custom-commands.md
View file
13 ...ve-services/Speech-Service/how-to-custom-commands-add-parameters-to-commands.md
View file
38 ...itive-services/Speech-Service/how-to-custom-commands-send-activity-to-client.md
View file
27 ...es/cognitive-services/Speech-Service/how-to-custom-commands-setup-speech-sdk.md
View file
17 ...les/cognitive-services/Speech-Service/quickstart-custom-commands-application.md
View file
10 articles/cognitive-services/Speech-Service/speech-sdk.md
View file
30 articles/cognitive-services/bing-visual-search/use-insights-token.md
View file
113 articles/cognitive-services/immersive-reader/reference.md
View file
10 articles/connectors/connectors-create-api-mq.md
View file
12 articles/connectors/connectors-native-recurrence.md
View file
14 articles/connectors/connectors-native-sliding-window.md
View file
21 articles/connectors/connectors-sftp-ssh.md
View file
17 articles/container-instances/container-instances-image-security.md
View file
36 articles/container-registry/container-registry-azure-policy.md
View file
30 articles/container-registry/container-registry-concepts.md
View file
26 articles/container-registry/container-registry-storage.md
View file
26 articles/container-registry/container-registry-tasks-authentication-key-vault.md
View file
34 ...es/container-registry/container-registry-tasks-cross-registry-authentication.md
View file
20 articles/cosmos-db/access-secrets-from-keyvault.md
View file
24 articles/cosmos-db/certificate-based-authentication.md
View file
52 articles/cosmos-db/cosmosdb-cassandra-api-migrate-data-striim.md
View file
54 articles/cosmos-db/cosmosdb-sql-api-migrate-data-striim.md
View file
43 articles/cosmos-db/create-real-time-weather-dashboard-powerbi.md
View file
12 articles/cosmos-db/data-explorer.md
View file
10 articles/cosmos-db/faq.md
View file
14 articles/cosmos-db/find-request-unit-charge.md
View file
16 articles/cosmos-db/graph-modeling.md
View file
20 articles/cosmos-db/graph-visualization.md
View file
61 articles/cosmos-db/high-availability.md
View file
12 articles/cosmos-db/how-to-backup-and-restore.md
View file
14 articles/cosmos-db/how-to-configure-cross-origin-resource-sharing.md
View file
22 articles/cosmos-db/how-to-configure-firewall.md
View file
30 articles/cosmos-db/how-to-configure-private-endpoints.md
View file
22 articles/cosmos-db/how-to-create-container.md
View file
14 articles/cosmos-db/how-to-create-multiple-cosmos-db-triggers.md
View file
13 articles/cosmos-db/how-to-define-unique-keys.md
View file
104 articles/cosmos-db/how-to-manage-conflicts.md
View file
72 articles/cosmos-db/how-to-manage-consistency.md
View file
13 articles/cosmos-db/how-to-manage-indexing-policy.md
View file
69 articles/cosmos-db/how-to-setup-cmk.md
View file
55 articles/cosmos-db/how-to-write-stored-procedures-triggers-udfs.md
View file
16 articles/cosmos-db/import-github-notebooks.md
View file
12 articles/cosmos-db/large-partition-keys.md
View file
65 articles/cosmos-db/mongodb-change-streams.md
View file
22 articles/cosmos-db/mongodb-compass.md
View file
18 articles/cosmos-db/mongodb-robomongo.md
View file
20 articles/cosmos-db/monitor-server-side-latency.md
View file
12 articles/cosmos-db/optimize-cost-throughput.md
View file
24 articles/cosmos-db/oracle-migrate-cosmos-db-blitzz.md
View file
16 articles/cosmos-db/partitioning-overview.md
View file
13 articles/cosmos-db/performance-levels.md
View file
17 articles/cosmos-db/provision-throughput-autoscale.md
View file
36 articles/cosmos-db/set-throughput.md
View file
21 articles/cosmos-db/sql-api-sdk-dotnet-changefeed.md
View file
24 articles/cosmos-db/sql-api-sdk-dotnet-core.md
View file
45 articles/cosmos-db/sql-query-mathematical-functions.md
View file
72 articles/cosmos-db/storage-explorer.md
View file
25 articles/data-factory/connector-azure-data-lake-store.md
View file
13 articles/data-factory/connector-azure-file-storage.md
View file
11 articles/data-factory/connector-ftp.md
View file
155 articles/data-factory/connector-sftp.md
View file
161 articles/data-factory/self-hosted-integration-runtime-troubleshoot-guide.md
View file
12 articles/data-factory/v1/data-factory-create-data-factories-programmatically.md
View file
10 articles/data-factory/v1/data-factory-create-pipelines.md
View file
10 ...cles/data-factory/v1/data-factory-invoke-stored-procedure-from-copy-activity.md
View file
16 articles/data-factory/v1/data-factory-json-scripting-reference.md
View file
12 articles/data-factory/v1/data-factory-samples.md
View file
56 articles/data-factory/v1/data-factory-scheduling-and-execution.md
View file
16 articles/data-factory/v1/data-factory-stored-proc-activity.md
View file
10 articles/data-factory/v1/data-factory-supported-file-and-compression-formats.md
View file
38 articles/data-factory/v1/data-factory-troubleshoot-gateway-issues.md
View file
10 articles/data-factory/v1/how-to-invoke-ssis-package-stored-procedure-activity.md
View file
45 articles/data-lake-analytics/data-lake-analytics-get-started-cli.md
View file
244 articles/data-lake-analytics/data-lake-analytics-u-sql-sdk.md
View file
21 articles/data-share/concepts-roles-permissions.md
View file
12 articles/data-share/data-share-troubleshoot.md
View file
11 articles/data-share/samples-powershell.md
View file
11 articles/databox/data-box-disk-portal-customer-managed-shipping.md
View file
122 articles/devtest-labs/configure-shared-image-gallery.md
View file
91 articles/devtest-labs/devtest-lab-add-claimable-vm.md
View file
51 articles/devtest-labs/devtest-lab-create-custom-image-from-vm-using-portal.md
View file
129 articles/devtest-labs/devtest-lab-manage-formulas.md
View file
98 articles/devtest-labs/test-app-azure.md
View file
48 articles/digital-twins/concepts-integration.md
View file
96 articles/digital-twins/concepts-route-events.md
View file
255 articles/digital-twins/how-to-manage-model.md
View file
33 articles/digital-twins/reference-service-limits.md
View file
48 articles/digital-twins/resources-customer-data-requests.md
View file
10 articles/dms/how-to-migrate-ssis-packages-managed-instance.md
View file
18 articles/dms/tutorial-sql-server-to-azure-sql.md
View file
35 articles/event-grid/managed-service-identity.md
View file
80 articles/event-grid/set-alerts.md
View file
40 articles/event-hubs/event-hubs-features.md
View file
121 articles/firewall-manager/ip-groups.md
View file
44 articles/firewall-manager/trusted-security-partners.md
View file
19 articles/firewall-manager/vhubs-and-vnets.md
View file
73 articles/firewall/dns-settings.md
View file
26 articles/firewall/firewall-faq.md
View file
13 articles/firewall/fqdn-tags.md
View file
20 articles/firewall/ip-groups.md
View file
14 articles/firewall/snat-private-range.md
View file
16 articles/firewall/sql-fqdn-filtering.md
View file
9 articles/frontdoor/front-door-diagnostics.md
View file
138 articles/governance/policy/concepts/effects.md
View file
30 articles/hdinsight/hadoop/apache-hadoop-use-sqoop-mac-linux.md
View file
24 articles/hdinsight/hadoop/apache-hadoop-use-sqoop-powershell.md
View file
66 articles/hdinsight/hdinsight-release-notes-archive.md
View file
107 articles/hdinsight/hdinsight-release-notes.md
View file
62 articles/hdinsight/hdinsight-using-spark-query-hbase.md
View file
42 articles/hdinsight/spark/apache-spark-connect-to-sql-database.md
View file
12 articles/hdinsight/spark/apache-spark-troubleshoot-rpctimeoutexception.md
View file
14 articles/hdinsight/spark/migrate-versions.md
View file
12 articles/hdinsight/spark/optimize-cluster-configuration.md
View file
12 articles/hdinsight/spark/optimize-data-processing.md
View file
12 articles/hdinsight/spark/optimize-data-storage.md
View file
12 articles/hdinsight/spark/optimize-memory-usage.md
View file
13 articles/hdinsight/spark/zookeeper-troubleshoot-quorum-fails.md
View file
10 articles/internet-analyzer/troubleshoot.md
View file
16 articles/iot-central/core/howto-set-up-template.md
View file
15 articles/iot-hub/iot-hub-customer-managed-keys.md
View file
27 articles/iot-hub/iot-hub-devguide-endpoints.md
View file
102 articles/iot-hub/iot-hub-metrics.md
View file
52 articles/iot-hub/iot-hub-monitor-resource-health.md
View file
238 articles/key-vault/keys/hsm-protected-keys-ncipher.md
View file
128 articles/lab-services/class-type-big-data-analytics.md
View file
89 articles/lab-services/hackathon-labs.md
View file
216 articles/lab-services/how-to-configure-student-usage.md
View file
73 ...es/lab-services/how-to-enable-nested-virtualization-template-vm-using-script.md
View file
18 articles/lighthouse/concepts/enterprise.md
View file
24 articles/lighthouse/how-to/view-manage-service-providers.md
View file
12 articles/logic-apps/concepts-schedule-automated-recurring-tasks-workflows.md
View file
10 articles/logic-apps/logic-apps-create-azure-resource-manager-templates.md
View file
12 articles/machine-learning/algorithm-module-reference/designer-error-codes.md
View file
12 articles/machine-learning/algorithm-module-reference/import-data.md
View file
22 ...es/machine-learning/algorithm-module-reference/train-anomaly-detection-model.md
View file
149 .../machine-learning/algorithm-module-reference/train-wide-and-deep-recommender.md
View file
94 articles/machine-learning/concept-compute-instance.md
View file
125 articles/machine-learning/concept-editions.md
View file
59 articles/machine-learning/concept-fairness-ml.md
View file
36 articles/machine-learning/concept-onnx.md
View file
85 articles/machine-learning/concept-optimize-data-processing.md
View file
38 articles/machine-learning/how-to-assign-roles.md
View file
22 articles/machine-learning/how-to-debug-parallel-run-step.md
View file
16 articles/machine-learning/how-to-deploy-azure-container-instance.md
View file
21 articles/machine-learning/how-to-deploy-inferencing-gpus.md
View file
16 articles/machine-learning/how-to-designer-transform-data.md
View file
86 articles/machine-learning/how-to-enable-app-insights.md
View file
10 articles/machine-learning/how-to-manage-workspace.md
View file
256 articles/machine-learning/how-to-setup-authentication.md
View file
15 articles/machine-learning/how-to-understand-automated-ml.md
View file
13 articles/machine-learning/how-to-use-labeled-dataset.md
View file
46 articles/machine-learning/resource-known-issues.md
View file
32 articles/machine-learning/studio/evaluate-model-performance.md
View file
12 articles/machine-learning/studio/support-aml-studio.md
View file
958 articles/machine-learning/team-data-science-process/sqldw-walkthrough.md
View file
47 articles/mariadb/concepts-read-replicas.md
View file
13 articles/mariadb/howto-configure-server-logs-cli.md
View file
206 articles/marketplace/gtm-offer-listing-best-practices.md
View file
32 articles/marketplace/marketplace-criteria-content-validation.md
View file
37 articles/marketplace/partner-center-portal/update-existing-offer.md
View file
174 articles/marketplace/review-publish-offer.md
View file
12 articles/media-services/live-video-analytics-edge/deploy-iot-edge-device.md
View file
99 articles/media-services/live-video-analytics-edge/troubleshoot-how-to.md
View file
78 articles/migrate/common-questions-discovery-assessment.md
View file
264 articles/migrate/concepts-azure-vmware-solution-assessment-calculation.md
View file
80 articles/migrate/concepts-dependency-visualization.md
View file
164 articles/migrate/how-to-create-azure-vmware-solution-assessment.md
View file
55 articles/migrate/how-to-modify-assessment.md
View file
26 articles/mysql/concepts-data-encryption-mysql.md
View file
73 articles/mysql/concepts-infrastructure-double-encryption.md
View file
49 articles/mysql/concepts-read-replicas.md
View file
18 articles/mysql/howto-configure-audit-logs-cli.md
View file
18 articles/mysql/howto-configure-audit-logs-portal.md
View file
26 articles/mysql/howto-configure-privatelink-portal.md
View file
12 articles/mysql/howto-configure-server-parameters-using-powershell.md
View file
23 articles/mysql/howto-configure-sign-in-azure-ad-authentication.md
View file
12 articles/network-watcher/network-watcher-monitor-with-azure-automation.md
View file
22 ...tification-hubs/notification-hubs-aspnet-backend-ios-apple-apns-notification.md
View file
12 ...ubs/notification-hubs-aspnet-backend-ios-push-apple-apns-secure-notification.md
View file
18 ...fication-hubs/notification-hubs-push-notification-http2-token-authentication.md
View file
21 articles/postgresql/concept-reserved-pricing.md
View file
13 articles/postgresql/concepts-aad-authentication.md
View file
10 articles/postgresql/concepts-connectivity-architecture.md
View file
89 articles/postgresql/concepts-hyperscale-reserved-pricing.md
View file
73 articles/postgresql/concepts-infrastructure-double-encryption.md
View file
48 articles/postgresql/concepts-logical.md
View file
26 articles/postgresql/howto-configure-privatelink-portal.md
View file
64 articles/postgresql/howto-double-encryption.md
View file
48 articles/postgresql/howto-tls-configurations.md
View file
43 articles/remote-rendering/how-tos/authentication.md
View file
10 articles/remote-rendering/how-tos/conversion/get-information.md
View file
18 articles/remote-rendering/how-tos/unity/install-remote-rendering-unity-package.md
View file
72 articles/remote-rendering/resources/troubleshoot.md
View file
52 articles/role-based-access-control/elevate-access-global-admin.md
View file
18 articles/role-based-access-control/role-assignments-external-users.md
View file
87 articles/role-based-access-control/role-assignments-list-portal.md
View file
95 articles/role-based-access-control/role-assignments-portal.md
View file
380 articles/role-based-access-control/transfer-subscription.md
View file
46 articles/search/cognitive-search-incremental-indexing-conceptual.md
View file
71 articles/search/cognitive-search-resources-documentation.md
View file
38 articles/search/cognitive-search-skill-ocr.md
View file
196 articles/search/cognitive-search-working-with-skillsets.md
View file
12 articles/search/index-add-scoring-profiles.md
View file
35 articles/search/knowledge-store-projections-examples.md
View file
96 articles/search/search-analyzers.md
View file
88 articles/search/search-api-migration.md
View file
12 articles/search/search-howto-index-azure-data-lake-storage.md
View file
30 articles/search/search-lucene-query-architecture.md
View file
92 articles/search/search-manage.md
View file
18 articles/search/search-more-like-this.md
View file
12 articles/search/search-security-manage-encryption-keys.md
View file
20 articles/search/search-security-trimming-for-azure-search.md
View file
33 articles/search/search-what-is-data-import.md
View file
23 articles/security-center/built-in-vulnerability-assessment.md
View file
60 articles/security-center/secure-score-security-controls.md
View file
16 articles/security-center/security-center-alert-validation.md
View file
152 articles/security-center/security-center-iaas-advanced-data.md
View file
52 articles/security-center/security-center-incident.md
View file
10 articles/security-center/security-center-remediate-recommendations.md
View file
10 articles/security/benchmarks/security-control-data-protection.md
View file
9 articles/security/develop/security-code-analysis-onboard.md
View file
22 articles/security/develop/security-code-analysis-releases.md
View file
10 articles/sentinel/connect-aws.md
View file
28 articles/sentinel/connect-azure-active-directory.md
View file
10 articles/sentinel/connect-azure-activity.md
View file
35 articles/sentinel/connect-azure-ad-identity-protection.md
View file
28 articles/sentinel/connect-azure-security-center.md
View file
15 articles/sentinel/connect-cef-solution-config.md
View file

0 comments on commit f7a67dd

Please sign in to comment.
You can’t perform that action at this time.