Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#130<< #131 |
СОДЕРЖАНИЕ
Группа компаний Талгар совместно с www.SQL.ru проводит третий ежемесячный семинар посвященный СУБД Microsoft SQL Server. Семинар состоится 21 февраля 2003 года в 11-00. Немного о MS SQL Server 2000 Автор: Владимир Белов
То что я хочу рассказать в данной статье, думаю известно многим DBA, но, анализируя вопросы приходящие в форум на
www.sql.ru, становится ясно, что эти моменты вызывают некоторые затруднения при работе. Учетная запись для старта сервисов MS SQL Server 2000 SQL Server в своем "стандартном" наборе имеет следующие службы:
Для запуска указанных сервисов вы можете использовать, скажем так, два пути.
Так как преимущество использования доменной учетной записи очевидно, то практически всегда, когда это возможно, используйте доменную учетную запись для старта SQL Server. Однако, здесь тоже есть свои "подводные" камни. Некоторые DBA, не долго мучаясь, стартуют сервис от имени пользователя, которые входит в группу Domen Admin. Но это фактически противоречит всем канонам безопасности, т.к., в случае взлома, ни что не мешает злоумышленнику выполнить какие-нибудь особо веселые команды через xp_cmdshell. Поэтому рекомендуется предоставить следующие разрешения для учетной записи для старта сервиса MSSQLSERVER и SQLSERVERAGENT:
· Full control на директорию с исполняемыми файлами SQL Server; - HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLSever
Во всяком случае, касаемо прав на ветки реестра - это рекомендации Microsoft. Обычно я предоставляю права на всю
ветвь MSSQLServer. ![]() Предоставление прав на уровне системы для пользователя Dealine, E-commerce на директорию с файлами данных. ![]() Предоставление прав на ветку реестра "MSSQLServer". Выполнение распределенных запросов
Предположим, у нас есть два сервера, которые имеют разную функциональную нагрузку, например, сервер TRELON с
финансовой программой и сервер NEPTUN с основной корпоративной программой (во всяком случае, так у нас в организации)
и появляется необходимость, например, при работе отчетов получить данные как с одного сервера, так и с другого.
Как всегда есть три пути решения данной "проблемы". USE master GO sp_configure 'remote proc trans', 1 -- аналог Enforce … GO reconfigure with override GO sp_configure 'remote access', 1 -- аналог Allow other … GO reconfigure with override GO ![]() Далее - к распределенным запросам. Насколько я понял, SQL Server все обнаруженные MS SQL сервера добавляет как Remote Server. Обычно я удаляю ненужные, а необходимые делаю как Linked Server. Разница между ними только в том, что:
- Во-первых, Remote Server - это только SQL Server, а Linked Server - это может быть и не SQL Server; Предположим, что на сервере TRELON есть SQL - логин DEALINE.CENTER\BelovV. Данному логину необходимо получить данные с сервера NEPTUN. Возьмем за основу то, что у нас запрос выполняется с сервера TRELON, сервер NEPTUN уже подключен как Linked Server. Если нет подключаем: - из QA выполнив: exec master..sp_addlinkedserver 'NEPTUN', N'SQL Server' exec master..sp_serveroption 'NEPTUN', 'DATA ACCESS', true - из EM: Security - Linked Server - New Linked Server. Указываем, что это будет у нас SQL Server, указываем имя сервера. Далее на вкладке "Server Options" отмечаем следующие пункты: Data Access RPC RPC Out Описание этих параметров выходит за рамки данной статьи, поэтому читайте о данных параметрах в BOL или спросите на форуме :) Добавление нового Linked Server
![]() ![]() Итак, сервер добавлен - можно идти дальше. А чтобы идти дальше есть три пути: Путь номер один
На вкладке "Security" в колонке "Local Login" указываем логин, которому нужен доступ на сервер NEPTUN. Далее на
сервере NEPTUN создаем такой же логин с необходимыми правами. Почему такой же? Для удобства администрирования. :) Путь номер два На сервере NEPTUN создать новый логин, например, "NEPTUN" и всем пользователям, которым необходим доступ на удаленный сервер, давать доступ под этим логином. Т.е., также на вкладке "Security" в колонке "Local Login" указать необходимый логин, а в колонке "Remote User" - указать логин "NEPTUN" Путь номер три
По моему мнению - это самый лучший путь, но, чтобы его использовать, у Вас должна быть развернута и функционировать
Active Directory. Без этого никак.
1. В оснастке Active Directory Users and Computers - Users найти пользователя, под которым запускаются сервисы
SQL Server'a и в свойствах данного пользователя на вкладке Account в Account options отметить флажок "Account is
trusted for delegention". После этого все должно работать. Иногда встречаются ошибки, такие как, например - пользователь устанавливает соединение с сервером TRELON, на котором установлен SP3, далее запускает распределенный запрос к серверу NEPTUN, на котором установлен SP2. В этом случае Вы получите ошибку "Login failed…". То есть необходимо обеспечить идентичность, скажем так, версий Ваших SQL серверов. И ещё одно условие - необходимо обеспечить идентичность установленных Windows Service Pack. ![]() Свойства компьютера в оснастке "Active Directory Users and Computers"
Свойства пользователя в оснастке "Active Directory Users and Computers"
Добавление нового пользователя. Безопасность Microsoft SQL Server 2000 (ПРОДОЛЖЕНИЕ) По материалам статьи Richard Waymire и Ben Thomas: Microsoft SQL Server 2000 Security
1. Введение 2.4. Kerberos и делегирование в среде Windows 2000 Kerberos - основной механизм аутентификации в сетях Windows 2000. Делегирование - способность передавать мандаты безопасности между компьютерами и прикладными программами. Для каждого перехода (hop) между компьютерами, сохраняются соответствующий мандат пользователя. SQL Server 2000 полностью поддерживает Kerberos, включая способность принимать делегированные билеты Kerberos, а также делегировать эти билеты далее (для Windows 2000), задействовав контроллеры домена Windows 2000 и Active Directory. Билет - это набор идентификационных данных для системы безопасности, выданных контроллером домена с целью проверки подлинности пользователя. В Windows 2000 используются билеты двух типов: билеты TGT и билеты службы. Билеты Kerberos применяются при удалённом вызове хранимых процедур и в распределенных запросах. Для получения дополнительной информации о Kerberos и безопасности Windows 2000, см. следующую статью: Windows 2000 Security Services Чтобы делегирование работало, все серверы, с которыми поддерживается соединение, должны быть под Windows 2000 с включённой поддержкой Kerberos, и должны использовать Active Directory. Кроме того, в Active Directory должны быть выполнены соответствующие установки для делегирования, чтобы это всё заработало:
· Account is sensitive and cannot be delegated. Эта опция не должна быть включена для делегирования запросов
пользователя. Чтобы использовать делегирование учетной записи, SQL Server должен иметь Service Principal Name (SPN), назначенный администратором домена учетной записи Windows 2000. SPN должен быть назначен для учетной записи службы SQL Server для конкретного компьютера. Делегирование подразумевает взаимную идентификацию. SPN необходим, что бы доказать подлинность SQL Server конкретного компьютера, работающего через конкретный сокет, и присвоенный администратором домена учетной записи Windows 2000. Устанавливать SPN для SQL Server должен администратор домена. Для получения дополнительной информации об утилите setspn, см. документацию по Windows 2000 Resource Kit. Что бы создать SPN для SQL Server 2000, выполните следующую команду: setspn -A MSSQLSvc/Host:port serviceaccount Например: setspn -A MSSQLSvc/server1.redmond.microsoft.com sqlaccountДля делегирования Вы должны использовать сокеты сетевой библиотеки TCP/IP. Вы не можете использовать именованные каналы потому, что адреса SPN есть только у сокета TCP/IP. Если Вы используете несколько портов, Вы должны завести SPN для каждого порта. Вы также можете включить делегирование и для учётной записи Localsystem. SQL Server 2000 сам регистрируется при запуске сервиса и автоматически получает SPN. Эта опция проще, чем предоставление делегирования при использовании учетной записи пользователя домена; однако, когда SQL Server 2000 будет остановлен, для учетной записи Localsystem SPN будет потерян. ПРОДОЛЖЕНИЕ СЛЕДУЕТ Отечественные статьи
Основные компоненты
диаграммы ERwin – сущности, атрибуты, связи. Понятие атрибута
Новые технические статьи Microsoft
Support
Webcast: Microsoft SQL Server: Troubleshooting SQL 2000 Virtual Server and
Service Pack Setups for Failover Clustering
Getting Rid of Excessive Files and Filegroups in SQL Server 7.0/2000 Звуковые файлы докладов на семинаре: "Построение защищенных (безопасных) приложений на базе Microsoft SQL Server 2000"
Самые популярные темы недели
Междумордие
Где
взять ADO
|
#130<< #131 |
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||