你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

部署由 Azure Arc 启用的 Active Directory 集成的 SQL 托管实例

项目
10/16/2024

本文介绍如何通过 Active Directory 身份验证部署启用了 Azure Arc 的 Azure SQL 托管实例。

先决条件

在开始部署 SQL 托管实例之前，请确保具备以下先决条件：

Active Directory 域
已部署 Azure Arc 数据控制器
已部署 Active Directory 连接器，且具有客户管理的密钥表或系统管理的密钥表

连接器要求

客户管理的密钥表 Active Directory 连接器和系统管理的密钥表 Active Directory 连接器是不同的部署模式，具有不同的要求和步骤。每种模式在部署期间都有特定的要求。选择你使用的连接器的选项卡。

客户管理的密钥表模式
系统管理的密钥表模式

对于 Active Directory 客户管理的密钥表部署，必须提供：

SQL 的 Active Directory 用户帐户
用户帐户下的服务主体名称 (SPN)
SQL 的主要终结点（以及可选的次要终结点）的 DNS A（转发）记录

准备部署

根据你的部署模式，完成以下步骤以准备部署 SQL 托管实例。

客户管理的密钥表模式
系统管理的密钥表模式

要在客户管理的密钥表模式下准备部署，请执行以下操作：

识别 SQL 终结点的 DNS 名称：为客户端将从 Kubernetes 群集外部连接到的 SQL 终结点选择唯一的 DNS 名称。
- DNS 名称应在 Active Directory 域中或在其后代域中。
- 本文中的示例使用 sqlmi-primary.contoso.local 作为主 DNS 名称，使用 sqlmi-secondary.contoso.local 作为辅助 DNS 名称。
标识 SQL 终结点的端口号：输入每个 SQL 终结点的端口号。
- 这些端口号必须位于 Kubernetes 群集的可接受端口号范围内。
- 本文中的示例使用 31433 作为主要端口号，使用 31434 作为辅助端口号。
为托管实例创建 Active Directory 帐户：为 Active Directory 帐户选择一个名称以表示你的托管实例。
- 该名称在 Active Directory 域中必须唯一。
- 本文中的示例使用 sqlmi-account 作为 Active Directory 帐户名。
创建帐户：
1. 在域控制器上，打开“Active Directory 用户和计算机”工具。创建表示托管实例的帐户。
2. 输入符合 Active Directory 域密码策略的帐户密码。你将在下一部分的某些步骤中使用此密码。
3. 确保帐户已启用。帐户不需要任何特殊权限。
为 Active Directory DNS 服务器中的 SQL 终结点创建 DNS 记录：在其中一个 Active Directory DNS 服务器中，为在步骤 1 中选择的 DNS 名称创建 A 记录（正向查找记录）。
- DNS 记录应指向 SQL 终结点将在其上侦听来自 Kubernetes 群集外部的连接的 IP 地址。
- 你不需要创建与 A 记录关联的反向查找指针 (PTR) 记录。
创建 SPN：要使 SQL 能够接受针对 SQL 终结点的 Active Directory 身份验证，必须在上一步中创建的帐户中注册两个 SPN。必须为主要终结点注册两个 SPN。如果希望对辅助终结点进行 Active Directory 身份验证，还必须为辅助终结点注册 SPN。

要创建并注册 SPN，请执行以下操作：
1. 使用以下格式创建 SPN：
```
MSSQLSvc/<DNS name>
MSSQLSvc/<DNS name>:<port>
```
2. 在其中一个域控制器上运行以下命令以注册 SPN：
```
setspn -S MSSQLSvc/<DNS name> <account>
setspn -S MSSQLSvc/<DNS name>:<port> <account>
```
  命令可能如以下示例所示：
```
setspn -S MSSQLSvc/sqlmi-primary.contoso.local sqlmi-account
setspn -S MSSQLSvc/sqlmi-primary.contoso.local:31433 sqlmi-account
```
3. 如果要在辅助终结点上执行 Active Directory 身份验证，请运行相同的命令来为辅助终结点添加 SPN：
```
setspn -S MSSQLSvc/<DNS name> <account>
setspn -S MSSQLSvc/<DNS name>:<port> <account>
```
  命令可能如以下示例所示：
