slapddgen

• slapddgen
  • 用法
  • 修改模板
  • Docker
    • 构建
    • 运行
      • 生产
  • 配置
    • cn=config.ldif
    • cn=module{0}.ldif,cn=config
    • olcDatabase={-1}frontend.ldif,cn=config
    • olcDatabase={0}config.ldif,cn=config
    • olcDatabase={1}monitor.ldif,cn=config
    • olcDatabase={2}mdb.ldif,cn=config
    • olcOverlay={0}memberof.ldif,olcDatabase={2}mdb,cn=config
    • olcOverlay={1}refint.ldif,olcDatabase={2}mdb,cn=config
    • olcOverlay={2}ppolicy.ldif,olcDatabase={2}mdb,cn=config
    • olcOverlay={3}unique.ldif,olcDatabase={2}mdb,cn=config
    • cn=schema.ldif,cn=config
    • cn=*.ldif,cn=schema,cn=config

注意：此工具非常非常初级。对我有效，可能对您也有效。

注意：确保您的编辑器在打开cn=schema中的任何文件时不会删除尾随空格，因为这会破坏ldif格式。

slapddgen 生成一个slapd.d，您可以通过指向它使用slapd -F将其加载到OpenLDAP服务器中。这将启动一个具有在线配置的服务器，即olc，这意味着配置本身存储在目录服务器中，而不是在slapd.conf中。

用法

此工具的输入包含在config.json中，或--config_file指向的内容。使用环境变量或CLI开关做这件事太麻烦了。从config.json中删除内容肯定会出问题，但对于模块、ACLs、索引和空数组应该没问题。

安装 slapddgen 后，您可以使用以下命令运行它：slapddgen generate --config_file=/path/to/config.json --output_dir=/path/to/write/config/to

修改模板

如果您了解自己在做什么，可以修改 templates/slapd.d 中的模板以适应您的需求。如果您已经使用 pip install 安装了 slapddgen，这样做可能会很麻烦，因此在这种情况下，克隆存储库并执行 pip install -e . 会更有帮助。

Docker

还有一个示例 Dockerfile，您可以使用它将所有内容打包到 Docker 容器中。这对于测试目的以及其他目的可能很有用。

构建

VERSION=$(git rev-parse --abbrev-ref HEAD)
docker build --no-cache=true \
    --build-arg BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ') \
    --build-arg COMMIT=$(git rev-parse HEAD) \
    --build-arg VERSION=${VERSION} \
    -t ldap:${VERSION} .

在构建发布版本时，请使用 git describe --abbrev=0 --tags 代替 VERSION。

运行

docker run -it -p 3389:389 -p 6636:636 ldap

这将使容器中的 389 端口（ldap:// URL）暴露给主机的 3389 端口（因此您不需要绑定在受保护的端口上），并针对 636 端口（ldaps://）执行相同的操作。

您可以使用 --entrypoint=/bin/sh 修改入口点。一旦您这样做，您仍然可以通过运行 slapd -u ldap -g ldap -d 256 手动在容器中启动 OpenLDAP。

生产

在生产环境中运行时，确保配置和数据可以持久到磁盘很重要。否则，每次重启容器时，您都会启动一个全新且空的目录服务。

为此，您可能需要挂载以下内容

• 配置：/etc/openldap
• 数据库：/var/lib/openldap/openldap-data

创建一个单独的用户 ldapd，默认 UID 为 55555。这是为了确保您可以正确映射主机用户和容器用户，避免在卷挂载中遇到权限问题。

要更改容器中 ldapd 用户的 UID，您必须重新构建它并传递 --build-arg UID=<number>。

配置

slapddgen 为您生成了一堆配置，并假设以下 DIT 布局

- {{suffix}}
--- {{baseOU}},{{suffix}}
----- ou=accounts,{{baseOU}},{{suffix}}
----- ou=groups,{{baseOU}},{{suffix}}
----- ou=policy,{{baseOU}},{{suffix}}

当然，您可以通过修改模板来自行更改此布局。

