У меня SQL Server 2012 работает в среде домена Active Directory. Я установил управляемую учетную запись службы для служб SQL, которые будут выполняться в соответствии с этот документ. Поскольку функциональный уровень моего домена - 2008, это обычный MSA, а не gMSA (группа). Все идет нормально. Проблема в том, что я хочу создать резервную копию баз данных на общем ресурсе UNC. Это не было бы проблемой, если бы служба SQL работала под обычной учетной записью домена, но управляемая учетная запись службы не может писать в общий каталог. Я явно дал разрешение в настройках безопасности для этого общего ресурса, но SQL все равно выдает ошибку при попытке сделать резервную копию. В частности, в сообщении об ошибке говорится:
System.Data.SqlClient.SqlError: не удается открыть устройство резервного копирования \ remoteserver \ Backupshare \ SQLbkup.bak. Ошибка операционной системы 1808 (Используемая учетная запись - это учетная запись компьютера. Используйте свою глобальную учетную запись или локальную учетную запись пользователя для доступа к этому серверу.) (Microsoft.SqlServer.Smo)
[Фактический путь к резервной копии изменен в целях редактирования]
Поиск по сообщению об ошибке дал только нерелевантные результаты. Некоторые дискуссии о технет показывают, что это должен можно дать MSA разрешение на запись в удаленный каталог. Есть идеи, что мне не хватает?
26 апреля 2018 Редактировать:
В моем исходном посте я не упомянул, что конкретная папка, на которую я хочу писать, - это общий ресурс CIFS на устройстве NetApp. Я не упомянул об этом, потому что не думал, что это актуально. Однако, поскольку я продолжал исследовать это и проводить больше тестов, кажется, что это действительно может быть проблема NetApp. В качестве теста я сделал общий доступ на обычной машине с Windows 7 и попытался записать туда свою резервную копию SQL. Это работало, пока я давал разрешение MSA для целевого каталога. Когда я заглянул в журнал безопасности на машине с Windows 7, я увидел, что входящее соединение использует учетные данные MSA, независимо от того, использовал ли я прокси в агенте SQL или нет.
Таким образом, на стороне SQL кажется, что даже если задание запускается от имени администратора домена, фактическая операция записи для файла bak выполняется как управляемая учетная запись службы. Если целью является компьютер Windows в домене, он может принять это входящее соединение. Однако NetApp не может - по крайней мере, с той версией Data ONTAP, которая у нас есть. Так что, похоже, мы в тупике. Тем не менее, спасибо Кэтрин за ваш ответ, который помог мне многому научиться. :)
Ваше задание резервного копирования выполняется как пользователь SQL Agent. Я предполагаю, что агент SQL работает как ваш MSA?
Я сам столкнулся с этим в тестовой среде, и резервное копирование прошло успешно, когда я предоставил учетной записи компьютера сервера доступ к общему ресурсу. Поскольку это была всего лишь тестовая среда, я решил, что этого достаточно. Я не знаю, сработает ли это для вас, или вы захотите продолжить это.
Я полагаю, проблема может заключаться в не назначении MSA SeAssignPrimaryTokenPrivilege. Необходимые привилегии для прокси-серверов SQL Agent являются:
Честно говоря, я ожидал, что не назначая MSA эти привилегии, чтобы задания агента возвращались к учетной записи пользователя MSA, а не к учетной записи компьютера, но ваше сообщение об ошибке и моя тестовая среда предполагают обратное.