Внешняя аутентификация ldap или windows

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

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

Сегодня в любой организации есть 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 следует рассматривать только при отсутствии других вариантов.

Every organization has a well-defined structure that defines employees’ roles and responsibilities in various departments such as sales, marketing, and IT. To effectively use enterprise resources and remain productive, organizations must develop access control measures. 

Active Directory (AD) authentication is one such measure you can use to manage users, applications, and other assets within the organization. When deployed, Active Directory authentication can simplify IT administration and enhance the overall security posture of the enterprise. Learn more about AD authentication, how it works, and how JumpCloud can help you improve its operations. 

What Is Active Directory Authentication?

AD authentication is a Windows-based system that authenticates and authorizes users, endpoints, and services to Active Directory. IT teams can use AD authentication to streamline user and rights management while achieving centralized control over devices and user configurations through the AD Group Policy feature. 

It also provides single sign-on (SSO) functionality, allowing users only to authenticate once and then seamlessly access any corporate resource in the domain for which they’re authorized. AD authentication is a successor to LAN Manager (LM) and NT LAN Manager (NTLM), protocols which were easily exploitable.

For example, LM used a fragile cryptographic scheme that modern processors could easily crack. Although NTLM — which succeeded LM — had some security enhancements around the strength of cryptography, it couldn’t provide mutual authentication and smart card authentication services. Due to these weaknesses, Microsoft replaced LM and NTLM protocols with AD starting with Windows 2000 Server operating systems (OSs). 

How Does Authentication Work in Active Directory?

Active Directory authentication is a process that supports two standards: Kerberos and Lightweight Directory Access Protocol (LDAP). 

1. Kerberos protocol

In a Kerberos-based AD authentication, users only log in once to gain access to enterprise resources. Instead of passing on the login credentials over the network, as is the case with LM and NTLM protocols, the Kerberos system generates a session key for the user. The generated session key lasts for a designated period, providing flexibility to users when it comes to authentication. 

Besides the session key, the Kerberos system also generates a token containing all the access policies and rights associated with the user. This ensures that users only access resources they are authorized to. 

If a client wants to connect to the AD server or the domain controller (DC) in this case, they must authenticate themselves to a key distribution center (KDC), which is a trusted third party. The KDC consists of two servers: authentication server (AS) and ticket granting server (TGS). The AS encrypts clients’ login credentials by using their password’s secret key. This is how the AS authenticates clients to the network.

After getting authenticated, the AS sends the user a ticket granting ticket (TGT), which is encrypted with a different secret key. When the client receives the TGT, it transmits it to the TGS alongside an authorization request to access the target resource on the server. The TGS then decrypts the TGT with its secret key that it shares with the AS. 

Next, the TGS issues a token to the client that it encrypts with another key. The third secret key is shared between the target server and TGS. Finally, the client transmits the received token to the target server. When the target server receives the token, it decrypts it with the TGS shared key to allow the client to access resources for a limited time (session). 

2. Lightweight Directory Access Protocol

LDAP is an open source and cross-platform protocol that provides AD authentication services. There are two options associated with LDAP-based authentication in AD:

• Simple authentication. In simple authentication, LDAP relies on login credentials to create a request to the server. It also supports anonymous and unauthenticated requests to corporate resources. 
• Simple authentication and security layer (SASL). The SASL approach uses other authentication services such as Kerberos to connect to the LDAP server. IT teams can use this method to enhance security because it separates authentication methods from application protocols.

Authenticating Linux Devices Through Active Directory

AD works seamlessly with Windows-based systems and services. While Windows may have dominated the OS market share in the 1990s, the same is not true today. Linux and macOS are now integral components in any IT infrastructure. As companies continue to leverage different OSs, the pressure to provide centralized access management becomes real. 

There are two primary methods you can leverage to connect Linux-based devices to AD.

LDAP

This approach requires the IT teams to reconfigure Linux-based devices to leverage the LDAP’s pluggable authentication module (PAM). Since AD authentication largely focuses on the Kerberos protocol, IT teams must manually manage the entire authentication process.

Samba

This is a standard Windows interoperability tool for Linux systems. IT teams can use Samba as an intermediary to support AD authentication in Linux machines. For example, IT teams can use the service to create domains, set up a shared print server, and configure PAM to allow users to authenticate to locally installed services. 

