Isilon : Управління правами спільного використання ISILON SMB.

Існують різні методи створення та управління PowerScale: Спільне використання та дозволи Isilon SMB.

Спершу нам потрібно зрозуміти основи того, як працює доступ користувача МСП або групи в Windows-середовищі.
Існує 2 типи дозволів при роботі з спільним сегментом SMB - 

• Дозвол на рівень поділу.
• NTFS або дозвіл на рівні папки.

Наведені нижче умови мають бути виконані для користувача доступу до спільного використання -

• Користувач, який намагається отримати доступ до спільного доступу, повинен бути частиною ACL на рівні NTFS, а також бути членом списку дозволів доступу до спільного використання.
• Користувач може бути або прямим записом у ACL та спільній частці, або бути членом групи, яка входить до ACL і спільної частки.
• Доступ до користувача визначається шляхом об'єднання NTFS та дозволів на спільне використання. Завжди застосовується найобмежувальніший дозвіл до користувача.

Розглянемо приклад, де користувач Джон, який також є членом групи доменів app_team намагається отримати доступ до спільного пакету малого та середнього бізнесу.
Нижче наведено деякі поширені сценарії щодо вибору доступу до спільного використання — 

Дозволи на спільне використання розглядаються першими для Access. 
Наведені вище приклади показують, що в кожному випадку найобмежувальніший доступ застосовується шляхом поєднання дозволів на рівні спільного використання та NTFS.
Однак є один виняток — коли ми застосовуємо дозвіл «Run as Root» на рівні спільного використання до будь-якого користувача або групи. Це налаштування фактично перекладає користувача або групу на кореневого користувача Isilon, тим самому надаючи цьому користувачу або групі кореневі права.

Тепер ми розглянемо різні способи управління акціями МСП на Isilon.

Використання Windows File Explorer для користувацьких зон доступу —
У цьому розділі йдеться про управління спільними ресурсами та дозволами SMB через Windows File Explorer.
Перший крок у управлінні спільними ділянками SMB — створити адміністративний спільний ресурс у базовому каталогу зони доступу.

*ЦЕ ПОРАДИ З ДИЗАЙНУ ДЛЯ КЛІЄНТА, ЯКІ НЕ СЛІД РЕАЛІЗУВАТИ TSE*

           Ми можемо створити базовий каталог зони будь-яким із наступних способів -  

1. Позначте стандартний /ifs спільний файл з обліковими даними адміністратора та створіть базовий каталог зони, необхідний для зони доступу.
   • Наприклад —
   • Якщо abc-ex.com\\john є адміністратором домену, і нам потрібно створити HR зони доступу з базовим каталогом зони /ifs/isi_prod/HR тоді 
   • Відкладіть карту за замовчуванням /ifs ділитися через IP у системній зоні доступу за допомогою abc-ex.com\\john 's Документи.
   • Створіть /ifs/isi_prod/HR Довідник.
   • Адміністратор домену тепер буде власником /ifs/isi_prod/HR Дерево каталогів і матиме повний контроль над зміною або призначенням нових дозволів іншим користувачам або групам.
2.  Якщо ми створюємо базовий каталог зони за допомогою WebUI або CLI OneFS, то користувач входу отримує права на структуру каталогу. Зазвичай адміністратори використовують root-користувача для входу, і тому root отримує права NTFS.
   • Але якщо у нас налаштований RBAC так, щоб адміністратори були частиною ролей SecurityAdmin і SystemAdmin, тоді користувач-адмін може увійти у WebUI зі своїми доменними обліковими даними і скористатися опцією за замовчуванням "Create zone base directory if it does not exist" у вікні створення зони доступу або створіть структуру каталогу з File System -> File System Explorer.
   • Якщо ви використовуєте CLI, виконайте команду mkdir для створення структури каталогу або використовуйте --create-path при створенні команди створення зони доступу.
   • Примітка. Якщо ми використовуємо цей метод для створення каталогу, він отримає дозволи POSIX. Нам потрібно буде успадкувати адміністративного користувача або групу для підкаталогів, запустивши команду - chmod +a user/group domain\\user/group allow object_inherit,conatiner_inherit <zone-base-directory-path>

•  Після створення базового каталогу зони створіть прихований адміністративний ресурс через WebUI OneFS або через CLI

• Поділитися адміністратором - app$
• Частка для забезпечення - app-p1 (/ifs/isi-prod/apps/app-p1)
• Груповий доступ - xyz-ex\fe-apps
• Зона доступу - Apps 
• Базовий каталог - /ifs/isi-prod/apps
• Адмін - xyz-ex.com\adm_john91
  • Відкладіть карту app$ ділитися через обліковий запис adm_john91 адміністратора та ім'я IP або SC зони в зоні доступу додатків.
  • Створіть папку «Поділитися» /ifs/isi-prod/apps/app-p1. 
  • Клацніть правою кнопкою миші по папці app-p1: Властивості —> Безпека —> Редагування —> Додайте fe-додатки з необхідним доступом до списку.
• Тепер ми можемо створити частку app-p1 з xyz-ex.com\fe-apps у списку дозволів і у папці /ifs/isi-prod/apps/app-p1 через Isilon WebUI або CLI.

Використання Провідника файлів Windows для системної зони -
 