生成的配置使用在线/动态配置，即 olc，即 olcConfig。因此，没有所谓的 slapd.conf，您将需要使用 ldapmodify 的帮助来应用 ldif 以进一步配置 OpenLDAP 服务器。

生成的 slapd.d 目录可以用于从头开始启动 OpenLDAP 服务器。以下部分假设您已运行 slapddgen 并解释了生成的配置中的某些内容。

cn=config.ldif

以下设置与 Alpine 相关

olcConfigFile: /etc/openldap/slapd.conf
olcConfigDir: /etc/openldap/slapd.d/
olcArgsFile: /run/openldap/slapd.args
olcPidFile: /run/openldap/slapd.pid

值得注意的是

olcPasswordCryptSaltFormat: $6$rounds=50000$%.16s

这使用 crypt 的 SHA512，循环次数为 50,000（密钥拉伸）。这关系到 olcPasswordHash 设置在 olcDatabase={-1}frontend.ldif 中以及 olcPPolicyHashCleartext 在 olcOverlay={2}ppolicy.ldif,olcDatabase={2}mdb,cn=config 中。

cn=module{0}.ldif,cn=config

配置了要加载的模块。值得注意的是 olcModulePath 和与 olcModulePath 相关的多个 olcModuleLoad 条目。

olcDatabase={-1}frontend.ldif,cn=config

前端数据库是一个特殊、伪数据库，它包含应用于所有其他 olcDatabase 的默认设置。

两个有趣的条目是

olcMonitoring: FALSE
olcPasswordHash: {CRYPT}

olcMontioring 禁用所有数据库的监控覆盖。它将明确为 olcDatabase={2}mdb.ldif 启用。另一个确保我们始终使用 {CRYPT} 作为我们的密码哈希机制。应用于密码哈希的设置由 olcPasswordCryptSaltFormat 定义。

olcDatabase={0}config.ldif,cn=config

这里唯一值得关注的是 olcAccess 条目，定义了允许实体读取/写入 cn=config 的 ACL。

olcDatabase={1}monitor.ldif,cn=config

与上一节一样，olcAccess 是唯一值得关注的部分。

olcDatabase={2}mdb.ldif,cn=config

这一部分很有趣，因为它定义了我们实际条目在 DIT 中的数据存储，以及其他如 ACL 等内容。

值得关注

olcSuffix: dc=example,dc=com
olcRootDN: cn=Manager,dc=example,dc=com
olcRootPW: {CRYPT}super-long-hash
olcMonitoring: TRUE
olcDbMaxSize: 536870912
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbIndex: objectClass eq
olcDbIndex: uid eq,sub
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: member eq
olcDbIndex: memberof eq

olcSuffix 定义了所有条目的默认后缀。olcRootDN 是该数据库 "root" 用户的 DN，可以修改任何内容，无论 ACLs 如何。olcRootPW 是 olcRootDN 的密码，由 slappasswd -h '{CRYPT}' -c '$6$rounds=50000$%.16s' 生成。

olcMonitoring 启用对数据库的监控，olcDbDirectory 包含数据库存储在磁盘上的路径。

olcDbIndex 条目定义了 OpenLDAP 将为我们维护的索引，并有助于加快搜索操作。

olcDbMaxSize 定义了分配给数据库的内存映射的大小。在运行时，其大小不能超过此值，尽管您可以将其设置为更高的值然后重启。该值以字节为单位，我们的默认值是半个吉比特（GiB）。

像往常一样，还有许多管理数据访问的 olcAccess 条目。

olcOverlay={0}memberof.ldif,olcDatabase={2}mdb,cn=config

在此处存储 memberof 插件配置。memberof 插件将为 DIT 中的任何条目添加一个虚拟属性 memberOf，存储此 DN 是哪些成员。

假设您有三个 groupOfNames 引用用户在 member 属性中。该用户的 memberOf 属性将包含这三个 groupOfNames 的 DN。请注意，memberOf 只包含直接/立即的成员资格，不包含任何继承的成员资格（它不会递归展开成员属性）。

感兴趣的设置是

olcMemberOfDangling: error
olcMemberOfDanglingError: constraintViolation
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