```
setspn -S MSSQLSvc/sqlmi-secondary.contoso.local sqlmi-account
setspn -S MSSQLSvc/sqlmi-secondary.contoso.local:31434 sqlmi-account
```
生成包含帐户和 SPN 条目的密钥表文件：若要使 SQL 能够向 Active Directory 进行身份验证并接受 Active Directory 用户的身份验证，请使用 Kubernetes 机密提供密钥表文件。
- 密钥表文件包含针对托管实例和 SPN 生成的 Active Directory 帐户的加密条目。
- SQL Server 将此文件用作其针对 Active Directory 的凭据。
- 要生成 keytab 文件，有多个工具可供选择：
  - adutil：适用于 Linux（请参阅 adutil 简介）
  - ktutil：在 Linux 上可用
  - ktpass：适用于 Windows
  - 自定义脚本
若要生成专用于托管实例的密钥表文件，请执行以下操作：
1. 使用以下自定义脚本之一：
  - Linux：create-sql-keytab.sh
  - Windows Server：create-sql-keytab.ps1
  这些脚本接受几个参数，并为包含 keytab 的 Kubernetes Secret 生成一个密钥表文件和一个 YAML 规范文件。
2. 在脚本中，将参数值替换为托管实例部署的值。
  
  对于输入参数，请使用以下值：
  - --realm：大写的 Active Directory 域名。示例： CONTOSO.LOCAL
  - --account：注册 SPN 的 Active Directory 帐户。示例： sqlmi-account
  - --port：主 SQL 终结点的端口号。示例： 31433
  - --dns-name：主 SQL 终结点的 DNS 名称。
  - --keytab-file：密钥表文件的路径。
  - --secret-name：是为其生成规范的密钥表机密的名称。
  - --secret-namespace：包含密钥表机密的 Kubernetes 命名空间。
  - --secondary-port：辅助 SQL 终结点端口号（可选）。示例： 31434
  - --secondary-dns-name：辅助 SQL 终结点的 DNS 名称（可选）。
  为托管密钥表的 Kubernetes 机密选择一个名称。使用部署了托管实例的命名空间。
3. 运行以下命令来创建密钥表：
```
AD_PASSWORD=<password> ./create-sql-keytab.sh --realm <Active Directory domain in uppercase> --account <Active Directory account name> --port <endpoint port> --dns-name <endpoint DNS name> --keytab-file <keytab file name/path> --secret-name <keytab secret name> --secret-namespace <keytab secret namespace>
```
  命令可能如以下示例所示：
```
AD_PASSWORD=<password> ./create-sql-keytab.sh --realm CONTOSO.LOCAL --account sqlmi-account --port 31433 --dns-name sqlmi.contoso.local --keytab-file sqlmi.keytab --secret-name sqlmi-keytab-secret --secret-namespace sqlmi-ns
```
4. 运行以下命令以验证密钥表是否正确：
```
klist -kte <keytab file>
```
为密钥表部署 Kubernetes 机密：使用在上一步中创建的 Kubernetes 机密规范文件来部署机密。

规范文件类似于以下示例：
```
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: <secret name>
  namespace: <secret namespace>
data:
  keytab: <keytab content in Base64>
```
若要部署 Kubernetes 机密，请运行以下命令：
```
kubectl apply -f <file>
```
你的命令可能类似于以下示例：
```
kubectl apply -f sqlmi-keytab-secret.yaml
```

要在系统管理的密钥表模式下准备部署，请执行以下操作：

