1 — When a user logs on to a computer, the Local Security Authority (LSA, a part of the Local Security Authority Subsystem) generates an access token that represents the user's security context. The access token consists of unique security identifiers (SID) for every group that the user is a member of. These SIDs include transitive groups and SID values from SIDHistory of the user and the group accounts.
И перевыпустить это токен можно только путем манипуляций со стороны клиента. Ко всему прочему, нужно дропать и переустанавливать все существующие соединения. Фактически — помогает только логоф-логон, что в середине дня делать крайне неудобно.
С AD две проблемы:
1 — обновление вектора пользователя, при добавлении/исключении в группы
2 — ограничение на членство в группах в 1020 штук. Мы реально в это упёрлись
Согласен, что система нетривиальная. Пока всё достаточно прозрачно, но, конечно, может и разрастись в неподъемного монстра. Именно поэтому мы решили, что добавление функционала проводиться не будет, только багфикс. Можно, конечно, перепилить ее с внутренней базы на кастомные поля в AD, но кмк это только всё усложнит. Если все понимают риски на входе и готовы их нести — почему нет? Ну и, конечно, везде своя специфика.
Понимаю, что жуткий некропостинг, но, возможно, кому-то пригодится.
В очередной раз переделывали свою систему управления правами и придумалось ( и сделалось) такое решение:
— на *nix системе генерится дерево неизменяемых каталогов для каждого пользователя на основании списка доступных ему проектов. В нашем случае это легко — уровни вложенности с 1 по N в нашей архитектуре статичны и изменяются только через админку;
— на N+1 уровне вложенности линкуются папки проектов из существующего Windows-файлового хранилища;
— на том же *nix сервере создается параметризованная по имени пользователя smb-шара, которая ведет его к персональному дереву каталогов.
Что достигаем таким образом:
1. Доступ пользователя к файлам теперь не зависит от AD групп, а только от групп в «админке». Таким образом, изменения доступа можно отрабатывать мгновенно;
2. Нет необходимости применять группы доступа к результирующим папкам в хранилище;
3. Сохраняются пути к файлам «как раньше», т.е. нет необходимости править ярлыки пользователям, переход на новую систему проходит абсолютно прозрачно, можно обмениваться путями к файлам в почте — если доступ к каталогу есть, то путь одинаков для всех пользователей, что UNC, что через примапленый диск;
4. В силу того, что софт построения дерева каталогов рисует только те папки, куда у пользователя есть доступ, то ликвидирован косвенный источник утечки — раньше, если даже не было доступа, пользователь видел имя папки (а она как правило называлась по имени клиента или пордукта)
5. Не ломая старую структуру хранения данных на Windows, получаем все преимущества мониторинга от *nix
Есть, конечно, и минусы, но в нашем случае, плюсы их существенно перевесили.
>>Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
В бизнесе моей организации такое — сплошь и рядом. Обычно это, конечно, не 5-й уровень, но второй-третий — запросто.
Имеем проектную группу — 1й уровень. В проектной группе — проект — 2й уровень. Внутри проекта — идет деление по папкам — ТЗ, переписка с клиентом, калькуляция и т.п. — 3й уровень. Для каждой папки — свои права. В ТЗ имеют дополнительный доступ, например, юристы, в документацию — нормативщик и т.д. Это не реальный слепок, но общую ситуацию вполне характеризует.
Меня к использованию групп для траверсов подтолкнула особенность распространения прав в Windows — даже в случае применения прав «только на эту папку», система все равно норовит обежать все дерево поддиректорий. А дерево зачастую настолько велико, что назначение прав может занимать до часа.
Подозреваю, что изобретаю велосипед, но, чтобы избежать подобного, надо в каком-то автоматическом режиме создавать группы AD и назначать права _при создании_ папки на сервере. Боюсь даже представить, насколько вырастет база AD при таком подходе, и как эффективно отслеживать удаление папок и т.д.
Мне кажется, важно понимать, что эффективную систему документооборота на таких средствах сделать невозможно. В нашей компании, например, достаточно жестко (в том числе и в связи с требованиями ISO) ограничена структура контролируемых папок, поэтому достаточно эффективно удается работать с разрешениями на папки.
Если есть идеи/механизмы более оптимального отслеживания/переназначения — маякните и мне. Было бы очень полезно, достаточно много времени уходит на ручную работу с правами на папки.
Статья интересная и полезная. Реализовал в сети примерно то же самое.
Вижу существенный недостаток — необходимость прописывать КАЖДЫЙ раз права на траверс директорий при изменении доступов в нижних уровнях.
Тогда как гораздо удобнее один раз создать группу FILE-путь-TR с правами траверса и включать в нее все необходимое. Возможно, в вашей сети это обусловлено какими-либо дополнительными требованиями, но мне это существенно облегчило жизнь.
Что я еще реализовал в своей сети — это группы с запретом доступа. Считайте это паранойей, но у меня все shared-accounts, да и просто пользователи, которым нечего делать на этом ресурсе, внесены в них. И на каждом ресурсе таким группам запрещено любое действие. На всякий случай. Если у кого-то из админов AD рука дрогнет.
Резюмирую — в своей сети я на каждую папку навешиваю 4 группы доступа (за исключением описанных автором редких групп с неспецифическими правами) — это FILE-...-RO, FILE-...-RW, FILE-...-NA, FILE-...-TR в терминологии статьи. Не уверен, что это идеальный способ, но позволяет решить 99% возникающих у меня задач с разграничением доступа.
И перевыпустить это токен можно только путем манипуляций со стороны клиента. Ко всему прочему, нужно дропать и переустанавливать все существующие соединения. Фактически — помогает только логоф-логон, что в середине дня делать крайне неудобно.
2 — так это не работает, увы
support.microsoft.com/en-us/help/328889/logging-on-a-user-account-that-is-a-member-of-more-than-1010-groups-ma
Да и если бы работало — членство, все равно, было бы неочевидно. Та же внешняя база, только с другого ракурса.
С AD две проблемы:
1 — обновление вектора пользователя, при добавлении/исключении в группы
2 — ограничение на членство в группах в 1020 штук. Мы реально в это упёрлись
Согласен, что система нетривиальная. Пока всё достаточно прозрачно, но, конечно, может и разрастись в неподъемного монстра. Именно поэтому мы решили, что добавление функционала проводиться не будет, только багфикс. Можно, конечно, перепилить ее с внутренней базы на кастомные поля в AD, но кмк это только всё усложнит. Если все понимают риски на входе и готовы их нести — почему нет? Ну и, конечно, везде своя специфика.
В очередной раз переделывали свою систему управления правами и придумалось ( и сделалось) такое решение:
— на *nix системе генерится дерево неизменяемых каталогов для каждого пользователя на основании списка доступных ему проектов. В нашем случае это легко — уровни вложенности с 1 по N в нашей архитектуре статичны и изменяются только через админку;
— на N+1 уровне вложенности линкуются папки проектов из существующего Windows-файлового хранилища;
— на том же *nix сервере создается параметризованная по имени пользователя smb-шара, которая ведет его к персональному дереву каталогов.
Что достигаем таким образом:
1. Доступ пользователя к файлам теперь не зависит от AD групп, а только от групп в «админке». Таким образом, изменения доступа можно отрабатывать мгновенно;
2. Нет необходимости применять группы доступа к результирующим папкам в хранилище;
3. Сохраняются пути к файлам «как раньше», т.е. нет необходимости править ярлыки пользователям, переход на новую систему проходит абсолютно прозрачно, можно обмениваться путями к файлам в почте — если доступ к каталогу есть, то путь одинаков для всех пользователей, что UNC, что через примапленый диск;
4. В силу того, что софт построения дерева каталогов рисует только те папки, куда у пользователя есть доступ, то ликвидирован косвенный источник утечки — раньше, если даже не было доступа, пользователь видел имя папки (а она как правило называлась по имени клиента или пордукта)
5. Не ломая старую структуру хранения данных на Windows, получаем все преимущества мониторинга от *nix
Есть, конечно, и минусы, но в нашем случае, плюсы их существенно перевесили.
Это даже официально называется макет (или mock-up)
В бизнесе моей организации такое — сплошь и рядом. Обычно это, конечно, не 5-й уровень, но второй-третий — запросто.
Имеем проектную группу — 1й уровень. В проектной группе — проект — 2й уровень. Внутри проекта — идет деление по папкам — ТЗ, переписка с клиентом, калькуляция и т.п. — 3й уровень. Для каждой папки — свои права. В ТЗ имеют дополнительный доступ, например, юристы, в документацию — нормативщик и т.д. Это не реальный слепок, но общую ситуацию вполне характеризует.
Заранее спасибо.
Подозреваю, что изобретаю велосипед, но, чтобы избежать подобного, надо в каком-то автоматическом режиме создавать группы AD и назначать права _при создании_ папки на сервере. Боюсь даже представить, насколько вырастет база AD при таком подходе, и как эффективно отслеживать удаление папок и т.д.
Если есть идеи/механизмы более оптимального отслеживания/переназначения — маякните и мне. Было бы очень полезно, достаточно много времени уходит на ручную работу с правами на папки.
Вижу существенный недостаток — необходимость прописывать КАЖДЫЙ раз права на траверс директорий при изменении доступов в нижних уровнях.
Тогда как гораздо удобнее один раз создать группу FILE-путь-TR с правами траверса и включать в нее все необходимое. Возможно, в вашей сети это обусловлено какими-либо дополнительными требованиями, но мне это существенно облегчило жизнь.
Что я еще реализовал в своей сети — это группы с запретом доступа. Считайте это паранойей, но у меня все shared-accounts, да и просто пользователи, которым нечего делать на этом ресурсе, внесены в них. И на каждом ресурсе таким группам запрещено любое действие. На всякий случай. Если у кого-то из админов AD рука дрогнет.
Резюмирую — в своей сети я на каждую папку навешиваю 4 группы доступа (за исключением описанных автором редких групп с неспецифическими правами) — это FILE-...-RO, FILE-...-RW, FILE-...-NA, FILE-...-TR в терминологии статьи. Не уверен, что это идеальный способ, но позволяет решить 99% возникающих у меня задач с разграничением доступа.