¿Es posible permitir que un usuario del Dominio A escriba en el recurso compartido de archivos del Dominio B sin una relación de confianza?

Actualmente estoy trabajando con dos servidores Windows 2008, cada uno de los cuales se ejecuta en dominios completamente separados sin posibilidad de establecer una relación de confianza entre ellos.

Lo que necesito para encontrar una manera de hacerlo es tener un servicio en "Controlador de dominio A" capaz de escribir en un recurso compartido de archivos en "Dominio B".

Puedo asignar una unidad del Controlador de dominio A al "Dominio B" (\\ Carpeta) usando una cuenta del Dominio B, (Dominio_B \ Cuenta). Sin embargo, no puedo ejecutar el servicio en el controlador de dominio A bajo esta cuenta ya que Domain_B \ Account no puede ser autenticado por él.

¿Hay alguna manera de hacer esto aparte de configurar los permisos de "\\ Carpeta" para permitir la lectura / escritura de la EVERYONEcuenta, lo cual me resisto a hacer por las obvias razones de seguridad?

— Silthias
fuente

Tendrá que reprogramar el servicio para usar la suplantación, o solo credenciales específicas, al tratar con el servidor de dominio B. De esa manera, puede ejecutarse como un usuario, pero comunicarse con el Dominio B como otro.

— Ƭᴇcʜιᴇ007

Supongo que, al reprogramar el servicio, ¿estás hablando a un nivel de codificación y no es algo que pueda hacer un administrador del sistema? En cuanto al comentario sobre credenciales específicas, ¿sería esto también el mismo o se refiere a un método diferente? Esencialmente no tengo forma de acceder / modificar la forma en que funciona el servicio, solo la cuenta con la que se ejecuta el servicio a través de services.msc

— Silthias

Sí, desafortunadamente quise decir que tendrás que reprogramar el servicio. Si no puede, está luchando contra la seguridad de Windows para intentar hacerlo de otra manera, con el objetivo de evitar este tipo de comunicación no confiable y de dominio cruzado. Incluso agregar el grupo "Todos" probablemente no será suficiente, ya que el grupo "Todos" solo cubre "Todos" en el dominio (o en dominios de confianza). Un dominio no confiará en las credenciales para el otro, a menos que las proporcione manualmente cuando sea necesario (reprogramando) o introduzca una confianza de dominio, lo que dice que no puede hacer.

— Ƭᴇcʜιᴇ007

Pero quién sabe, tal vez alguien tenga una solución utilizable. :) Solo te advierto que quizás no tengas suerte (según mi experiencia).

— Ƭᴇcʜιᴇ007

Maldición, pensé que ese podría ser el caso. Supongo, pero esperaba contra toda esperanza que hubiera un camino. Gracias.

— Silthias

Una solución:

(Tenga en cuenta que esto no funcionará en un controlador de dominio, ya que no diferencian entre los inicios de sesión AD y locales en un controlador de dominio)

Cree un usuario local en la computadora A, es decir, ComputerA \ SharedServiceUser
Cree un usuario local en la computadora B con exactamente el mismo nombre de usuario y contraseña, es decir, ComputerB \ SharedServiceUser
Establezca permisos en el recurso compartido en la Computadora B para el usuario local creado en la ComputadoraB
Configure el servicio en ComputerA para que se ejecute como usuario local en ComputerA

Esto funciona porque los hashes de contraseña de Windows no sal. Entonces, cuando el servicio en ComputerA pasa su identidad a través de la red como. \ SharedServiceUser con Hash como contraseña, coincide con la identidad del usuario local en ComputerB. \ SharedServiceUser

— Sam
fuente