识别 SQL 终结点的 DNS 名称：为客户端将从 Kubernetes 群集外部连接到的 SQL 终结点选择唯一的 DNS 名称。
- DNS 名称应在 Active Directory 域中或其后代域中。
- 本文中的示例使用 sqlmi-primary.contoso.local 作为主 DNS 名称，使用 sqlmi-secondary.contoso.local 作为辅助 DNS 名称。
标识 SQL 终结点的端口号：输入每个 SQL 终结点的端口号。
- 这些端口号必须位于 Kubernetes 群集的可接受端口号范围内。
- 本文中的示例使用 31433 作为主要端口号，使用 31434 作为辅助端口号。
为 SQL 选择 Active Directory 帐户名称：选择将代表托管实例的 Active Directory 帐户的名称。
- 此名称在 Active Directory 域中应是唯一的，并且该帐户不得预先存在于域中。此帐户在域中自动生成。
- 本文中的示例使用 sqlmi-account 作为 Active Directory 帐户名。
为 Active Directory DNS 服务器中的 SQL 终结点创建 DNS 记录：在其中一个 Active Directory DNS 服务器中，为在步骤 1 中选择的 DNS 名称创建 A 记录（正向查找记录）。
- DNS 记录应指向 SQL 终结点将在其上侦听来自 Kubernetes 群集外部的连接的 IP 地址。
- 你不需要创建与 A 记录关联的反向查找指针 (PTR) 记录。

设置 Active Directory 身份验证的属性

若要为 Azure Arc Active Directory 身份验证部署 Azure Arc 启用的 SQL 托管实例，请更新部署规范文件来引用要使用的 Active Directory 连接器实例。在 SQL 规范文件中引用 Active Directory 连接器会自动为 Active Directory 身份验证设置 SQL。

客户管理的密钥表模式
系统管理的密钥表模式

要在客户管理的密钥表模式下支持 SQL 上的 Active Directory 身份验证，请在部署规范文件中设置以下属性。有些属性是必需的，有些是可选的。

必须

spec.security.activeDirectory.connector.name：要加入以进行 Active Directory 身份验证、预先存在的 Active Directory 连接器自定义资源的名称。如果输入此属性的值，则将实施 Active Directory 身份验证。
spec.security.activeDirectory.accountName：托管实例的 Active Directory 帐户名称。
spec.security.activeDirectory.keytabSecret：Kubernetes 机密的名称，该机密用于托管用户的预创建密钥表文件。此机密必须与托管实例位于同一命名空间中。仅当在客户管理的密钥表模式下进行 Active Directory 部署时，此参数才是必需的。
spec.services.primary.dnsName：输入主 SQL 终结点的 DNS 名称。
spec.services.primary.port：输入主 SQL 终结点的端口号。

可选

spec.security.activeDirectory.connector.namespace：要加入以进行 Active Directory 身份验证、预先存在的 Active Directory 连接器的 Kubernetes 命名空间。如果不输入值，则使用 SQL 命名空间。
spec.services.readableSecondaries.dnsName：输入辅助 SQL 终结点的 DNS 名称。
spec.services.readableSecondaries.port：输入辅助 SQL 终结点的端口号。

要在系统管理的密钥表模式下支持 SQL 上的 Active Directory 身份验证，请在部署规范文件中设置以下属性。有些属性是必需的，有些是可选的。

必须

spec.security.activeDirectory.connector.name：要加入以进行 Active Directory 身份验证、预先存在的 Active Directory 连接器自定义资源的名称。如果输入此属性的值，则将实施 Active Directory 身份验证。
spec.security.activeDirectory.accountName：托管实例的 Active Directory 帐户名称。此帐户是为此托管实例自动生成的，在部署 SQL 之前，域中不得存在。
spec.services.primary.dnsName：输入主 SQL 终结点的 DNS 名称。
spec.services.primary.port：输入主 SQL 终结点的端口号。

可选

spec.security.activeDirectory.connector.namespace：要加入以进行 Active Directory 身份验证、预先存在的 Active Directory 连接器的 Kubernetes 命名空间。如果不输入值，则使用 SQL 命名空间。
spec.security.activeDirectory.encryptionTypes：Kerberos 加密类型列表，允许 spec.security.activeDirectory.accountName 中提供的自动生成 Active Directory 帐户。接受的值为 RC4、AES128 和 AES256。如果未输入加密类型，则允许所有加密类型。要禁用 RC4，可以仅输入 AES128 和 AES256 作为加密类型。
spec.services.readableSecondaries.dnsName：输入辅助 SQL 终结点的 DNS 名称。
spec.services.readableSecondaries.port：输入辅助 SQL 终结点的端口号。