Authenticating Macs Through Active Directory

IT teams can use an LDAP and AD connector to configure Macs to access basic account details in AD DS (Active Directory Domain Services) infrastructures. These tools allow IT teams to leverage AD authentication to allow users access corporate resources from their Macs when deployed. AD connector can also provide federated SSO by mapping AD identities to macOS identity and access management (IAM) roles. 

For example, the AD connector can generate all the attributes needed to authenticate macOS devices to AD infrastructure. However, machines with macOS 10.12 or later cannot join an AD domain without domain services of at least Windows Server 2008. To use AD on such devices, IT teams must enable weak cryptography, which jeopardizes the organization’s security. 

Shortcomings of Active Directory Authentication

In the 1990s and early 2000s, most device management tools and systems were largely driven by on-prem Windows OSs, and AD authentication worked well with such IT environments. However, today’s OS landscape has increasingly become heterogeneous, with Linux and macOS platforms emerging on the scene as well as cloud-based infrastructure. 

Consequently, providing access controls and management in a heterogeneous IT environment has become a headache for IT teams in organizations. While legacy AD authentication can address IAM, it is far from efficient. In most cases, IT teams have been forced to use LDAP to authenticate Linux and macOS devices to AD, which creates an added layer to integrate and manage.

Essentially, organizations end up with multiple “mini directories” rather than one centralized and authoritative directory platform to offer authentication and authorization services. Besides heterogeneous OSs, the adoption rate for software-as-a-service (SaaS) applications and other cloud-based services has been dramatic in recent years.

This adoption comes with its own fair share of challenges in the IAM landscape. For example, most SaaS applications tend to be siloed, which complicates their management from an authorization perspective. Also, onboarding users in a SaaS-first environment is time-consuming and tedious because it involves users across multiple departments. 

Leverage JumpCloud Directory to Extend Active Directory Authentication in Heterogeneous IT Environments

JumpCloud is a comprehensive cloud-based directory platform that businesses can leverage to address the shortcomings of AD authentication in heterogeneous IT environments. You can use the JumpCloud Directory Platform to extend AD authentication to virtually all IT resources within the organization. You can also use JumpCloud to extend AD to the cloud or eliminate on-prem DCs entirely.

What Is LDAP Authentication? 

LDAP (Lightweight Directory Access Protocol) is a widely-used open directory services protocol, which allows computer systems to access user directory information over a network.. LDAP provides a way to organize information (often user authentication information) in a hierarchical manner and to access this information quickly.

LDAP authentication is a process of verifying the identity of a user by checking the provided credentials (username and password) against the data stored in an LDAP directory server. The directory server holds information about all authorized users in the system and their attributes such as passwords, names, and access privileges. 

When a user tries to log in, the system sends the user’s credentials to the directory server and the server validates the information. If the information matches what is stored in the directory, the user is granted access, otherwise the authentication request is denied.

In this article:

• Why Is LDAP Important for Authentication?
• LDAP vs. Active Directory: What Is the Difference?
• How LDAP Authentication Works
• LDAP Authentication Code Examples
  • Simple Authentication
  • Authentication with Two Organizational Units (OUs)
• Authentication and Authorization with Frontegg

Why Is LDAP Authentication Important? 

The following are some of the key benefits of using LDAP for authentication:

• Centralized management: With LDAP, user authentication information is stored in a centralized location, making it easier to manage and update.
• Scalability: LDAP is designed to handle large volumes of user authentication data, making it an ideal solution for large organizations with many users.
• Interoperability: LDAP is a standard protocol and is supported by many different platforms, making it easy to integrate with other systems and applications.
• Security: LDAP uses encryption for transmitting authentication information, ensuring that user credentials are protected during transmission.
• Efficiency: LDAP is designed to be fast and efficient, making it well-suited for real-time authentication requests.

LDAP vs. Active Directory: What Are the Differences?

Active Directory is a directory service created by Microsoft for use in Windows-based networks. It provides centralized management of resources, including users, computers, and other network devices, and is designed to make administration and management of large, complex enterprise networks easier.

LDAP and Active Directory are both directory services used for managing and organizing information, but they have some key differences, including:

	LDAP	Active Directory
