了解 Linux 和容器上 SQL Server 的 Active Directory 驗證
適用於：
SQL Server - Linux
本文提供詳細資訊，說明部署於 Linux 或容器上 SQL Server 的 Active Directory 驗證運作方式。
概念
輕量型目錄存取通訊協定 (LDAP)
LDAP 是適用於各種目錄服務的應用程式協定，包含 Active Directory。 目錄服務會儲存使用者和帳戶資訊，以及安全性資訊 (例如密碼)。 這些資訊會經過加密，然後與網路上的其他裝置共用。
若要深入了解如何保護 LDAP，請參閱如何在 Windows Server 中啟用 LDAP 簽署。
Kerberos
Kerberos 為驗證通訊協定，可用來驗證使用者或主機電腦的身分識別。 您可以將其視為驗證用戶端和伺服器的一種方式。
當您在具備 Windows 和非 Windows 伺服器與用戶端的異質 (混合) 環境中工作時，如果需要使用採用 Active Directory 的目錄服務，您會需要兩種檔案：
- 金鑰表 (「金鑰資料表」的簡稱)
- Kerberos 組態檔 (
krb5.conf或krb5.ini)
什麼是金鑰表檔案？
Linux 或 Unix 系統上的伺服器處理序無法設定為透過 Windows 服務帳戶執行程序。 若要讓 Linux 或 Unix 系統在啟動時自動登入 Active Directory，您必須使用「金鑰表」檔案。
金鑰表是一個密碼編譯檔案，其中包含受 Kerberos 保護的服務表示，以及金鑰發佈中心 (KDC) 中與該服務相關聯之服務主體名稱的長期「金鑰」。 金鑰並非密碼。
金鑰表可用於：
- 向網路中的另一項服務驗證服務本身，或
- 將服務的輸入目錄使用者 Kerberos 服務票證解密。
什麼是 krb5.conf 檔案？
/etc/krb5.conf 檔案 (也稱為 krb5.ini) 可為 Kerberos v5 (KRB5) 和 GNU 簡單驗證及安全性階層 API (GSSAPI) 程式庫提供組態輸入。
這些資訊包含預設網域、各網域的屬性 (例如金鑰發佈中心)，以及預設的 Kerberos 票證存留期。
Active Directory 驗證需要此檔案才能運作。 krb5.conf 為 INI 檔案，但索引鍵/值組中的每個值都可以是由 { 和 } 括住的子群組。
如需 krb5.conf 檔案的相關詳細資訊，請參閱 MIT Kerberos Consortium 文件。
為 Linux 上的 SQL Server 設定 Kerberos
這些是在執行 Linux 上的 SQL Server 的主機伺服器中所需要的值。 若您有其他 (非 SQL Server) 服務是在相同的主機上執行，您的 krb5.conf 檔案可能會需要更多項目。
以下是供參考的 krb5.conf 範例檔案：
[libdefaults]
default_realm = CONTOSO.COM
[realms]
CONTOSO.COM = {
kdc = adVM.contoso.com
admin_server = adVM.contoso.com
default_domain = contoso.com
}
[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM
libdefaults：必須有default_realm值。 此值會指定主機機器所屬的網域。realms(選用)：kdc值可針對各個領域進行設定，以指定機器在查詢 Active Directory 帳戶時應聯繫的金鑰發佈中心。 若您已設定多個 KDC，則每次連線的 KDC 會由循環配置資源選取。domain_realm(選用)：可能會提供每個領域的對應。 若未提供，則 Linux 上的 SQL Server 會假設網域contoso.com對應至領域CONTOSO.COM。
Kerberos 驗證流程
取得票證授權票證 (TGT) 的前兩個步驟與 Windows 上的 Kerberos 驗證相同：
用戶端會將使用者名稱及密碼 (已加密) 傳送至網域控制站 (DC)，以開始登入程序。
在針對內部儲存體檢查使用者名稱和密碼後，DC 會將使用者的 TGT 傳回給用戶端。
Linux 上的 SQL Server 會使用金鑰表檔案來為服務主體名稱 (SPN) 讀取密碼，然後將用於授權連線的加密 Blob 解密。 後續步驟會概述此流程。
使用者擁有 TGT 後，用戶端就會指定 SQL Server 執行個體的主機名稱和連接埠，藉此啟動與 SQL Server 的連線。
SQL 用戶端會以格式
MSSQLSvc/<host>:<port>在內部建立服務主體名稱。 此格式為大部分 SQL Server 用戶端的硬式編碼格式。用戶端會針對該 SPN 向 DC 要求工作階段金鑰，以啟動 Kerberos 交握。 TGT 和 SPN 兩者都會傳送至 DC。
- DC 驗證 TGT 和 SPN 後，即會將工作階段金鑰傳送至用戶端，用於連線至 SQL Server SPN。
- 工作階段金鑰中的加密 blob 會傳送至伺服器。
SQL Server 從金鑰表 (
mssql.keytab) 針對 SPN 讀取密碼，此金鑰表是磁碟上的檔案，含有加密 (SPN、密碼) 元組。SQL Server 利用該才查詢到的密碼，將來自用戶端的加密 blob 解密，以取得用戶端的使用者名稱。
SQL Server 在
sys.syslogins資料表中查詢用戶端，以確認用戶端是否已獲授權可進行連線。接受或拒絕連線。
為 SQL Server 容器設定 Kerberos
容器中 SQL Server 的 Active Directory 驗證基本上與 Linux 上的 SQL Server 相同， 唯一的差異在於 SQL Server 主機 SPN。 在先前的案例中，因為我們是透過 SQL Server 主機的名稱進行連線，故 SPN 為 MSSQLSvc/<host>:<port>。 不過現在我們需要連線至容器。
如果是 SQL Server 容器，您可以在容器內建立 krb5.conf 檔案。 執行容器的主機節點不必屬於網域，但應該要能夠連到容器將會嘗試連線的網域控制站。
由於我們是要連線到容器，因此用戶端連線中的伺服器名稱可能會與主機名稱不同。 可以是主機名稱、容器名稱或其他別名。 此外，SQL Server 的公開連接埠很有可能不會是預設的 1433。
您必須使用儲存於 mssql.keytab 的 SPN 來連線至 SQL Server 容器。 舉例來說，若 mssql.keytab 中的 SPN 為 MSSQLSvc/sqlcontainer.domain.com:8000，您會使用 sqlcontainer.domain.com,8000 作為用戶端 (包含 sqlcmd、SQL Server Management Studio 與 Azure Data Studio) 中的連接字串。
SQL Server 群組重新整理
您可能會很好奇，若您只需要一個要驗證的服務主體名稱，為什麼金鑰表中會有使用者帳戶。
假設您有一個使用者 adUser，是群組 adGroup 的成員。 若將 adGroup 新增為 SQL Server 的登入，這表示 adUser 也會具備登入 SQL Server 執行個體的權限。 雖然 adUser 仍與 SQL Server 保持連線，但網域管理員可能從 adGroup 移除了 adUser。 現在 adUser 應該不再具備能夠登入 SQL Server 的權限，但已經通過 Kerberos 驗證流程並為連線狀態。
我們會定期執行稱為「群組重新整理」的流程，以避免不再允許的連線使用者執行特殊權限動作 (例如建立登入或變更資料庫)。
SQL Server 具備用於群組重新整理的特殊權限 Active Directory 帳戶。 此帳戶可透過下列任一方式進行設定：搭配使用 mssql-conf 與 network.privilegedadaccount 設定，或預設為主機機器的機器帳戶 (<hostname>$)。
mssql.keytab 中的特殊權限帳戶認證會用來模擬用戶端 (在此範例中為 adUser)。 SQL Server 會與自己進行 Kerberos 交握，以找出群組成員資格的資訊，並將其與 sys.syslogins 進行比較，藉此確認 adUser 是否仍具備必要的權限，可連線至要求的 Transact-SQL 命令並加以執行。 若 adUser 已從 adGroup 中移除，則連線會由 SQL Server 終止。
群組重新整理需要下列兩個條件：
- SQL Server 執行個體與內部部署的 Active Directory 網域之間的網路連線能力。
- SQL Server 所連線的網域與內部部署的 Active Directory 網域之間的雙向信任。 如需詳細資訊，請參閱了解 Active Directory。