Дать права на папку сервера рабочей группы локальному пользователю станции домена?
Надобность очень странная, но требуют именно так.
Имеется домен с единственным контроллером на базе Windows Server 2016 (S1).
В этот домен включен сервер Windows Server 2012 (S2), но не как сервер домена, а как обычный компьютер. На этом сервере имеются локальные учётные записи.
Имеется сервер на базе Windows Server 2025 (S3), недоменный (рабочая группа). На этом сервере имеется шара, причём созданная локально (через Общие папки - Общие ресурсы в Управлении компьютером, а не через Файловые службы в Диспетчере серверов).
И вот теперь нужно на эту папку на S3 дать права локальной учётной записи с сервера S2. Вот вывернись на изнанку, а именно так. И при этом ни включение S3 в домен, ни настройку доверительных отношений - не разрешают.
Само собой на S3 при попытке изменения прав доступа к папке (папка - свойства - безопасность - добавить) в списке местоположений (кнопка Размещение в соответствующих окнах) отображается только сам S3, и не отображаются ни S1, ни S2, ни домен. Попытка ввода имени пользователя вручную, в различных вариантах, однозначно наталкивается на "Следующий объект не принадлежит ни одному из доменов, перечисленных в диалоге "Выбор размещения", и поэтому недопустим."
Как полагаете, задача вообще решаема?
UPDATE
Видимо, я не очень чётко сформулировал. Должно быть так:
Во-первых, в Безопасности для папки на S3 указан именно пользователь с S2.
Во-вторых, если пользователь сменил пароль на S2, то вследствие кросс-аутентификации новый пароль применяется и для доступа к шаре, без каких-либо дополнительных синхронизаций.
Я тоже не вижу решения. Но, как обычно, надежда на коллективный разум умирает последней.
Причём хрен бы с им, с назначением прав. Сейчас меня больше всего интересует узкий вопрос - как заставить в списке доступных местоположений появиться местоположению, которое дефолтно даже не сканируется. При этом я совершенно не против установления для этого каких-то дополнительных постоянных подключений, запоминания паролей и пр. - но увы. Попытка, например, создать перманентное подключение с S3 к ресурсу на S2 к появлению S2 в списке не приводит. S3 упорно не желает читать юзеров с S2, хотя даже и знает имя и пароль учётной записи с достаточными для этого правами. А переместить S2 из домена в одну с S3 рабочую группу - нельзя.
Руслан Федосеев, а в домене? какая принципиальная разница-то? были бы права на чтение этой информации, да служба, которая эту информацию отдаст. Проблема как раз в том, что и служба есть, и права есть - ведь апплет локальных пользователей и групп читает эту информацию по щелчку пальцев... в смысле апплет, запущенный на S3 и подключенный читать с S2, с вводом соотв. учётный данных, имеющих на это право, конечно.
Добавьте на сервер с которого к папке будете подключаться пользователя с учетные данными 1в1 как на сервере где папку сделали под которого раздали. Из этого пользователя можно будет заходить на эту общую папку даже не вводя логин/пароль, домен будет использоваться по идее локальный для проверки пользователя
Попробуйте так:
На компах которым нужен доступ в коммандной строке выполните
net use Z: \\192.168.1.6\Share1 P@ssw0dd /User:User1@S3 /Persistent:yes
где
Z: имя будущего сетевого диска
192.168.1.6 - IP сервера S3 (рекомендую именно по IP)
P@ssw0dd - пароль локального пользователя User1 на сервере S3
Вы невнимательно прочитали вопрос. Для доступа к шаре на S3 необходимо использование локальной учётной записи с S2, а не с S3.
Да и не нужно мне постоянного подключения.
TheBigBear, обычно это задница какого-нить большого начальника или бухгалтера требует: "Я ничего не хочу менять в своих привычках, сделайте как я хочу".
TheBigBear, не старайтесь найти логики в этой системе. Я её тоже не нашёл. Но система уже есть такая, как есть, и изменения в неё вноситься не должны (или во всяком случае это далеко за рамками моей компетенции, а убеждать мне тупо лень).
Подключение сетевого диска с сохранением имени пользователя решает задачу. Про постоянное - не постоянное в задаче не было ничего. Имя пользователя сервер должен знать, то есть пользователь у него должен присутствовать как локальный.
RStarun, ещё раз. Ваше решение требует синхронизации локальных пользователей на S2 и локальных пользователей на S3, включая пароли, которые пользователи S2 имеют полное право менять в любой момент. То есть требуется фактически непрерывное обслуживание. В поставленной задаче это НЕ решение.
Akina, решение не требует синхронизации паролей, пользователи S2 могут менять свои пароли как пожелают. Вот на сервере S3 им пароли менять не следует, но они могут этих паролей и не знать.
На всякий случай уточняю механизм. Есть пользователь Ivanov (S2), ему нужно в папку на сервере S3. Создаем пользователя IvanovS3 (на сервере S3). На сервере S2 находясь под учеткой Ivanov подключаем сетевой диск, в настройках подключения пишем "использовать другую учетную запись" вводим данные S3\IVanovS3 и эту запись сохраняем. Сетевой диск теперь доступен пользователю. Он может менять пароль на S2, его учетка никак не повлияет на другую учетку на S3. Чем не решение?
Тем, что вы привязали аутентификацию к сеансу пользователя на S2. Во всём остальном к такой схеме претензий нет. Но она делает совершенно не то, что требуется. Им нужно, чтобы, подключаясь к \\S3\Share, причём НЕ из RDP-сеанса на S2, можно было указать в качестве имени пользователя user@S2, соотв. пароль - и получить доступ в пределах имеющихся прав. А вот эти права дать и не получается.
Даже в теории чтобы этого добиться нужно настраивать в том или ином виде синхронизацию данных о пользователях/некую федеративную связь. Если доступ нужен не с s2, а непосредственно с ПК, то почему на ПК не прописать тот же сетевой диск с подключением от S3\IvanovS3 ?
Даже в теории чтобы этого добиться нужно настраивать в том или ином виде синхронизацию данных о пользователях/некую федеративную связь.
Вот и мне так казалось, что невозможна аутентификация одной учётной записи через доступ от имени другой учётной записи - а без этого никакой косвенной аутентификации не получается.
В общем, шли бы оне лесом. Объявлю задачу нерешаемой, и точка. Не нравится - пусть ищут другого исполнителя. Или расширяют список допустимых действий. Я бы вообще втащил S3 в домен и не парился.
почему на ПК не прописать тот же сетевой диск с подключением от S3\IvanovS3 ?
Первая проблема - этих ПК не одна и не две штуки. Как я где-то говорил - у пользователя есть права на изменение пароля. Соответственно сменил пароль на сервере с шарой - и поскакал по всем компам менять запомненный пароль. Это даже навскидку.
