Сетевой и локальный доступ к ресурсу. ИМHО, принципы правильной организации. Часть 1
Попросили меня изложить собственные рассуждения при назначении сетевого доменного и локального доступа к ресурсу. И я подумал, отчего бы и не здесь? Не стану упоминать реальных имен (доменов) и получится в общем и целом как бы ;)) усреднено для любой сети в среде AD. ))
Если Вы не согласны с мною изложенным (или у Вас есть уточнения, дополнения) - поясните свое мнение в комментарии к.
Исходные данные
Есть некий домен, обзовем его условно - KOV4EG ;)
Компьютеры переведены в домен, а пользователи по-прежнему работают локально (логонятся не в домен, а под локальной учетной записью компьютера).
ОС сетевая MS Windows Server 2012/2008/2003
Домен KOV4EGя работает под управлением AD'2012
ОС локального ресурса (и рабочей станции) - MS Windows 7 Pro
ТРЕБУЕТСЯ:
1. Разобраться с проблемами доступа пользователей друг у к другу, все находятся в одной комнате.
1.2. Почему нет доступа к почтовому ящику внутренней почты?
2. Описать правильное предоставление доступа пользователей к рабочей станции/серверу, когда компьютеры находятся в домене, а пользователи работают локально на своих компьютерах (так называемый локальный доступ, больше характерный для одноранговых сетей)
3. Описать предоставление доступа пользователей к некому доменному сетевому ресурсу (файловый сервер в домене)
4. Как правильно предоставлять доступ в домене (компьютер и пользователь логонятся в домен).
пункты 3 и 4 рассматриваются во 2 части
[Немного теории, о том какие сети бывают и соответственно как в них организован доступ, позаимстованная часть]
--
Немного теории, какие сети есть, часть 1 позаимстованная
(с) http://geek-nose.com/active-directory-dlya-chajnikov/
Active Directory - служба каталогов корпорации Microsoft для ОС семейства Windows NT. Данная служба позволяет администраторам использование групповых политик для обеспечения единообразия настроек пользовательской рабочей среды, установки ПО, обновлений и пр.
В чем суть работы Active Directory и какие задачи она решает?
Принципы организации одноранговых и многоранговых сетей
1. Организация рабочей группы (Workgroup) в одноранговых сетях;
Логическое построение компьютерной сети можно осуществить с помощью 2 подходов:
2. Организация службы каталогов (Active Directory) в клиет-серверных (многоранговых) сетях.
Рассмотрим ситуацию когда имеются 2 рабочие станции - РС1 и РС2, которые объединены между собой, и стоит задача организации предоставления совместных ресурсов.
Эту задачу можно решить двумя способами.
Первый способ - расшарить для всех необходимый ресурс, позволяя таким образом любому пользователю обращаться к ресурсу. Такой способ нам не подходит, ввиду отсутствия элементарного уровня безопасности.
Второй способ - создание на обоих рабочих станциях учетных записей пользователей, которым разрешен доступ к совместным ресурсам. На РС1 помимо учетной записи user1 мы создаем учетную запись user2 c точно таким же паролем, как на РС2, т.е. 54321, а на РС2 учетную запись user2 с паролем 12345.
Таким образом, каждый узел непосредственно выполняет контроль аутентификации и авторизации пользователей - это одноранговая сеть.
На данном этапе все хорошо: проблема авторизации и аутентификации решена - доступ будет разрешен только ограниченному кругу лиц, который мы указали.
Но возникает другая проблема, что если пользователь user2 на РС2 решит изменить свой пароль? Тогда если пользователь user1 сменит пароль учетной записи, доступ user2 на РС1 к ресурсу будет невозможен.
Еще один пример: у нас есть 20 рабочих станций с 20-ю учетными записями, которым мы хотим предоставить доступ к некоему файловому серверу, для этого мы должны создать 20 учетных записей на файловом сервере и предоставить доступ к необходимому ресурсу. А если их будет не 20, а 200?
Как вы понимаете администрирование сети при таком подходе превращается в кромешный ад.
Поэтому подход с использованием рабочих групп подходит для небольших офисных сетей с количеством ПК не более 10 единиц.
При наличии в сети более 10 рабочих станций, рационально оправданным стает подход, при котором одному узлу сети делегируют права выполнения аутентификации и авторизации. Этим узлом и выступает контролер домена - Active Directory (AD).
Контролер хранит базу данных учетных записей, т.е. он хранит учетку и для РС1 и для РС2. Теперь все учетные записи прописываются один раз на контролере, а необходимость в локальных учетных записях теряет смысл.
Теперь, когда пользователь заходит на ПК, вводя свой логин и пароль, эти данные передаются в закрытом виде на контролер домена, который выполняет процедуры аутентификации и авторизации.
После контролер выдает пользователю, осуществившему вход, что-то вроде паспорта, с которым он в дальнейшем работает в сети и который он предъявляет по запросу других компьютеров сетки, серверов к чьим ресурсам он хочет подключиться.
---
[Теория предоставления доступа]
Как предлагает Microsoft, в общем случае, предлагается организовать доступ к ресурсу (R) через создание групп пользователей.
В упрощенном виде,
если пользователь логонится в Active Directory (AD) группы могут быть:
1.Создание группы пользователей в Active Directory
- G - глобальной группой безопасности в рамках конкретного домена;
- LD - локальной в домене, т.е. группа в которую могут входить G-группы доменов, связанных между собою двухсторонними доверительными отношениями;
- U - универсальные, для организации доступа между двумя ветвями разных лесов, не имеющих между собою доверительных отношений;
- GR - группа распространения, как правило, для подписки на некий информационный ресурс по электронной почте.
--
если пользователь логонится в компьютер, а не в AD, есть еще и:
- L - локальная группа, как правило для компьютера, выступающего в роли сервера (ресурса);
Недостатком L-группы является то, что для настройки состава группы необходимо подключаться к этому компьютеру, выступающему в роли сервера ресурса с последующим редактированием ее.
!!!Обращаю Ваше внимание, что для компьютера, подключенного в домен, теоретически - для регулирования группы имеющей доступ к ресурсу компьютера можно было бы применять G-группу в составе домена, но тогда нужно вводить, понятные для всех админов, наименования групп, указывающих, что они используются на неком (конкретном) сервере ресурсов.
zum Beispiel: G_WS0338_Full
Преимущество этого подхода в том, что в этом случае, состав групп регулируется непосредственно в AD, в одном месте :) и не надо каждый раз мучительно вспоминать что, где и как регулируется)))
Пользователь (User) может входит в состав любой из групп.
Рекомендуемая схема назначения доступа к доменному ресурсу:
R -> U <- LD <- G <- G <- User
то есть "расшифровывая":
Ресурс(R) может назначаться для универсальной (U) и/или локальной в домене (LD) группы, в состав которой может включаться группа безопасности (G),- обращаю Ваше внимание - в состав группы безопасности _одного_домена_ может входить другая группа безопасности (G) и/или непосредственно пользователь домена (User)
Для локального доступа
R -> <- G <- G <- User
или
R -> <- L <- User
:) Пока все понятно? ))
Поехали дальше.
Рассмотрим применение политик доступа в конкретных примерах
[Решение и выводы]
1. Разобраться с проблемами доступа пользователей друг у к другу, все находятся в одной комнате.
Проблемы начались после смены пароля локальной учетной записи пользователя, а также смены логина отдельной учетной записи на конкретных компьютерах.
Собственно это и было причиной), а также то, что ж8-) на каждом конкретном компьютере доступ предоставлялся по принципу "как сделали", т.е.
- в одном случае все пользователи комнаты были прописаны на конкретных компьютерах;
- в другом случае доступ к ресурсу предоставлялся группе "опытные пользователи", а каждый локальный пользователь был включен в локальную группу "опытные пользователи" конкретного компьютера;
- в третьем случае (отдельный компьютер) доступ предоставлялся под одной учетной записью локального пользователя данного компьютера.
Как пример - назначения
В комнате всего 5 (пять) компьютеров))
Естественно при смене локальной учетной записи или смене пароля у отдельной учетной записи вся схема благополучно "свалилась".
Не вижу особого смысла выяснять кто конкретно назначал такой вид экзотического доступа, да еще и разные))
Дешевле рассказать как ПРАВИЛЬНО, по-моему в данном случае это сделать
Итак,
смотрим теорию предоставления доступа.
Ресурсу назначается соответствующий доступ не пользователям а, группе пользователей. Т.е. однажды назначив доступ, в дальнейшем достаточно регулировать только состав конкретной группы
1а. Локальный доступ, локальные группы на "сервере" ресурса.
На каждом компьютере отдельно создаются группы L_Read (доступ только на чтение), L_Full (полный доступ), в которые включаются конкретные ДОМЕННЫЕ учетные записи пользователей.
1а_1. Полный доступ
1а_2. Назначение доступа на чтение
Важно понимать, что для того, чтобы пользователи локальный групп могли получать доступ к компьютеру по ЛВС, этим группам должен быть предоставлен групповыми политиками соответствующий доступ. Ведь локальные группы на каждом подобном "сервере" не опубликованы в домене (читайте: не известны домену), и, соответственно никак не охвачены доменной групповой политикой учетных записей.
Поэтому запускаем локальную групповую политику: Пуск / Выполнить.../ gpedit.msc / Ок
И назначаем соответствующим группам права, это тут:
1а_3.
1а_4.
Рекомендуется еще вместо группы "Все" - при доступе из сети, если не предполагается предоставлять его анонимным пользователям (сети) применять группу "Прошедшие проверку" - в этом случае уменьшится сетевой трафик обращения к ресурсу.
Для предоставления доступа на чтения права доступа по сети - достаточно.
Для полного доступа к назначенным папкам и файлам необходимо назначить еще для права = включение соответствующей группы в "Архивация файлов и каталогов" и "Восстановление файлов и каталогов".
Это тут(скриншот ниже указан для другого ресурса и другой группы, но суть - та же):
3. Добавление группы в "Архивация файлов и каталогов"
4. Добавление группы L_Full в "Восстановление файлов и каталогов"
И непременное выполнение на сервере и рабочей станции (чтобы не ждать тайм-аута репликации серверов в сети):
5. Принудительное обновление групповых политик. Аналогичную операцию рекомендуется выполнить и на рабочей станции ;)
Пока - все)
Вопросы?
Если Вы не согласны с мною изложенным (или у Вас есть уточнения, дополнения) - поясните свое мнение в комментарии к.
Исходные данные
Есть некий домен, обзовем его условно - KOV4EG ;)
Компьютеры переведены в домен, а пользователи по-прежнему работают локально (логонятся не в домен, а под локальной учетной записью компьютера).
ОС сетевая MS Windows Server 2012/2008/2003
Домен KOV4EGя работает под управлением AD'2012
ОС локального ресурса (и рабочей станции) - MS Windows 7 Pro
ТРЕБУЕТСЯ:
1. Разобраться с проблемами доступа пользователей друг у к другу, все находятся в одной комнате.
1.2. Почему нет доступа к почтовому ящику внутренней почты?
2. Описать правильное предоставление доступа пользователей к рабочей станции/серверу, когда компьютеры находятся в домене, а пользователи работают локально на своих компьютерах (так называемый локальный доступ, больше характерный для одноранговых сетей)
3. Описать предоставление доступа пользователей к некому доменному сетевому ресурсу (файловый сервер в домене)
4. Как правильно предоставлять доступ в домене (компьютер и пользователь логонятся в домен).
пункты 3 и 4 рассматриваются во 2 части
[Немного теории, о том какие сети бывают и соответственно как в них организован доступ, позаимстованная часть]
--
Немного теории, какие сети есть, часть 1 позаимстованная
(с) http://geek-nose.com/active-directory-dlya-chajnikov/
Active Directory - служба каталогов корпорации Microsoft для ОС семейства Windows NT. Данная служба позволяет администраторам использование групповых политик для обеспечения единообразия настроек пользовательской рабочей среды, установки ПО, обновлений и пр.
В чем суть работы Active Directory и какие задачи она решает?
Принципы организации одноранговых и многоранговых сетей
1. Организация рабочей группы (Workgroup) в одноранговых сетях;
Логическое построение компьютерной сети можно осуществить с помощью 2 подходов:
2. Организация службы каталогов (Active Directory) в клиет-серверных (многоранговых) сетях.
Рассмотрим ситуацию когда имеются 2 рабочие станции - РС1 и РС2, которые объединены между собой, и стоит задача организации предоставления совместных ресурсов.
Эту задачу можно решить двумя способами.
Первый способ - расшарить для всех необходимый ресурс, позволяя таким образом любому пользователю обращаться к ресурсу. Такой способ нам не подходит, ввиду отсутствия элементарного уровня безопасности.
Второй способ - создание на обоих рабочих станциях учетных записей пользователей, которым разрешен доступ к совместным ресурсам. На РС1 помимо учетной записи user1 мы создаем учетную запись user2 c точно таким же паролем, как на РС2, т.е. 54321, а на РС2 учетную запись user2 с паролем 12345.
Таким образом, каждый узел непосредственно выполняет контроль аутентификации и авторизации пользователей - это одноранговая сеть.
На данном этапе все хорошо: проблема авторизации и аутентификации решена - доступ будет разрешен только ограниченному кругу лиц, который мы указали.
Но возникает другая проблема, что если пользователь user2 на РС2 решит изменить свой пароль? Тогда если пользователь user1 сменит пароль учетной записи, доступ user2 на РС1 к ресурсу будет невозможен.
Еще один пример: у нас есть 20 рабочих станций с 20-ю учетными записями, которым мы хотим предоставить доступ к некоему файловому серверу, для этого мы должны создать 20 учетных записей на файловом сервере и предоставить доступ к необходимому ресурсу. А если их будет не 20, а 200?
Как вы понимаете администрирование сети при таком подходе превращается в кромешный ад.
Поэтому подход с использованием рабочих групп подходит для небольших офисных сетей с количеством ПК не более 10 единиц.
При наличии в сети более 10 рабочих станций, рационально оправданным стает подход, при котором одному узлу сети делегируют права выполнения аутентификации и авторизации. Этим узлом и выступает контролер домена - Active Directory (AD).
Контролер хранит базу данных учетных записей, т.е. он хранит учетку и для РС1 и для РС2. Теперь все учетные записи прописываются один раз на контролере, а необходимость в локальных учетных записях теряет смысл.
Теперь, когда пользователь заходит на ПК, вводя свой логин и пароль, эти данные передаются в закрытом виде на контролер домена, который выполняет процедуры аутентификации и авторизации.
После контролер выдает пользователю, осуществившему вход, что-то вроде паспорта, с которым он в дальнейшем работает в сети и который он предъявляет по запросу других компьютеров сетки, серверов к чьим ресурсам он хочет подключиться.
---
[Теория предоставления доступа]
Как предлагает Microsoft, в общем случае, предлагается организовать доступ к ресурсу (R) через создание групп пользователей.
В упрощенном виде,
если пользователь логонится в Active Directory (AD) группы могут быть:
1.Создание группы пользователей в Active Directory
- G - глобальной группой безопасности в рамках конкретного домена;
- LD - локальной в домене, т.е. группа в которую могут входить G-группы доменов, связанных между собою двухсторонними доверительными отношениями;
- U - универсальные, для организации доступа между двумя ветвями разных лесов, не имеющих между собою доверительных отношений;
- GR - группа распространения, как правило, для подписки на некий информационный ресурс по электронной почте.
--
если пользователь логонится в компьютер, а не в AD, есть еще и:
- L - локальная группа, как правило для компьютера, выступающего в роли сервера (ресурса);
Недостатком L-группы является то, что для настройки состава группы необходимо подключаться к этому компьютеру, выступающему в роли сервера ресурса с последующим редактированием ее.
!!!Обращаю Ваше внимание, что для компьютера, подключенного в домен, теоретически - для регулирования группы имеющей доступ к ресурсу компьютера можно было бы применять G-группу в составе домена, но тогда нужно вводить, понятные для всех админов, наименования групп, указывающих, что они используются на неком (конкретном) сервере ресурсов.
zum Beispiel: G_WS0338_Full
Преимущество этого подхода в том, что в этом случае, состав групп регулируется непосредственно в AD, в одном месте :) и не надо каждый раз мучительно вспоминать что, где и как регулируется)))
Пользователь (User) может входит в состав любой из групп.
Рекомендуемая схема назначения доступа к доменному ресурсу:
R -> U <- LD <- G <- G <- User
то есть "расшифровывая":
Ресурс(R) может назначаться для универсальной (U) и/или локальной в домене (LD) группы, в состав которой может включаться группа безопасности (G),- обращаю Ваше внимание - в состав группы безопасности _одного_домена_ может входить другая группа безопасности (G) и/или непосредственно пользователь домена (User)
Для локального доступа
R -> <- G <- G <- User
или
R -> <- L <- User
:) Пока все понятно? ))
Поехали дальше.
Рассмотрим применение политик доступа в конкретных примерах
[Решение и выводы]
1. Разобраться с проблемами доступа пользователей друг у к другу, все находятся в одной комнате.
Проблемы начались после смены пароля локальной учетной записи пользователя, а также смены логина отдельной учетной записи на конкретных компьютерах.
Собственно это и было причиной), а также то, что ж8-) на каждом конкретном компьютере доступ предоставлялся по принципу "как сделали", т.е.
- в одном случае все пользователи комнаты были прописаны на конкретных компьютерах;
- в другом случае доступ к ресурсу предоставлялся группе "опытные пользователи", а каждый локальный пользователь был включен в локальную группу "опытные пользователи" конкретного компьютера;
- в третьем случае (отдельный компьютер) доступ предоставлялся под одной учетной записью локального пользователя данного компьютера.
Как пример - назначения
В комнате всего 5 (пять) компьютеров))
Естественно при смене локальной учетной записи или смене пароля у отдельной учетной записи вся схема благополучно "свалилась".
Не вижу особого смысла выяснять кто конкретно назначал такой вид экзотического доступа, да еще и разные))
Дешевле рассказать как ПРАВИЛЬНО, по-моему в данном случае это сделать
Итак,
смотрим теорию предоставления доступа.
Ресурсу назначается соответствующий доступ не пользователям а, группе пользователей. Т.е. однажды назначив доступ, в дальнейшем достаточно регулировать только состав конкретной группы
1а. Локальный доступ, локальные группы на "сервере" ресурса.
На каждом компьютере отдельно создаются группы L_Read (доступ только на чтение), L_Full (полный доступ), в которые включаются конкретные ДОМЕННЫЕ учетные записи пользователей.
1а_1. Полный доступ
1а_2. Назначение доступа на чтение
Важно понимать, что для того, чтобы пользователи локальный групп могли получать доступ к компьютеру по ЛВС, этим группам должен быть предоставлен групповыми политиками соответствующий доступ. Ведь локальные группы на каждом подобном "сервере" не опубликованы в домене (читайте: не известны домену), и, соответственно никак не охвачены доменной групповой политикой учетных записей.
Поэтому запускаем локальную групповую политику: Пуск / Выполнить.../ gpedit.msc / Ок
И назначаем соответствующим группам права, это тут:
1а_3.
1а_4.
Рекомендуется еще вместо группы "Все" - при доступе из сети, если не предполагается предоставлять его анонимным пользователям (сети) применять группу "Прошедшие проверку" - в этом случае уменьшится сетевой трафик обращения к ресурсу.
Для предоставления доступа на чтения права доступа по сети - достаточно.
Для полного доступа к назначенным папкам и файлам необходимо назначить еще для права = включение соответствующей группы в "Архивация файлов и каталогов" и "Восстановление файлов и каталогов".
Это тут(скриншот ниже указан для другого ресурса и другой группы, но суть - та же):
3. Добавление группы в "Архивация файлов и каталогов"
4. Добавление группы L_Full в "Восстановление файлов и каталогов"
И непременное выполнение на сервере и рабочей станции (чтобы не ждать тайм-аута репликации серверов в сети):
5. Принудительное обновление групповых политик. Аналогичную операцию рекомендуется выполнить и на рабочей станции ;)
Пока - все)
Вопросы?