Вообще, самое правильное, чтобы юзеры заводились в домен организации, там включались в нужные группы.
Авторизация в ERP должна идти через доменную авторизацию, внутри в ERP (и прочих учетках)
юзеров быть не должно - права на уровне СУБД. А СУБД должна быть настроена на юзеров из
домена, а не внутренних.
Тогда администрирование юзеров всей конторы делается 1 раз на каждое событие - при приеме
на работу ->при переназначении должностей-полномочий ->при увольнении.
Сразу для всех систем конторы от почты, файлопомойки, печати на большой gestetner до ERP,
CRM, отчетности, SCM, корпоративного банкинга и порталов работы с внешними организациями.
Мы у себя этого почти добились. Все-таки в реальности сталкиваешься с "зоопарком", и тогда
приходится идти на компромиссы. Например, вот что делать, если одна из систем использует
авторизацию на уровне юзера linux ? Героически добавлять сервер под linux в лес AD ? Или
делать скрипт на tcl, периодически сравнивающий юзеров в linux с доменными и прибивающий
уволенных ? Или написать правило на Exchange-сервере, которое отбирает письма на отдел
кадров со словами в заголовке типа "увольнение, прием, новый человек ..." и пересылающие их
админу AD, по совместительству - админу linux ?
Или вот еще. Что делать, если некая система в качестве СУБД юзает MySQL ? Тут с доменной
авторизацией как-то через ж№;", пардон, через Tomcat только можно (это если система на Java).

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

IgorKstrizhВообще, самое правильное, чтобы юзеры заводились в домен организации, там включались в нужные группы.
Я бы не стал так категорично утверждать. Например продавцов в торговом зале или кладовщиков, у которых нет своего компьютера и они могут на любов свободном (в зале или на складе) зайти в систему - посмотреть остаток товара или отгрузку сделать тоже заводить? И на каждый чих перелогин делать?

Гм. Вы путаете процесс авторизации юзера и процесс добавления его как юзера в систему. Авторизоваться в учетной системе юзер, при условии что он введен в домен и в учетку как юзер домена, может как вводя логин вида домен\логин и свой доменный пароль, так и используя виндовую авторизацию.
Для учетных систем, особенно с веб-интерфейсом, делают первый вариант авторизации более приоритетным. 1С 8.2, к примеру, если юзер вошел в домен, то толстый клиент автоматически делает виндовую авторизацию. И MS CRM тоже, если юзер вошел в домен, то будет автоматическая виндовая авторизация в веб-интерфейсе, а если не вошел, или вошел в другой домен - то ему прийдется, всего-лишь, ввести имя-пароль.

С Ораклом не работаем вообще.

В нашем зоопарке MS SQL, PostgreSQL, MySQL, Progress.
Авторизация в системах на первых двух СУБД через AD - очень удобна. На остальных - пока невозможна.