none
Доступ к папкам в windows server 2012 RRS feed

  • Вопрос

  • Здравствуйте.

    Есть сервер 2012 входящей в рабочую группу.На нем созданы пользователи всей рабочей группы.Есть несколько сетевых папок с разграниченным доступом. Проблема в следующем не один пользователь не может зайти не в одну сетевую папку пишет"отсутствует доступ к папке".Если на папку дать доступ группе "Все"то зайти на нее можно и если при этом запретить вход на эту папку конкретному пользователю,то он все равно будет на нее заходить(т.е вход осуществляется под "гостем" а не под конкретным пользователем).Кто знает как осуществляется проверка пользователей на сервер 2012?,потому что на 2003 сервере такая схема работала.

    9 апреля 2013 г. 17:49

Ответы

  • В данном случае если ваша "схема" работала на Win2003, то она будет работать и на Win2012. В данном отношении ничего не изменилось. Смотрите внимательнее кому ставите правило запрета. Правило запрета всегда имеет приоритет перед разрешающими, даже доп. окно выскакивает при установке запрещающих правил с предупреждением. Неважно даже, что гость у вас включён (выключите его!).

    При попытке входа с рабочей станции на сервер в рабочей группе имеет значение только имя пользователя и его пароль. Если связка имя_пользователя-пароль совпадает на клиенте и на сервере, то аутентификация проходит успешно. Имя машины неважно (а вот имя домена имеет значение, но это не ваш случай).  Если при этом на шарке стоит явный запрет для этого пользователя, то доступа не будет. Сервер в рабочей группе может оперировать только с локальными учётными данными, ни про какие WS1\UserX он не знает и права назначить им не сможет. Имеет значение только имя учётной записи.

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

    На сервере выполните: Win+R -> cmd -> compmgmt.msc 

    В дереве выберите пункт  Shared Folders ("Общие папки") -> Sessions (Сессии) и там увидите открытые сессии к шаркам и имена пользователей.

    На проблемном клиенте откройте "менеджер паролей", выполнив команду. Пуск -> выполнить ->  control userpasspasswords2. Вкладка расширенные -> управление паролями. И там ищите сохранённые учётные данные к этому ресурсу.

    P.S. Желательно всё-таки не давать права группе "Все", а создать на сервере специальную группу с названием, отражающим её назначение, и уже туда добавить пользователей которым нужен доступ. Установка запрещающих правил в подавляющем большинстве случаев является необоснованным и в корне неправильным подходом.


    10 апреля 2013 г. 13:51

Все ответы

  • А клиентские ОС какие?

    Включите на сервере аудит событий входа, посмотрите в журнале безопасности что происходит.

    На сколько я понимаю, Вы создали на сервере, входящем в рабочую группу, учётные записи пользователей (например, user1, user2 и т.д.). У Вас получились учётки SERVER\user1, SERVER\user2 и т.д. Но когда пользователь входит на свою рабочую станцию, он заходит с учёткой WS1\user1. Соответственно, получить доступ к разделяемой папке он пытается тоже под этой учёткой - WS1\user1. А на сервере прописано только SERVER\user1. Как Вы понимаете, это разные учётки. Пропишите на папку разрешение для учётки WS1\user1 - должно пустить.


    Сергей Панченко

    10 апреля 2013 г. 4:23
    Отвечающий
  • Мысль хорошая,но как прописать учетку WS1\user1?....все что можно прописать имеет вид server\........

    10 апреля 2013 г. 7:47
  • Мысль хорошая,но как прописать учетку WS1\user1?....все что можно прописать имеет вид server\........

    У меня нет под рукой сервера, не входящего в домен, но, вроде бы, там можно прямо так и написать: WS1\User1.

    Второй вариант: проводить подключение к разделяемой папке по учётной записью, принадлежащей серверу: с рабочей станции откройте папку с разделяемыми ресурсами сервера, в меню по правой кнопки мыши выберите "Подключить сетевой диск...", в открывшемся окне поставьте галку "Использовать другие учётные данные" (при необходимости поставьте и галку "Восстанавливать при входе в систему") и нажмите кнопку "Готово". Появится окно ввода данных учётной записи, тут набирайте SERVER\user1 и пароль этого пользователя.

    PS. Замечу, что если на рабочей станции у пользователя User1 (это будет WS1\User1) поменять пароль, то на сервере пароль пользователя User1 не изменится (это будет SERVER\User1).


    Сергей Панченко



    10 апреля 2013 г. 8:10
    Отвечающий
  • В данном случае если ваша "схема" работала на Win2003, то она будет работать и на Win2012. В данном отношении ничего не изменилось. Смотрите внимательнее кому ставите правило запрета. Правило запрета всегда имеет приоритет перед разрешающими, даже доп. окно выскакивает при установке запрещающих правил с предупреждением. Неважно даже, что гость у вас включён (выключите его!).

    При попытке входа с рабочей станции на сервер в рабочей группе имеет значение только имя пользователя и его пароль. Если связка имя_пользователя-пароль совпадает на клиенте и на сервере, то аутентификация проходит успешно. Имя машины неважно (а вот имя домена имеет значение, но это не ваш случай).  Если при этом на шарке стоит явный запрет для этого пользователя, то доступа не будет. Сервер в рабочей группе может оперировать только с локальными учётными данными, ни про какие WS1\UserX он не знает и права назначить им не сможет. Имеет значение только имя учётной записи.

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

    На сервере выполните: Win+R -> cmd -> compmgmt.msc 

    В дереве выберите пункт  Shared Folders ("Общие папки") -> Sessions (Сессии) и там увидите открытые сессии к шаркам и имена пользователей.

    На проблемном клиенте откройте "менеджер паролей", выполнив команду. Пуск -> выполнить ->  control userpasspasswords2. Вкладка расширенные -> управление паролями. И там ищите сохранённые учётные данные к этому ресурсу.

    P.S. Желательно всё-таки не давать права группе "Все", а создать на сервере специальную группу с названием, отражающим её назначение, и уже туда добавить пользователей которым нужен доступ. Установка запрещающих правил в подавляющем большинстве случаев является необоснованным и в корне неправильным подходом.


    10 апреля 2013 г. 13:51
  •  спасибо.все получилось.

    12 апреля 2013 г. 11:32