Это должно быть возможно даже с учетом несоответствий DN, проблема здесь заключается в том, как имена пользователей переводятся в DN во время аутентификации.
Вместо того чтобы полагаться на шаблон dn, попробуйте через поиск LDAP.
Ключ должен установить dn_lookup_bind
для поиска до аутентификации пользователя.Таким образом, плагин LDAP сначала свяжется с этими учетными данными, чтобы выполнить поиск, а затем свяжется с DN соответствующей записи, чтобы выполнить вход пользователя:
auth_ldap.dn_lookup_attribute = userPrincipalName # or sAMAccountName
auth_ldap.dn_lookup_base = dc=example,dc=com # restrict to user ou if any
auth_ldap.dn_lookup_bind = {managerDN, Password} # AD manager account
# auth_ldap.user_dn_pattern should be left unset to be sure the lookup actually searches
# for a match in dn_lookup_attribute and not for a built-up dn.
Я упомянул учетные данные из «менеджера AD», но этоЭто может быть любая учетная запись с достаточными разрешениями для поиска записей целевого пользователя.
Учитывая эту конфигурацию, когда плагин входит в процесс авторизации, он может правильно обрабатывать поиск членства в группе, используя фактического пользователя dn.
Редактировать - несмотря на то, что говорится в документацииauth_ldap.dn_lookup_bind
Чтобы выполнить поиск перед привязкой, задайте для auth_ldap.dn_lookup_bind кортеж {UserDN, Password}
.
, может быть безопаснее явно указать:
auth_ldap.dn_lookup_bind.user_dn = <UserDN>
auth_ldap.dn_lookup_bind.password = <Password>
# (OP was required to do so to make it work)