订阅内容

如果您使用红帽 Ansible 自动化平台管理 Windows 主机,那么这篇博客非常适合您!我想重点介绍一下 Active Directory 清单插件,它可以让 Active Directory 成为 Ansible 自动化平台的事实来源。首先,让我们回顾一下为什么清单管理如此重要。

Ansible 自动化平台旨在成为一个简单、强大且无代理的自动化工具。

introducing-microsoft-active-directory-inventory-plug-ansible

无代理架构在可自动化的范围和深度上为我们提供了极大的灵活性,因为我们不再局限于管理可以安装代理的设备。在这个无代理世界中,清单管理成为成功的基石。通常,我们需要知道:

  • 我们需要管理哪些设备?我们从哪里获得最新且准确的基础架构列表?
  • 我们如何对节点进行分类,以便确定如何针对它们进行自动化?例如,我们针对数据库服务器运行的自动化将不同于针对 Web 服务器的自动化。

清单插件为这些问题提供了一个巧妙的解决方案。在最简单的形式中,它们是脚本并允许我们指向事实来源,以收集服务器列表和可能帮助我们更好地了解如何针对它们进行自动化的任何特征。

当我们考虑管理 Microsoft Windows 环境时,Active Directory 会成为非常有吸引力的事实来源,因为服务器通常会注册到一个域中。得益于 Microsoft AD 的红帽 Ansible 认证内容集,我们现在拥有一组可以与 Microsoft Active Directory 交互的出色模块,更重要的是,还拥有一个可以利用 Active Directory 作为事实来源的清单插件。 借助此清单插件,我们可以根据主机的 Active Directory 属性和组成员资格对主机进行过滤和分组。

让我们看一下插件的实际应用。

从命令行入手

让我们从命令行开始,使用自动化内容浏览器和自动化执行环境。有关安装和配置自动化内容浏览器的说明,请参见 内容创建文档Ansible 自动化平台 2.4+ 附带的受支持执行环境已包含我们开始与 Microsoft Active Directory 集成所需的一切,包括 microsoft.ad 集合以及必要的 Python 依赖项。对于之前的版本,您可能需要 自定义执行环境,以满足这些前提条件。

幸运的是, debug_ldap_client 模块可用于检查必要的 Python 依赖项以及 DNS 和 Kerberos 配置。由于我们使用的是自动化执行环境,我们将在镜像内运行此模块,以检查是否具备清单插件 所需的依赖项。我们可以忽略回溯错误,因为我们只关心用例中是否存在所需的 Python 依赖项。

$ ansible-navigator exec -- ansible localhost -m microsoft.ad.debug_ldap_client
  < Output Truncated >