• Довідник бази зон /ifs оскільки зона доступу до системи вже існує.
• Дозвіл NTFS на /ifs Directory за замовчуванням передбачає, що всі читають, записують і виконують.
• Це можна видалити, і лише адміністраторам можна присвоїти дозволи, виконавши наведені нижче команди - 
  • chmod -a Everyone allow  dir_gen_read,dir_gen_write,dir_gen_execute,delete_child /ifs
  • chmod +a user/group domain\\user/group allow dir_gen_all,object_inherit,container_inherit /ifs

• Ми можемо приховати стандартний shareshare ifs і призначати лише необхідних адміністраторів домену до списку дозволів на спільне використання.

Використовуючи "Run as Root" Дозвіл

на спільне використання SMB Вищенаведені розділи добре працюють, якщо ми налаштовуємо нову PowerScale: Кластер Isilon, але якщо у нас вже є існуючий PowerScale: В Isilon, де адміністратори не контролюють дерево каталогів, єдиний спосіб змінити дозволи — це через CLI, увійшовши як корінь або присвоївши дозвіл

на спільний ресурс Run-as-Root.У PowerScale є опція: Акції Isilon SMB для призначення "run-as-root" дозволу, коли цей дозвіл присвоюється користувачу або групі, ця сутність буде відтворена з кореневим користувачем Isilon, який надає цьому користувачу кореневі права.

Ми розглянемо той самий приклад для створення спільного використання даних із наведеними нижче вимогами - 

• Частка для забезпечення - app-p1 (/ifs/isi-prod/apps/app-p1)
• Груповий доступ - xyz-ex\fe-apps 
• Адмін - xyz-ex.com\adm_john91
  • Створіть спільний ресурс через Isilon WebUI та призначте адміністратора xyz-ex\adm_john91 the run-as-root Дозвіл і виберіть "Create SMB share directory if it does not exist".
  • Створений спільний файл тепер матиме root-прави для облікового запису адміністратора.
  • Адміністратор тепер може віднести спільний ресурс через Windows File Explorer і призначати доменну групу xyz-ex.com необхідні дозволи.
  • Ми також можемо призначити групу xyz-ex.com\fe-apps the run-as-root Дозвол, але це не рекомендується, оскільки група матиме кореневі привілеї для спільного каталогу та всіх його підкаталогів.

Використання управління комп'ютерами

WindowsЧастку можна створити та керувати через MMC управління комп'ютером.

Якщо адміністратор має керувати спільними ресурсами SMB через MMC управління комп'ютером, цей користувач має бути членом локальної групи адміністраторів зони доступу.
Потрібно виконати наведені нижче кроки, щоб додати користувача або групу адміністратора домену до локальної групи адміністраторів.

• Відкрийте Isilon WebUI, натисніть Access -> Членство та ролі.
• Виберіть зону доступу зі списку поточних зон доступу.
• Натисніть на Групи та виберіть LOCAL:System для провайдерів. 
• Натисніть на Перегляд/Редагувати для групи адміністраторів, Редагувати групу -> Додати учасників.

Тепер ми можемо підключатися до облікових даних користувачів адміністратора через консоль Computer Management MMC.

• Увійти в систему через обліковий запис, який був доданий до локальної групи адміністраторів на попередньому кроці.
• Пошук і відкриття Computer Management у рядку пошуку Windows.
• Натисніть на Дія -> Підключитися до іншого комп'ютера
• Розгорніть спільні папки.
• Клацніть правою кнопкою миші по спільних папках і натисніть «Новий поділитися».
• Пройдіть через майстер створення спільного контенту, щоб створити нову спільність.

Ми також можемо керувати дозволами на спільне використання та NTFS вже існуючих ресурсів через ту ж консоль.

Загальні міркування щодо призначення дозволів на спільне використання 

• Зазвичай корисно призначати групові дозволи на рівні спільного використання та NTFS, а також контролювати доступ користувачів шляхом зміни членства в групі.
• Наприклад — 
• Розглянемо, що у кластері є 2 робочі процеси додатків, які знаходяться у власних зонах доступу: App1 і App2.
• Каталог бази зони App1 : /ifs/isi-prod/app1
• Каталог бази зони App2 : /ifs/isi-prod/app2
• Адміністраторський обмін для App1 : app1$
• Адміністративний обмін для App2: app2$
• Ми можемо створювати доменні групи, такі як app1-rw, app1-ro, app2-rw, app2-ro, що представляють групи читання-запису та лише для читання.
• Адміністратор може відобразити ці акції app1$, app2$ і додати вищезазначені групи до дозволів NTFS так, що app1-rw/app2-rw Groups має повний контроль або права на читання-запис та app1-ro/app2-ro має дозволи лише для читання. 
• Також додайте ці групи до дозволів для обміну так, щоб app1-rw/app2-rw має повний контроль або змінює права на зміну та app1-ro/app2-ro має дозволи лише для читання.
• Адміністратор тепер може додавати необхідних користувачів до цих доменних груп залежно від рівня доступу.

• Примітка. Цей метод ефективний, якщо у нас є спільні ресурси, до яких мають доступ певна група користувачів або команд. Це не буде корисно для управління індивідуальними акціями. Дозволи на рівні shares 

• У попередньому розділі ми бачили, що це завжди найобмежувальніший доступ, наданий користувачу шляхом поєднання дозволів на рівні спільного використання та NTFS.
• Враховуючи це, ми можемо встановити дозволи на спільне використання на Everyone -Full Control і керувати дозволами лише на рівні NTFS, хоча це простіший спосіб керування дозволами, він не рекомендується для чутливих даних, оскільки пропускає другий фактор автентифікації на рівні share.