AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約

Active Directory ドメインに参加できない WorkSpaces Personal ワークスペースをトラブルシューティングする方法を教えてください。

所要時間3分
0

Amazon WorkSpaces Personal で WorkSpace を作成しようとしましたが、ドメインに参加しようとしたときにエラーが表示されました。

解決策

注: フォレストの信頼を使用している場合、ドメインへの参加を試みたときにユーザーと WorkSpace が別々の Active Directory にあると、エラーが発生します。Amazon Linux、Ubuntu、Red Hat Enterprise Linux (RHEL) WorkSpaces では、双方向の信頼を使用するのがベストプラクティスです。Ubuntu と RHEL WorkSpaces は、Active Directory の統合にシステムセキュリティサービスデーモン (SSSD) を使用しています。SSSD はフォレストの信頼をサポートしていないため、代わりに外部信頼を設定する必要があります。

ドメインコントローラとの通信を確認する

WorkSpace が任意の仮想プライベートクラウド (VPC) リソース経由で Active Directory ドメインコントローラと通信できることを確認してください。該当するリソースは、セキュリティグループ、ネットワークアクセスコントロールリスト (ネットワーク ACL)、ルートテーブルなどです。また、WorkSpace がディレクトリコントローラと通信するために必要なポートでドメインコントローラと通信できることも確認してください。

WorkSpaces は、VPC のエラスティックネットワークインターフェイスを使用して、ドメインに参加してログインするときに、必要なポートでドメインコントローラと通信します。

ディレクトリを作成して WorkSpaces に登録すると、ディレクトリサービスがセキュリティグループ directoryID_controllers を作成し、WorkSpaces がセキュリティグループ directoryID_workspacesMembers を作成します。これらのセキュリティグループのいずれかのルールで、WorkSpaces がドメインコントローラと通信することを許可していない場合、新しい WorkSpace を作成することはできません。この問題を解決するには、セキュリティグループにデフォルトルールがあることを確認してください。AD Connector では、ディレクトリセキュリティグループはデフォルトですべてのアウトバウンドトラフィックを許可します。その他の Active Directory の詳細については、「AWS Directory Service for Microsoft Active Directory で作成されるもの」を参照してください。

重要: セキュリティグループ directoryID_workspacesMembers が変更されていないことを確認してください。デフォルトでは、WorkSpaces のセキュリティグループはすべてのアウトバウンドトラフィックを許可します。

セルフマネージド Microsoft Active Directory の場合は、オンプレミスのファイアウォールが WorkSpaces サブネットからドメインコントローラへのトラフィックを、必要なポートでブロックしていないことを確認してください。

必要なポートが Windows WorkSpace で開いていることを確認する

次の手順を実行します。

  1. 各 WorkSpaces のサブネットで Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動し、セキュリティグループ directoryID_workspacesMembers をアタッチします。
  2. RDP を使用してインスタンスに接続します
  3. オペレーティングシステム (OS) のファイアウォールを無効にして静的 DNS を設定するには、次の PowerShell コマンドを実行します。
    Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
    Set-DnsClientServerAddress -InterfaceIndex ((Get-NetAdapter).ifIndex) -ServerAddresses ("DNS Server IP 1","DNS Server IP 2")
    注: DNS Server IP 1DNS Server IP 2 は、お使いの DNS サーバーの IP アドレスに置き換えます。
  4. PortQry ツールを使用して、ドメインコントローラへの接続をテストします。詳細については、Microsoft のウェブサイトで「1 つ以上のターゲットポートを指定する」を参照してください。PortQry ツールをダウンロードするには、Microsoft のウェブサイトで「PortQry コマンドライン ポート スキャナー バージョン 2.0」を参照してください。ポートへの接続をテストするには、DNS サーバーとドメインコントローラの IP アドレスごとに、次のコマンドを実行します。
    portqry -n DNS Server IP address -p both -e 53
    portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 88
    portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 389
    portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 445
    portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 636
    portqry -n Domain-FQDN-Domain-Controller-IP-address -p udp -e 123,137,138
    portqry -n Domain-FQDN-Domain-Controller-IP-address -p tcp -e 135,139
    注: DNS Server IP address をお使いの IP アドレスに、Domain-FQDN-Domain-Controller-IP-address を実際の完全修飾ドメイン名 (FQDN) またはドメインコントローラの IP アドレスに置き換えます。
  5. エラーが見つかったら修正してください。すべてのポートテストが正常に完了したら、インスタンスをドメインに手動で参加させます。
    注: この手順を使用することで、AWS マネージド Microsoft AD またはセルフマネージド Active Directory にインスタンスを参加させることができます。

