У нас есть очень необычная проблема в нашей сети.
Есть два сайта: главный офис (1x сервер SBS 2003 и 20x ПК: смесь Win7 и XP) и удаленный сайт, подключенный через VPN (1x ПК XP, также в том же домене, что и ПК в главном офисе).
В нашем домене существует около 10 групп безопасности, которые используются для предоставления пользователям домена доступа к различным сетевым дискам. В главном офисе все работает как положено.
Однако на удаленном сайте у некоторых пользователей домена возникают серьезные проблемы с сетью, если они становятся членами одной конкретной группы безопасности (называемой «_publicprograms»). Вместо того, чтобы получить Больше доступа (как это происходит на основном сайте с этой группой безопасности), вместо этого они не могут просматривать любой общие ресурсы на сервере (\\ server), если они входят в эту группу безопасности.
Если пользователь затем удаляется из группы безопасности «_publicprograms», выходит из системы на удаленном сайте, а затем снова входит в систему, он снова может просматривать и получать доступ к общим ресурсам на сервере в обычном режиме (оба связаны с безопасностью group и другие, например сетевые принтеры, подключенные к серверу). Эта проблема повторяется на 100%.
Это странно, потому что:
эта проблема не возникает на главном сайте с той же учетной записью пользователя домена, на ПК в том же подразделении, что и ПК на удаленном сайте
в конфигурации этой группы безопасности в AD нет ничего очевидного отличия от любой из других наших групп безопасности
Я бы даже не подумал об этом возможно для членства в группе безопасности, чтобы можно было предотвратить перечисление любых (или всех, в данном случае) общих ресурсов на сервере таким образом. Я не говорю только о том, что пользователь просто отказано в доступе к общим ресурсам (что можно объяснить разрешениями NTFS), но неспособность просто список расшарен на сервере.
Эван: вот собственный результирующий набор политик сервера, как вы просили.
Возможно, вы сможете найти здесь подсказку:
Резюме:
Настройки:
События политики:
Я, наконец, решил эту проблему после того, как поработал над тем, что я считал совершенно не связанной с AD проблемой.
Предыдущий ИТ-специалист создал около 10 совершенно ненужных групп безопасности, некоторые из которых были вложены в другие (во многих было всего 1 или 2 члена). Это был беспорядок, и он показывает, что он делал некоторые ленивые предположения о том, как организация будет использовать свои сетевые диски (что делает невозможным свободный выбор отдельных дисков для предоставления доступа пользователю, поскольку некоторые из них в конечном итоге были объединены). В целом это все еще работало - и приведение в порядок AD не входило в мой список приоритетов (поэтому я до сих пор не удосужился над этим поработать).
На этой неделе реорганизация AD стала более актуальной проблемой после того, как я понял, что новый пользователь был членом группы безопасности, которая была частью цепочки вложенных групп безопасности («groupA» была членом «B», которая была членом « C "и т. Д.), Что в конечном итоге привело к тому, что пользователь получил 2 дополнительных сетевых диска, подключенных при входе в систему, которые они не должны были видеть.
На основном сайте пользователь мог войти в систему как обычно и просто получил доступ к этим дополнительным подключенным дискам и по-прежнему мог просматривать общие ресурсы сервера. На удаленном сайте (возможно, как-то связанном с относительно низкой пропускной способностью сети 3G) пользователь потерял весь доступ к тому же серверу через VPN (согласно моему вопросу), когда он был членом этой единственной группы безопасности. Очень странно, но вы можете понять, почему у меня возникло искушение стереть ОС на рабочей станции в надежде, что это решит проблему.
После почти дня реорганизации разрешений NTFS для раздела данных, реорганизации членства в группах и удаления как можно большего количества лишних групп безопасности (а также обеспечения того, чтобы никакие группы безопасности не были членами других групп - в основном потому, что в этом не было необходимости в этом относительно небольшая организация) проблема, которую я здесь разместил, мгновенно исчезла. Мне даже не приходилось заходить в офис, не говоря уже о перезагрузке ОС на рабочей станции на удаленном сайте - все, что мне нужно было сделать, это удаленно подключиться к серверу и привести в порядок все, что связано с группами безопасности в AD.
Проблема, по всей видимости, возникла из-за комбинации более медленного соединения удаленного сайта (VPN через сотовую сеть 3G) и нескольких вложенных групп безопасности.
Между прочим, прежде чем распутать и упростить наши группы безопасности AD, я также попытался воссоздать проблему на моем домашнем ПК, связав его с офисом через ту же ссылку LogMeIn Hamachi VPN, присоединив его к домену, а затем войдя в систему как проблемную учетную запись. я был неспособный чтобы воссоздать проблему. Моя домашняя сеть снижается на 25 Мбит / с, на 2,5 Мбит / с, поэтому я думаю, что пропускная способность (или задержка) могла быть здесь фактором.
Возможно, мораль этой истории такова: если вы полностью у вас закончились идеи из-за проблемы, которая потенциально может быть связана с разрешениями ... засучите рукава, включите чайник и будьте готовы потратить день на тщательную очистку Active Directory!