none
Вопросы по SQL RRS feed

  • Вопрос

  • Коллеги добрый день!

    Вопрос может глупый но значимый для меня. Разворачиваю MSSQL 2017 в домене. От какого пользователя должны быть запущены службы

    Агент SQL Sever

    Ядро СУБД SQL Server

    Программа запуска управляющей программы

    Обозреватель SQL Server

    Я так понимаю это не доменный администратор и не обычный пользователь домена? Или все же оставить запуск от стандартных учетных записей.

    1 февраля 2019 г. 12:16

Ответы

  • Под DBE и Agent разные доменные учетные записи (но это лишь мое мнение).
    А для Browser вы не сможете поменять учетку по умолчанию (local system), да и сам сервис вам нужен только тогда, когда более одного экземпляра SQL в пределах сервера или экземпляр один, но именованный.
    • Помечено в качестве ответа Razor1212007 6 февраля 2019 г. 6:10
    4 февраля 2019 г. 7:46
  • Вам нужно два правила в wf:
    для Browser:
    netsh advfirewall firewall add rule name =
    "SQL Server Browser UDP 1434" dir = in protocol = udp action = allow localport = 1434 profile = DOMAIN

    для BDE (для SQL 2017):
    netsh advfirewall firewall add rule name = "SQL 2017 Database Engine" dir = in program = "%ProgramFiles%\Microsoft SQL Server\MSSQL14.SQL2017\MSSQL\Binn\sqlservr.exe" action = allow profile = DOMAIN

    Статья тут: Configure the Windows Firewall to Allow SQL Server Access
    • Изменено Bernasovsky Eugene 5 февраля 2019 г. 16:52
    • Помечено в качестве ответа Razor1212007 6 февраля 2019 г. 6:10
    5 февраля 2019 г. 16:42