Purpose	Open, vendor-neutral directory protocol	Microsoft-specific directory service for Windows-based networks
Functionality	Mainly focused on directory services, often used for authentication	Comprehensive directory service including authentication, authorization, etc.
Scalability	Basic scalability features	Advanced scalability features, such as multiple domain controllers and replication
Integration	Can be integrated with a wide range of technologies	Tightly integrated with other Microsoft technologies, such as Windows Server
Security	Supports encryption for secure transmission of data	Supports advanced security features, such as fine-grained access control
Ease of Administration	Basic administration tools	Advanced administration tools and a graphical user interface

To summarize, LDAP is a basic directory protocol that is often used for authentication, while Active Directory is a comprehensive directory service that is well-suited for large, complex enterprise networks. The choice between the two will depend on the specific requirements of the organization.

How Does LDAP Authentication Work? 

LDAP authentication typically works as follows:

1. The user provides their credentials (username and password) to the system.
2. The system sends a bind request to the LDAP server, containing the user’s credentials.
3. The LDAP server checks the user’s credentials against the data stored in its directory.
4. If the credentials match, the server sends a success message to the system, indicating that the user has been authenticated.
5. The system grants the user access to the requested resource.
6. If the credentials do not match, the server sends a failure message to the system, indicating that the user has not been authenticated.
7. The system denies the user access to the requested resource.

LDAP uses encryption to protect the transmission of user credentials between the system and the LDAP server, ensuring that sensitive information is kept secure. Additionally, the LDAP directory is designed to be highly available and reliable, to ensure that user authentication requests can be processed quickly and efficiently.

LDAP Authentication Code Examples 

Simple Authentication

The code below uses the Python ldap library to connect to the Active Directory server and verify the user’s credentials. If the bind is successful, the user’s credentials are correct, and the function returns True. If the bind fails due to invalid credentials, the function returns False. If something else goes wrong, an error message is printed, and the function returns False.

The code looks like this:

import ldap

def authenticate(username, password):
    ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
    server = "ldaps://ldap.example.com:636"
    base_dn = "dc=example.com"
    user_dn = "uid={},{}".format(username, base_dn)
    try:
        l = ldap.initialize(server)
        l.protocol_version = ldap.VERSION3
        
        l.simple_bind_s(user_dn, password)

If the bind was successful:

        return True
    except ldap.INVALID_CREDENTIALS:

If the bind failed:

        return False
    except ldap.LDAPError as error:
        print("Error:", error)
        return False

Authentication with Two Organizational Units (OUs)

The code below is similar to the previous example, with one key difference: the user_dn is specified with two organizational units (OUs), ou=users and ou=intranet. This makes it possible to have separate user directories for different parts of the organization. 

The ou=intranet OU ensures that only users within the intranet can authenticate, while the ou=users OU narrows it down to the specific user directory. The rest of the code remains the same, performing the LDAP bind and checking the user’s credentials.

Here’s an example of how to perform LDAP authentication using Active Directory with a compartmentalized intranet in Python:

import ldap

def authenticate(username, password):
    ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
    server = "ldaps://ldap.example.com:636"
    base_dn = "dc=example.com"
    user_dn = "uid={},ou=users,ou=intranet,{}".format(username, base_dn)

    try:
        l = ldap.initialize(server)
        l.protocol_version = ldap.VERSION3
        l.simple_bind_s(user_dn, password)

If the bind was successful, the credentials are correct:

        return True
    except ldap.INVALID_CREDENTIALS:

If the bind failed, the credentials are incorrect:

    return False
    except ldap.LDAPError as error:

If something else went wrong and the authentication failed:

 print("Error:", error)
        return False
    finally:
        # close the connection to the server
        l.unbind_s()

Authentication and Authorization with Frontegg

The industry standard today is to use Authentication providers to “build the door”, but what about Authorization (the door knob)? Most authentication vendors don’t go that extra mile, forcing SaaS vendors to invest in expensive in-house development. This often delays investment in core technology development, which negatively impacts innovation and time-to-market (TTM) metrics. 

Frontegg’s end-to-end user management platform allows you to authenticate and authorize users with just a few clicks. Integration takes just a few minutes, thanks to its plug-and-play nature. It’s also multi-tenant by design. 

Start For Free