"packages": {
    "dnspython": "2.3.0",
    "krb5": "0.5.0",
    "pyspnego": "0.9.0",
    "sansldap": "0.1.0"

要创建清单定义以查询 Active Directory 服务器,我们的清单文件必须以 microsoft.ad.ldap.yml 或 microsoft.ad.ldap.yaml 结尾,因此我们可以将它简称为 microsoft.ad.ldap.yml。 为了进行测试,我使用了以下配置。不必质疑,我知道用户名和密码是纯文本格式。 这只是为了让我们能够进行一些初始连接测试,以便开始使用我们可能想要运用的一些属性。稍后我们将修复凭据。

plugin: microsoft.ad.ldap
server: ms-ad.demolab.local
username: svc-aap-ldap
password: Redhat123
tls_mode: ldaps

现在,我们可以使用 Ansible 自动化平台导航器的“inventory”子命令,从命令行测试插件。由于我们使用的是 ldap,因此要通过 /etc/pki/ca-trust 路径将 CA 信任存储从 RHEL 主机映射到执行环境。

查看输出结果,可以看到我们发现了一台名为 MS-AD 的主机,它是我们的域控制器。 

$ ansible-navigator inventory -i microsoft.ad.ldap.yml --list -m stdout --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
{
"_meta": {
    "hostvars": {
        "MS-AD": {
            "ansible_host": "ms-ad.demolab.local",
            "microsoft_ad_distinguished_name": "CN=MS-AD,OU=Domain Controllers,DC=demolab,DC=local"
        }
    }
},
"all": {
    "children": [
        "ungrouped"
    ]
},
"ungrouped": {
    "hosts": [
        "MS-AD"
    ]
}
}

连接看起来良好,但我们获得的信息过少,而且我们未能将主机添加到任何组中。我们可以向清单插件提供大量 记录的参数,以便根据需要进行自定义。

实际上,Active Directory 中的所有计算机属性都可用于过滤、设置变量或对主机进行分组。要查看 MS-AD 主机的所有可用属性,我们可以在安装了 Active Directory PowerShell 模块的 Windows 主机上使用以下 PowerShell 命令。

Get-ADComputer -Identity "MS-AD" -Properties *

让我们添加一些额外的参数,并开始对主机进行分组。更新清单配置文件 - microsoft.ad.ldap.yml,以添加要从 Active Directory 检索的一些额外属性。在更新后的示例中,获取“OperatingSystem”和“location”的属性,以及计算机所属的所有组的列表。如果 regex_search 行看起来令人震惊,请不要担心,这是我从 文档复制粘贴过来的。

配置的最后一部分定义了我们的 Ansible 自动化平台组,以便我们可以对节点进行分类。所有计算机都将自动添加到名为“windows”的组中。我们还要将属于“Production”域组成员的任何主机添加到对应的名为“production”的组中。最后,我们将根据操作系统和位置属性将主机添加到组中。以下是最终的配置文件。

plugin: microsoft.ad.ldap
server: ms-ad.demolab.local
username: svc-aap-ldap
password: Redhat123
tls_mode: ldaps
attributes:
  OperatingSystem:
operating_system:
  location:
  memberOf:
computer_membership: this | map("regex_search", '^CN=(?P<name>.+?)((?<!\\),)', '\g<name>') | flatten
groups:
  windows: true
  production: '"Production" in computer_membership'
keyed_groups:
- key: operating_system | lower
  prefix: os
  default_value: unknown
- key: location | lower
  default_value: unknown
  prefix: location

通过命令行进行最后一次测试。让我们回顾一下从 Active Directory 获取的属性。带有“__ansible_unsafe”的值表示它们 不得用于 jinja2 模板

$ ansible-navigator inventory -i microsoft.ad.ldap.yml -m stdout --host MS-AD --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
{
    "ansible_host": "ms-ad.demolab.local",
    "computer_membership": [
    {
        "__ansible_unsafe": "Production"
    }
    ],
    "location": {
    "__ansible_unsafe": "london-dc1"
    },
    "microsoft_ad_distinguished_name": "CN=MS-AD,OU=Domain Controllers,DC=demolab,DC=local",
    "operating_system": {
    "__ansible_unsafe": "Windows Server 2019 Standard Evaluation"
    }
}

接下来,让我们查看一下组成员资格。我们的服务器现在是四个 Ansible 自动化平台组的成员,我们可以根据需要使用这些组来进行定位。

$ ansible-navigator inventory -i microsoft.ad.ldap.yml -m stdout --graph --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
@all:
  |--@_london_dc1:
  |  |--MS-AD
  |--@os_windows_server_2019_standard_evaluation:
  |  |--MS-AD
  |--@production:
  |  |--MS-AD
  |--@windows:
  |  |--MS-AD

测试完成!让我们看看如何在具有自动化控制器的企业环境中使用它。

配置自动化控制器

借助自动化控制器,企业能够以标准化方式部署、启动、委派和审核自动化。现在需要修复我们的明文凭据,并对清单配置进行一些控制。

  1. 创建凭据类型 - 自动化控制器允许我们定义 自定义凭据类型,以便与各种系统交互,同时保持我们的安全态势。这让我们能够在运行时注入环境变量,而不是以明文的形式。查看 清单插件的文档,您会发现它将接受各种环境变量进行身份验证。我们将在自动化控制器中使用这些变量。

    在自动化控制器 UI 中,前往“Credential Types”,并按下“Add”。 为凭据类型提供一个名称,我们将其命名为“Microsoft AD Inventory”。对于“Input configuration”,我们可以使用这些字段来定义所期望的用户名、密码和 AD 服务器信息。

    fields:
      - id: MICROSOFT_AD_LDAP_USERNAME
    type: string
    label: Username
      - id: MICROSOFT_AD_LDAP_PASSWORD
    type: string
    label: Password
    secret: true
      - id: MICROSOFT_AD_LDAP_SERVER
    type: string
    label: AD Server
    required:
      - MICROSOFT_AD_LDAP_USERNAME
      - MICROSOFT_AD_LDAP_PASSWORD
      - MICROSOFT_AD_LDAP_SERVER

    “injector configuration”定义我们将注入到清单同步中的变量。请使用以下内容:

    env:
      MICROSOFT_AD_LDAP_SERVER: '{{ MICROSOFT_AD_LDAP_SERVER }}'
      MICROSOFT_AD_LDAP_PASSWORD: '{{ MICROSOFT_AD_LDAP_PASSWORD }}'
      MICROSOFT_AD_LDAP_USERNAME: '{{ MICROSOFT_AD_LDAP_USERNAME }}'

 

  1. 创建凭据 - 现在我们有了新的凭据类型,可以创建对应的凭据了。转到“Credentials”,并单击“Add”。选择新的凭据类型“Microsoft AD Inventory”,然后填写用户名、密码和 Active Directory 服务器,与命令行中的操作一样。

  1. 创建项目 - 我们希望在源代码控制中管理我们的 Active Directory 清单配置,以便更改能够通过相关的同行审查和批准。自动化控制器中的项目允许我们映射到源代码控制存储库。我已将为命令行编写的配置推送到 GitHub 存储库 - https://github.com/pharriso/ansible_microsoft_ad_inventory

    重要信息!- 我们尚未将用户名、密码或 Active Directory 服务器推送到源代码控制。这些现在由自动化控制器中的凭据处理。请从清单配置中删除这些参数!

    在自动化控制器 UI 中,前往“Projects”并单击“Add”。以下是我们项目的详细信息,其中填充了相应的源代码控制 URL。有关其他项目字段的更多信息,请参阅 本文档

  1. 创建清单 - 我们已准备好创建清单。导航到“Inventories”,单击“Add”,然后单击“Add Inventory”。为清单指定一个适当的名称。

    点击“Save”后,将有其他选项可用于该清单。选择“Sources”,然后单击“Add”。在这里,我们将通过选择清单配置文件和凭据来整合我们的配置。以下是我们已完成的清单来源。

    注意 - 此处唯一可能的问题是,您需要手动输入清单文件名,然后按 Enter 键以填充该字段。

点击“Save”后,我们会在屏幕底部看到“Sync”按钮。按下此按钮将运行我们的清单插件。我们可以通过查看“Last job status”或转到“Jobs”菜单项来跟踪进度。希望我们能看到“Success”!

我们可以前往“Inventories”、“Demolab AD Inventory”,然后选择“Hosts”选项卡,以验证我们的插件配置。我们应该会看到我们的主机已导入:

单击主机,我们还可以查看从 Active Directory 收集的变量(属性)。最后,我们可以单击“Groups”选项卡,以检查是否对主机进行了正确分组。

 

后续步骤

清单管理是利用 Ansible 自动化平台优化和扩展自动化的关键。Microsoft AD 清单插件正是一个很好的例子,展示了 Ansible 自动化平台如何为像我们这样的用户带来简化的体验。希望通过将 Active Directory 用作事实来源,您将能够加快使用 Ansible 自动化平台实现 Windows 自动化的进程。


关于作者

Pat Harrison works for Red Hat in the UK as an Associate Principal Specialist Solution Architect focused on Ansible automation. Prior to this, Pat worked as a Red Hat Consultant helping to deliver solutions across various Red Hat products.
Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事