Axapta и ActiveDirectory

[Nikolaich]

Коллеги - не подскажите насколько реально синхронизировать ActiveDirectory и Аксапту? Например внутренний телефон и мыло ? И если знаете, то приведите пример если нетрудно

[Nikolaich]

Уже сам нашел - ActiveDirectoryEmplTable (класс)

[Dronas]

А вот как бы в обратную сторону, ну к примеру в ActiveDirectory сменить инфу?

[Romb]

Занимался этой проблемой. Ничего для работы с AD кроме системного класса ADObject не нашел. К сожалению, он весьма убогий по функциональности.

Задача у меня была не только получать данные из AD, но и иногда проверять авторизацию в AD, на основе пользователей генерить пользователей Axapta, web-пользователей, сотрудников и т.д. В итоге пришлось брать внешние com-компоненты для работы с LDAP, писать в Axapta оболочку для них + форму настройки/синхронизации БД пользователей Axapta и БД пользователей из AD. Сейчас все это и использую, но тут есть необходимость компоненты регистрировать на машине, где работает Axapta. Если интересует могу выложить проект.

[Dronas]

Было бы интересно глянуть...

[gl00mie]

Цитата:

Сообщение от Romb

В итоге пришлось брать внешние com-компоненты для работы с LDAP. Сейчас все это и использую, но тут есть необходимость компоненты регистрировать на машине, где работает Axapta.

Внешние компоненты? Одним из наиболее прямых путей работы с AD через LDAP, по-моему, является ADSI, а для него ничего дополнительно регистрировать не нужно (за исключением NT4, но на ней, думаю, мало кто будет запускать аксапту) - в w2k/wxp/w2k3 уже все есть

[Romb]

Насчет ADSI согласен. Тоже сначала попытался использовать родные средства, но сходу не получилось.

Компоненты от Novell мне показались более понятными, времени было мало, в общем я их и стал использовать.

Вообще, если есть примеры использования ADSI в Axapta, то они бы были полезными для всех. Переложить reference c сайта microsoft на код Axapta я не смог.

[Romb]

Обещанный проект выложить для всех, к сожалению не могу, т.к. это оказывается наша интеллектуальная собственность. ;(

Кому интересно, кидайте мыло, вышлю в индивидуальном порядке, в тайной переписке.

[gl00mie]

Цитата:

Сообщение от Dronas

А вот как бы в обратную сторону, ну к примеру в ActiveDirectory сменить инфу?

Зависит от того, какую инфу требуется сменить. По большому счету, легко (при наличии нужных прав в домене ) меняется все, единственно, с чем возникает геморрой, - это завязки с Exchange, т.е. создание/удаление контактов, изменение емыльных адресов и т.п. Это все необходимо делать, например, через CDOEXM (Collaboration Data Objects for Exchange Management). Если кому-то понадобится, могу кинуть пример кода на vbs для создания, что называется, mail-enabled контакта/пользователя в AD (коим обычный пользователь IADsUser с установленным mail не является). Hint: текущее значение и изменение значения IADsUser.mail не производит на Ms Exchange абсолютно никакого впечатления, это чисто информативное поле.
А вообще, есть такая замечательная вещь как ADSI Scriptomatic - приблуда, генерящая скрипты на vbs для работы с ADSI в зависимости от того, что именно вам нужно сделать: прочитать данные о пользовател/группе/OU и т.п. Для изменения данных о пользователях/etc в этих скриптах достаточно get заменить на set и указать нужные значения.

[Dronas]

И всё же, есть интересный такой интерфейсик, как IADs, впринципе он всё делает, но вот методы Put(Ex) Get(Ex) работать отказываются, как с ними быть?

Это я к тому, что не хочется делать дополнительные компоненты

[gimer]

Цитата:

Сообщение от gl00mie

Зависит от того, какую инфу требуется сменить. По большому счету, легко (при наличии нужных прав в домене ) меняется все

Подскажите - а какие права должны быть у пользователя, от которого запускается обновление данных в AD (Windows Server 2008)? Просто у меня происходит затык именно при попытке обновить данные. Выдается - Access denied.
Или подскажите, где можно прочитать об этом именно для обновления данных в AD через Axapta.

[gl00mie]

Цитата:

Сообщение от gimer

Подскажите - а какие права должны быть у пользователя, от которого запускается обновление данных в AD?

Смотря каких данных... С таким же успехом можно спросить, какие должны быть права для изменения того или иного произвольного файла в корпоративной сети. У каждого объекта в AD свой набор прав доступа, определяющих, кто и что с ним может делать, эти права, как и в случае с файловой системой, могут наследоваться, есть определенные права по умолчанию, но все равно для произвольно взятого объекта AD нельзя сказать, какие именно нужны права для его изменения (если только вы не входите в группу Domain Admins - в последнем случае обычно прав хватит почти на все).

Цитата:

Сообщение от gimer

Или подскажите, где можно прочитать об этом именно для обновления данных в AD через Axapta.

Тут не важно, через что обновлять данные, важно, какие права есть у учетной записи, под которой осуществляется доступ к AD. Для того или иного объекта права доступа можно, к примеру, узнать с помощью ADSI Edit

[gimer]

Я не очень разбираюсь в настройках прав доступа, поэтому можно еще пояснить?
Я хочу обновить значение атрибута employeeID у пользователя AD, который связан в AX с сотрудником через пользовательские данные. Все вроде хорошо, но когда я пытаюсь сохранить изменения, то по логам я вижу, что ldap говорит, что access denied.
Обновление запускается через runas() от имени определенного пользователя, которому вроде все права прописали (дошло уже до того, что временно его даже включали в группу Domain admins), но это не помогает.
Отсюда у меня вопрос - где конкретно мне нужно задать права на запись атрибутов для определенного пользователя?

Заранее спасибо.

[S.Kuskov]

Цитата:

Сообщение от gimer

Обновление запускается через runas()

Runas - в смысле аксаптовский runas? А с чего вы взяли, что привилегии, которые он даёт распространяются и на операционную систему? Или я что-то не так понял?

[gimer]

Цитата:

Сообщение от S.Kuskov

Runas - в смысле аксаптовский runas? А с чего вы взяли, что привилегии, которые он даёт распространяются и на операционную систему? Или я что-то не так понял?

В AX добавлен пользователь AD, для которого задаются соответствующие права. И потом я хочу выполнить обновление данных учетки в AD любого пользователя, который связан с сотрудником в AX. Именно для этого и запускаю от имени пользователя, для которого будут заданны соответствующие права.

Когда я тестировал на виртуалке, на которой были установлены сервер, скуль и AX, именно по такому алгоритму у меня все отработало, правда только в том случае, если я запускал от имени пользователя, связанного с учетной записью Administrator.
Теперь, когда тестирую уже на распределенной системе, возникает именно такая проблема, которую я описал в предыдущих постах.

[S.Kuskov]

Цитата:

Сообщение от gimer

все отработало, правда только в том случае, если я запускал от имени пользователя, связанного с учетной записью Administrator.

Это, потому что функция runas() подменяет контекст только внутри аксапты. Работа в Windows будет по прежнему происходить от имени исходного пользователя. А как иначе?

[gimer]

Цитата:

Сообщение от S.Kuskov

Это, потому что функция runas() подменяет контекст только внутри аксапты. Работа в Windows будет по прежнему происходить от имени исходного пользователя. А как иначе?

Я наверно неправильно выразился. Входил я в систему под другим пользователем, соответственно и в AX, а потом уже в AX я запускал runas() от имени Administrator и все успешно обновлялось