Внешняя аутентификация ldap или windows — Ваш верный помощник с OS Windows

Время на прочтение7 мин

Количество просмотров93K

Сегодня в любой организации есть LDAP-каталог, наполненный пользователями этой организации. Если присмотреться, вы найдете одно или несколько приложений, которые используют этот же каталог для «аутентификации». И кавычки здесь неспроста, ведь LDAP — это протокол доступа к каталогам, спроектированный для чтения, записи и поиска в службе каталогов. Это не протокол аутентификации. Термин «LDAP-аутентификация», скорее, относится к той части протокола (операции bind), где определяется, кто вы такой, и какие права доступа имеете к информации каталога.

Со временем LDAP стал службой аутентификации де-факто. Широко распространенные и доступные службы LDAP, такие, как Active Directory, стали лакомым кусочком для разработчиков программного обеспечения, которые хотят встроить аутентификацию в свои продукты. Клиентские библиотеки LDAP доступны практически для любого фреймворка, а реализовать интеграцию относительно легко.

Но несмотря на то, что применение LDAP может помочь решить задачу внедрения аутентификации пользователей в различных приложениях компании, оно создает множество проблем. В отличие от специально предназначенных протоколов аутентификации, при использовании LDAP возникают различные уязвимости информационной безопасности.

Чтобы разобраться в том, что это за уязвимости, сперва нужно понять, как работает LDAP-аутентификация.

Как работает LDAP-аутентификация

Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).

Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время. В пункте выдачи сотрудник спрашивает мое имя, адрес и просит ключи от дома, чтобы подтвердить мою личность. Затем сотрудник службы доставки приезжает ко мне домой и открывает дверь моим ключом. Он заходит внутрь, чтобы убедиться, что я там живу, например, по фотографиям на стене или по имени адресата на корреспонденции. После этого сотрудник возвращается в пункт выдачи и сообщает мне, что успешно подтвердил мою личность, и я могу получить свою посылку! Ура!

Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.

К счастью, в реальном мире у нас есть документы для подтверждения личности, например, водительские права или паспорт, которые выданы государственными органами, и их подлинность не вызывает сомнений. Я могу предоставить эти документы курьеру для собственной идентификации без передачи ключей.

В мире LDAP мы все еще должны передавать наши ключи, чтобы открыть дверь от нашего имени. Мы передаем наш пароль стороннему лицу, и он пытается с его помощью проникнуть на сервер LDAP. Если ему удается получить доступ, мы не можем быть уверены, что наши учетные данные не скомпрометированы. При этом злоумышленник получит не только возможность разблокировать дверь LDAP, но и доступ к любому приложению, использующему те же учетные данные.

К счастью, в более полном мире аутентификации у нас также есть паспорта и водительские права! Протоколы аутентификации, такие как Kerberos, SAML и OpenID Connect, выпускают токены третьим лицам. Токены подтверждают, что вы являетесь тем, за кого себя выдаете, и нет необходимости передавать кому-либо свои ключи. Поскольку LDAP никогда не разрабатывался как протокол аутентификации, соответствующие механизмы у него отсутствуют.

Недостатки LDAP как системы аутентификации

В 2007 году Шумон Хак выпустил фантастическую статью (LDAP Weaknesses as a Central Authentication System), в которой он описывает три конкретные проблемы при использовании LDAP в качестве системы аутентификации.

1. Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными

Автор подчеркивает, что защитить от атаки небольшой набор серверов аутентификации гораздо проще, чем защитить большое количество серверов приложений.

В своем большинстве серверы аутентификации, как правило, находятся под тщательным присмотром специалистов, обладающих значительным опытом в области информационной безопасности.

С другой стороны, серверы приложений имеют совершенно иной уровень безопасности и более подвержены риску компрометации. Они менее защищены, работают с более сложными программными стеками и с большей вероятностью имеют уязвимости. И чаще они находятся под управлением людей, которые не имеют глубоких знаний о безопасности. Построение правильной системы безопасности — сложнейший процесс, в котором очень легко допустить ошибку.

