Возможный относиться к пользователю в AD без всего пути LDAP?
Или настройте свой сервер, чтобы удалить строку хижины или настроить сервер, чтобы проанализировать .php файлы через интерпретатор PHP и затем удалить строку хижины.
Я никогда не встречался с сервером, который (к моему знанию так или иначе) даже способен к использованию той строки хижины, таким образом, я не могу даже начать воображать то, что Вы используете для предложения чего-либо более описательного, чем это. Если Вы обеспечиваете больше детали в своем сообщении, возможно, кто-то с опытом в том, что Вы используете, может дать Вам лучший ответ.
Это действительно зависит от того, как приложение реализует привязку объекта. Некоторые приложения просто не поддерживают поиск по поддереву (что в таких случаях очень расстраивает). Вы должны спросить своего поставщика, поддерживает ли их продукт поиск по поддереву, который позволяет вам подключаться к более высокому уровню каталога и выполнять поиск в нем. Возможно, они просто могут напрямую связываться с пользовательским объектом. Я работаю с приложением, для которого это так ... Это действительно расстраивает, и я сталкиваюсь с проблемой, которую вы часто описываете.
Если их провайдер поддерживает это, что-то вроде этого будет выполнять поиск по поддереву.
<LDAP://DC=mydomain,DC=com>;&(objectClass=User)(cn=myusername);distinguishedName,cn,AdsPath;subTree
Скорее всего, хотя, если они просят у вас полный DN, то это то, что им понадобится.
Похоже, вы специально имеете в виду настройку Bind DN, которую приложение будет использовать для аутентификации в LDAP?
Если это так, то вы совершенно правы; вам не нужно жестко кодировать DN пользователя. UPN также действителен ( username @ upnsuffix , где upnsuffix - это обычно полное доменное имя вашего домена).
Можно ли его отправить, и могут ли другие пути LDAP, такие как поисковая база или идентификаторы пользователей / групп, застряли к конкретным путям, полностью зависят от программного обеспечения, реализующего их, поэтому ваш пробег может отличаться.
Если объект пользователя используется для целей аутентификации, я могу понять их точку зрения с точки зрения того, как они определяют пользователя. Как вы знаете, LDAP поддерживает объекты с одним и тем же CN (общим именем) во всем пространстве имен LDAP. Итак, предполагая, что вы только ссылались на объект, используя его CN, вы могли бы ссылаться на пользователя в другой части вашего пространства имен.
Это отличается, на мой взгляд, от ситуаций, когда приложению необходимо больше запрашивать LDAP. свободно, например: устройство, которое должно разрешать пользовательские объекты в целом, должно быть указано в подходящем корне дерева, чтобы найти соответствующих пользователей. Здесь, конечно, поиск в поддереве имеет определенную цель.
Возвращаясь к исходной задаче, вы можете выбрать «предотвратить случайное удаление» вариант (или любые другие слова) для учетной записи пользователя. Это не остановит его перемещение, но предотвратит одну возможную ошибку. Вы также можете создать сценарий периодической команды «dsquery user», чтобы убедиться, что ваша учетная запись не была перемещена.
Наконец, если ваши администраторы «перестраивают» ваши OU без надлежащего контроля изменений, то кому-то все равно нужна пощечина; -)