Налаштування для веб-додатків класичної перевірки автентичності Windows за допомогою протоколу Kerberos необхідна, щоб сценарії працювали очікуваним чином. У деяких сценаріях може використовуватися перевірка Windows на основі тверджень, але в цьому випадку результати можуть не відповідати описаним в наступних сценаріях.
У цьому сценарії виконуються наступні дії:
Налаштування двох веб-додатків з зонами за замовчуванням, що використовують для перевірки справжності протокол Kerberos
Створення двох тестових сімейств сайтів, по одному в кожному веб-додатку
Перевірка настройки IIS для веб додатки
Перевірка можливості виконання веб-додатком перевірки справжності клієнтів і використання для неї протоколу Kerberos
Обхід кожного веб-додатки та перевірка пошуку контенту в кожному тестовому сімействі сайтів
Створіть облікові записи служб для пулу додатків IIS веб-додатків
Зареєструйте імена учасників служби для веб-додатків в обліковому записі служби, створеної для пулу додатків IIS веб-додатків
Налаштуйте обмежене делегування Kerberos для облікових записів служб
Створіть керовані облікові записи SharePoint Server
Створіть додаток-службу пошуку SharePoint
Створіть веб-додатки SharePoint
Переконайтеся, що перевірка достовірності Kerberos включена
Переконайтеся, що перевірка справжності в режимі ядра відключена
Встановіть сертифікати для SSL
Клієнт Windows 7
Відкрийте порти брандмауера, щоб пропускати трафік HTTP через порти за замовчуванням і через порти, які не є портами за замовчуванням
Переконайтеся, що клієнти можуть підключатися до портів Kerberos в Active Directory
Протестуйте перевірку справжності для браузера
Переконайтеся, що перевірка справжності правильно працює в браузері
Перевірте відомості про вхід в систему в журналі подій безпеки веб-сервера
За допомогою засобів сторонніх розробників перевірте, чи правильно встановлена перевірки автентичності Kerberos
Перевірте індекс і запити пошуку SharePoint Server
Перевірте доступність браузера з серверів індексу
Передайте приклад контенту і виконайте обхід
Для кожного облікового запису служби налаштуйте набір імен учасників служби, зіставляються іменах вузлів DNS, призначеним кожному веб-додатком.
Всі веб-додатки SharePoint Server, незалежно від номера порту, використовують наступний формат імені учасника служби:
HTTP /<имя узла DNS>
HTTP /<Полное доменное DNS-имя>
Для веб-додатків, які працюють через нестандартні порти (що відрізняються від 80/443), зареєструйте додаткові імена учасників служби з номером порту:
HTTP /<имя узла DNS>:<порт>
HTTP /<Полное доменное DNS-имя>:<порт>
Див. У додатку пояснення рекомендацій настройки імен учасників служби з номером порту і без нього для HTTP-служб, працюючих не через порти за замовчуванням (80, 443). Технічно правильним способом посилання на HTTP-службу, що працює через нестандартні порти, є додавання номера порту в ім'я учасника служби, але через відомі проблем, описаних в додатку, потрібно налаштувати імена учасників служби і без порту. Зверніть увагу, що в нашому прикладі імена учасників служби без вказівки порту для веб-додатки teams не означає можливість скористатись послугою через порти за замовчуванням (80, 443).
У нашому прикладі для двох облікових записів, створених на попередньому кроці, налаштовані наступні імена учасників служби:
На таку схему принципово показується, що буде налаштовуватися в цьому сценарії:
Для цього буде налагоджено обмежене делегування Kerberos, що дозволяє делегування між обліковими записами онлайнової служби пулу додатків IIS. На таку схему принципово описані потрібні шляхи обмеженого делегування.
Пам'ятайте, що веб-додаток визначається ім'ям служби з використанням імені учасника служби, яке призначене посвідченню пулу додатків IIS. Облікових записів служб, що обробляє запити, має бути дозволено делегувати посвідчення клієнта призначеним службам. В результаті будуть налаштовані наступні шляхи обмеженого делегування:
Щоб налаштувати делегування, можна використовувати оснастку "Active Directory - користувачі і комп'ютери". Клацніть правою кнопкою миші кожну обліковий запис служби і відкрийте діалогове вікно властивостей. У цьому діалоговому вікні з'явиться вкладка для делегування (зверніть увагу, що ця вкладка з'являється, тільки якщо об'єкту призначено ім'я учасника служби, комп'ютери мають ім'ям учасника служби за замовчуванням). На вкладці делегування виберіть Довіряйте цьому користувачу делегування зазначених служб. потім виберіть Використовувати будь-протокол перевірки автентичності.
Натисніть кнопку Додати. щоб додати служби, делегування яким буде дозволено для користувача (облікового запису служби). Для вибору імені учасника служби знайдіть об'єкт, до якого належить ім'я учасника служби. У нашому випадку виконується спроба делегування HTTP-службі, що означає виконання пошуку для облікового запису служби пулу додатків IIS, якому ім'я учасника служби було призначено на попередньому кроці.
У діалоговому вікні Вибір користувачів або комп'ютерів клацніть Користувачі і комп'ютери. знайдіть облікові записи служби пулу додатків IIS (в нашому прикладі vmlab \ svcPortal10App і vmlab \ svcTeams10App), а потім натисніть кнопку ОК.
Буде запропоновано вибрати служби, призначені об'єктів, на ім'я учасника служби.
Виконайте ці дії для кожного облікового запису служби в середовищі, для якої потрібно делегування. У нашому прикладі це список облікових записів служб
Перед створенням своїх веб-додатків налаштуйте облікові записи служб, створені на попередніх етапах, як керовані облікові записи в SharePoint Server. Завчасне виконання цієї дії дозволить пропустити його при створенні самих веб-додатків.
Дії для настройки керованої облікового записуУ центрі адміністрування клацніть елемент Безпека.
У розділі Загальні безпеку клацніть елемент Налаштування керованих облікових записів.
Клацніть Зареєструвати керовану запис і створіть керовану обліковий запис для кожного облікового запису служби. У цьому прикладі ми створили п'ять керованих облікових записів служб:
Ім'я: SharePoint - Teams5555
При створенні нового веб-додатки також створюється нова зона, зона за замовчуванням, налаштована для використання постачальником перевірки автентичності Windows. Постачальника і його налаштування для зони можна бачити при управлінні веб-додатком, спочатку вибираючи веб-додаток, потім клацаючи Постачальники перевірки справжності на панелі інструментів. У діалоговому вікні постачальників перевірки автентичності перераховані всі зони для обраного веб-додатки разом з постачальником перевірки автентичності для кожної зони. Після вибору зони з'являться параметри перевірки автентичності для цієї зони.
При неправильному налаштуванні параметрів Windows і неправильному виборі NTLM при створенні веб-додатки, можна використовувати діалогове вікно редагування перевірки автентичності для зони, щоб переключити для зони значення з "NTLM" на "Узгодження". Якщо в якості режиму перевірки справжності не був обраний класичний режим. необхідно або створити нову зону, розширюючи веб-додаток на новий веб-сайт IIS, або видалити і заново створити веб-додаток.
Для цього прикладу було налаштоване два сімейства веб-сайтів:
Шлях сімейства веб-сайтів
Для веб-додатки порталу буде налаштоване використання HTTPS, а також HTTP, щоб продемонструвати роботу делегування з захищеними службами SSL. Щоб налаштувати SSL, веб-додатком порталу знадобиться другий зіставлення для альтернативного доступу SharePoint Server (AAM) для кінцевої точки HTTPS.
Дії для настройки зіставлень для альтернативного доступуУ центрі адміністрування виберіть пункт Керування додатками.
В елементі Веб-додатки клацніть налаштувати зіставлення для альтернативного доступу.
У списку Вибір набору зіставлень альтернативного доступу виберіть Змінити набір зіставлень альтернативного доступу.
Виберіть веб-додаток порталу.
Натисніть кнопку Зберегти.
Перед тестуванням перевірки автентичності переконайтеся, що клієнти можуть отримувати доступ до веб-додатків SharePoint Server, використовуючи налаштовані порти HTTP. Крім того, переконайтеся, що клієнти можуть проходити перевірку автентичності в Active Directory і запитувати квитки Kerberos від KDC через стандартні порти Kerberos.
Зазвичай, щоб дозволити отримання запитів через порти TCP 80 і TCP 443, потрібно налаштувати брандмауер на кожному интерфейсном веб-сервері. Відкрийте брандмауер Windows в режимі підвищеної безпеки і перейдіть до наступних правил для вхідних підключень:
Служби Інтернету (вхідний трафік HTTP)
Служби Інтернету (вхідний трафік HTTPS)
Переконайтеся, що в використовуваної середовищі відкриті відповідні порти. У нашому прикладі для доступу до SharePoint Server використовується HTTP (порт 80), тому дане правило було включено.
Крім того, нам потрібно відкрити порт, який не є портом за замовчуванням, але використовуваний в нашому прикладі (TCP 5555). Якщо веб-сайти працюють через нестандартні порти, також знадобиться дозволити трафік HTTP через ці порти.
Центр поширення ключів Kerberos - PCR (TCP-вхідні)
Центр поширення ключів Kerberos - PCR (UDP-вхідні)
Центр поширення ключів Kerberos (TCP-вхідні)
Центр поширення ключів Kerberos (UDP-вхідні)
Переконайтеся, що в використовуваної середовищі ці правила включені і що клієнти можуть підключатися до KDC (контролер домену), використовуючи порт 88.
Тепер, після настройки Active Directory, DNS і SharePoint Server, можна протестувати правильність настройки перевірки достовірності Kerberos, перейшовши в свої веб-додатки. При тестуванні в браузері переконайтеся у виконанні наступних умов:
Тестовий користувач увійшов в систему комп'ютера Windows XP, Vista або Windows 7, приєднаного до домену, в якому встановлений SharePoint Server, або увійшов в домен, який є довіреною для домену SharePoint Server.
У браузері включена вбудована перевірка справжності Windows. На вкладці Додатково у вікні Властивості оглядача переконайтеся, що в розділі "Безпека" встановлено прапорець Дозволити вбудовану перевірку автентичності Windows *:
Можна налаштувати автоматичний вхід і для інших зон, але тема рекомендацій для зон безпеки IE знаходиться поза рамками даної статті. У цій демонстрації для всіх тестів буде використовуватися зона інтрамережі.
Переконайтеся, що прапорець Автоматично визначати приналежність до інтрамережі встановлено в пункті Властивості оглядача -> Безпека -> Місцева интрасеть -> Веб-сайти.
При використанні повного доменного імені для доступу до веб-додатків SharePoint Server переконайтеся, що повні доменні імена включені в зону интрасети, або явно задайте включення за допомогою символів узагальнення (наприклад, "* .vmlab.local").
Найпростіший спосіб визначити, чи використовується перевірка справжності Kerberos, - увійти на тестову робочу станцію і перейти на що цікавить веб-сайт. Якщо користувачеві не пропонується ввести облікові дані і сайт правильно відображається, можна вважати, що вбудована перевірка справжності Windows працює. Наступний крок - визначити, чи використовувався протокол узгодження для узгодження перевірки автентичності Kerberos в якості постачальника перевірки автентичності для запиту. Для цього можна скористатися наступними способами.
Якщо перевірка достовірності Kerberos працює правильно, журнали подій безпеки на інтерфейсних веб-серверах міститимуть події входу в систему з ідентифікатором події ID = 4624. У загальних відомостях для цих подій буде видно ідентифікатор безпеки, зареєстрований на комп'ютері, і який використовується процес входу в систему, який повинен бути процесом Kerberos.
Якщо потрібно очистити кеш квитків, запустіть Klist з необов'язковим параметром purge. Klist purge
Перейдіть на веб-сайти, які використовують перевірку достовірності Kerberos.
Переконайтеся, що квитки веб-додатків, для яких виконується перевірка справжності, знаходяться в списку кешованих квитків. У нашому прикладі виконується перехід на наступні веб-сайти, з наступними зареєстрованими іменами учасників служби:
Вийдіть з системи настільного комп'ютера і увійдіть назад, щоб очистити все кешированниє підключення до веб-сервера і змусити браузер узгодити перевірку достовірності Kerberos і виконати перевірку справжності.
У Fiddler повинні з'явитися запити до багатофункціонального веб-сервера SharePoint Server і його відповіді.
Перший HTTP 401 - це спроба браузера виконати запит GET без перевірки автентичності. У відповіді сервер відправляє назад "HTTP 401 - unauthorized", показуючи в цій відповіді, які методи перевірки автентичності він підтримує. У наступному запиті клієнт повторює відправку попереднього запиту, але в цей раз в заголовках запиту передається квиток для веб-додатки. При успішній перевірці автентичності сервер відправить назад запитаний ресурс.
NetMon дозволяє побачити весь обмін запитами та відповідями TCP з KDC і веб-серверами SharePoint Server, створюючи повне уявлення про трафік, що утворює повний запит перевірки автентичності. Щоб перевірити роботу перевірки автентичності Kerberos за допомогою netmon, виконайте наступні дії:
Вийдіть з системи клієнта і знову зайдіть, щоб очистити кеш квитків Kerberos. Додатково можна використовувати KerbTray, щоб очистити кеш квитків, клацнувши правою кнопкою миші значок KerbTray і вибравши Purge Tickets (Очистити квитки).
Запустіть NetMon в режимі адміністратора. Клацніть правою кнопкою миші ярлик NetMon і виберіть Запуск від імені адміністратора.
Запустіть нове захоплення інтерфейсів, що підключаються до контролера Active Directory використовуваного середовища і інтерфейсним веб-серверів.
Відкрийте Internet Explorer і перейдіть в веб-додаток.
Коли нарешті з'явиться веб-сайту зупиніть захоплення і додайте фільтр дисплея, щоб показати кадри для перевірки автентичності Kerberos і трафіку HTTP.
Вікно кадрів повинно містити як трафік HTTP, так і трафік KerberosV5.
Щоб чітко показати імена учасників служб, запитувані при зверненні клієнта до ресурсу, захищеному SSL, можна використовувати засіб, подібне netmon, захоплююче трафік між клієнтом і сервером, і перевірити запити квитків Kerberos.
Або вийдіть і знову увійдіть в систему клієнтського комп'ютера, або очистіть все кешированниє квитки Kerberos за допомогою KerbTray.
Запустіть нове захоплення NetMon на клієнтському комп'ютері. Не забудьте запустити NetMon з привілеями адміністратора.
Зупиніть захоплення NetMon і перевірте трафік KerberosV5. Інструкції про фільтрації відображення захоплення см. В розділі NetMon 3.4 цієї статті.
Знайдіть запит TGS, відправлений клієнтом. У запиті повинно бути видно ім'я учасника служби, ви запросили в параметрі "Sname".
Зверніть увагу, що "Sname" - це HTTP / portal.vmlab.local, а не HTTPS / portal.vmlab.local.
Перед запуском обходу переконайтеся, що сервер індексу отримує доступ до веб-додатків і успішно проходить перевірку автентичності. Увійдіть на сервер індексу і відкрийте в браузері тестові сімейства веб-сайтів. Якщо сайти успішно відображаються і не з'являються жодні діалогові вікна перевірки автентичності, перейдіть до наступного кроку. Якщо при доступі до сайтів в браузерах виникають якісь проблеми, поверніться до попередніх кроків, щоб перевірити правильність виконання всіх дій з налаштування.
У кожному сімействі веб-сайтів передайте "затравочний" документ (який легко визначається при пошуку) в бібліотеку документів сімейства сайтів. Наприклад, створіть текстовий документ, що містить слова "alpha, beta, delta", і збережіть його в бібліотеці документів кожного сімейства сайтів.
Потім перейдіть в центр адміністрування SharePoint і запустіть повний обхід для джерела контенту "Локальні сайти SharePoint" (який за замовчуванням буде містити два тестових сімейства веб-сайтів).