Отключить sso в chrome
Один из ведущих разработчиков Google Chrome, Адрианна Портер Фельт (Adrienne Porter Felt), не видит в данном поведении серьезной проблемы. Она считает, что это стоит расценивать как визуальный индикатор того, что пользователь авторизован в аккаунте Google, но это не означает, что его данные фактически загружаются.
С другой стороны, Мэтью Грин, профессор криптографии Университета Джона Хопкинса, считает, что данный аспект имеет очень важное значение, поскольку в данном случае браузер фактически ассоциируется с учетной записью Google. Такое поведение не должно происходить, если только пользователь сам не захочет войти в аккаунт Chrome. Даже если данные браузерной активности и синхронизация отключены, некоторые данные могут быть собраны только на стадии самого процесса аутентификации.
I’m still annoyed that Chrome has gone to mandatory Google login — exactly the same way Android did (and has received enormous criticism for) — and people at Google are acting like they’re surprised people are upset.
— Matthew Green (@matthew_d_green) 22 сентября 2018 г.
Также примечателен тот факт, что за счет принудительной авторизации пользователей в аккаунт Chrome при использовании сервисов Google, таких как Gmail, браузер подпадает под совершенно другую категорию политики конфиденциальности Chrome. В частности, в политике конфиденциальности указано, что после того, как вы вошли в учетную запись, на сервера Google будет загружена различная информация.
Все это приводит к путанице. С одной стороны, представители Google заявляют, что ваши данные не будут загружаться, но согласно политики конфиденциальности обмен данными с серверами Google запускается после входа в аккаунт.
Тот факт, что Google решила принудительно авторизовать вас в браузере без вашего разрешения, также вызывает у Грина обеспокоенность тем, что в один прекрасный день технологический гигант запустит синхронизацию ваших данных, когда вы утратили бдительность.
Синхронизация без разрешения?
После включения синхронизации, статус функции можно посмотреть в меню Настройки.
Однако, Портер заверила, что при принудительной авторизации в Chrome после авторизации на сервисах Google, синхронизация не включается.
Действительно, если зайти в настройки, то функция синхронизации в этом случае остается неактивной. Тем не менее, часть персональной информации может быть получена на этапе процесса аутентификации.
Как отключить автоматический вход в Chrome
Если вы хотите продолжить использовать Google Chrome, но не хотите, чтобы состояние авторизации на сервисах Google синхронизировалось с вашим браузером, вы можете отключить данное поведения, используя флаг Identity consistency between browser and cookie jar со следующим описанием:
При включении, браузер самостоятельно управляет входом и выходом из аккаунтов Google. – Mac, Windows, Linux, Chrome OS, Android
После выполнения этих шагов автоматический вход в Chrome не будет выполняться при авторизации на GMail или других сервисах Google.
Альтернативная сборка Chrome с акцентом на приватность
Для тех, кто хочет использовать более приватную, но более старую версию Chrome, можно протестировать сторонний форк Chrome под названием ungoogled-chromium.
В описании репозитория сообщается, что «ungoogled-chromium - это Google Chromium, без интеграции с Google. В нем реализованы некоторые изменения для улучшения конфиденциальности, контроля и прозрачности».
Согласно общедоступной информации о проекте разработчики попытались улучшить конфиденциальность за счет следующих мер:
- Отключение или удаление сервисов и функции, которые взаимодействуют с Google или ослабляют конфиденциальность.
- Разделения двоичных файлов из исходного дерева и использования модифицированных версий, предоставленных системой или созданных из источника.
- Отключения функций, которые препятствуют контролю и прозрачности, а также добавления или изменения функции, которые их продвигают (эти изменения незначительны и не оказывают существенного влияния на общий пользовательский интерфейс).
Для тех, кто не хочет компилировать исходный код и просто желает воспользоваться прекомпилированными двоичными файлами, существуют версии для Linux, macOS и Windows. Версии Linux и macOS построены на Chrome 68, а в Windows-версии в качестве базы используется Chrome 67.
Для чего нужна сквозная аутентификация в Google Chrome
Когда у вас в компании уже построена инфраструктура на базе домена Active Directory, то это подразумевает использование одной учетной записи на всех сервисах компании. Так как сейчас у сотрудника не обязательно есть только компьютер, у него может быть рабочий, планшет, телефон, ноутбук. Все эти устройства давно так же заводятся в домен и управляются централизовано. Когда вы включаете в компании политику стойкости пароля (PSO), то тем самым вы вынуждаете сотрудника делать его пароль очень сложным. Это за собой влечет сложность ввода учетных данных на мобильных устройствах, отнимая время вашего хелпдеска. Дабы всем упростить жизнь, есть такое понятие, как SSO (Single Sign On), если перевести на русский, это это единая точка входа.
Идея сквозной аутентификации очень проста, вы входите один раз под своей корпоративной учетной записью на устройство, а далее все сервисы компании на которых настроена SSO, для вас доступны без ввода логина и пароля. Согласитесь, что это очень удобно. Так мы например, недавно производили настройку SSO для ManageEngine ServiceDesk или для vCenter Server. Благодаря этому могу выделить плюсы:
- Удобство для пользователей, что влечет экономию простоя их рабочего времени
- Экономия времени сотрудников технической поддержки
- Простота доступа к новым сервисам компании
- Более высокая безопасность
Методы настройки SSO в Google Chrome
Я могу выделить вот такие методы сквозной аутентификации в данном браузере:
- Брать список надежных узлов в Internet Explorer
- Настройка через командную строку
- Настройка через реестр Windows
- Настройка через групповую политику
Параметры управления белым списком сайтов для SSO
В Google Chrome есть ряд настроек, которые отвечают за автоматический sso login.
- AuthNegotiateDelegateWhitelist (Белый список серверов Kerberos для передачи прав) - данный параметр говорит Google Chrome, для каких сервисов необходимо предоставлять данные встроенной аутентификацию Windows. Допускается указание названий серверов через запятую и использование подстановочных знаков (*).
- AuthServerWhitelist (Белый список аутентификации сервера) - в данный список вносятся сервера, для которых будет включен вход sso login. Тут ваш браузер будет ждать запрос от прокси-сервера или сервера, внесенного в этот список. Если вы не зададите данный параметр, то при обращении на сервер, где вы хотите, чтобы работала сквозная авторизация, Google Chrome будет проверять является ли данный адрес частью зоны интранет, напоминаю, это он берет из Internet Explorer, если сайт в интранет не входит (Местная интрасеть), то он сделает вывод, что сайт является частью интернета и будет игнорировать сквозной вход на сервер.
Настройка встроенной аутентификацию Windows в Google Chrome локально
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --auth-server-whitelist="*.pyatilistnik.org" --auth-negotiate-delegate-whitelist="*.pyatilistnik.org"
Пробуем теперь перезапустить ваш браузер и проверить автоматический вход на нужный вам сервис. Обратите внимание, что в итоге задали все те же две настройки auth-server-whitelist и auth-negotiate-delegate-whitelist.
Настройка сквозной авторизации через реестр
Выше мы выяснили, что у хрома есть два параметра auth-server-whitelist и auth-negotiate-delegate-whitelist. Оба параметра являются всего лишь ключами реестра Windows. Вот вам две ветки реестра, где вы найдете нужные ключи реестра.
Для конкретного пользователя \HKEY_CURRENT_USER\Software\Policies\Google\Chrome и для всего компьютера HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\ChromeТут должны быть ключи с типом REG_SZ. Все записи начинаются со знака *.имя домена и перечисляются через запятую. После внесения или создания данных ключей, вам нужно перезапустить Google Chrome.
Настройка встроенной аутентификацию Windows в Google Chrome через GPO
Когда у вас большая компания и огромный штат сотрудников, вам для быстрого распространения настроек, подойдет использование объектов групповой политики. Для этого у вас должен быть создан центральный репозиторий политик и скопирован в него последний набор ADMX шаблонов для Google Chrome.
Как импортировать шаблон настроек Google Chrome в ваш репозиторий, я уже подробно рассказывал, смотрим по ссылке. Создаем новый объект GPO или используем уже существующий. Напоминаю, что все настройки вы можете применять, как к компьютерам, так и к пользователям. Я буду применять к сотрудникам, перейдите в раздел:
Вводим тут сервер через запятую.
Далее вы обновляете групповые политики у пользователя на рабочей станции и можете проверить сквозную аутентификацию. Так же в Google Chrome, в адресной строке введите адрес chrome://policy/. Тут вы можете увидеть прилетевшие политики. Так же есть кнопка обновления "Повторно загрузить политики".
Настройка SSO в Google Chrome для Azure
Если вы произвели интеграцию вашего Active Directory в облако Azure, то для работы Single Sign On есть расширение "Windows 10 Accounts". Используйте это расширение для входа на поддерживаемые веб-сайты с учетными записями в Windows 10. Если у вас есть удостоверение, поддерживаемое Microsoft, в Windows 10, вам не потребуется вводить учетные данные для входа на поддерживаемые веб-сайты. Вам нужно будет использовать это расширение, если ваша организация внедрила политику условного доступа. В настоящее время это расширение поддерживает удостоверения Azure Active Directory.
В этой статье объясняется, как настроить систему единого входа (SSO) со сторонним поставщиком идентификационной информации, где Google выступает в роли поставщика услуг. Однако вы можете настроить систему единого входа, где Google выступает в роли поставщика идентификационной информации.
Чтобы настроить систему единого входа на базе SAML со сторонним поставщиком идентификационной информации, выполните инструкции из статей ниже.
Чтобы узнать подробную информацию о настройке SSO на уровне организационного подразделения или группы, посмотрите видеообзор.
Система единого входа
Благодаря системе единого входа вашим пользователям не придется входить отдельно в каждое корпоративное облачное приложение. Когда вы настроите систему единого входа, пользователи смогут входить в сервисы сторонних поставщиков идентификационной информации, а затем получать доступ к приложениям Google без необходимости повторного ввода учетных данных. При этом действуют следующие ограничения:
- Даже если пользователи уже вошли в сервис стороннего поставщика идентификационной информации, в качестве дополнительной меры безопасности Google будет иногда запрашивать подтверждение личности. Дополнительные сведения и информацию о том, как отключить процесс подтверждения, можно найти в статье Как работает безопасный вход на базе SAML.
- Вы можете настроить дополнительную двухэтапную аутентификацию для пользователей с доступом к сервисам Google. Как правило, если система единого входа включена, двухэтапная аутентификация не выполняется. Подробнее о том, как проверяется личность пользователя с помощью дополнительных мер безопасности…
Система единого входа также доступна на устройствах Chrome. Дополнительную информацию можно найти в статье Настройка системы единого входа на базе SAML для устройств Chrome.
На устройствах с ОС Android версии до 2.1 используется аутентификация Google. Выполняя вход на таком устройстве, вы должны ввести полный адрес электронной почты управляемого аккаунта Google, включая имя пользователя и домен. После этого вы сразу перейдете в приложение. Google не перенаправит вас на страницу единого входа независимо от маски сети.
Когда URL страницы входа в систему SSO для iOS-приложений начинается с "google." или похожего домена, приложение Google для iOS открывается в браузере Safari. В результате происходит ошибка входа в SSO. По этой причине перечисленные ниже префиксы использовать нельзя:
Все URL страницы единого входа с такими префиксами нужно изменить.
Как работает URL для изменения пароля
Как устранить неполадки в работе системы единого входа
Информацию об устранении неполадок можно найти в Справочном центре. Обратите внимание, что существует множество коммерческих организаций, предлагающих продукты для работы системы единого входа и профессиональные услуги по интеграции. Партнеров и сторонние компании, которые помогут вам настроить систему единого входа, можно найти в каталоге Google Workspace Marketplace.
Примечание. Служба поддержки Google Workspace не оказывает помощь в настройке системы единого входа, использующей сторонние поставщики идентификационной информации.
браузер посылал запрос в ldap-сервер на получение ticket по kerberos-протоколу?
- Сам по себе хром ни к какому ldap-серверу обращаться не будет. Если речь идёт о линуксе, то на клиенте должен быть указан соответствующий керберос-сервер. Винда должна быть заведена в соответствующий домен.
- Далее ты получаешь на клиенте керберос-тикет kinit username@DOMAIN .
- Далее, для chromium нужно создать политику:
Там должно быть 'Unauthorized', но не уверен, что это на что-то влияет. Вполне вероятно, браузер смотрит только на статус.
ну я профан в этих делах. а что не так?
спасибо за ответ. на самом деле то у меня клиент на виртуалке на винде, соответственно, хром тоже на ней, и access directory тоже на виртуалке на винде, только лишь собственный сервер(с логикой) на линуксе. с ldap вообще никогда не работал, полное дно
да вроде ж браузер и есть клиент в данном случае?
Первое: ldap и kerberos - разные вещи. ldap может работать без кербероса, керберос может работать без лдапа.
Второе: Если у тебя есть домен active directory (что такое access directory?), и винда, заведённая в этот домен, то при входе под доменной учётной записью, она сама получает тикет.
Третье: Как на винде включить керберос аутентификацию в хроме нагугли сам, там примерно тоже, что и в линупсе, только где-то в глубинах реестра.
Четвертое: Клиент кербероса - это твоя винда. Если ты вдруг заведёшь хрома в домен, отдельно от винды, так чтобы он мог самостоятельно получать тикеты, то тогда он станет клиентом кербероса. Покуда он лишь использует тикеты хоста - клиентом кербероса он не является.
Пятое: Вообще непонятно, что непонятного написано в первом посте, и что мешает немного подумать, погуглить, и сделать всё как надо. Ты либо говори конкретно, что не получается, либо RTFM, пока не начнёшь понимать, что происходит. Ты вообще про то, что такое керберос читал?
Ты вообще про то, что такое керберос читал?
ну так, смутновато конечно
Клиент кербероса - это твоя винда
Ну очевидно, что надо более подробно изучить, что такое керберос, как он работает и для чего используется. Тогда большая часть твоих вопросов отпадёт сама.
я думал браузер это делает автоматом
хм, а когда мы заходим в учетную запись на винде, то мы, получается, получаем TGT уже? а для взаимодействия с сервером нам нужен TGS, правильно?
xperious ★★ ( 08.08.17 14:09:26 )Последнее исправление: xperious 08.08.17 14:10:23 (всего исправлений: 1)
когда мы заходим в учетную запись на винде, то мы, получается, получаем TGT уже?
Ну по идее да. Когда ты вводишь логин/пароль, винда передаёт его на kdc, а оттуда приходит tgt. Вся остальная аутентификация в сервисах ведётся с использованием уже полученного тикета.
а для взаимодействия с сервером нам нужен TGS, правильно?
С каким сервером? Непонятно, что ты имеешь ввиду.
С каким сервером? Непонятно, что ты имеешь ввиду.
ну имел ввиду свой сервер с логикой, на линуксе
ну имел ввиду свой сервер с логикой, на линуксе
Так же, как я понимаю, клиент проверяет, известен ли service principal твоего сервиса kdc и проверяет его подлинность. Но тут не уверен, бывают ли исключения. У меня такое получалось только заводя линукс в домен AD. Хотя можно пошаманить в AD и создать принципал и keytab для сервиса самому.
и снова к вопросу о самопосылании KRB_TGS_REQ браузером
The client requests a Service Ticket (TGS_REQ).
ну вроде как может браузер сам посылать то. разве нет?
А что он по-твоему посылает?
всмысле нужно проверить маркер времени из TGS(TGS сервиса посылает ему клиент т.к. их два приходят от KDC клиенту)? или что-то еще?
хм, думаю пакет KRB_TGS_REQ по протоколу kerberos5, если не ошибаюсь
xperious ★★ ( 08.08.17 18:16:24 )Последнее исправление: xperious 08.08.17 18:17:20 (всего исправлений: 1)
всмысле нужно проверить маркер времени из TGS(TGS сервиса посылает ему клиент т.к. их два приходят от KDC клиенту)? или что-то еще?
Учитывая, что TGS - это ticket granting server, часть kdc, твоё предложение выглядит сомнительно и не поддаётся расшифровке.
Сервису нужно проверить, что токен, присланный клиентом - не какая-то херня, а правильный токен, содержащий валидный мандат для аутентификации именно на этом сервисе именно этого клиента.
хм, думаю пакет KRB_TGS_REQ по протоколу kerberos5, если не ошибаюсь
А что такое KRB_TGS_REQ?
Учитывая, что TGS - это ticket granting server, часть kdc, твоё предложение выглядит сомнительно и не поддаётся расшифровке.
ну смысл в чем: от active directory к клиенту приходят два сеансовых билета(сразу сервису ничего не приходит). один из них передается сервису от клиента. сеансовый билет состоит из общего ключа для клиента и сервера, имя пользователя, маркер времени, и сколько времени может жить билет. так вот, когда этот сеансовый билет попадает к серверу от клиента, то он расшифровывается, из него берется этот самый маркер времени, по которому мы удостоверяемся что клиент валиден. я понял так, возможно что-то опять не правильно.
то он расшифровывается, из него берется этот самый маркер времени, по которому мы удостоверяемся что клиент валиден.
Ну сервис удостоверяется в валидности клиента по самому факту расшифровки. Маркер времени это доп. проверка для защиты от повторов и способ подтвердить сервису свою подлинность. А так всё правильно, вроде.
Разговор ушёл куда-то в дебри.
Короче, чтобы получить tgt тебе нужен пароль пользователя. Ты его можешь получить только при входе в систему. Вот именно тогда хост и получает свой tgt, а далее его вовремя обновляет.
Хром никакого tgt не получает. Он берёт tgt от хоста(твоей винды), и запрашивает у kdc ( у tgs) сеансовый билет сервиса (он же мандат сервиса), и отдельно сеансовый ключ. Всё. Дальше он общается только с сервисом, покуда срок действия мандата не истечёт.
Хром никакого tgt не получает. Он берёт tgt от хоста(твоей винды),
вот это самое не понятное: как хром может его получить от оси? хотя бы на линуксе
хм, и еще вопрос: мой сервак, я так понимаю, надо тоже регистрировать в AD?
вот это самое не понятное: как хром может его получить от оси?
Он получается пользователем, и вполне логично, что он доступен ему для чтения. Иначе зачем он вообще нужен?
Ну в моей центоси по дефолту тикеты хранятся в KEYRING:persistent:%, так что видимо как-то так. Для общего понимания, можешь потыкать kinit/klist/kvno. Для их работы необходим tgt, но на kdc его получает только kinit.
Он получается пользователем, и вполне логично, что он доступен ему для чтения. Иначе зачем он вообще нужен?
хм, ну вот смотрите: у меня есть изначальная задача сделать sso авторизацию через ldap на пользование моим(ну не совсем моим, разумеется) сервером, я выбрал через kerberos и нагуглил ту статейку на хабре выше. я хотел повторить что есть в ней, и вот понимаю, что чтобы посылался сеансовый билет серверу, то у меня не сделано что-то. а почему там SPNEGO еще прикручен? я так понял spnego это вообще отдельный протокол не связанный с kerberos
Читайте также: