AWS – Wirednet Blog

正直、とても希な事象と思います。が、書いておかないと忘れそうなので残しておきます。

起こったこと

Azure ADの自分のテナントにいるユーザと、外部招待したユーザのメールアドレスの@マークよりも前が全く一緒の文字列だった。
そのためSCIMのExternalID属性が重複してしまってユーザ作成がエラーになって止まってしまう。

概要図

fabri.comのAzure ADでAWS SSO連携を設定している。

この状態で、外部招待ユーザのtanaka.taroと自社テナントにいるtanaka.taroを同時にAWS SSOに連携しようとすると、片方が重複しているユーザ扱いになって登録に失敗する。(※Azure ADのプロビジョニングログには重複していることが表示されない or 詳細メッセージのResponse Stringsの中に埋もれているので非常に気づかれにくい)

対処：自動プロビジョニングの設定を変更する

Azure ADのエンタープライズアプリケーションからプロビジョニングの編集を行う。

マッピングから、「Provision Azure Active Directory Users」のリンクに移動。

属性マッピングの画面になるので、下の方に言ってExternalIdのマッピング属性を編集する。

属性の編集で、“ソース属性”を”mailNickname” (メールアドレスの@よりも左側の文字列)から、”mail” (メールアドレス全体)に変更する。
※ExternalIDとして重複しないものであれば他の文字列を持つ属性でも良さそうです。

後はプロビジョニングし直すだけ。

前提としてのAzure ADとAWS SSO連携の話は↓の記事を見てください。

AWS SSOとAzure ADを組み合わせて、複数のAWSアカウントにさっとログイン出来るようにしたよ

なかなか個人でAWSアカウントを複数持っていてコンソリデーテッドビリング＋Organization Unitを組んでいる人も少ないとは思いますが……。

会社組織などでAWSアカウントを、Aシステム用本番＋検証、BシステムのPoC用……等と分けて手配されているところは多いと思います。アカウント分けて作った方がIAMロールとか請求書とか何かと分けて管理した方が楽だったりしますし。

でもそうなると、AWSアカウントのログイン画面(Signin URL)をブックマークしておいたり、社内ポータルに掲示して置くの面倒くさくなりませんか？
ということで、AWS SSOを使ってこんな感じで管理すると便利になるので、やり方をご紹介。

ちなみにAzure AD上にもエンタープライズアプリケーションとして登録されるのでMyAppsにも表示されるようになります。

Azure ADポータルで、エンタープライズアプリケーションを作成する

「独自のアプリを追加」で、「ギャラリー以外のアプリケーション」を選択

AWSマネジメントコンソールを一個ずつSSOする時は、下にあるAmazon Web Servicesを使えば良いんですが、今回はAWS SSOの自動プロビジョニングを設定したいので独自アプリを選択します。

エンタープライズアプリケーションとして作成されたら、この画面は後で使うので閉じずにおいておきます。

AWS SSOを有効化する

AWSマネジメントコンソールでAWS SSOを検索して「有効化」する。
このとき、東京リージョンだと有効化出来ないのでどこか別なリージョン(自分の場合は米国西部 (オレゴン) us-west-2)で有効化しました。

AWS SSOの認証認可を行う、IDソースの設定

ここで、Azure ADのエンタープライズアプリケーションとして連携させるためのSAMLメタデータをダウンロードしておきます。
後でIDプロバイダーのメタデータ設定するのでこの画面は閉じずにおいておきます。

Azure ADでシングルサインオンの設定

Azure ADの画面に戻って、「2. シングルサインオンの設定」を実施します。

シングルサインオン方式としてSAMLを選択します。

メインペインの右上の「メタデータファイルをアップロードする」から、先ほどAWS SSO管理画面でダウンロードしたSAMLメタデータをアップロードします。

メタデータの読み込みに成功すると、自動的に識別子や応答URLが設定されます。

基本的なSAML構成を保存して、SAML署名証明書のところからフェデレーションメタデータXMLをダウンロードします。

AWS SSOの自動プロビジョニング設定

閉じずに置いておいたAWS SSOの画面に戻って、IdP SAMLメタデータに先ほどAzure上でダウンロードしたフェデレーションメタデータXMLをアップロードします。

次に、設定からSCIMの自動プロビジョニングを有効化します。

自動プロビジョニング(SCIM)の画面からSCIMエンドポイント、アクセストークンを取得します。

Azure ADからAWS SSOに対する自動プロビジョニングの設定

エンタープライズアプリケーション画面の左ペインから「プロビジョニング」を選択し、「作業の開始」を実施します。

AWS SSO管理画面で取得した、“SCIMエンドポイント”を”テナントのURL”に、”アクセストークン”を”シークレットトークン”にそれぞれ貼り付けます。
貼り付けたら「テスト接続」を押して、”指定した資格情報にはプロビジョニングを有効にする権限があります”と表示されることを確認します。

自動プロビジョニングの設定が終わったので保存しておきます。

Azure ADのエンタープライズアプリケーションの利用者を登録する

左ペインの「ユーザとグループ」から、実際にこのAWS SSO画面にアクセスさせたいユーザやグループを選択して追加します。

AWS SSOのユーザ一覧に、Azure ADのユーザが自動プロビジョニングされる

先ほどのまでの設定が上手く行っていれば、AWS SSOのユーザ一覧にAzure ADのユーザが自動的に連携されるようになります。

AWSアカウントへのアクセス設定を行う

この辺は直感的な画面なので割愛。

AWS SSO画面にアクセス

あとはAWS SSOのユーザポータルURLを、別なブラウザでアクセスすれば冒頭で上げたように複数のAWSアカウントの一覧が表示される。

AWS SSOの設定画面と、実際にSSOアクセスを試すブラウザはシークレットーモードなりFirefox/Chrome/Edge等で分離した方が、クッキーやセッションが混じるトラブルを回避できる。

お疲れさまでした！

参考

The Next Evolution in AWS Single Sign-On
https://aws.amazon.com/jp/blogs/aws/the-next-evolution-in-aws-single-sign-on/