はじめに

2022 年 11 月ごろに、WorkSpaces が SAML 2.0 の一般提供を開始するアップデートがありました。Azure AD や Okta, OneLogin といった IdP と連携が出来るようになったため、会社の中で全社的な IdP が有る場合はそれと連携ができます。これによって、会社全体のガバナンスポリシーに沿うことができたり、人の入れ替えに対応する負担が軽減できるメリットがあります。

今回の記事では、WorkSpaces と Azure AD で SAML 2.0 の連携を行う設定を紹介します。AWS の公式 Document やサーバーワークスさんの記事を参考にしました！ありがとうございます！

どんなログイン画面になるの？

いきなり設定に入る前に、どんなログイン画面になるのか紹介します。

まず、WorkSpaces Client を起動します。初回限定ですが、WorkSpaces の Registration Code を入力します。

Azure AD と SAML 連携をしているため、「Continue to sign in to WorkSpaces」というボタンが表示されます。非 SAML 連携の場合は、このボタンではなく、ID・Password を入力する画面となっています。このボタンを押します。

自動的にブラウザが立ち上がり、Azure AD のログイン画面が表示されます。Azure AD にログインします。

Azure AD 側で管理されているパスワードを入力します。

ブラウザ上で「Log in to WorkSpaces」が表示されるため、これを押します。

すると、WorkSpaces Client の画面が自動的に切り替わります。ブラウザで入力したユーザー名が自動的に入力され、再度パスワードが求められます。これは、WorkSpaces と連携している Active Directory 上のユーザーのパスワードを入力します。 Azure AD だけで完結するわけではなく、別途 Active Directory や Microsoft AD が必要なのが注意点ですね。

Active Directory 側のパスワードを入力します。技術的には Azure AD と Active Directory のパスワードが異なっている場合でも、それぞれ別のパスワードを入力すれば利用可能です。ただ、二重管理は面倒です。本番環境では、Azure AD Connect を構成することで、Active Directory と Azure AD 間のユーザーやパスワードを同期するとよいでしょう。

無事にログインが出来ると、WorkSpaces の画面が表示されます。

構成図

この記事で検証する構成図を紹介します。個人的に勘違いしていたのが、Azure AD があれば Active Directory が不要だと思い込んでいたんですが、そんなことなかったです。Azure AD と Active Directory の両方を利用しています。

これは余談ですが、本番環境を想定すると、Azure AD と Active Directory でユーザー情報を二重管理するのは大変です。Azure AD Connect を EC2 などで構成することで、Azure AD と Active Directory 間のユーザーやパスワードを同期するとよいでしょう。次の構成図のように、Azure AD Connect を用意する構成が考えられます。

それでは設定をしてみましょう！

Azure AD : エンタープライズアプリケーションの作成

新しいアプリケーションを選択します。

独自アプリケーションの作成を押します。

適当に名前を入れて、作成を押します。

作成されました。

Azure AD : フェデレーションメタデータのダウンロード

作成したエンタープライズアプリケーションを選択します。

シングルサインオンの設定を押します。

SAML を選択します。

AWS で提供されている SAML メタデータを、作業用端末にファイルとして保存します。

メタデータファイルをアップロードする　を押します。

ダウンロードした XML ファイルを選択して、追加を押します。

保存を押します。

フェデレーションメタデータ XML をダウンロードします。

AWS : IAM で Identity Provider を作成

AWS のマネージメントコンソールにある IAM で作業を進めます。Identity Provider のメニューで Add provider を押します。

名前の指定や、ダウンロードしたメタデータ XML ファイルをアップロードして、Add provider を押します。

Identity Provider が作成されました。

AWS : IAM Role を作成

WorkSpaces と Azure AD が連携するための IAM Role を作成します。

Create Role を押します。

Identity Provider 等の指定を行います。

後で権限設定をするため、Next を押します。

IAM Role 名を適当に指定します。

Create Role を押します。

IAM Role が作成されました。作成した IAM Role の画面で、Edit trust policy を押します。

TagSession を追加して、Update policy を押します。

次に、Permissions から、Create Inline policy を押します。

次のような JSON ポリシーを入力します。環境に合わせて書き換えてください。

リージョン名 : ap-northeast-1
AWS アカウント ID : 111111111111
Directory の ID : d-95677d48dc

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "arn:aws:workspaces:ap-northeast-1:111111111111:directory/d-95677d48dc",
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}"
                }
            }
        }
    ]
}

適当に名前を入れて、保存を押します。

Azure AD : SAML 認証応答のアサーションを設定

Azure AD の画面で、属性とクレームから編集を押します。

次の値を入れていきます。

クレーム名	値
一意のユーザー識別子 (名前 ID)	user.mailnickname [nameid-format:persistent]
https://aws.amazon.com/SAML/Attributes/Role	IAM ロールのARN,Identity Provider の ARN
https://aws.amazon.com/SAML/Attributes/RoleSessionName	user.mailnickname
https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email	user.mail

まず、デフォルトで存在している 4 行のクレームは削除します。

新しいクレームの追加を押します。

Role に関する設定を入れます。この「ソース属性」は、AWS IAM 上で作成した IAM Role と、Identity Provider の ARN をカンマ区切りで入力します。AWS アカウント ID はダミーですが、こんな感じで入力します。

arn:aws:iam::111111111111:role/WorkSpacesSamlAccessRole,arn:aws:iam::111111111111:saml-provider/AzureADforWorkSpaces

設定されました。

このような感じで、残りの設定を入れていきます。次の画面が全て入れた状態です。

「必要な要求」の部分は、このように設定します。「永続的」と指定するところが見逃し気味なので注意しましょう。