Проблема заключается в том, что если один сервер приложений скомпрометирован, то все учетные данные, которыми пользовались их владельцы во время атаки, также скомпрометированы. Под угрозой находится и любая другая система, которая использует тот же каталог LDAP для аутентификации.

2. Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных

LDAP-сервер не может гарантировать безопасность транзакции. Несмотря на то, что LDAP-сервер, например, может обеспечить принудительное выполнение операции bind по TLS, чтобы гарантировать, что учетные данные не передаются в открытом виде, сам сервер никогда не принимал никакой роли в получении учетных данных от пользователя. Существует риск, что приложение будет получать пароль по небезопасному каналу.

3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной

Пароль пользователя или секрет аутентификации должен оставаться секретом. Он должен быть известен только самому пользователю и системе аутентификации. При использовании LDAP-аутентификации пользователь вынужден поделиться своим секретом с третьей стороной, чтобы она затем смогла использовать данный секрет для взаимодействия с LDAP-каталогом от имени пользователя.

Важно упомянуть, что при использовании специально предназначенных протоколов аутентификации, таких как Kerberos, и даже с более раннего — NTLM, секрет пользователя никогда не передается по сети. Клиентское устройство и сервер используют криптографические операции, чтобы доказать друг другу, что у них один и тот же секрет и при этом даже не обмениваются самим секретом.

К пунктам Шумона Хука добавлю описание нескольких нюансов LDAP-аутентификации, основываясь на собственном опыте. Прежде всего, тема касается использования Active Directory.

4. Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать

В одном из моих прошлых постов блога описывается, как анонимные и неаутентифицированные bind’ы позволяли обхитрить разработчиков приложений и заставляли пропускать неавторизованных пользователей. Возможность выполнения операции bind без проверки подлинности — одна из тонкостей протокола, о которой не знают даже самые опытные специалисты по LDAP.

Каталоги устроены непросто и способны хранить огромное количество организационной информации и предоставляют множество настраиваемых способов ее хранения. Я видел очень много случаев, когда разработчик приложения предполагал, что существует определенный класс объекта или атрибут, а когда их не обнаруживалось, приложение падало. Для аутентификации пользователя не должны требоваться и применяться знания о структуре данных, хранящихся в каталоге. Протокол аутентификации должен абстрагироваться от деталей хранилища объектов, расположенного уровнем ниже.

5. Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом

При управлении Active Directory в большой распределенной среде есть один неприятный нюанс: трудно определить, какие конкретно приложения используют Active Directory в качестве LDAP-каталога, и как именно администраторы приложений настроили LDAP-клиент.

Ниже представлены примеры ужасов некорректной настройки.

Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
Отправка паролей в открытом виде на 389-й порт.
Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?

Заставить LDAP-клиент работать легко. Но только тот факт, что он работает, не означает, что конфигурация правильная.

6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга

Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна (если только вы не собираетесь внедрять свои собственные технологии, что само по себе является плохой идеей). Альянс FIDO стремится сделать пароли пережитком прошлого, а каждое приложение, использующее аутентификацию LDAP, будет помехой на пути к беспарольной политике.

Какие есть варианты?

Сегодня веб-приложения действительно могут обойтись без LDAP-аутентификации. Существует множество прекрасных веб-протоколов аутентификации, таких как SAML, WS-Federation и OpenID Connect, которые не требуют учетных данных пользователя для работы со сторонними приложениями. Бесчисленное количество продуктов предоставляют эти услуги, включая Active Directory Federation Service (встроенные в Windows Server) или сторонние сервисы, такие как Microsoft Azure AD, Okta, Ping и другие. Если в организации нет федеративного IdP, первое, что нужно сделать — внедрить его.

Главное, на что стоит обратить внимание при выборе нового ПО — поддержка современных протоколов аутентификации. Даже если приложение требуется бизнесу здесь и сейчас, не стоит спешить с выбором решения, особенно, если этот выбор ограничен только продуктами с LDAP-аутентификацией. Стоит попробовать донести до выбранного вендора необходимость доработки продукта с использованием более современных протоколов аутентификации. Возможно он прислушается и пересмотрит свой план разработки.

