Добрый час хабровчане.
Вопрос решен, но обо всем по порядку.
Ну во-первых:
Поздравляю Шарик, ты балбес
Описанные исходные кейсы выполнялись не на том сервере что нужно, я просто перепутал открытые соединения в открытой SSMS, чтож, тупашить еще никто не отменял.
Теперь о возможных путях решения.
Для гибкости администрирования создал группу доступа в Active Directory, и на нужную шару выдал группе права.
Вариант 1.
Добавил учетную запись компьютера, на котором крутится инстанция MSSQL в группу доступа.
Имя пользователя запускающего службу MSSQL не менял, стандартно он выполняется от Local System.
Результат выполнения резервного копирования базы командой в SSMS: Success
Владелец созданного файла резервной копии на сетевой шаре: учетная запись компьютера
Вариант 2.
Добавил учетную запись доменного пользователя в группу доступа, изменил пользователя от которого запускается инстанция MSSQL на этого же пользователя.
Результат: Success
Владелец созданного файла на сетевой шаре: учетная запись указанного выше доменного пользователя.
З.Ы. При предоставлении доступа с использованием группы, необходимо, чтобы потребитель доступа выполнил релогин в Active Directory. Юзер - логофф, логон; ПК - рестарт. При назначении прав на шару напрямую, релогин не требуется. Как-то игрался с подобным кейсом и не мог понять почему не работает когда все назначено верно.
Для чистоты эксперимента вход на каждую из тестируемых инстанций MSSQL выполнялся с использованием локальной аутентификации SQL, и ясное дело, у такого пользователя не было доступа к используемой сетевой шаре.
Нет. Поскольку SSMS - это клиент, а не сервер, и действия выполняются от имени клиента.
Так что скорее данное предположение ошибочно.
Теперь осталось решить как поступить правильнее в контексте безопасности:
Использовать учетную запись ПК для доступа к шаре, или использовать учетную запись технологического пользователя сервиса MSSQL.
Большое спасибо всем кто не остался в стороне и принял участие в дискуссии.
Средний
Средний