Azure AD : フェデレーションのリレー状態を構成する

基本的な SAML 構成を編集します。

リレーの状態に設定するURLは、リージョンごとに異なりますが、東京リージョンの場合は、以下のURLになります。

https://workspaces.euc-sso.ap-northeast-1.aws.amazon.com/sso-idp?registrationCode=【WorkSpacesの登録コード】

WorkSpaces の登録コードは、AWS マネージメントコンソールから確認が可能です。

次のように指定して保存します。

Active Directory : ユーザーを登録

Active Directory 上でユーザーを作成します。今回は技術検証なので、Active Directory 上のユーザーと、Azure AD 上でそれぞれ二重管理をします。本番の環境は二重管理になるの辛いので、Azure AD Connect を使って同期をするとよいでしょう。

ws-user01 で作成します。

パスワードを指定します。

ユーザーが作成されました。

該当のユーザーのプロパティから、メールアドレスを指定します。これは、Azure AD 上のユーザーのメールアドレスと同じであることが必要です。

Azure AD : ユーザー作成

新しいユーザーを作成します。

Azure AD 上でも同じ名前でユーザーを作成します。

作成を押します。

ユーザーが作成されました。

作成したユーザーのプロパティを編集します。

メールアドレスを指定して、保存を押します。Active Directory 側と一致が必要です。

WorkSpaces 用に作成したエンタープライズアプリケーションにユーザーを紐づけます。

選択を押します。

割り当てを押します。

割り当てられました。

Azure AD : アプリのリンクをコピー

https://myapps.microsoft.com/
にアクセスして、Azure AD 上で作成したユーザーを使ってログインします。

WorkSpaces のアプリが表示されているので、「リンクのコピー」を押します。

このような URL がコピーされます。

https://launcher.myapps.microsoft.com/api/signin/e3b25c8a-1e91-452b-b7fb-26894694fb31?tenantId=54d4fb23-4655-46de-ab3a-4698a1111116

上記リンクの「/signin/」以降をコピーして、https://myapps.microsoft.com/signin/ の末尾に付与します。付与した例が以下の通りです。

https://myapps.microsoft.com/signin/e3b25c8a-1e91-452b-b7fb-26894694fb31?tenantId=54d4fb23-4655-46de-ab3a-4698a1111116

WorkSpaces : SAML 2.0 を有効化する

WorkSpaces から、Directory を選択します。

Authentication を編集します。

SAML 2.0 Identity Provider を編集します。

生成した URL を入力して、Save を押します。

WorkSpaces で該当のユーザーに作成する

WorkSpaces で、概要のユーザー用の環境を作成します。Create WorkSpaces を押します。

該当の Directory を指定します。

該当のユーザーを選択して、Next を押します。

適当に Bundle を指定して Next を押します。

自動停止を有効にして、Next を押します。

デフォルトのまま Next を押します。

Create を押します。

これで設定が完了です！

動作確認

動作確認をしていきましょう。WorkSpaces Client がインストールされている端末で、Registration Code を入力します。Registration Code は二回目以降はスキップすることもできます。

「Continue to sign in to WorkSpaces」のボタンを押します。

自動的にブラウザが立ち上がり、Azure AD のログイン画面が表示されます。Azure AD にログインします。

Azure AD 側で管理されているパスワードを入力します。

ブラウザ上で「Log in to WorkSpaces」が表示されるため、これを押します。

すると、WorkSpaces Client の画面が自動的に切り替わります。ブラウザで入力したユーザー名が自動的に入力され、再度パスワードが求められます。これは、WorkSpaces と連携している Active Directory 上のユーザーのパスワードを入力します。

無事にログインが出来ると、WorkSpaces の画面が表示されます。

Tips1 : sAMAccountName の確認方法

Active Directory の sAMAccountName と、Azure AD 側で設定した「一意のユーザー識別子 (名前 ID)」の「user.mailnickname」の一致が必要です。

Active Directory の sAMAccountName は、PowerShell で以下のコマンドを実行することで確認できます。

以下の表示の「SamAccountName」がsAMAccountName です。

PS C:\Users\Admin> Get-ADUser -Filter { SamAccountName -eq "ws-user01" } | Format-List


DistinguishedName : CN=ws-user01,OU=Users,OU=sharead,DC=sharead,DC=local
Enabled           : True
GivenName         :
Name              : ws-user01
ObjectClass       : user
ObjectGUID        : df0ea6fe-3b1c-4698-a2fe-e348ef7eb87f
SamAccountName    : ws-user01
SID               : S-1-5-21-2415499674-2393242095-994390223-1610
Surname           : ws-user01
UserPrincipalName : ws-user01@sharead.local



PS C:\Users\Admin>

この記事の環境では、sAMAccountName の「ws-user01」と、Azure AD 上のメールニックネームの「ws-user01」一致していることが必要です。なお、SAML のクレーム要求の設定で紐づけを変えることもできるはずです。

検証を通じてわかったこと

Azure AD と連携をしても、別途 Active Directory や Microsoft AD が必要。
ユーザーやパスワードが、Azure AD と Active Directory で二重管理するのが辛いので、Azure AD Connect で連携するのが良さそう
WorkSpaces で SAML 連携をしていると、Web ブラウザからのアクセスが利用できない。ログインしようとしてもエラー画面が表示される。SAML 連携を行う場合は、OS にインストールする WorkSpaces Client から利用する。

参考 URL

【Amazon WorkSpaces】Azure ADを利用したSAML認証を試してみた
https://blog.serverworks.co.jp/workspaces-saml

Setting up SAML 2.0
https://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html