准备部署规范文件

接下来，准备 YAML 规范文件以部署 SQL 托管实例。对于使用的模式，请在规范文件中输入部署值。

注意

在两种模式的规范文件中，YAML 示例中的 admin-login-secret 值均提供基本身份验证。可以使用参数值登录到托管实例，然后为 Active Directory 用户和组创建登录名。有关详细信息，请参阅连接到 Azure Arc 启用的已集成 Active Directory 的 SQL 托管实例。

客户管理的密钥表模式
系统管理的密钥表模式

以下示例显示了客户管理的密钥表模式的规范文件：

apiVersion: v1
data:
  password: <your Base64-encoded password>
  username: <your Base64-encoded username>
kind: Secret
metadata:
  name: admin-login-secret
type: Opaque
---
apiVersion: sql.arcdata.microsoft.com/v3
kind: SqlManagedInstance
metadata:
  name: <name>
  namespace: <namespace>
spec:
  backup:
    retentionPeriodInDays: 7
  dev: false
  tier: GeneralPurpose
  forceHA: "true"
  licenseType: LicenseIncluded
  replicas: 1
  security:
    adminLoginSecret: admin-login-secret
    activeDirectory:
      connector:
        name: <Active Directory connector name>
        namespace: <Active Directory connector namespace>
      accountName: <Active Directory account name>
      keytabSecret: <keytab secret name>
  services:
    primary:
      type: LoadBalancer
      dnsName: <primary endpoint DNS name>
      port: <primary endpoint port number>
    readableSecondaries:
      type: LoadBalancer
      dnsName: <secondary endpoint DNS name>
      port: <secondary endpoint port number>
  storage:
    data:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi
    logs:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi

以下示例显示了系统管理的密钥表模式的规范文件：

apiVersion: v1
data:
  password: <your Base64-encoded password>
  username: <your Base64-encoded username>
kind: Secret
metadata:
  name: admin-login-secret
type: Opaque
---
apiVersion: sql.arcdata.microsoft.com/v3
kind: SqlManagedInstance
metadata:
  name: <name>
  namespace: <namespace>
spec:
  backup:
    retentionPeriodInDays: 7
  dev: false
  tier: GeneralPurpose
  forceHA: "true"
  licenseType: LicenseIncluded
  replicas: 1
  security:
    adminLoginSecret: admin-login-secret
    activeDirectory:
      connector:
        name: <Active Directory connector name>
        namespace: <Active Directory connector namespace>
      accountName: <Active Directory account name>
  services:
    primary:
      type: LoadBalancer
      dnsName: <primary endpoint DNS name>
      port: <primary endpoint port number>
    readableSecondaries:
      type: LoadBalancer
      dnsName: <secondary endpoint DNS name>
      port: <secondary endpoint port number>
  storage:
    data:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi
    logs:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi

部署托管实例

对于客户管理的密钥表模式和系统管理的密钥表模式，请使用准备好的规范 YAML 文件来部署托管实例：

保存文件。下一步中的示例使用 sqlmi.yaml 来指定文件名，但可以选择任何文件名。
运行以下命令以使用规范部署实例：
```
kubectl apply -f <specification file name>
```
命令可能如以下示例所示：
```
kubectl apply -f sqlmi.yaml
```

通过

部署由 Azure Arc 启用的 Active Directory 集成的 SQL 托管实例

先决条件

连接器要求

准备部署

设置 Active Directory 身份验证的属性

必须

可选

必须

可选

准备部署规范文件

部署托管实例

反馈

其他资源

通过

部署由 Azure Arc 启用的 Active Directory 集成的 SQL 托管实例

先决条件

连接器要求

准备部署

设置 Active Directory 身份验证的属性

必须

可选

准备部署规范文件

部署托管实例

相关内容

反馈

其他资源