Здравствуйте.

Существует такой отчёт RSLDAPSYNC_USER. Для того, чтобы он работал, необходимо в транзакции LDAP создать запись для соединения с AD. Там можно указать логин и пароль технического пользователя AD, а можно поставить галку "Анонимное считыв.". При выполнении синхронизации (или даже просто при поиске в транзакции LDAP) информация из этой записи передаётся в ФМ 'LDAP_SYSTEMBIND'. У этого ФМ есть импортируемый параметр WRITEREAD. Опытным путём удалось обнаружить, что получить информацию из AD можно только если задать там 'W' и при этом необходимо обязательно использовать технического пользователя AD, даже если в настройках LDAP-соединения указано анонимное считывание. Потому что если реально не завести пользователя, то сам 'LDAP_SYSTEMBIND' отрабатывает-то нормально, а вот дальнейший 'LDAP_SEARCH' в этом случае всегда возвращает 1 в LDAPRC. И данных никаких не получает.

В http://forums.sdn.sap.com/thread.jspa?threadID=748876 описан пример с использованием 'LDAP_SIMPLEBIND', где ему не передаются логины и пароли. Но я пробовал - ситуация такая же. Если не передавать логин/пароль, то ничего не работает. Есть похожая тема и у нас - viewtopic.php?f=14&t=23661. Она помечена как решённая, но была опубликована в 2007 году, а потом в 2009 туда была дописана ситуация как у меня.

Соответственно вопрос - поборол ли кто-нибудь эту проблему? И вообще - использует ли кто-нибудь LDAP-синхронизацию?

Мы говорим про доступ к абстрактному LDAP, или к конкретному LDAP из Windows A(ctive) D(irectory)?
Если последнее, то анонимный доступ отключен по-умолчанию с 2003-й версии, если не ошибаюсь.

Речь о конкретном AD на основе WINDOWS SERVER 2003 и 2008.
А откуда информация об отключении анонимного доступа?

Я в общем не оспариваю это, сам думал, что может быть на стороне AD какие-то ограничения дополнительные есть. Только меня смущает, что в составе WINDOWS есть, например, утилиты dsquery, dsget, а также csvde и ldifde, которые могут получать информацию из AD безо всякой аутентификации в домене. И я проверил - в моём домене они могут получить всё анонимно. Достаточно чтобы контроллер домена был доступен по сети. А вот получить данные утилитой ldapsearch (под линуксом) у меня пока не получилось.

dsquery считывает LDAP без аутентификации?
видимо потому что запускается под учеткой доменного юзера

сработает ли если зайти локальным администратором?

http://support.microsoft.com/kb/326690/en-us?fr=1

Можно и включить.
Но оно надо?

Да, наверно я проверял под доменным аккаунтом. Сейчас попробовал - действительно требует пароль если запрашивать не из под доменного.

Всё бы ничего, но есть небольшая проблема - логин/пароль технического пользователя можно узнать. Хотя он как бы хранится в SecureStore, но из 'LDAP_SEARCH' вызывается 'SECSTORE_READ_ITEM' и после него пароль видно. Конечно не все смогут вызвать 'SECSTORE_READ_ITEM', но с учётом того, что внедрять это я собираюсь на всех системах, получается многовато народу, включая всяких сторонних консультантов.

А что значит "многовато". Насколько я понимаю, увидеть этот пароль могут только те, кто имеет права на отладку.
Таких прав даже у обычных консультантов не должно быть, только у абаперов. Много ли у вас таких? Тем более в продуктиве.
И много ли среди них тех, кто реально полезет смотреть вычислять этот пароль именно в этом месте? Это ведь должно быть нужно, чтобы таким озадачиться.

С другой стороны знание реквизитов в домене не так уж много может дать потенциальному злоумышленнику, если этой учетке никаких прав в этом домене не дали.
Кроме необходимых в данном случае.

В любом случае вариантов тут немного, если хочется решить задачу синхронизации с AD.

Консультанты-абаперы у нас есть. В остальном я согласен с Вашими доводами. Единственный момент ещё - если я запрашиваю данные через dsguery|dsget, то они вполне воспринимают мой неявный аккаунт даже если он из другого домена (но имеющего доверительные отношения с запрашиваемым доменом). А вот что указывать в транзакции LDAP (и можно ли вообще там использовать аккаунт из другого домена)? Или нужно заводить технические акакаунты для каждого домена?

Решил в эту тему дописать, хотя пометил её уже как решённую.

Выяснилось, что бывает 2 вида аутентификации в LDAP: simple и SSPI. В составе Windows Server есть утилита LDIFDE.EXE, которая поддерживает оба:Отличия между ними в том, что если использовать первый, то ничего не шифруется и в том, что доступ к данным доверяющего домена может быть только при втором методе. При этом в ФМ SAP 'LDAP_COMMONBIND' есть параметр AUTHMECH, но передавать в нём можно только 0, что соответствует simple.

Отсюда вывод, что для того, чтобы воспользоваться встроенными возможностями LDAP необходимо иметь аккаунты во всех доменах, забить их логины и пароли в явном виде в SecStore и при передаче данных по сети ничего шифроваться не будет. А ведь SAP ещё предоставляет средства для обратного процесса: данными из SAP обновлять данные в AD, и всё это тоже без шифрования. Всё это сильно сужает возможности пользования встроенными средствами.