WorkSpaces Personal + Simple AD構成にOkta SAML連携を設定してログインしてみた

こんにちは、ゲームソリューション部のsoraです。

今回は、WorkSpaces Personal + Simple AD構成にOkta SAML連携を設定し、実際にログインするまでの流れを書いていきます。

構成

今回構築した構成は以下です。

• VPC内のプライベートサブネットにSimple ADとWorkSpacesを配置
• インターネットアクセスはNAT Gateway経由
• OktaをSAML IdPとしてWorkSpacesに連携し、ログイン体験とMFAをOkta側に一元化

Managed Microsoft AD（MSAD）とは異なり、Simple ADではAWSマネジメントコンソールからユーザー登録はできないため、WindowsのEC2を一時的に配置してユーザー登録を行いました。（構成図には記載なし）

認証フロー

この構成では、Okta認証とAD認証の2段階でログインする流れになります。

1. WorkSpacesクライアントアプリでWorkSpacesの登録コードを入力
2. Oktaのログイン画面にリダイレクト
3. Oktaで認証（ID/パスワード + MFA）
4. OktaがSAMLアサーション（署名付き証明書）をAWSに返却
5. AWSでSAMLアサーションを検証し、IAMロールを引き受ける
6. WorkSpacesがNameIDを使って、ADのsAMAccountNameを検索
7. WorkSpacesのパスワード画面が表示される（ユーザー名はSAMLから自動入力、編集不可）
8. ADのパスワードを入力してログイン完了

ポイントは、Okta認証とAD認証は完全に別物であるため、それぞれでログインが必要です。

• Okta 認証：Oktaに登録されたユーザーかを確認する
• AD 認証：ADに登録されたユーザーかを確認する

OktaとADの間に直接の連携はなく、sAMAccountNameとメールアドレスを手動で一致させる運用になります。
つまりユーザー管理の一元化はできていません。

構築

IAM（SAML 連携）

SAML連携のために、IAM側には以下の 2 つのリソースを作成します。

• IAM SAML Provider：Okta のメタデータ XML を登録
• IAM Role：SAML フェデレーション用のロール

IAM Role の Trust Policy では、Condition に SAML:aud = https://signin.aws.amazon.com/saml を指定します。

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "<SAML Provider ARN>"
  },
  "Action": [
    "sts:AssumeRoleWithSAML",
    "sts:TagSession"
  ],
  "Condition": {
    "StringEquals": {
      "SAML:aud": "https://signin.aws.amazon.com/saml"
    }
  }
}

ここで注意点が 2 つあります。

• Condition を SAML:sub_type = persistent にしてしまうと Not authorized to perform sts:AssumeRoleWithSAML エラーになります。正しくは SAML:aud です
• Action には sts:TagSession も必要です。属性ステートメントで PrincipalTag:Email を渡すためで、これがないとログイン時にエラーになります

ロールには workspaces:Stream の権限を付与します。

Okta（SAMLアプリ）

Okta側ではSAMLアプリを作成し、以下を設定します。

属性ステートメントは以下です。

アプリケーションのユーザー名はデフォルトだとメールアドレスがそのままNameIDとして渡されます。
カスタムで@より前だけを渡す形にしておかないと、WorkSpacesのログイン画面でユーザー名がusername@example.comのようになり、AD側で一致するユーザーが見つからず認証失敗しました。

Simple AD

Simple AD自体はTerraformでaws_directory_service_directoryを定義するだけで作成できます。

WorkSpacesディレクトリへの登録は aws_workspaces_directory で行い、SAML 連携は saml_propertiesブロックで有効化します。
NAT Gateway経由でインターネットアクセスする場合は enable_internet_access = false にします。

AD ユーザー作成

Simple ADはAWSマネジメントコンソールからユーザーを作成できないため、ドメイン参加済みのWindowsのEC2からldifdeコマンドでユーザーを作成します。

dn: CN=username,CN=Users,DC=example,DC=local
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: username
sAMAccountName: username
userPrincipalName: username@example.local
mail: username@example.com
userAccountControl: 544

パスワードの設定は System.DirectoryServices 経由で行います。

$entry = New-Object System.DirectoryServices.DirectoryEntry(
  "LDAP://<AD_DNS_IP>/CN=username,CN=Users,DC=example,DC=local",
  "Administrator@example.local", "<admin_password>")
$entry.Invoke("SetPassword", "<user_password>")
$entry.InvokeSet("userAccountControl", 512)
$entry.CommitChanges()

また、Simple ADはAD Web Servicesに非対応のため、New-ADUserなどのPowerShell ADコマンドレットは使えません。
ユーザー作成にはldifdeかSystem.DirectoryServicesを使う必要があります。

また、管理用EC2に日本語AMIを使う場合、ネットワークアダプタ名がイーサネットになります。
user_dataでDNS設定をする際にSet-DnsClientServerAddress -InterfaceAlias "Ethernet*"と書いてもマッチしなかったため、Get-NetAdapter | Where-Object {$_.Status -eq "Up"} で動的にアダプタを取得しました。

WorkSpaces

ADユーザーを作成した後、aws_workspaces_workspaceでWorkSpacesを作成します。

注意として、WorkSpacesは作成から6時間以内はcompute_type_nameを変更できません。
すぐにスペック変更したい場合は削除→再作成する必要があります。（15 分程度かかりました）

動作確認

準備ができたので、WorkSpacesクライアントアプリからログインしてみます。

1. 登録コードの入力

WorkSpacesクライアントアプリを起動し、登録コードを入力します。
登録コードはAWSマネジメントコンソールのWorkSpaces画面で確認できます。

2. Okta ログイン

登録コードを入力するとOktaのログイン画面にリダイレクトされます。
OktaのID/パスワードとMFA（Okta Verify）で認証します。

3. WorkSpaces パスワード入力

Okta認証が通ると、WorkSpacesのパスワード画面が表示されます。
ユーザー名はSAMLのNameIDから自動入力されており、編集できません。

4. デスクトップ表示

ログインが完了し、WorkSpaces のデスクトップが表示されました。

ブラウザからWebページが閲覧できており、インターネットへ接続できていることも確認できました。

Simple AD の GPO 制限について

補足として、Simple ADではGPO（Group Policy Object）は閲覧のみ可能で、作成・編集・削除・リンクはできません。

Domain Admins権限であっても、GPOの新規作成や編集はAccess Deniedになります。

New-GPO -Name "TestGPO"

Set-GPRegistryValue -Name "Default Domain Policy" -Key "HKLM\Software\Test" -ValueName "TestValue" -Type String -Value "test"

# → FAILED: アクセスが拒否されました。 (HRESULT からの例外:0x80070005 (E_ACCESSDENIED))

Simple AD 作成時にデフォルトで存在する Default Domain Policyにはパスワードポリシー（最小 8 文字、複雑性あり、有効期限なし）が設定されていますが、これをカスタマイズすることはできません。
GPOを業務要件に合わせて管理したい場合はManaged Microsoft ADを使う必要があります。

最後に

WorkSpaces Personal + Simple AD構成にOkta SAML連携を設定してログインしてみました。
この記事がどなたかの参考になれば幸いです。