Прочее

WindowsNT · Отправлено: **11:00, 19-06-2014** | #11

1. вы же после установки инсталляционные файлы уберёте с компьютера пользователя, не так ли?
2. Оптовые инсталляции делаются другими методами — скриптование, политики, SCCM и прочая.
3. А что будет, если попадёт в лапы?

Короч, если инсталляции будут лежать на другом сервере, net use работать будет. А так, как вы хотели изначально, — не будет.

mcmurphy · Отправлено: **13:47, 23-06-2014** | #12

Добрый день!
Спрошу тут, чтобы не плодить темы.
Есть тестовая сеть: КД, пару серверов и раб станция. Серверы под вин 2008 р2.
Прямо на КД были 2 расшаренные папки (сделал по-быстрому, потестировать права доступа). Сетевой доступ - Пользователи домена: чтение, изменение. Доступ НТФС - создатель-владелец, система, группа доменных пользователей чтение и выполнение, администраторы: полный доступ. Группу "Пользователи" из списка доступа удалил.
Один из серверов вывожу из домена (имя рабочей группы не совпадает с именем домена), потом переименовываю комп, перезагружаюсь. Чисто случайно решил с него зайти на КД, и что интересно - пустило. Более того, пускает в эти две папки, и дало удалить файлы.
Сразу подумал, про совпадение имени админской учетки и паролей и там и там. После смены пароля на этом уже не-доменном сервере при подключении стало спрашивать пароль.
Непонятно - почему пускало после вывода из домена?

El Scorpio · Отправлено: **05:20, 30-06-2014** | #13

Цитата mcmurphy:

Сразу подумал, про совпадение имени админской учетки и паролей и там и там. После смены пароля на этом уже не-доменном сервере при подключении стало спрашивать пароль. »

Совпадение логина и пароля локальной учётной записи (админа) с одной из учётных записей домена.
Во избежание подобного нужно указывать другие пароли локальным профилям администраторов.

Цитата mcmurphy:

имя рабочей группы не совпадает с именем домена »

имя рабочей группы ни на что не влияет.

mcmurphy · Отправлено: **21:59, 02-07-2014** | #14

Ок, спасибо! То, что пароли совпадали - я на это и подумал, совет хороший.
Я думал, что контроллер домена (домен) должен сам себя защищать, от пользователей НЕ домена. Ведь учетки компа из рабочей группы в АД нет... Оказывается, это не защита.

El Scorpio · Отправлено: **02:04, 03-07-2014** | #15

Цитата mcmurphy:

Ведь учетки компа из рабочей группы в АД нет. »

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

А доступ к файлам в основном определяется списком пользователей. Более того, любую сетевую папку можно подключить с компьютера, используя логин вида "domain\username". Разве что это не прокатит при работе в сеансе доменного пользователя, потому что система не позволит одновременные подключения от имени разных пользователей (будет активным только подключение от пользователя домена, вошедшего в систему).
Зато пользователи компьютеров вне домена (а также локальные пользователи доменных компьютеров) легко могут использовать сетевые папки сервера.

Самая очевидная возможность ограничить использование доменных профилей со "сторонних" компьютеров - задать в параметрах пользователя перечень компьютеров, с которых может быть осуществлён вход в систему.
Но и здесь засада - перечень использует символьные имена NETBIOS, а значит:
1) для каждого пользователя нужно будет перечислять вручную все дозволенные компьютеры (в пределах отдела и т.д.)
2) после переименования компьютера придётся вручную править параметры.
3) злоумышленник может назначить своему компьютеру такое же имя (и доменный суффикс) без ввода компьютера в домен.

Если более опытные товарищи опишут лучшие способы ограничения безопасности (с привязкой объектов доменных пользователей к объектам доменных компьютеров), скажу им "большое спасибо"

Iska · Отправлено: **08:10, 03-07-2014** | #16

Цитата El Scorpio:

Вообще-то "учётки компов" используются очень редко. »

При развёртывании приложений посредством GP в режиме «на машину».

El Scorpio · Отправлено: **09:44, 03-07-2014** | #17

Цитата Iska:

При развёртывании приложений посредством GP в режиме «на машину». »

Об этом я и писал - когда нужно автоматически установить приложение не на всё "подразделение домена" в целом, а на отдельные компьютеры (или группу компьютеров), или как-то иначе ограничить применение групповых политик.

lxa85 · Отправлено: **10:17, 03-07-2014** | #18

Размышления фоново вслух.
Если MS что-либо придумает, чтобы ограничить вход на ресурсы домена только с компьютеров включенных в домен, то:

Что на по этому поводу говорит протокол kerberos ?
Что делать с другими OS? Маки, Линуксы?
Не получим ли мы обратный эффект? BYOD (BYOT, BYOP, BYOPC). Когда пользователь принес собственное устройство (телефон, ноутбук), и хочет получить доступ к доменным ресурсам из-под своей (легальной, белой и пушистой учетной) записи, а мы ему кукиш в морду?

WindowsNT · Отправлено: **11:21, 03-07-2014** | #19

1. Перечисление имён касается только интерактивного логона. Но не сетевого. Ессно, безопасность не увеличивает.
2. С чем боремся вообще? С тем, что злоумышленник подключил к сети свой компьютер, затем с него логонится на контроллер? Как насчёт начать бороться с физическими подключениями?
3. IPSec Domain Isolation может оказаться единственным ответом. Но начинающие не потянут.

Iska · Отправлено: **11:22, 03-07-2014** | #20

Цитата El Scorpio:

Об этом я и писал - когда нужно автоматически установить приложение не на всё "подразделение домена" в целом, а на отдельные компьютеры (или группу компьютеров), или как-то иначе ограничить применение групповых политик. »

Неа. Вы писали про другое. Я же — про то, что без раздачи права доступа к разделённому ресурсу, содержащему административные пакеты, на группу безопасности «компьютеры домена» (или как оно там) — система на этих компьютерах не получит доступ к этим пакетам.