Правильно обрабатывать разрешения sql-сервера с помощью Navision

Question

Фон

Я нахожусь в процессе создания приложения (называемого MyApp), которое должно считывать данные из базы данных SQL Server, обрабатываемой Navision.Пользователи Navision должны иметь возможность использовать мое приложение без изменения разрешений в базе данных.

Кажется, что Navision обрабатывает разрешения на уровне приложений.Он выполняет проверку разрешений, не сохраняя их в базе данных.

Проблема

Navision перезаписывает пользователей, разрешения и другие связанные объекты в базе данных при синхронизации с базой данных, поэтому обычный подходсоздание пользователя БД и просто его использование не сработает.

Возможное решение

Я думаю, что наиболее подходящим решением будет создание роли MyApp в Active-Directory, котораяпредоставляет необходимые разрешения для БД и добавляет эту роль всем пользователям.

Я не знаю, как это сделать, или даже если это возможно.Другие решения или предложения приветствуются, но, пожалуйста, предлагайте только решения, которыми можно управлять из ActiveDirectory или Navision.

Сервер является сервером SQL Server 2008 под управлением Navison 5, а клиентом является Navision 6. IЯ использую Active Directory для Windows Server 2K8.

РЕДАКТИРОВАТЬ:

Мое приложение представляет собой приложение для создания и проектирования ящиков.Он должен считывать имена и идентификаторы клиентов, а также несколько элементов в таблице элементов, и поэтому мне нужна эта функциональность

Answer 1

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

Если вы хотите получить доступ к данным в SQL Server с использованием модели безопасности NAV (т. Е. Через роли приложения SQL, которые создает NAV), вам следует использовать CFront API (устанавливается через параметр SDK). Если вы используете веб-сервисы NAV 2009, это также вариант.

Если вы хотите получить прямой доступ к SQL Server, вам придется самостоятельно управлять разрешениями с помощью SQL Server. Если вы создаете сценарий SQL для предоставления разрешения, легко восстановить все, что NAV может удалить во время синхронизации имен входа.

Вы не можете предоставить разрешение SQL от Active Directory в точности так, как вы описали. Вместо этого необходимо сопоставить группы Active Directory либо с именами входа SQL Server, либо с именами входа NAV Windows (в зависимости от того, решите ли вы обращаться к SQL напрямую или использовать поддерживаемый NAV API). Примечание: разрешения, связанные с ролью, управляются в SQL или NAV соответственно; не в нашей эры.

С точки зрения администрирования вы можете просто добавлять и удалять пользователей из этой группы Active Directory. Если вы используете модель повышенной безопасности NAV, у каждого пользователя в группе AD также должна быть запись в логинах Windows, и при каждом внесении изменений вы должны синхронизировать логины. Это небольшое неудобство - похмелье от родной базы данных.

Answer 2

В целом, пропуск уровня NAV и чтение / запись непосредственно в БД вообще не рекомендуется, поскольку вы обходите всю бизнес-логику NAV, которая хранится в таблице и объектах отчета в NAV.

Что собирается делать ваше приложение (широкими штрихами, если вы не можете получить конкретную информацию) и будет ли возможно использование надстройки NAV или порта данных?