Дано:
Доменная сеть.
На сервере1 крутится сервис. На сервере2 имеется шара, доступ к которой должен получить сервис на сервере1.
Сервис запущен под системным аккаунтом, соответственно в домене он не авторизован и к шаре доступа не имеет.

Решения:
1. Коллега посоветовал запустить сервис от имени доменного юзера, имеющего доступ к шаре, и все будет ок. (из соображений безопасности я выбрал второй вариант решения)
2. В нужный момент авторизовать сервис в домене (типа вот такой колбасой кода) пользователем, имеющим доступ к шаре, сделать нужные дела и разлогиниться.

Есть ли еще варианты решения?
Без использования апишных вызовов как в варианте 2, а только средствами фрейморка.

Здравствуйте, Muxa, Вы писали:

M>Дано:
M>Доменная сеть.
M>На сервере1 крутится сервис. На сервере2 имеется шара, доступ к которой должен получить сервис на сервере1.
M>Сервис запущен под системным аккаунтом, соответственно в домене он не авторизован и к шаре доступа не имеет.

M>Решения:
M>1. Коллега посоветовал запустить сервис от имени доменного юзера, имеющего доступ к шаре, и все будет ок. (из соображений безопасности я выбрал второй вариант решения)
M>2. В нужный момент авторизовать сервис в домене (типа вот такой колбасой кода) пользователем, имеющим доступ к шаре, сделать нужные дела и разлогиниться.

M>Есть ли еще варианты решения?
M>Без использования апишных вызовов как в варианте 2, а только средствами фрейморка.

А [в] чем, по-твоему, второй вариант безопаснее первого?

Здравствуйте, Muxa, Вы писали:

M>Есть ли еще варианты решения?

При наличии Active Directory дать лоступ к шаре компьютеру, на котором работает сервис.

M>Без использования апишных вызовов как в варианте 2, а только средствами фрейморка.

Ну обращаться к API всё равно придётся, если не напрямую, то через фреймворк.

Есть ещё вариант через SSPI, но там тоже API, и кода, пожалуй, даже поболее, зато никаких привилегий не нужно. Хотя в случае сервиса это последнее не актуально.

Впрочем, вероятно, к SSPI можно получить доступ через NegotiateStream, связав два экземпляра прямо внутри приложения и задав имперсонацию, но кода вряд-ли получится меньше.

В 4-м фреймворке появилось довольно много новых классов, связанных с безопасностью, может там что найдётся.

_FR>А [в] чем, по-твоему, второй вариант безопаснее первого?

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

Здравствуйте, Muxa, Вы писали:

_FR>>А [в] чем, по-твоему, второй вариант безопаснее первого?

M>я вот второй раз подумал и уже не совсем согласен со своими словами.
M>раньше полагал что, что бы сервис можно было запустить от имени другого пользователя, этот другой пользователь должен быть локальным админом. не?
M>соотв. если весь код сервиса выполняется под этим пользователем можно натворить делов.
M>еще меня смущало то что, необходимо помнить что запуск сервиса необходимо делать не от имени системного аккаунта.

Вовсе не обязательно. Можно специально для данного сервиса создать ограниченного во всём, что не нужно и при этом со всеми необходимыми правами пользователя, который будет ходить только туда, куда дозволено и делать ровно то, что разрешено.

Во втором же случае кому-то может стать известным пароль и пользователь, которые имеют определённые привелегии.

Здравствуйте, Muxa, Вы писали:

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

Достаточно иметь право входа в качестве службы.

M>соотв. если весь код сервиса выполняется под этим пользователем можно натворить делов.
M>еще меня смущало то что, необходимо помнить что запуск сервиса необходимо делать не от имени системного аккаунта.

А если будет работать от LocalSystem, то "натворить делов" ему будет ещё проще LocalSystem по умолчанию имеет все права локальных администраторов плюс обладает привилегиями, которых по умолчанию нет даже у админов.

JR>А если будет работать от LocalSystem, то "натворить делов" ему будет ещё проще LocalSystem по умолчанию имеет все права локальных администраторов плюс обладает привилегиями, которых по умолчанию нет даже у админов.

Кстати, кроме LocalSystem имеются ещё встроенные учётки LocalService и NetworkService, отличаются разными комбинациями сетевых и локальных прав. В MSDN есть их описание.

Здравствуйте, Muxa, Вы писали:

M>Дано:
M>Доменная сеть.
M>На сервере1 крутится сервис. На сервере2 имеется шара, доступ к которой должен получить сервис на сервере1.
M>Сервис запущен под системным аккаунтом, соответственно в домене он не авторизован и к шаре доступа не имеет.

Поднять на втором сервере FTP как вариант не рассматривали?