Можно ли разрешить пользователю домена A писать на файловом ресурсе домена B без доверительных отношений?

1651
Silthias

В настоящее время я работаю с двумя серверами Windows 2008, каждый из которых работает в совершенно разных доменах без возможности установить доверительные отношения между ними.

То, что мне нужно, чтобы найти способ сделать это иметь службу на «Контроллере домена А», способную записывать на файловый ресурс на «Домене Б».

Я могу подключить диск с контроллера домена A к «домену B» (\\ Folder), используя учетную запись из домена B (Domain_B \ Account). Однако я не могу запустить службу на контроллере домена A под этой учетной записью, так как Domain_B \ Account не может быть аутентифицирована им.

Есть ли способ сделать это, кроме установки разрешений «\\ Папка», чтобы разрешить чтение / запись для EVERYONEучетной записи, что я неохотно делать по очевидным причинам безопасности?

1
Вам придется перепрограммировать службу, чтобы использовать олицетворение или только определенные учетные данные при работе с сервером домена B. Таким образом, он может работать как один пользователь, но взаимодействовать с доменом B как другой. Ƭᴇcʜιᴇ007 10 лет назад 0
Я предполагаю, перепрограммируя службу, вы говорите на уровне кодирования, а не что-то, что может сделать администратор системы? Что касается комментария о конкретных учетных данных, это также будет то же самое, или вы ссылаетесь на другой метод? По сути, у меня нет способа доступа / изменения способа работы службы, только учетная запись, под которой работает служба через services.msc. Silthias 10 лет назад 0
Да, к сожалению, я имел в виду, что вам придется перепрограммировать сервис. Если вы не можете этого сделать, то вы боретесь с безопасностью Windows, пытаясь сделать это любым другим способом, который нацелен на предотвращение такого ненадежного междоменного взаимодействия. Даже добавления группы «Все», вероятно, будет недостаточно, поскольку группа «Все» охватывает только «Все» в домене (или в доверенных доменах). Один домен не будет доверять учетным данным для другого, если вы не предоставите их вручную при необходимости (путем перепрограммирования) или не введете доверие к домену, что, как вы говорите, вы не можете сделать. Ƭᴇcʜιᴇ007 10 лет назад 0
Но кто знает, может быть, у кого-то есть подходящее решение. :) Я просто предупреждаю вас, что вам может не повезти (из моего опыта). Ƭᴇcʜιᴇ007 10 лет назад 0
Блин, я думал, что это может быть так. Я думаю, но надеялся против надежды, что был способ. Благодарю вас. Silthias 10 лет назад 0

1 ответ на вопрос

0
Sam

One solution:

(Note this will not work on a domain controller as they do not differentiate between AD and Local logins on a domain controller)

  1. Create a local user on Computer A ie ComputerA\SharedServiceUser
  2. Create a local user on Computer B with exactly the same username and password ie ComputerB\SharedServiceUser
  3. Set permissions on the share on Computer B for the local user created on ComputerB
  4. Set the service on ComputerA to run as the local user on ComputerA

This works because windows password hashes don't salt. So when the service on ComputerA passes its identity across the network as .\SharedServiceUser with Hash as password it matches the local user identity on ComputerB .\SharedServiceUser

Похожие вопросы