Все ответы

  • Добрый День.

    Посмотрите статью Настройка учетных записей службы Windows и разрешений


    Я не волшебник, я только учусь MCP, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте нажать на кнопку "Пометить как ответ" или проголосовать за полезное сообщение. Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter, YouTube, GitHub, Instagram

    1 февраля 2019 г. 12:24
    Модератор
  • Добрый День.

    Посмотрите статью Настройка учетных записей службы Windows и разрешений


    Я не волшебник, я только учусь MCP, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте нажать на кнопку "Пометить как ответ" или проголосовать за полезное сообщение. Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter, YouTube, GitHub, Instagram


    Virtual Accounts Виртуальные учетные записи (начиная с Windows Server 2008 R2 и Windows 7) — это управляемые локальные учетные записи , которые предоставляют следующие возможности для упрощения администрирования служб. Управление виртуальной учетной записью осуществляется автоматически, и она может получать доступ к сети в среде домена. Если установка SQL Server выполняется со значением по умолчанию для учетных записей служб, используется виртуальная учетная запись с именем, соответствующим имени экземпляра, в формате NT SERVICE\<ИМЯ_СЛУЖБЫ>. Службы, запускаемые от имени виртуальных учетных записей, получают доступ к сетевым ресурсам с использованием учетных данных учетной записи компьютера в формате <имя_домена>\<имя_компьютера>$. При указании виртуальной учетной записи для запуска SQL Server оставьте поле пароля пустым. Если для виртуальной учетной записи не удалось зарегистрировать имя участника-службы (SPN), выполните регистрацию вручную. Дополнительные сведения о регистрации SPN вручную см. в статье Регистрация имени участника-службы для соединений Kerberos.

    Как я понял оставить все как есть, запуск от указанных учетных записей. Или смотрю в книгу вижу фигу.  А как же тогда добавить права SQL сервера  к папке допустим для бэкапов касперского?


    • Изменено Razor1212007 1 февраля 2019 г. 13:45
    1 февраля 2019 г. 13:36
  • Зависит от того, какую задачу вы хотите решить.

    Пример: Есть сервер А и сервер Б. На сервере А установлены два экземпляра SQL под виртуальными учетными записями.

    Задача: Запретить одному из экземпляров SQL доступ к серверу Б.

    1 февраля 2019 г. 13:57
  • Зависит от того, какую задачу вы хотите решить.

    Пример: Есть сервер А и сервер Б. На сервере А установлены два экземпляра SQL под виртуальными учетными записями.

    Задача: Запретить одному из экземпляров SQL доступ к серверу Б.

     Есть сервера А в домене.

    Задача установить SQL сервер,  подключить к нему базы касперского, WSUS, 1C, ,базы другого программного обеспечения.

    Как я понял оптимальным и правильным будет в домене, создать учетную запись обычного пользователя в домене.  И назначить запуск Агент SQLServer и Ядро Субд Sql Server именно от этого пользователя. А запуск обозревателя оставить от Local Service.

    Что скажите?

    • Изменено Razor1212007 4 февраля 2019 г. 6:53
    4 февраля 2019 г. 6:30
  • Под DBE и Agent разные доменные учетные записи (но это лишь мое мнение).
    А для Browser вы не сможете поменять учетку по умолчанию (local system), да и сам сервис вам нужен только тогда, когда более одного экземпляра SQL в пределах сервера или экземпляр один, но именованный.
    • Помечено в качестве ответа Razor1212007 6 февраля 2019 г. 6:10
    4 февраля 2019 г. 7:46
  • Но я бы начал с того, что собрал воедино требования в отношении SQL ко всем продуктам, чьи базы вы намерены держать на конкретном экземпляре.
    4 февраля 2019 г. 7:48
  • Но я бы начал с того, что собрал воедино требования в отношении SQL ко всем продуктам, чьи базы вы намерены держать на конкретном экземпляре.

    А отчего зависят требования. Что можно улучшить? Ведь я устанавливаю стандартную установку, на этапе установки разве можно что то заложить, то что в дальнейшем не поменять?
    4 февраля 2019 г. 15:43
  • Проще же изначально понимать целостную картину, чем потом исправлять. В основном потом можно почти все поменять - но это будет дольше, чем изначально сделать.

    Самое простое - а все ли продукты поддерживают именно 2017 версию? И учесть, что работает и официально поддерживается - это совершенно разные вещи.

    Какая нужна авторизация (windows или mixed), а вдруг нужны какие-то флаги, дополнительные сервисы (full text).

    Collation.

    4 февраля 2019 г. 16:45
  • Проще же изначально понимать целостную картину, чем потом исправлять. В основном потом можно почти все поменять - но это будет дольше, чем изначально сделать.

    Самое простое - а все ли продукты поддерживают именно 2017 версию? И учесть, что работает и официально поддерживается - это совершенно разные вещи.

    Какая нужна авторизация (windows или mixed), а вдруг нужны какие-то флаги, дополнительные сервисы (full text).

    Collation.


    А если базы уже имеются? Я так понимаю мне нужно отсоединить от старого сервера, примонтировать к новому и Переименовать новый сервер.  Так как даже у касперского нет никакого софта по переносу базы. Тот же самый WSUS, тоже я так понимаю по такой технологии работает.  Спасибо за помощь, мало работал с SQL,  а задачи стоят.
    5 февраля 2019 г. 6:32
  • Вы бы в первом посте сразу написали, что нужно сделать и в чем вопрос.

    Перенос баз может осуществляться путем backup на старом месте - restore на новом, либо через detach на старом - attach на новом.

    Кроме баз нужно будет перенести например security (пользоватетелей)

    5 февраля 2019 г. 9:34
  • Вы бы в первом посте сразу написали, что нужно сделать и в чем вопрос.

    Перенос баз может осуществляться путем backup на старом месте - restore на новом, либо через detach на старом - attach на новом.

    Кроме баз нужно будет перенести например security (пользоватетелей)

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

    Задачи 2.

    1.Перенести старые базы в новый SQL Server, поэтому и задавался вопрос по установке SQL какие права давать.

    2. А вторая задача подготовить 2 SQL сервер для работы с самонаписанным софтом и поэтому как таковых требований к серверу нет.  Это как тестовый стенд. 

    А в чем преимущество Под DBE и Agent разные доменные учетные записи?

    И второй вопрос кто должен являться администратором SQL сервера доменная учетная запись DBE или Agent. Или все таки создать 3 учетную запись?

    5 февраля 2019 г. 12:09
  • "они сами автоматически установили права"
    это что-то не понятное

    "перенести старые базы в новый SQL Server"
    тут вроде разобрались

    "в чем преимущество Под DBE и Agent разные доменные учетные записи"
    в безопасности

    "кто должен являться администратором SQL сервера доменная учетная запись DBE или Agent"
    учетные записи сервисов на то и делаются, чтобы ограничить права. Роль sysadmin должны иметь учетные записи тех сотрудников, которые DBA и ни в коем случае не сервисные учетные записи.

    5 февраля 2019 г. 15:45
  • "они сами автоматически установили права"
    это что-то не понятное

    "перенести старые базы в новый SQL Server"
    тут вроде разобрались

    "в чем преимущество Под DBE и Agent разные доменные учетные записи"
    в безопасности

    "кто должен являться администратором SQL сервера доменная учетная запись DBE или Agent"
    учетные записи сервисов на то и делаются, чтобы ограничить права. Роль sysadmin должны иметь учетные записи тех сотрудников, которые DBA и ни в коем случае не сервисные учетные записи.

    В безопасность- Имена входа, добавил пользователя KLadmin (который является администратором Kaspersky Security Center). Захожу в свойство базы, а данному пользователю уже предоставлены права.

    С учетными записями спасибо, объяснили.

    Вопрос еще не совсем мне понятный. При включенном Брэндмауре на сервере База данных не работает Ни касперский ни Система Бэкапов. Они все имеют базу на сервере Бах данных. При отключенном брэндмаур все ок

    1. Что сделал в Configuration Manager добавил 1433 порт

    2. Добавил правило для UDP и TCP 1433 порта в брэндмаур

    3. Но ни SQL Managment Studio не открывается на удаленном ПК, хотя стоит правило разрешать удаленное использование. Ни указанные выше программы не запускаются.

    Отключаю и все ОК.

    5 февраля 2019 г. 16:28
  • Вам нужно два правила в wf:
    для Browser:
    netsh advfirewall firewall add rule name =
    "SQL Server Browser UDP 1434" dir = in protocol = udp action = allow localport = 1434 profile = DOMAIN

    для BDE (для SQL 2017):
    netsh advfirewall firewall add rule name = "SQL 2017 Database Engine" dir = in program = "%ProgramFiles%\Microsoft SQL Server\MSSQL14.SQL2017\MSSQL\Binn\sqlservr.exe" action = allow profile = DOMAIN

    Статья тут: Configure the Windows Firewall to Allow SQL Server Access
    • Изменено Bernasovsky Eugene 5 февраля 2019 г. 16:52
    • Помечено в качестве ответа Razor1212007 6 февраля 2019 г. 6:10
    5 февраля 2019 г. 16:42
  • Вам нужно два правила в wf:
    для Browser:
    netsh advfirewall firewall add rule name =
    "SQL Server Browser UDP 1434" dir = in protocol = udp action = allow localport = 1434 profile = DOMAIN

    для BDE (для SQL 2017):
    netsh advfirewall firewall add rule name = "SQL 2017 Database Engine" dir = in program = "%ProgramFiles%\Microsoft SQL Server\MSSQL14.SQL2017\MSSQL\Binn\sqlservr.exe" action = allow profile = DOMAIN

    Статья тут: Configure the Windows Firewall to Allow SQL Server Access

    Спасибо за помощь. Вы гуру SQL )
    6 февраля 2019 г. 6:10
  • Господа, а почему никто не упомянул про общепринятые практики, рекомендации? Что SQL Server уже давно желательно стартовать на управляемых служебных учетных записях (Managed Service Accounts, MSA)?

    Вот небольшая статья, как это настроить: Управляемые учётные записи служб (Managed Service Accounts)

    Проблема в том что если из-под обычного доменного аккаунта запущена служба, то узнать её пароль довольно просто. А отталкиваясь от того, что учётная запись SQL Server Agent по умолчанию является sysadmin на экземпляре СУБД, получаем неслабую такую дырку в безопасности.

    Что касается портов, то если хотите использовать dedicated admin connection (а вы хотите), то нужно добавить в исключения ещё и 1434 TCP.

    9 февраля 2019 г. 11:51