ポリシーには 1 つ以上のアクセス ルールが含まれます。各ルールには、Workspace ONE ポータル全体または指定された Web およびデスクトップ アプリケーションへのユーザー アクセスを管理するための設定値が含まれます。

ネットワーク、デバイス タイプ、AirWatch デバイスの登録および遵守ステータス、またはアクセスされているアプリケーションなどの条件に基づいて、ブロック、許可、またはステップアップ認証などのアクションを実行するように、ポリシー ルールを構成できます。

ネットワーク範囲

各ルールにネットワーク範囲を指定して、ユーザー ベースを指定します。ネットワーク範囲は、1 つ以上の IP 範囲から構成されます。アクセス ポリシー セットを構成する前に、[セットアップ] > [ネットワーク範囲] ページの [ID とアクセス管理] タブでネットワーク範囲を作成します。

環境内の各 ID プロバイダ インスタンスは、ネットワーク範囲と認証方法を関連付けます。ポリシー ルールを構成するときには、既存の ID プロバイダ インスタンスによってネットワーク範囲が関連付けられていることを確認します。

特定のネットワーク範囲を構成して、ユーザーがアプリケーションにログインおよびアクセスできる場所を制限できます。

デバイス タイプ

このルールで管理するデバイス タイプを選択します。クライアント タイプには、[Web ブラウザ]、[Workspace ONE アプリ]、[iOS]、[Android]、[Windows 10]、[OS X] および [すべてのデバイス タイプ] があります。

ルールを構成して、コンテンツにアクセスできるデバイス タイプ、およびそのタイプのデバイスによるすべての認証要求でポリシー ルールを使用するように指定します。

認証方法

ポリシー ルールで、認証方法が適用される順序を設定します。認証方法は、リストの順序で上位から適用されます。ポリシー内の認証方法とネットワーク範囲構成に一致する最上位の ID プロバイダ インスタンスが選択されます。ユーザー認証要求がその ID プロバイダ インスタンスに転送され、認証が行われます。認証に失敗すると、リストの上位から二番目の認証方法が選択されます。

2 つの認証方法を使用してユーザーの認証情報を検証し、合格しなければユーザーがログインできないようにするアクセス ポリシー ルールを構成できます。1 つまたは両方の認証方法で失敗し、フォールバック方法も構成されている場合、ユーザーは構成されている次の認証方法の認証情報を入力するように求められます。次の 2 つのシナリオは、この認証チェーンがどのように機能するかを説明しています。

  • 最初のシナリオでは、パスワードと Kerberos の認証情報を使用してユーザーを認証することを求めるアクセス ポリシー ルールが構成されています。認証にパスワードと RADIUS の認証情報を求めるフォールバック認証がセットアップされています。ユーザーはパスワードを正しく入力しましたが、正しい Kerberos の認証情報を入力していません。ユーザーは正しいパスワードを入力したため、フォールバック認証で、RADIUS の認証情報だけが要求されます。ユーザーはパスワードを再入力する必要はありません。

  • 2 番目のシナリオでは、パスワードと Kerberos の認証情報を使用してユーザーを認証することを求めるアクセス ポリシー ルールが構成されています。認証に RSA SecurID と RADIUS を求めるフォールバック認証がセットアップされています。ユーザーはパスワードを正しく入力しましたが、正しい Kerberos の認証情報を入力していません。フォールバック認証では、認証に RSA SecurID の認証情報と RADIUS の認証情報の両方が要求されます。

アクセス ポリシー ルールで認証とデバイス コンプライアンスの検証を求めるように構成するには、組み込み ID プロバイダのページで、[AirWatch とのデバイス コンプライアンス] を有効にする必要があります。コンプライアンス チェックのためのアクセス ポリシー ルールの構成を参照してください。

認証セッションの有効期間

各ルールで、認証の有効期間を設定します。再認証までの待機時間 値は、ユーザーがポータルにアクセスするか、または特定のアプリケーションを起動した前回の認証イベント以来の最長時間を決定します。たとえば、Web アプリケーション ルールに値 4 を指定すると、ユーザーが別の認証イベントを開始して時間が延長される場合を除いて、Web アプリケーションを 4 時間起動できます。

カスタムのアクセス拒否エラー メッセージ

無効な認証情報、不適切な構成、またはシステム エラーによってユーザーのログイン試行が失敗すると、アクセス拒否のメッセージが表示されます。デフォルトのメッセージは、次のとおりです。有効な認証方法が見つからなかったため、アクセスは拒否されました。

各アクセス ポリシー ルールに、デフォルトのメッセージをオーバーライドするカスタム エラー メッセージを作成できます。このカスタム メッセージには、アクション メッセージを呼び出すテキストおよびリンクを含めることができます。たとえば、管理するモバイル デバイス用のポリシー ルールで、ユーザーが未登録のデバイスからログインしようとした場合のために、次のようなカスタム エラー メッセージを作成できます。社内リソースにアクセスするには、このメッセージの最後にあるリンクをクリックしてデバイスを登録してください。デバイスが既に登録されている場合は、サポートにお問い合わせください。

デフォルト ポリシーの例

次に示すポリシーは、特定のポリシーが指定されていないアプリケーション ポータルおよび Web アプリケーションへのアクセスを制御するために、デフォルトのポリシーを構成する方法の一例です。

ポリシー ルールは、ポリシーの一覧にある順序で上位から評価されます。[ポリシー ルール] セクションでルールをドラッグ アンド ドロップして、ルールの順序を変更できます。

    • 社内ネットワークの場合、Kerberos とパスワード認証という 2 つの認証方法がフォールバック方法として、ルールに構成されています。社内ネットワークからアプリケーション ポータルにアクセスするため、サービスはまず Kerberos によるユーザー認証を試行します。これは、ルールで最初に記載されている認証方法であるためです。それが失敗すると、ユーザーは Active Directory のパスワードを入力するよう求められます。ユーザーはブラウザを使用してログインし、8 時間のセッション期限までユーザー ポータルにアクセスできます。

    • 外部ネットワーク（全ての範囲）からのアクセスの場合、構成される認証方法は RSA SecurID の 1 つだけです。外部ネットワークからアプリケーション ポータルにアクセスする際、ユーザーは SecurID でログインするよう要求されます。ユーザーがブラウザを使用してログインすると、4 時間のセッション期限までアプリケーション ポータルにアクセスできます。

  2. このデフォルトのポリシーは、Web およびデスクトップ アプリケーション固有のポリシーが設定されていない、すべての Web およびデスクトップ アプリケーションに適用されます。