Amazon Linux 2、Ubuntu、RHEL WorkSpace で必要なポートが開いていることを確認する

次の手順を実行します。

  1. WorkSpace の起動に使用した Linux OS を使用して、各 WorkSpaces のサブネットで EC2 インスタンスを起動し、セキュリティグループ directoryID_workspacesMembers をアタッチします。
  2. SSH を使用してインスタンスに接続します
  3. WorkSpaces サブネットからドメインコントローラへのポート接続をテストするには、次のコマンドを実行します。
    nc -z -v -w 15 domain controller ip 53
    nc -z -v -u -w 15 domain controller ip 53
    nc -z -v -w 15 domain controller ip 88
    nc -z -v -u -w 15 domain controller ip 88
    nc -z -v -u -w 15 domain controller ip 135
    nc -z -v -w 15 domain controller ip 389
    nc -z -v -u -w 15 domain controller ip 389
    nc -z -v -w 15 domain controller ip 636
    nc -z -v -u -w 15 domain controller ip 636
    nc -z -v -w 15 domain controller ip 3268
    nc -z -v -w 15 domain controller ip 3269
    apt-get install -y adcli
    adcli info -S Domain FQDN
    adcli info -S domain controller ip
    注: domain controller ip はドメインコントローラの IP アドレスに、Domain FQDN は FQDN に置き換えます。
  4. エラーが見つかったら修正してください。すべてのポートテストが正常に完了したら、インスタンスをドメインに手動で参加させます。

netcat コマンドフラグに関する詳細については、下記のコマンドフラグの概要を参照してください。

  • nc-z は、リモートホストで開いているポートをスキャンしますが、完全な接続は確立しません。
    注: IPv4 アドレスにのみ接続する場合は、nc -4 を使用します。
  • nc-v では、詳細な出力を行います
  • nc-u では、TCP ではなく UDP を使用します。
    注: nc-t を使用すると、すべての TCP 接続が表示されます。
  • nc-w では、確立できない接続のタイムアウトを指定します。

(AD Connector のみ) サービス AWS アカウントのアクセス許可を確認する

WorkSpace をドメインに参加させるには、アクセス許可を委任してドメイン認証情報を設定する必要があります。組織で AD Connector を使用している場合は、サービスアカウントを使用して Active Directory と通信するのがベストプラクティスです。AD Connector の設定を確認するには、次の手順を実行します。

  1. サービスアカウントが Active Directory でアクティブ化されていることを確認します。
  2. サービスアカウントのパスワード有効期限が切れていないことを確認します。
  3. WorkSpaces 組織単位 (OU) のサービスアカウントに委任されたアクセス許可が正確であることを確認します。
  4. WorkSpaces ディレクトリ内の OU 名が正確であることを確認します。

デフォルトでは、認証されたユーザーは最大 10 台のコンピューターをドメインに参加させることができます。このクォータを超えると、ドメインに参加しようとしたときに問題が発生します。クォータを変更する方法については、Microsoft のウェブサイトで「ユーザーがドメインに参加できるワークステーション数の既定の制限」を参照してください。

関連情報

Linux インスタンスがドメインに参加できないか、認証できない

AWS公式
AWS公式更新しました 2ヶ月前
コメントはありません

関連するコンテンツ