本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Managed AWS Microsoft AD 故障診斷 以下可協助您疑難排解在建立或使用 AWS Managed Microsoft AD Active Directory 時可能遇到的一些常見問題。 ## AWS Managed Microsoft AD 的問題 有些故障診斷任務只能由 完成 支援。以下是一些任務： + 重新啟動 Directory Service您提供的網域控制站。 + [升級您的 AWS Managed Microsoft AD](ms_ad_upgrade_edition.md). 若要建立支援案例，請參閱[建立支援案例和案例管理](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)。 ## Netlogon 和安全頻道通訊的問題 作為對 [CVE-2020-1472](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472) 的緩解措施， Microsoft 已發佈修補，以修改網域控制站處理 Netlogon 安全通道通訊的方式。由於引進這些安全的 Netlogon 變更， AWS 因此 Managed Microsoft AD 可能不會接受某些 Netlogon 連線 （伺服器、工作站和信任驗證）。 若要確認問題是否與 Netlogon 或安全通道通訊相關，請在 Amazon CloudWatch Logs 中搜尋事件 ID 5827 (針對與裝置身分驗證相關的問題) 或 5828 (針對與 AD 信任驗證相關的問題)。如需 AWS Managed Microsoft AD 中的 CloudWatch 的資訊，請參閱 [啟用 AWS Managed Microsoft AD 的 Amazon CloudWatch Logs 日誌轉送](ms_ad_enable_log_forwarding.md)。 如需 CVE-2020-1472 緩解措施的詳細資訊，請參閱 網站上的[如何管理 Netlogon 安全通道連線中與 CVE-2020-1472 相關聯的變更](https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e)。 Microsoft ## 嘗試重設使用者密碼時，您會收到 'Response Status： 400 Bad Request' 錯誤 嘗試重設使用者的密碼時，您會收到類似以下的錯誤訊息： `Response Status: 400 Bad Request` 當您的 AWS Managed Microsoft AD Organizational Unit (OU) 中有相同使用者登入名稱的重複物件時，您可能會遇到此問題。使用者登入名稱必須是唯一的。如需詳細資訊，請參閱 Microsoft 文件中的[對目錄資料問題進行故障診斷](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb727059(v=technet.10)?redirectedfrom=MSDN)。 ## 密碼復原 如果使用者忘記密碼或無法登入 AWS Managed Microsoft AD 目錄，您可以使用 AWS 管理主控台PowerShell或 重設密碼 AWS CLI。 如需詳細資訊，請參閱[重設 AWS Managed Microsoft AD 使用者密碼](ms_ad_manage_users_groups_reset_password.md)。 ## 其他資源 下列資源可協助您在使用 時進行故障診斷 AWS。 + **[AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/)** – 尋找FAQs和其他資源的連結，以協助您疑難排解問題。 + **[AWS 支援中心](https://console.aws.amazon.com/support/home#/)** - 取得技術支援。 + **[AWS 高級支援中心](https://aws.amazon.com/premiumsupport/)** - 取得高級技術支援。 下列資源可協助您疑難排解常見的 Active Directory 問題。 + [Active Directory 文件](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-overview) + [AD DS疑難排解](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting) **Topics** + [AWS Managed Microsoft AD 的問題](#general_issues) + [Netlogon 和安全頻道通訊的問題](#ms_ad_tshoot_netlogon_issues) + [嘗試重設使用者密碼時，您會收到 'Response Status： 400 Bad Request' 錯誤](#ms_ad_tshoot_reset_password) + [密碼復原](#ms_ad_tshoot_password_recovery) + [其他資源](#troubleshoot_general_resources) + [Amazon EC2 Linux 執行個體網域聯結錯誤](ms_ad_troubleshooting_join_linux.md) + [AWS Managed Microsoft AD 低可用儲存空間](ms_ad_troubleshooting_low_storage_space.md) + [結構描述延伸錯誤](ms_ad_troubleshooting_schema.md) + [信任建立狀態原因](ms_ad_troubleshooting_trusts.md) + [對 AWS Managed Microsoft AD 高 CPU 使用率進行故障診斷](ms_ad_troubleshooting_high_cpu.md) # Amazon EC2 Linux 執行個體網域聯結錯誤 以下可協助您疑難排解將 Amazon EC2 Linux 執行個體加入 AWS Managed Microsoft AD 目錄時可能遇到的一些錯誤訊息。 ## Linux 執行個體無法加入網域或驗證 Ubuntu 14.04、16.04 和 18.04 執行個體*必須在* DNS 中反向解析，領域才能使用 Microsoft Active Directory。否則，您可能會遇到以下兩種情況之一： ### 情況 1：尚未加入領域的 Ubuntu 執行個體 對於嘗試加入領域的 Ubuntu 執行個體，`sudo realm join` 命令可能無法提供加入網域的所需許可，並可能顯示以下錯誤： \$1 Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success) adcli: couldn't connect to EXAMPLE.COM domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success) \$1 Insufficient permissions to join the domain realm: Couldn't join realm: Insufficient permissions to join the domain ### 情況 2：已加入領域的 Ubuntu 執行個體 對於已加入 Microsoft Active Directory 網域的 Ubuntu 執行個體，使用網域登入資料嘗試 SSH 進入執行個體可能會失敗，並出現下列錯誤： \$1 ssh admin@EXAMPLE.COM@198.51.100 no such identity: /Users/username/.ssh/id\$1ed25519: No such file or directory admin@EXAMPLE.COM@198.51.100's password: Permission denied, please try again. admin@EXAMPLE.COM@198.51.100's password: 如果您使用公有金鑰登入執行個體並查看 `/var/log/auth.log`，可能會看到下列有關無法找到使用者的錯誤： May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 user=admin@EXAMPLE.COM May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): received for user admin@EXAMPLE.COM: 10 (User not known to the underlying authentication module) May 12 01:02:14 ip-192-0-2-0 sshd[2251]: Failed password for invalid user admin@EXAMPLE.COM from 203.0.113.0 port 13344 ssh2 May 12 01:02:15 ip-192-0-2-0 sshd[2251]: Connection closed by 203.0.113.0 [preauth] 不過，`kinit` 對於使用者仍然有效。請看如下範例： ubuntu@ip-192-0-2-0:\$1\$1 kinit admin@EXAMPLE.COM Password for admin@EXAMPLE.COM: ubuntu@ip-192-0-2-0:\$1\$1 klist Ticket cache: FILE:/tmp/krb5cc\$11000 Default principal: admin@EXAMPLE.COM ### 解決方法 目前對於這兩種情況的建議解決方法是停用 `/etc/krb5.conf` 中 [libdefaults] 區段的反向 DNS，如下所示： ``` [libdefaults] default_realm = EXAMPLE.COM rdns = false ``` ## 無縫域加入的單向信任身分驗證問題 如果您在 AWS Managed Microsoft AD 和內部部署 Active Directory 之間建立了單向傳出信任，則嘗試使用 Winbind 的信任 Active Directory 登入資料對加入 Linux 執行個體的網域進行身分驗證時，可能會遇到身分驗證問題。 ### 錯誤 Jul 31 00:00:00 EC2AMAZ-LSMWqT sshd[23832]: Failed password for user@corp.example.com from xxx.xxx.xxx.xxx port 18309 ssh2 Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): getting password (0x00000390) Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): pam\$1get\$1item returned a password Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): request wbcLogonUser failed: WBC\$1ERR\$1AUTH\$1ERROR, PAM error: PAM\$1SYSTEM\$1ERR (4), NTSTATUS: \$1\$1NT\$1STATUS\$1OBJECT\$1NAME\$1NOT\$1FOUND\$1\$1, Error message was: The object name is not found. Jul 31 00:05:00 EC2AMAZ-LSMWqT sshd[23832]: pam\$1winbind(sshd:auth): internal module error (retval = PAM\$1SYSTEM\$1ERR(4), user = 'CORP\$1user') ## 解決方法 若要解決此問題，您需要執行下列步驟以註解或移除 PAM 模組組態檔 (`/etc/security/pam_winbind.conf`) 中的指令。 1. 在文字編輯器中開啟 `/etc/security/pam_winbind.conf` 檔案。 ``` sudo vim /etc/security/pam_winbind.conf ``` 1. 註解或移除以下指令 **krb5\$1auth = yes**。 ``` [global] cached_login = yes krb5_ccache_type = FILE #krb5_auth = yes ``` 1. 停止 Winbind 服務，然後重新啟動它。 ``` service winbind stop or systemctl stop winbind net cache flush service winbind start or systemctl start winbind ``` # AWS Managed Microsoft AD 低可用儲存空間 當您的 AWS Managed Microsoft AD 由於 Active Directory 的可用儲存空間不足而受損時，需要立即採取動作，才能將目錄恢復為作用中狀態。以下章節涵蓋造成這種損害最常見的兩個原因： 1. [SYSVOL 資料夾正在存放超過必要的群組政策物件](#sysvol-folder-gpo) 1. [Active Directory 資料庫已填滿磁碟區](#ad-db-filled-volume) 如需 AWS Managed Microsoft AD 儲存體的定價資訊，請參閱 [Directory Service 定價](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table)。 ## SYSVOL 資料夾正在存放超過必要的群組政策物件 這種損害的常見原因是在 SYSVOL 資料夾中存放了非必要的群組原則處理檔案。這些非必要的檔案可能是 EXE、MSI 或任何其他並非群組原則應處理的必要檔案。群組原則應處理的必要物件是群組政策物件、登入/登出指令碼，以及[群組原則物件的中央存放區](https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/create-and-manage-central-store)。任何非必要檔案都應存放在 Managed Microsoft AD 網域控制站 ( AWS Managed Microsoft AD) 以外的檔案伺服器上。 如果需要[群組原則軟體安裝](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software)的檔案，建議您使用檔案伺服器來存放這些安裝檔案。如果您不想自行管理檔案伺服器， AWS 會提供受管檔案伺服器選項 [Amazon FSx](https://aws.amazon.com/fsx/)。 若要移除任何不必要的檔案，您可以透過通用命名慣例 (UNC) 路徑存取 SYSVOL 共用。例如，如果您網域的完整網域名稱 (FQDN) 是 example.com，SYSVOL 的 UNC 路徑會是 "\$1\$1example.local\$1SYSVOL\$1example.local\$1"。一旦您找到並移除群組原則處理目錄時不需要的物件，其應該就會在 30 分鐘內回到作用中狀態。如果 30 分鐘後目錄未處於作用中狀態，請聯絡 AWS Support。 只將必要的群組原則檔案存放在您的 SYSVOL 共享中，可以確保您不會因為 SYSVOL 膨脹而損害您的目錄。 ## Active Directory 資料庫已填滿磁碟區 造成這種損害的常見原因是 Active Directory 資料庫填滿了磁碟區。如要驗證是否是這種情況，您可以檢閱您目錄中物件的 **total (總)** 計數。我們將 **total (總)** 這個字以粗體表示，是為了讓您了解 **deleted (已刪除)** 的物件仍然會計入目錄中的物件總數。 根據預設， AWS Managed Microsoft AD 會將 AD Recycling Bin 中的項目保留 180 天，之後才會成為 Recycled-Object。一旦物件成為 Recycled-Object (已標記)，便會另外再保留 180 天，最後才會從目錄清除。所以當物件遭到刪除時，物件仍會存在目錄資料庫中達 360 天，之後才會遭到清除。這就是為什麼必須評估物件的總數。 如需 AWS Managed Microsoft AD 支援物件計數的詳細資訊，請參閱 [Directory Service 定價](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table)。 如要取得目錄中包含已刪除物件的物件總數，您可以從加入網域的 Windows 執行個體執行以下 PowerShell 命令。如需如何設定管理執行個體的步驟，請參閱 [AWS Managed Microsoft AD 中的使用者和群組管理](ms_ad_manage_users_groups.md)。 ``` Get-ADObject -Filter * -IncludeDeletedObjects | Measure-Object -Property 'Count' | Select-Object -Property 'Count' ``` 以下是以上命令的範例輸出： ``` Count 10000 ``` 如果總計數超過您上述備註中您目錄大小所支援的物件數，您便已超過您目錄的容量。 以下是解決這項損害的選項： 1. 清理 AD 1. 刪除任何不需要的 AD 物件。 1. 從 AD 資源回收筒移除任何不需要的物件。請注意，這是一項破壞性動作，且復原這些遭到刪除物件的唯一方法是執行目錄還原。 1. 以下命令將會從 AD 資源回收筒移除任何遭到刪除的物件。 **重要** 使用此命令時請特別小心，因為這是一項破壞性動作，且復原這些遭到刪除物件的唯一方法是執行目錄還原。 ``` $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName $NetBios = $DomainInfo.NetBIOSName $ObjectsToRemove = Get-ADObject -Filter { isDeleted -eq $true } -IncludeDeletedObjects -SearchBase "CN=Deleted Objects,$BaseDn" -Properties 'LastKnownParent','DistinguishedName','msDS-LastKnownRDN' | Where-Object { ($_.LastKnownParent -Like "*OU=$NetBios,$BaseDn") -or ($_.LastKnownParent -Like '*\0ADEL:*') } ForEach ($ObjectToRemove in $ObjectsToRemove) { Remove-ADObject -Identity $ObjectToRemove.DistinguishedName -IncludeDeletedObjects } ``` 1. 向 AWS Support 開啟案例，請求 Directory Service 回收可用空間。 1. 如果您的目錄類型是 Standard Edition 使用 AWS Support 開啟案例，請求將目錄升級至 Enterprise Edition。這也會增加您目錄的成本。如需定價資訊，請參閱 [Directory Service 定價](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table)。 在 AWS Managed Microsoft AD 中，**AWS 委派的已刪除物件存留期管理員**群組的成員能夠修改 `msDS-DeletedObjectLifetime` 屬性，該屬性會設定已刪除物件在變成資源回收物件之前保留在 AD 回收筒中的天數。 **注意** 這是進階主題。如果設定不當，可能會導致資料遺失。我們強烈建議您先檢閱 [The AD Recycle Bin: Understanding, Implementing, Best Practices, and Troubleshooting](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/the-ad-recycle-bin-understanding-implementing-best-practices-and/ba-p/396944)，以進一步了解這些程序。 將 `msDS-DeletedObjectLifetime` 屬性值變更為較低的數字，有助於確保您的物件數不會超過支援的層級。此屬性最低的有效值可以設為 2 天。一旦超過這個值，您將再也無法使用 AD 資源回收筒復原遭到刪除的物件。您將需要從快照還原目錄，才能復原這些物件。如需詳細資訊，請參閱[使用快照還原 AWS Managed Microsoft AD](ms_ad_snapshots.md)。**系統會從時間點進行還原，因此快照還原可能導致資料遺失。** 如要變更您目錄的刪除物件生命週期，請執行以下命令： **注意** 如果您照原樣執行命令，該命令會將刪除物件生命週期屬性值設為 30 天。如果您想要讓它更長或更短，請以您偏好的數字取代 "30"。但是，我們建議您不要超過預設值 180。 ``` $DeletedObjectLifetime = 30 $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,$BaseDn" -Partition "CN=Configuration,$BaseDn" -Replace:@{"msDS-DeletedObjectLifetime" = $DeletedObjectLifetime} ``` # 結構描述延伸錯誤 以下可協助您針對延伸 AWS Managed Microsoft AD 目錄的結構描述時可能遇到的一些錯誤訊息進行疑難排解。 ## 參考項目 **錯誤** *Add error on entry starting on line 1: Referral The server side error is: 0x202b A referral was returned from the server. 延伸伺服器錯誤為：0000202B：RefErr：DSID-0310082F，資料 0、1 個存取點 \$1tref 1：'example.com' 修改的物件數量：0* **疑難排解** 請確定所有辨別名稱欄位包含正確的網域名稱。在上述範例中，`DC=example,dc=com` 應該取代成 Cmdlet `Get-ADDomain` 所示的 `DistinguishedName`。 ## 無法讀取匯入檔案 **錯誤** *Unable to read the import file. Number of Objects Modified: 0* **疑難排解** 匯入的 LDIF 檔案是空的 (0 個位元組)。請確定所上傳的是正確檔案。 ## 語法錯誤 **錯誤** *There is a syntax error in the input file Failed on line 21 The last token starts with 'q'. Number of Objects Modified: 0* **疑難排解** 第 21 行的文字格式不正確。無效文字的第一個字母是 `A`。請使用有效的 LDIF 語法更新第 21 行。如需如何格式化 LDIF 檔案的詳細資訊，請參閱「[步驟 1：建立您的 LDIF 檔案](create.md)」。 ## 屬性或值已存在 **錯誤** *Add error on entry starting on line 1: Attribute Or Value Exists The server side error is: 0x2083 The specified value already exists. The extended server error is: 00002083: AtrErr: DSID-03151830, \$11: \$1t0: 00002083: DSID-03151830, problem 1,006 (ATT\$1OR\$1VALUE\$1EXISTS), data 0, Att 20,019 (mayContain):len 4 Number of Objects Modified: 0* **疑難排解** 已套用結構描述變更。 ## 沒有這類屬性 **錯誤** *Add error on entry starting on line 1: No Such Attribute The server side error is: 0x2085 The attribute value cannot be removed because it is not present on the object. The extended server error is: 00002085: AtrErr: DSID-03152367, \$11: \$1t0: 00002085: DSID-03152367, problem 1,001 (NO\$1ATTRIBUTE\$1OR\$1VAL), data 0, Att 20,019 (mayContain):len 4 Number of Objects Modified: 0* **疑難排解** LDIF 檔案嘗試從類別移除屬性，但該屬性目前未連接到這個類別。可能已套用結構描述變更。 **錯誤** *Add error on entry starting on line 41: No Such Attribute 0x57 The parameter is incorrect. The extended server error is: 0x208d Directory object not found. The extended server error is: "00000057: LdapErr: DSID-0C090D8A, comment: Error in attribute conversion operation, data 0, v2580" Number of Objects Modified: 0* **疑難排解** 第 41 行所列的屬性不正確。請再次檢查拼法。 ## 沒有這類物件 **錯誤** *Add error on entry starting on line 1: No Such Object The server side error is: 0x208d Directory object not found. 延伸伺服器錯誤為：0000208D：NameErr：DSID-03100238、問題 2001 (NO\$1OBJECT)、資料 0、最佳相符：'CN=結構描述、CN=組態、DC=example、DC=com' 修改的物件數量：0* **疑難排解** 辨別名稱 (DN) 所參考的物件不存在。 # 信任建立狀態原因 當 AWS Managed Microsoft AD 的信任建立失敗時，狀態訊息會包含其他資訊。以下可協助您了解這些訊息的意義。 ## 存取遭拒 嘗試建立信任時存取遭拒。信任密碼不正確或遠端網域的安全設定不允許設定信任。如需信任的詳細資訊，請參閱 [使用網站名稱和 DCLocator 提高信任效率](#enhancing-trust-site-names)。為解決此問題，請嘗試以下操作： + 確認您使用的是您在遠端網域上建立對應信任時，所使用的相同信任密碼。 + 確認您的網域安全設定允許建立信任。 + 確認您的本機安全政策已正確設定。特別是檢查 `Local Security Policy > Local Policies > Security Options > Network access: Named Pipes that can be accessed anonymously` 並確保其中包含至少下列三個具名管道： + netlogon + samr + lsarpc + 確認上述具名管道是否以 **NullSessionPipes** 登錄機碼上的值存在，該登錄機碼位於登錄路徑 **HKLM\$1SYSTEM\$1CurrentControlSet\$1services\$1LanmanServer\$1Parameters** 中。這些值必須插入到單獨的列中。 **注意** 根據預設，`Network access: Named Pipes that can be accessed anonymously` 並未設定且會顯示 `Not Defined`。這是正常的，因為網域控制站之 `Network access: Named Pipes that can be accessed anonymously` 的有效預設設定為 `netlogon`、`samr`、`lsarpc`。 + 在*預設網域控制器政策*中驗證下列伺服器訊息區塊 (SMB) 簽署設定。您可以在**電腦組態** > **Windows 設定** > **安全設定** > **本機政策/安全選項**中找到這些設定。它們應該符合下列設定： + Microsoft 網路用戶端：數位簽署通訊 （一律）：預設：已啟用 + Microsoft 網路伺服器：數位簽署通訊 （一律）：已啟用 ### 使用網站名稱和 DCLocator 提高信任效率 Default-First-Site-Name 等第一個站台名稱不需要在網域之間建立信任關係。不過，在網域之間對齊網站名稱可以大幅改善網域控制站定位器 (DCLocator) 程序的效率。此對齊可改善預測和控制跨樹系信任的網域控制站選擇。 DCLocator 程序對於尋找不同網域和樹系的網域控制站至關重要。如需 DCLocator 程序的詳細資訊，請參閱 [Microsoft 文件](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/troubleshoot-domain-controller-location-issues)。高效率的網站組態可讓網域控制站位置更快且更準確，進而在跨樹系操作中提升效能和可靠性。 如需網站名稱和 DCLocator 程序如何互動的詳細資訊，請參閱下列Microsoft文章： + [如何跨信任找到網域控制站](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-domain-controllers-are-located-across-trusts/ba-p/256180) + [跨樹系的網域定位器](https://techcommunity.microsoft.com/blog/askds/domain-locator-across-a-forest-trust/395689) ## 指定的網域名稱不存在或無法聯絡 若要解決此問題，請確保網域的安全群組設定和 VPC 的存取控制清單 (ACL) 正確無誤，而且您已準確輸入條件式轉寄站的資訊。 AWS 設定安全群組只開啟 Active Directory 通訊所需的連接埠。在預設設定中，安全群組接受從任何 IP 地址到這些連接埠的流量。傳出流量僅限於安全群組。您將需要更新安全群組的傳出規則，以允許流量傳出到內部部署網路。如需安全需求的詳細資訊，請參閱「[步驟 2：準備您的 AWS Managed Microsoft AD](ms_ad_tutorial_setup_trust_prepare_mad.md)」。 ![\[編輯安全群組\]](http://docs.aws.amazon.com/zh_tw/directoryservice/latest/admin-guide/images/edit_security_group.png) 如果其他目錄網路的 DNS 伺服器使用公有 (非 RFC 1918) IP 地址，您將需要在目錄上新增從 Directory Services 主控台到 DNS 伺服器的 IP 路由。如需詳細資訊，請參閱[建立、驗證或刪除信任關係](ms_ad_setup_trust.md#trust_steps)及[先決條件](ms_ad_setup_trust.md#trust_prereq)。 網際網路號碼分配局 (IANA) 為私有網際網路保留了以下三個 IP 地址空間區塊： + 10.0.0.0 ‒ 10.255.255.255 (10/8 字首) + 172.16.0.0 ‒ 172.31.255.255 (172.16/12 字首) + 192.168.0.0 ‒ 192.168.255.255 (192.168/16 字首) 如需詳細資訊，請參閱 https：//[https://tools.ietf.org/html/rfc1918](https://tools.ietf.org/html/rfc1918)。 確認 AWS Managed Microsoft **AD 的預設 AD 站點名稱**與內部部署基礎設施中的**預設 AD 站點名稱**相符。電腦會使用其所屬的域 (而非使用者的域) 來決定網站名稱。重新命名網站以符合最近的內部部署部署可確保 DC 定位器使用最近網站的‏域控制站。如果這樣還是無法解決問題，可能因已快取之前建立的條件式轉寄站資訊，而阻礙新信任的建立。請稍候幾分鐘，然後重試建立信任和條件式轉寄站。 如需如何運作的詳細資訊，請參閱 Microsoft 網站上的[跨樹系信任的網域定位器](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689)。 ![\[第一個網站的預設名稱\]](http://docs.aws.amazon.com/zh_tw/directoryservice/latest/admin-guide/images/default_first_site_name.png) ## 無法在此域上執行該操作 若要解決此問題，請確保兩個域的 / 目錄沒有重疊的 NETBIOS 名稱。如果域的 / 目錄確實具有重疊的 NETBIOS 名稱，請使用不同的 NETBIOS 名稱重新建立其中一個域，然後重試。 ## 錯誤 "Required and valid domain name" 導致信任建立失敗 DNS 名稱只能包含字母字元 (A-Z)、數字字元 (0-9)、減號 (-) 和句點 (.)。僅當用於分隔域樣式名稱的組成部分時才允許使用句點字元。另外，請考量： + AWS Managed Microsoft AD 不支援與單一標籤網域的信任。如需詳細資訊，請參閱[Microsoft支援單一標籤網域](https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/single-label-domains-support-policy)。 + 根據 RFC 1123 ([https://tools.ietf.org/html/rfc1123](https://tools.ietf.org/html/rfc1123))，DNS 標籤中只能使用 A 到 Z、a 到 z、0 到 9 以及連字號 (-)。DNS 名稱中也使用句點 (.)，但僅用於 DNS 標籤之間和 FQDN 末尾。 + 根據 RFC 952 ([https://tools.ietf.org/html/rfc952](https://tools.ietf.org/html/rfc952))，名稱 (網路、主機、閘道或域) 是最多 24 個字元的文字字串，由字母 (A-Z )、數位 (0-9)、減號 (-) 和句點 (.) 組成。請注意，僅當用於分隔「域樣式名稱」的組成部分時才允許使用句點。 如需詳細資訊，請參閱Microsoft網站上的[遵守主機和網域的名稱限制](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959336(v=technet.10))。 ## 測試信任的一般工具 以下是可用於解決各種信任相關問題的工具。 **AWS Systems Manager Automation 疑難排解工具** [支援自動化工作流程 (SAW)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-support.html) 利用 AWS Systems Manager Automation 為您提供預先定義的 Runbook Directory Service。[AWSSupport-TroubleshootDirectoryTrust](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awssupport-troubleshootdirectorytrust.html) Runbook 工具可協助您診斷 AWS Managed Microsoft AD 與內部部署 Microsoft Active Directory 之間的常見信任建立問題。 **DirectoryServicePortTest 工具** [DirectoryServicePortTest](samples/DirectoryServicePortTest.zip) 測試工具在針對 AWS Managed Microsoft AD 與內部部署 Active Directory 之間的信任建立問題進行疑難排解時很有幫助。如需使用工具的方法範例，請參閱「[測試您的 AD Connector](ad_connector_getting_started.md#connect_verification)」。 **NETDOM 和 NLTEST 工具** 管理員可以使用 **Netdom** 和 **Nltest** 命令列工具來尋找、顯示、建立、移除和管理信任。這些工具直接與域控制站上的 LSA 機構通訊。如需如何使用這些工具的範例，請參閱 Microsoft 網站上的 [Netdom](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc772217(v=ws.11)) 和 [NLTEST](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11))。 **封包擷取工具** 您可以使用內建的 Windows 套件擷取公用程式，對潛在的網路問題進行調查和疑難排解。如需詳細資訊，請參閱 [Capture a Network Trace without installing anything](https://techcommunity.microsoft.com/t5/iis-support-blog/capture-a-network-trace-without-installing-anything-amp-capture/ba-p/376503) 一文。 # 對 AWS Managed Microsoft AD 高 CPU 使用率進行故障診斷 以下可協助您對 AWS Managed Microsoft AD 網域控制站上的高 CPU 問題進行疑難排解。 ## 尋找根本原因 疑難排解高 CPU 使用率的第一步是分析 CloudWatch 指標，以識別可能解釋資源消耗增加的模式。 ### 步驟 1： Review Directory Service CloudWatch 指標 使用 CloudWatch 指標監控 AWS Managed Microsoft AD 效能，以識別與高 CPU 用量相關的流量模式。如需檢視和解譯 Directory Service 指標的詳細資訊，請參閱 [使用 CloudWatch 監控 AWS Managed Microsoft AD 網域控制站的效能](ms_ad_monitor_dc_performance.md)。 尋找下列可能說明 CPU 增加的關鍵指標中的轉移模式： + **每秒 DNS 查詢** – 突然峰值可能表示 DNS 解析問題或應用程式設定錯誤。 + **Kerberos/NTLM 身分驗證** – 來自使用者登入或服務帳戶的較高身分驗證率。 + **每秒 LDAP 查詢** – 增加來自應用程式或服務的 LDAP 流量。 比較目前的指標與歷史基準，以識別高 CPU 使用率何時開始，並將其與特定流量增加建立關聯。如果在指標中找不到相互關聯，則根本原因不會造成流量大幅增加。相反地，根本原因可能是效率不佳的 LDAP 查詢，請跳到 [步驟 3：使用流量鏡像擷取詳細的流量分析](#ms_ad_high_cpu_step3)。 ### 步驟 2：使用 VPC 流程日誌識別來源機器 VPC 流程日誌提供有效的方法來識別產生流量至網域控制站之機器的來源 IP 地址。如需詳細資訊，請參閱[使用 VPC 流量日誌記錄 IP 流量](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)。使用目的地連接埠號碼來區分服務： + **連接埠 53** – DNS 查詢 + **連接埠 88** – Kerberos 身分驗證 + **連接埠 123** – NTP 時鐘同步 + **連接埠 135、49152-65535** – RPC + **連接埠 389、636、3268、3269** – LDAP 查詢 （標準 LDAP 為 389 或 3268，LDAPS 為 636 或 3269) + **連接埠 445** – SMB 檔案共用 （群組政策） + **連接埠 464** – Kerberos 密碼變更 + **連接埠 9389** – Active Directory Web Service 若要啟用和分析 VPC 流程日誌： + 為包含網域控制器 ENIs子網路啟用 VPC 流程日誌。 + 依目的地連接埠篩選日誌，以識別流量模式。 + 依期間內大多數封包和/或大多數位元組進行組織。 + 分析來源 IP 地址，以判斷哪些機器產生最多流量。 ### 步驟 3：使用流量鏡像擷取詳細的流量分析 VPC 流程日誌提供有關請求實際內容的有限資訊。如需更詳細的分析，請考慮流量鏡像以擷取完整的封包資料。如需詳細資訊，請參閱[開始使用流量鏡射來監控網路流量](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-getting-started.html)。當您需要分析時，這特別有用： + LDAP 篩選條件的複雜性和效率 + 特定 DNS 查詢模式 + 身分驗證請求詳細資訊 流量鏡射可讓您擷取傳送至網域控制站執行個體的完整網路封包，對導致高 CPU 使用率的流量進行深入分析。 ### 步驟 4：調查來源應用程式並最佳化流量 識別來源機器和流量模式後，請調查產生流量的應用程式： + **檢閱應用程式組態** – 檢查應用程式是否進行效率不佳的查詢或請求過多。避免將應用程式硬式編碼為單一網域控制器。 + **分析 LDAP 查詢** – 效率不佳的 LDAP 查詢是高網域控制器 CPU 的最常見原因。尋找可能受益於屬性索引的複雜篩選條件。 + **檢查 DNS 快取** – 確認已啟用 DNS 用戶端快取，以減少重複的查詢。 + **檢查身分驗證模式** – 識別服務帳戶是否過於頻繁地進行身分驗證。 ## 解決策略 根據您的調查，實作適當的最佳化策略： ### 最佳化應用程式 + **最佳化 LDAP 查詢** – 重寫複雜的 LDAP 查詢。避免將搜尋基礎設定為網域的根目錄，而是將其設定為您要搜尋物件所在的 OU。避免使用執行子樹狀目錄搜尋的搜尋範圍。請改用基本或單一層級範圍。在篩選條件中包含物件類別。例如 `(objectClass=user)` 或 `(objectClass=computer)`。除非屬性已編製索引，否則請避免在篩選條件中使用萬用字元。如果需要萬用字元掃描，請新增索引。如需詳細資訊，請參閱[擴展您的 AWS Managed Microsoft AD 結構描述](ms_ad_schema_extensions.md)。不要編製所有內容的索引，因為索引程序也會增加 CPU 使用率。 ``` # Sample LDIF code to index the email attribute dn: CN=mail,CN=Schema,CN=Configuration,DC=yourdomain,DC=com changetype: modify replace: searchFlags searchFlags: 1 ``` + **啟用 DNS 用戶端快取** – 設定用戶端在本機快取 DNS 回應，以減少伺服器負載。 + **實作連線集區** – 設定應用程式以重複使用 LDAP 連線，而不是為每個查詢建立新的連線。 ### 擴展您的目錄基礎設施 如果流量最佳化無法解決高 CPU 使用率： + **新增更多網域控制站** – 透過部署其他網域控制站來分配負載來橫向擴展。如需詳細資訊，請參閱[部署 AWS Managed Microsoft AD 的其他網域控制站](ms_ad_deploy_additional_dcs.md)。 + **升級至 Enterprise Edition** – 如果使用 Standard Edition，請升級至 Enterprise Edition，以提高 CPU 容量和效能。如需詳細資訊，請參閱[升級您的 AWS Managed Microsoft AD](ms_ad_upgrade_edition.md)。如果已經使用 Enterprise Edition，請聯絡 [AWS 支援](https://docs.aws.amazon.com//awssupport/latest/user/case-management.html) 以增加容量。 如需 AWS Managed Microsoft AD 版本的定價資訊，請參閱 [Directory Service 定價](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table)。