olcMemberOfDangling 指定如果修改会导致悬空引用，我们将返回错误，返回类型为 olcMemberOfDanglingError。

olcMemberOfRefInt 指定我们使用引用完整性插件（参见下一节）。

olcMemberOfGroupOC 指定我们监视悬空引用的 objectClass。这通常仅对组有用，我们使用 groupOfNames 作为组。olcMemberOfAD 指定用于存储组成员的属性，即 member，而 olcMemberOfMemberOfAD 指定关系存储的属性，即 memberOf。

olcOverlay={1}refint.ldif,olcDatabase={2}mdb,cn=config

此配置引用完整性插件。引用完整性将负责更新存储在指定属性中的任何 DN 的引用，如果该 DN 被重命名/移动。

值得注意的是

olcRefintAttribute: owner
olcRefintAttribute: manager
olcRefintAttribute: memberOf
olcRefintAttribute: member
olcRefintAttribute: roleOccupant
olcRefintModifiersName: cn=Manager,dc=example,dc=com

olcRefintAttribute 指定我们想要执行引用完整性的属性。这只能是存储唯一名称的属性。

olcRefintModifiersName 指定我们将存储在由引用完整性插件更新的任何条目的 modifiersName 操作属性中。

olcOverlay={2}ppolicy.ldif,olcDatabase={2}mdb,cn=config

密码策略插件允许配置密码（如存储在 userPassword 属性中的密码）的某些最小要求。

值得注意的是

olcPPolicyHashCleartext: TRUE
olcPPolicyDefault: cn=password,ou=policy,dc=example,dc=com
olcPPolicyUseLockout: FALSE

olcPPolicyHashCleartext 意味着服务器将自动使用 olcPasswordHash 对任何以明文发送的密码进行哈希处理。

olcPPolicyDefault 定义一个条目，在其中我们存储默认密码策略，我们可以设置其他设置。该条目应具有 objectClass: pwdPolicy。其设置在此处记录。

您可以在树的 ou=policy 部分创建额外的/不同的密码策略，并通过在它们上添加 pwdPolicySubentry 属性将它们附加到用户，指向不同的策略。

olcPPolicyUseLockout 指示服务器在尝试绑定时是否应返回 InvalidCredentials（FALSE）或返回 AccountLocked（TRUE）。此配置的默认值为 FALSE，以便无法使用此功能来枚举帐户。

olcOverlay={3}unique.ldif,olcDatabase={2}mdb,cn=config

独特的覆盖层允许对树的一部分（或整个树）上的属性的唯一约束进行强制。尽管RDN始终被强制唯一（例如，你不能有两个人具有相同的uid），但其他属性并非如此，最重要的是像uidNumber、gidNumber或homeDirectory这样的东西。

您可以通过添加一个olcUniqueURI条目来创建约束：形式为ldap:///[base dn]?[attributes...]?scope[?filter]。

例如，如果您想强制唯一的gidNumber，可以这样做：ldap:///?gidNumber?sub。不幸的是，这将强制在posixAccount和posixGroup上执行gidNumber约束，因此您将无法创建一个将gidNumber设置为posixGroup的GID的posixAccount，这是不可取的。相反，您可以这样操作

olcUniqueURI: ldap:///ou=groups,ou=example,dc=example,dc=com?gidNumber?sub
olcUniqueURI: ldap:///ou=accounts,ou=example,dc=example,dc=com?gidNumber?sub
olcUniqueURI: ldap:///ou=example,dc=example,dc=com?uidNumber?sub

现在约束将独立于这些树的这部分执行，而不是作为一个整体。

cn=schema.ldif,cn=config

这里没有什么相关的要查看或更改的。它只需要存在。一旦服务器启动，此条目将自动由服务器内部的类和属性（主要是所有olc*对象类和属性）更新。

cn=*.ldif,cn=schema,cn=config

包含服务器加载的模式文件。

更新这个相当棘手。最“简单”的方法是生成一个包含模式包含语句的slapd.conf，然后使用slapdest -f /path/to/slapd.conf -F /path/to/slapd.d将其导出。