Число десктоп-приложений с «толстым клиентом», поддерживающих современные протоколы аутентификации, растет, и это действительно радостная тенденция. Эти приложения обычно были оплотом LDAP-аутентификации. Растет число SDK, таких, как Microsoft Authentication Library (MSAL), которые позволяют разработчикам легко добавлять поддержку современных сервисов аутентификации в свои мобильные и десктоп-приложения.

В конечном счете, стоит признать, что в сегодняшней реальности не все приложения поддерживают современные протоколы аутентификации, и, возможно, никогда и не будут. Внедрение полного запрета LDAP-аутентификации, вероятно, невозможно ни в одной организации. Однако ни в коей мере не стоит поощрять применение LDAP-аутентификации внутри организации. Использование LDAP следует рассматривать только при отсутствии других вариантов.

Источник

LDAP Authentication on Windows Server

ProVision supports LDAP authentication (including Windows Server). To setup an LDAP server for authentication, you must perform the following procedures:

Configuring the LDAP functions on your Windows Server

You should confirm these steps with your LDAP admin — the purpose of this walkthrough is to provide some level of detail on how to extend LDAP functionality to support integration with an application like ProVision.

Step 1: Prepare to extend the Schema (http://technet.microsoft.com/en-us/library/cc961754.aspx)

This is not a minor operation and requires interaction with various control modification areas of Windows Server:

If you have not modified the schema before, you will need to use the Active Directory Schema console on a DC (Domain Controller) to permit write access to the DC schema.
Since the schema object has dedicated permissions, admins must be a member of the Schema Administrator group (Schema Admins).
Note that the DC that is holding the Schema Master Role is the only one allowed to write to it.

Step 2: Decide on method for Installing/executing Schema Extensions (http://technet.microsoft.com/en-us/library/cc961742.aspx)

If you have already used other AD integrations, this should be straightforward. We recommend using the LDIF script method

Step 3: Add and Modify a Schema Object (http://technet.microsoft.com/en-us/library/cc961575.aspx)

To add a new attribute to the schema, you first have to create a attribute object. The you will need to complete the following steps:

Select a name for the attribute (ProVision assumes that the name will be ‘sixConnGroup‘)
Get a valid Object Identifier (OID) from an issuing authority (http://msdn.microsoft.com/en-us/library/ms677620.aspx)
- Generate an Object Identifier
Document the attribute syntax
Confirm that the attribute should be single-value
Confirm the attribute indexing behavior
Decide if the attribute needs to be distributed to the Global Catalog

LDAP Schema — Example

attributetype (1.3.6.1.4.1.5023215.2.3.21 NAME 'sixConnGroup' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.3.6.1.4.1.5023215.2.4.2 NAME 'sixConnectPermissionsV2' DESC '6Connect Permissions Object v2' SUP top AUXILIARY MUST ( sixConnGroup ) )

LDAP User Example

SSH into your openLDAP server and create a new ‘ldif’ file. Example:

dn: cn=JoeSmith,ou=people,dc=6connect,dc=com
cn: JoeSmith
sn: JoeSmith
objectclass: top
objectclass: person
objectclass: sixConnectPermissionsV2
sixConnGroup: "Global Admins"
sixConnGroup: "IT Engineering"
sixConnGroup: "Sales"
sixConnGroup: "Customer Admin"
userPassword: testpass

To create a new user, make a new ldif file and change all instances of «JoeSmith» to whatever username you wish to create and update the password. Keep all of the object class definitions as listed above. Add a sixConnGroup declaration for each ProVision user group a user is in.

After the file is created, run the following command to add the new user to LDAP server:

 ldapadd -h [SERVER] -x -f [LDIF FILE] -D [ROOTDN] -w [ROOT PW] -v

Example:

 ldapadd -h localhost -x -f 6connect.ldif -D "cn=Manager,dc=6connect,dc=com" -w secret -v

The user will now be active in openLDAP and can be used to login to ProVision.

Test the LDAP Server

To query the LDAP server, run the following command on any server which has openLDAP enabled:

ldapsearch -b [BASE] -h [IPADDRESS] -D [DOMAIN] -w [PASSWORD] [USER]

Note: We have not been able to use a v6 address at with this tool, even though multiple sources say it should work.

At the end of the command where [USER] is specified, user or groups can be used (in LDAP format) to query.

Example:

ldapsearch -b "dc=6connect,dc=com" -h 50.240.195.129 -D "cn=Mayor,ou=people,dc=6connect,dc=com" -w testpass "cn=MajorMiner"

Configure ProVision for LDAP Authentication

To configure the use of LDAP authentication, follow the steps below.

Log into 6connect ProVision
Go to Settings Tab → Admin Settings -> Authentication
Select «LDAP» under «Authentication Options»
Move the LDAP Enable selector to the «ON» position.
Fill in the hostname or ip address, authentication port, LDAP Security, Auth DN, Fetch DN, and Filter DN.
1. Optionally, enter the LDAP Username and Password in order to allow ProVision to import LDAP Contacts and sync LDAP contact information (see: Contact Manager)
Click «Save Changes».

Example values in this case would be:

LDAP Enable: (Checked)
LDAP Server Address: 52.240.195.12
LDAP Port: 389 ( or SSL/TLS port is 636)
LDAP Security: None
LDAP Auth DN: cn=%LOGIN%,ou=people,dc=6connect,dc=com
LDAP Fetch DN: cn=%LOGIN%
LDAP Filter DN: cn=%LOGIN%

Setting default login authentication options

In the login screen, you would select the authentication method from the dropdown. If you like, you can set the default login option in the following way:

Go to the /data/globals.php and open in vi (or other editor). Add in the following text as the last line of the file (before the closing ?>)

define(‘DEFAULT_LOGIN_TYPE’, ‘radius’);

Acceptable values are «local», «radius» and «ldap». If this line is not present in globals.php, the default option is «local».

Using SSL encryption

To use SSL encryption with LDAP, the ldap.conf file must be correctly configured on the ProVision server.

Typically, the LDAP configuration file is kept at «/etc/ldap/ldap.conf». Make sure the following line is present:

TLS_REQCERT allow

and restart the webserver.

Add or Update LDAP Settings

To add or update LDAP settings, go to the Settings Tab → Admin to enter the Admin area.

Then, click the «Authentication» sub-tab at the top of the Admin Settings page, and select «LDAP» from the «Authentication Options» module.

Enter or update the following settings:

LDAP Enable: check the box to enable LDAP functionality.
LDAP Server Address: Set the IP address of your LDAP server.
LDAP Port: Set the port for your LDAP server
LDAP Security: Select the security method of your LDAP server — SSL, TLS or None
LDAP Auth DN/Fetch DN/Filter DN: These strings are used to first authentication the 6connect user and then to retrieve their permissions. The string ‘%LOGIN%’ should be inserted in place of the user’s common name both strings. (ex: cn=%LOGIN%,ou=people,dc=6connect,dc=com)
LDAP Group Attribute: If using an internal list of user groups instead of 6connect groups, enter the attribute name for the LDAP groups here. If a Group Attribute is set, it will be used first, otherwise the 6connect schema will be used.
LDAP Username / LDAP Password: Optionally, you may enter LDAP admin credentials to allow ProVision to import and sync LDAP contacts. See Contact Manager for details on LDAP contacts.
Mapping Permissions to 6connect schema: To integrate 6connect permissions with your existing directory structure then you will need the 6connect schema. It should snap in with any existing LDAP structure and allow you to assign 6connect permissions to your existing users. You can download a copy of the schema from this section.

Once at least one LDAP server has been added, a list will appear at the top of the Radius module. Add an additional Radius server by clicking «Add new server».

ProVision will try to connect to each server listed in the order listed, until a success is returned. Disabled servers will display in grey, and the currently selected server will display in bold.

When done, click «Save Changes».

Источник

Чтобы разобраться в том, что это за уязвимости, сперва нужно понять, как работает LDAP-аутентификация.

Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).

Недостатки LDAP как системы аутентификации

1. Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными

2. Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных

3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной

4. Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать

5. Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом

Ниже представлены примеры ужасов некорректной настройки.

Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
Отправка паролей в открытом виде на 389-й порт.
Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?

6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга

Какие есть варианты?

Источник

Авторизация внешних пользователей и систем через LDAP¶

TDG поддерживает технологию единого входа
(Single Sign-On)
– механизм аутентификации, позволяющий пользователям получать доступ к нескольким приложениям и сервисам c
одним набором учетных данных.
Это означает, что авторизоваться в TDG можно как через пользователей и
токены приложений, так и с использованием такого внешнего инструмента, как LDAP.

LDAP (Lightweight Directory Service Protocol) – открытый протокол
для хранения и получения данных из службы каталогов.
LDAP позволяет централизованно настраивать права доступа к данным.

В TDG доступны три способа настройка протокола LDAP:

в веб-интерфейсе TDG;
через конфигурационный файл config.yml;
через GraphQL API, в секции account_provider.

В этом руководстве рассмотрим первые два способа настройки протокола.

Для выполнения примера требуются:

настроенный кластер TDG;
настроенный сервер LDAP.

Примечание

Для локального тестирования LDAP-авторизации можно использовать сервер GLAuth.
Гарантируется работа с версией GLAuth 2.0.0

Руководство включает в себя следующие шаги:

Особенности конфигурации LDAP
Настройка LDAP в веб-интерфейсе
Настройка LDAP в файле конфигурации

Особенности конфигурации LDAP¶

По умолчанию, логин в систему – это строка вида user@domain, где:

user – пользователь LDAP, который состоит в определенном домене и организационном подразделении;
domain – домен LDAP.

Пример: tdguser@my.domain.ru.

Если подключена Active Directory, служба каталогов Microsoft,
для входа в систему используется адрес электронной почты пользователя LDAP.
В качестве фильтра при этом используется атрибут Active Directory userprincipalname=email,
где email – адрес электронной почты пользователя.

Каждый пользователь LDAP состоит в одной или нескольких группах LDAP (domain group).
Группе LDAP задается определенная роль (например, admin), которая определяет
права доступа для пользователя из этой группы.
Если пользователь LDAP состоит сразу в нескольких группах, он получает разрешения на действия из всех ролей, заданных
для этих групп.

Настройка LDAP в веб-интерфейсе¶

Добавим новую конфигурацию LDAP через веб-интерфейс TDG.

На вкладке Settings > LDAP нажмите кнопку Add Configuration.

Картинка с сайта: www.tarantool.io
В диалоговом окне LDAP укажите параметры, необходимые для вашей конфигурации:
- Domain – доменное имя, используемое в доменном логине пользователя (tdguser@my.domain.ru).
  Пример: my.domain.ru;
- Hosts – адрес подключения к серверу LDAP. Пример: server.my.domain.ru:389;
- Organizational units (опционально) – названия организационных подразделений или групп пользователей.
  Параметр будет пропущен, если для него не задано явное значение. Пример: tarantool;
- Options (опционально) – настройки LDAP. Параметр будет пропущен, если для него не задано явное значение;
- Roles – описание ролей, которые будут назначаться пользователю в зависимости от групп LDAP, в которых он
  состоит. Для каждой роли описаны название роли и соответствующие ей LDAP-группы.
  Описание LDAP-группы состоит из общего имени (CN), названия организационного подразделения или LDAP-группы (OU)
  и компонентов домена (DC).
  
  Пример: добавьте роль admin. Для нее в поле Domain Groups укажите значение
  CN=tarantool, OU=groups, OU=other_groups, DC=my, DC=domain, DC=ru;
- Search timeout (опционально) – время ожидания ответа от сервера LDAP в секундах.
  Значение по умолчанию: 2;
- Use TLS (опционально) – использование TLS.
  Значение по умолчанию: false;
- Use Active Directory (опционально) – использование Active Directory.
  Значение по умолчанию: false.
При настройке обратите внимание на параметры domain и organizational_units.
Эти параметры используются при аутентификации для поиска пользователя в соответствующем домене и организационном подразделении.

Полное описание параметров LDAP приведено в разделе ldap справочника конфигурации.
Нажмите кнопку Submit, чтобы добавить конфигурацию LDAP.
Чтобы войти в систему как пользователь LDAP, нажмите кнопку Log in в правом верхнем углу.
В диалоговом окне Authorization введите логин (вида user@domain) и пароль пользователя LDAP, затем
нажмите кнопку Login.

Настройка LDAP в файле конфигурации¶

Указать конфигурацию LDAP можно:

в общем конфигурационном файле (секция ldap в файле config.yml);
в отдельном файле ldap.yml.

Полное описание параметров LDAP приведено в разделе
ldap справочника конфигурации.

Пример конфигурации с включенными TLS и Active Directory:

ldap:
  - domain: 'my.domain.ru'
    organizational_units: ['tarantool']
    hosts:
      - server.my.domain.ru:389
    use_active_directory: true
    use_tls: true
    search_timeout: 2
    options:
      - LDAP_OPT_X_TLS_CACERTFILE: /certs/CA_Root.crt
    roles:
      - domain_groups:
          - 'cn=tarantool,ou=groups,ou=other_groups,dc=my,dc=domain,dc=ru'
        role: 'admin'

Созданный yml-файл с настройками конфигурации нужно упаковать в zip-архив и загрузить
в TDG согласно инструкции.

Нашли ответ на свой вопрос?

Обратная связь

Источник

У вас есть возможность для безопасного входа на портал с использованием Облегченного протокола доступа к каталогам (LDAP) или Windows Active Directory. При использовании LDAP учетные данные управляются с помощью сервера LDAP вашей организации. Когда вы используете Windows Active Directory управление учетными записями происходит с помощью Microsoft Windows Active Directory. Приступать к настройке аутентификации на уровне портала можно после обновления хранилища аутентификаций портала для LDAP или Active Directory.

Настройка организации для работы с HTTPS-коммуникацией

По умолчанию, ArcGIS Enterprise активирует HTTPS для всех подключений. Если вы ранее изменили этот параметр, чтобы разрешить обмен данными как по протоколу HTTP, так и по протоколу HTTPS, необходимо перенастроить организацию для использования связи только по протоколу HTTPS, выполнив следующие действия:

Войдите на веб-сайт портала в качестве администратора вашей организации. URL-адрес имеет вид https://webadaptorhost.domain.com/webadaptorname/home.
На странице Моя организация щелкните вкладку Настройки, затем щелкните Безопасность.
Отметьте опцию Разрешить доступ к порталу только с использованием HTTPS.
Нажмите Сохранить, чтобы применить изменения.

Обновление хранилища аутентификаций вашей организации

Затем обновите хранилище аутентификаций портала, чтобы оно использовало либо протокол LDAP, либо учетные записи и группы Active Directory.

Обновление хранилища аутентификаций с помощью LDAP

Войдите в Portal Administrator Directory в качестве администратора вашей организации. URL-адрес имеет формат https://webadaptorhost.domain.com/webadaptorname/portaladmin.
Щелкните Безопасность > Конфигурация > Обновить хранилище аутентификаций.
Вставьте в текстовое окно Настройка хранилища пользователей (в формате JSON) информацию о пользовательской конфигурации LDAP вашей организации (в формате JSON). Либо добавьте в следующий пример информацию вашей организации.
```
{
  "type": "LDAP",
  "properties": {
    "userPassword": "secret",
    "isPasswordEncrypted": "false",
    "user": "uid=admin,ou=system",
    "userFullnameAttribute": "cn",
    "userGivenNameAttribute": "givenName",
    "userSurnameAttribute": "sn",
    "ldapURLForUsers": "ldaps://myLdapServer:10636/ou=users,ou=ags,dc=example,dc=com",
    "userEmailAttribute": "mail",
    "usernameAttribute": "uid",
    "caseSensitive": "false",
    "userSearchAttribute": "uid"
  }
}
```
В большинстве случаев вам будет необходимо изменить только значения для параметров user, userPassword и ldapURLForUsers. URL для вашего LDAP должен предоставляться администратором LDAP.

В приведенном выше примере URL-адрес LDAP относится к пользователям в определенном OU (ou=пользователи). Когда пользователи существуют в нескольких OU, URL-адрес LDAP может указывать на более высокий уровень OU или даже, при необходимости, на корневой уровень. В этом случае URL-адрес будет выглядеть так:

«ldapURLForUsers»: «ldaps://myLdapServer:10636/dc=example,dc=com»,

Учетной записи, которую вы используете для параметров пользователя, необходимо иметь права доступа для просмотра адреса эл. почты и имен пользователей в вашей организации. Хотя вы вводите пароль в виде обычного текста, он будет зашифрован, когда вы щелкните Обновить хранилище аутентификаций (ниже).

Если ваш LDAP чувствителен к регистру, установите для параметра caseSensitive значение true.
Для того, чтобы создать группы, которые будут использовать существующие группы LDAP в вашем хранилище идентификаций, вставьте информацию о конфигурации группы LDAP вашей организации (в формате JSON) в текстовое окно Конфигурация хранилища групп (в формате JSON), как показано ниже. Либо добавьте в следующий пример информацию о группах вашей организации. Если вы хотите использовать только встроенные группы портала, удалите все из текстового поля и пропустите этот шаг.
```
{
  "type": "LDAP",
  "properties": {
    "userPassword": "secret",
    "isPasswordEncrypted": "false",
    "user": "uid=admin,ou=system",
    "ldapURLForUsers": "ldaps://myLdapServer:10636/ou=users,ou=ags,dc=example,dc=com",
    "ldapURLForRoles": "ldaps://myLdapServer:10636/dc=example,dc=com",
    "usernameAttribute": "uid",
    "caseSensitive": "false",
    "userSearchAttribute": "uid",
    "memberAttributeInRoles": "member",
    "rolenameAttribute":"cn"
  }
}
```
В большинстве случаев вам будет необходимо изменить только значения для параметров user, userPassword и ldapURLForUsers. URL для вашего LDAP должен предоставляться администратором LDAP.

В приведенном выше примере URL-адрес LDAP относится к пользователям в определенном OU (ou=пользователи). Когда пользователи существуют в нескольких OU, URL-адрес LDAP может указывать на более высокий уровень OU или даже, при необходимости, на корневой уровень. В этом случае URL-адрес будет выглядеть так:

«ldapURLForUsers»: «ldaps://bar2:10636/dc=example,dc=com»,

Учетной записи, которую вы используете для параметров пользователя, необходимо иметь права доступа для просмотра адреса эл. почты и имен пользователей в вашей организации. Хотя вы вводите пароль в виде обычного текста, он будет зашифрован, когда вы щелкните Обновить хранилище аутентификаций (ниже).

Если ваш LDAP чувствителен к регистру, установите для параметра caseSensitive значение true.
Щелкните Обновить хранилище аутентификаций, чтобы сохранить изменения.

Обновление хранилища аутентификаций с помощью Active Directory

Войдите в Portal Administrator Directory в качестве администратора вашей организации. URL-адрес имеет формат https://webadaptorhost.domain.com/webadaptorname/portaladmin.
Щелкните Безопасность > Конфигурация > Обновить хранилище аутентификаций.
Вставьте в текстовое окно Настройка хранилища пользователей (в формате JSON format) информацию о пользовательской конфигурации вашей Windows Active Directory (в формате JSON). Либо добавьте в следующий пример информацию вашей организации.
```
{
  "type": "WINDOWS",
  "properties": {
    "userPassword": "secret",
    "isPasswordEncrypted": "false",
    "user": "mydomain\\winaccount",
    "userFullnameAttribute": "cn",
    "userEmailAttribute": "mail",
    "userGivenNameAttribute": "givenName",
    "userSurnameAttribute": "sn",
    "caseSensitive": "false"
  }
}
```
В большинстве случаев вам будет необходимо изменить только значения для параметров userPassword и user. Хотя вы вводите пароль в виде обычного текста, он будет зашифрован, когда вы щелкните Обновить хранилище аутентификаций (ниже). Для учетной записи, которую вы задали для параметров пользователя, необходимы права доступа только для просмотра адреса электронной почты и полного имени учетных записей Windows в сети. Если возможно, задайте для учетной записи пароль, срок действия которого не истекает.

В тех редких случаях, когда Windows Active Directory чувствительна к регистру, установите для параметра caseSensitive значение true.
Чтобы создать группы на портале, которые будут использовать существующие группы Active Directory в вашем хранилище идентификаций, вставьте информацию о конфигурации группы Active Directory Windows вашей организации (в формате JSON) в текстовое окно Конфигурация хранилища групп (в формате JSON), как показано ниже. Либо добавьте в следующий пример информацию о группах вашей организации. Если вы хотите использовать только встроенные группы портала, удалите все из текстового поля и пропустите этот шаг.
```
{
  "type": "WINDOWS",
  "properties": {
    "isPasswordEncrypted": "false",
    "userPassword": "secret",
    "user": "mydomain\\winaccount"
  }
}
```
В большинстве случаев вам будет необходимо изменить только значения для параметров userPassword и user. Хотя вы вводите пароль в виде обычного текста, он будет зашифрован, когда вы щелкните Обновить хранилище аутентификаций (ниже). Для учетной записи, которую вы задали для параметров пользователя, необходимы права доступа только для просмотра имен групп Windows в сети. Если возможно, задайте для учетной записи пароль, срок действия которого не истекает.
Щелкните Обновить хранилище аутентификаций, чтобы сохранить изменения.

Настройка дополнительных параметров хранилища аутентификаций

Существуют дополнительные параметры хранилища аутентификаций, которые можно изменить используя Portal Administrator Directory. Эти параметры включают такие опции, как: будут ли автоматически обновляться группы при входе на портал пользователя организации, установка интервала обновления участников, а также опцию, которая определяет, будет ли производиться проверка форматов разных имен пользователей. Более подробно см. в разделе Обновление хранилища аутентификаций.

Настройка аутентификации веб-уровня

Когда портал будет настроен с Active Directory или хранилищем аутентификаций LDAP, необходимо включить анонимный доступ через веб-адаптер в IIS или сервер приложений Java. Когда пользователи открывают страницу входа в организацию, они могут выполнить вход с помощью корпоративных или встроенных учетных записей. Корпоративные пользователи должны будут вводить свои учетные данные при каждом входе на портал; автоматический вход и система единого входа недоступны. При этом типе аутентификации также разрешается анонимный доступ к картам и другим ресурсам организации, к которым предоставлен доступ для всех.

Убедитесь в доступности портала, используя учетные данные

Откройте портал ArcGIS Enterprise. URL-адрес имеет формат: https://webadaptorhost.domain.com/webadaptorname/home.
Войдите под учетной записью организации (см. ниже пример синтаксиса).

При использовании аутентификации уровня портала участники вашей организации будут заходить в систему, используя следующий синтаксис:

При использовании портала вместе с Active Directory синтаксис может быть domain\username или username@domain. Независимо от того, как входит участник, имя пользователя всегда отображается на веб-сайте портала как username@domain.
При использовании LDAP синтаксис зависит от usernameAtrribute, указанного в конфигурации хранилища пользователей. На веб-сайте портала всегда отображается учетная запись в этом формате.

Добавление на портал корпоративных учетных записей

По умолчанию корпоративные пользователи могут работать с веб-сайтом портала. Однако они могут лишь просматривать элементы, открытые для всех пользователей организации. Это связано с тем, что корпоративные учетные записи не были добавлены на портал, и им не были выданы права доступа.

Добавьте учетные записи в свою организацию, используя один из следующих способов:

Индивидуально или пакетно (по одному, пакетно из файла CSV или из существующих групп LDAP)
Утилита командной строки
Автоматически

Рекомендуется назначить хотя бы одну корпоративную учетную запись в качестве администратора портала. Это можно сделать, выбрав роль Администратор при добавлении учетной записи. Теперь, когда у вас появилась дополнительная учетная запись администратора портала, вы можете назначить учетной записи главного администратора роль Пользователя или удалить ее. Более подробно см. в разделе О учетной записи главного администратора.

После добавления учетных записей пользователи смогут входить в организацию и пользоваться ресурсами.

Отзыв по этому разделу?

Источник