2016-10-28 21 views
1

Azure環境でWebアプリケーションの新しいインスタンスを作成するプロセスを自動化する一連のPowershellスクリプトを作成しました。これらのスクリプトの一部は、Graph APIを使用して、いくつかのAzure ADオブジェクトと、Single Sign-Onに使用するAuth0の対応するオブジェクトを作成します。これまでは、AADアプリケーション用に新しいキーをプログラムで作成することに成功していませんでした。私たちはいくつかの方法を試しましたが、結果として得られるアプリケーションにはキーがあることがわかりますが(Auth0の接続オブジェクトにはClient Secretフィールドにそのキーがあります)、認証しようとすると常にこのエラーが発生します:この時点までAzure AD Web App Keyの自動作成

error message

、我々はすでにシングルサインオンへのアプリへのアクセスを許可しているし、AADにディレクトリデータを読み取るために。 (編集:私たちは、手動で接続オブジェクトを作成するためにAuth0 API呼び出しによって返されたオブジェクトの一部であるprovisioning_ticket_URLを以下を通じてこれを行う。このURLは、Azureの資格情報のための私達を促し、その後、このページが表示されます。 grantaccess

このエラーは、Azureポータルからアプリケーションの新しいキーを手動で作成し、アプリケーションを保存し、新しく作成したキーをAuth0接続にコピーするまで続きます。そうすることで問題は解決しますが、この余分なステップを避けたいと思います。これらの値については

"passwordCredentials": 
    [ 
    { 
     "startDate": "2016-10-28T20:40:32Z", 
     "endDate": "2017-10-29T20:40:32Z", 
     "keyId": "(a GUID)", 
     "value": "(a Base64 string)" 
    } 
    ], 

、我々はそれらを生成しようとしました:私たちは、APIの呼び出しで作成している、我々はキーを定義し、このセクションを持ってAADアプリケーションの本体内に

API PUT呼び出しの値を受け入れますが、ログインしようとすると同じエラーが表示されます。例として、$ appKeyGUIDの値をプラグインする方法がありました$ appKeyValueは次のとおりです。

$appKeyGUID = [guid]::NewGuid() 
$guidBytes = [System.Text.Encoding]::UTF8.GetBytes($appKeyGUID) 
$appKeyValue = [System.Convert]::ToBase64String($guidBytes); 

にkeyIDとvalue、respe ctively。私は値が44文字でなければならないということを他のところで読んだことがありますが、これはそうではありません。

しかし、値そのものが問題ではないようです。私はAzureポータルを介してキーを生成しようとしましたが、KeyIdを取得するためにGraph API GET呼び出しを使用して、アプリケーション本体にこれら2つの正確な値をハードコーディングしましたが、ログインすると同じエラーが発生します。

どこが間違っているのですか?

EDIT:Per Philippeの提案によれば、私はADアプリケーションの表示名のみをポータルから変更しようとしましたが、実際に問題を解決しました。これにより、ポータルを介して保存する際に修正されていたアプリケーション本体内の別の場所で何かが間違っていた可能性があると考えられました。 (私はここhttp://www.cloudidentity.com/blog/2015/09/01/azure-ad-permissions-summary-table/、ここhttps://www.microsoftpressstore.com/articles/article.aspx?p=2473127&seqNum=2から学んだの)RequiredResourceAccessセクション内で、私はこれを持っていた:

{ 
    "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
    "type": "Role" 
}, 
{ 
    "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
    "type": "Scope" 
} 

の代わりに私が保存し、一つの小さな違いが確かにあった前に、そのマニュアルをやった後、マニフェストをチェックしますポータルがこれを変更します

{ 
    "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
    "type": "Role,Scope" 
}, 

私は2番目の形式に一致するように送信する本文を変更しました。残念ながら、この変更では同じエラーが発生しています。さらに、アプリケーションでAPI GET呼び出しによって返される本体と同じように、マニフェストがポータルでの保存の前後で同じであることを確認しました。 以外のは、ポータルの保存がアプリケーションの定義以外に変更されている必要があります。

その後、グラフAPIを使用して2つのPATCH呼び出しを実行して、表示名を何かに更新してから、ポータルを介して同様に動作し、問題を修正することを期待して戻しました。私はポータルを通じて、PATCH呼び出しが実際にアプリの表示名を変更していることを確認しました。残念ながら、これらの編集では問題が解決されなかったようですが、私はまだ元のエラーを受けています。

私たちは、このようなグラフAPI呼び出しでアプリケーションを作成します。

$uri = "https://graph.windows.net/$waadTenant/applications?api-version=1.6" 
$newADApp = (Invoke-RestMethod –Uri $uri –Headers $authHeader –Method POST -Body $newappbody –Verbose) 

そして、ここでは、我々はアプリケーションを定義するために使用して終了の$ newappbodyです。私はハードトラブルシューティングの目的のためにコード化されたいくつかのことを残してきた:それはここでは、アプリケーションの同意に関連している究極の問題のように思える

{ 
    "odata.type": "Microsoft.DirectoryServices.Application", 
    "displayName": "customer1", 
    "homepage": "https://customer1.(our tenant).com", 
    "identifierUris": 
    [ 
    "https://customer1.(our tenant).com" 
    ], 
    "replyUrls": 
    [ 
    "https://(our tenant).auth0.com/login/callback" 
    ], 
    "passwordCredentials": 
    [ 
    { 
     "startDate": "(a hardcoded date)", 
     "endDate": "(a hardcoded date)", 
     "keyId": "(hardcoded GUID that was previously generated by the portal and extracted through an API GET)", 
     "value": "(hardcoded Base64 like above)" 
    } 
    ], 
    "requiredResourceAccess": 
    [ 
    { 
     "resourceAppId": "00000002-0000-0000-c000-000000000000", 
     "resourceAccess": 
     [ 
     { 
      "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
      "type": "Role,Scope" 
     }, 
     { 
      "id": "311a71cc-e848-46a1-bdf8-97ff7156d8e6", 
      "type": "Scope" 
     }, 
     { 
      "id": "6234d376-f627-4f0f-90e0-dff25c5211a3", 
      "type": "Scope" 
     } 
     ] 
    } 
    ] 
} 
+1

表示名だけを変更し、新しいキーを作成せずにアプリを保存してみてください。これも問題を解決しますか? Azure ADでオブジェクトを作成するために使用しているコードを共有できますか?既にログインしてディレクトリを読み取るためにアプリに "許可"されていると言われていますが、どうしていますか? –

+0

@PhilippeSignoretフィリップ・リプライに時間を割いてくれてありがとう。私はそれに応じて質問を更新しました - 上の編集セクションをご覧ください。 – MGS

答えて

2

。 私はここに、より詳細に入るが、すぐに私たちの同意の枠組みを説明し、この文書を読んを取ること自由に感じます https://azure.microsoft.com/en-us/documentation/articles/active-directory-integrating-applications/

あなたがマニフェストあなたのアプリケーションに表示されているものは、しかし、あなたのアプリケーションの構成に関連していますあなたのアプリの同意記録はそこに見つからないので、私はあなたの 'a/b'テストが実り多いものではないと思います。

あなたが管理者でアプリケーションを保存している場合、Azureポータルにはバックグラウンドでいくつかの「魔法」があり、アプリケーションに同意するということです。ポータルでアプリケーションを最初から最後まで登録すると(再度管理者として)、アプリケーションを保存すると自動的に同意を記録します。これはバックグラウンドで行われ、結果として生成される「オブジェクト」は次のとおりです。テナント内のアプリケーションのサービスプリンシパルと、ユーザーとサービスプリンシパルとしてのユーザー間のリンクに同意します。作成されるリンクは、具体的には、「admin tenant-wide consent」オブジェクトです。これは、ログインURLに「prompt = admin_consent」をクエリ文字列として追加した場合と同じことです。

グラフAPIやAAD PowerShellなどの他のメソッドを使用してアプリケーションを作成すると、これらのオブジェクトが作成されず、試行して認証するときに表示されるエラーが発生します。

解決策は、他の人にアプリケーションにログインさせる前に、テナントの管理者との対話型ログインエクスペリエンスを一度必要とすることです。このログインの経験の間、あなたはあなたのアプリへの管理者の同意とそれに必要な権限を持っている必要があります。この1回の同意経験の後、アプリケーションへの/からの後続の呼び出しでは同意する必要はなく、問題が発生することはありません。要約中のSO

  1. が自動的にクエリ文字列「プロンプト= admin_consent」を使用して、あなたは
  2. は、その後、あなたのアプリケーションの情報を使用して、好きな方法で使用してアプリケーションを作成し、管理者とのインタラクティブログインを作成
  3. その後、しかし、あなたはそれが

おかげで動作するように期待してあなたのアプリを使用! Shawn Tabrizi

関連する問題