Меню

настройка ldap сервера windows 2008

Включение LDAPS на контроллере домена под управлением Windows Server 2008 R2

Исходные данные:

  • организация, использующая в качестве базы данных сотрудников Microsoft Active Directory, базирующуюся на Windows Server 2008 R2 контроллере домена;
  • написанная на php информационная система, поддерживающую протокол LDAP для взаимодействия с MS AD (например, Moodle).

Проблема: при соединении с AD по протоколу LDAP (порт 389) не работает функция php для смены пароля пользователю AD. Решением является переход на SSL-версию протокола — LDAPS (порт 636). На поиск способа включить поддержку LDAPS на контроллере домена было потрачено приличное количество времени, сэкономить которое может помочь данная статья.

Шаг 1, установка служб сертификатов на контроллер домена.

Заходим в панель управления сервером (Start — Administrative Tools — Server Manager). Add Roles — Active Directory Certificate Services — Next — Next — отмечаем Certification Authority Web Enrollment (Add Required Role Services) — Next — Enterprise — Next — Root CA — далее Next до конца.

Шаг 2, запрос на сертификат.

Создаём файл request.inf с текстом:
[Version]
Signature= «$Windows NT$»

[NewRequest]
KeySpec = 1
KeyLength = 1024
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
OID=1.3.6.1.5.5.7.3.2

[Extensions]
2.5.29.17=MDiCFURDNC5sb3JlLnVuaS1kdWJuYS5ydaAfBgkrBgEEAYI3GQGgEgQQhePOUDQ+
_continue_=7Uy5GtDgYOzldA==
Critical=2.5.29.17

Затем выполняем
certreq -new request.inf request.req

Шаг 3, получение сертификата у CA.

Вот тут самое интересное. Если попробовать разместить запрос на сертификат штатным способом, т.е. через MMC snap-in «Certification Authority» или командой
certreq -attrib «CertificateTemplate:DomainController» request.req , получаем ошибку «The DNS name is unavailable and cannot be added to the Subject Alternate name. 0x8009480f», которую обойти никаким способом так и не удалось. Зато сработала выдача сертификата через веб.
Заходим на localhost/certsrv/certrqxt.asp и вставляем в первое поле код из файла request.req; в поле Certificate Template выбираем Web Server. Скачиваем получившийся сертификат по ссылке Download certificate.

Шаг 4, импорт сертификата.

Winkey+R — mmc; нажимаем Ctrl+M, Certificates — Add — Computer Account — Next — Local Computer — Finish — OK. Certificates (local computer) — Personal — Certificates (правой кнопкой) — All Tasks — Import. Указываем файл, сделанный на шаге 3.

Шаг 5, проверка.

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

источник

Enabling LDAPS on Windows 2008 Active Directory Server

I installed Active Directory by selecting the “Active Directory Domain Services” Role from the Server Manager Dialogue. Step by step instructions can be seen in Deploying a Test Windows Environment in a KVM Infrastucture.

Читайте также:  настройка велосипеда под свой рост

Running an ldapsearch against a Windows AD Server

After you installed AD you can confirm that it’s listening on port 389:

We can see it’s listening on port 389 and there are some local connections to that port for the AD server. Now let’s go ahead and add a test LDAP user for our queries.

Add New User to AD via the “Active Directory Users and Computers” Console

To start the “Active Directory Users and Computers” Console, execute the following command from the run dialogue:

At which point you will see the following window:

Then right click in the white space and go to “New” -> “User”:

Then fill out the User information:

Lastly set the user’s password:

After it’s all said and done you will see the following in the “Active Directory Users and Computers” Console:

So our test user will be elatov.

Use ldp.exe to browse the AD Server

From the run dialogue run:

and you will see the following:

Now let’s bind to the AD server, since we are local to the AD server we can just bind with the same user that we are currently logged in:

and let’s leave the defaults:

After clicking OK, you will see the connection go through and the bind to the AD server succeed:

Now let’s start browsing the AD server, first let’s select the “Tree” view:

After that we need to choose the BaseDN, this is basically where we want to start the search. We will choose dc=elatov,dc=local, which is basically the root of the AD server.

I just want to see all the available branches/children that are part of the AD server:

Expanding the User branch and locating our test user “elatov”, we see the following:

We can see that the DN (Distinguished Name) of the test user is:

From now one since we know all the users are under “CN=Users,DC=elatov,DC=local” we will use that as our BaseDN, this way we don’t have to query the whole AD structure.

Use dsquery to find DNs of Users

There is a command line utility called dsquery, which shows a more succinct view. For example to find the DN of our user, we can run the follow command from the command prompt:

If you want to find out all the available groups in an AD server, you can run the following:

Use openldap Tools to perform an LDAP Query

There are a couple of versions of LDAP clients for Linux:

Читайте также:  плагин для настройки консоли в wordpress

Usually the location of the binary will let you know which one you have. For example here are two binaries on the same system:

RedHat mostly uses the Mozilla version. From “LDAP Tool Locations”:

For all Red Hat Directory Server guides and documentation, the LDAP tools used in the examples, such as ldapsearch and ldapmodify, are the Mozilla LDAP tools. For most Linux systems, OpenLDAP tools are already installed in the /usr/bin/ directory.

The two different versions have different arguments so make sure you know which one you are using. Let’s perform an LDAP query with openldap tools first:

We can see that I used “CN=Users,DC=elatov,DC=local” as my baseDN and I used the account “[email protected]” to bind to the AD server. I could also use the elatov account to bind with, for example:

Notice this time I just grabbed the name field to narrow down the search results.

Use mozldap Tools to perform an LDAP Query

Here is the same query as above using the Mozilla LDAP tools:

For now only the password arguments are different.

Enabling LDAPS on the AD Server

After installing the “Active Directory Domain Services” role, it actually starts the AD Server on the Secure port (636):

But since we have not uploaded an appropriate certificate it won’t work properly.

LDAPS Prerequisites

The list is available at Event ID 1220 — LDAP over SSL, from that page:

Certificate must be valid for the purpose of Server Authentication. This means that it must also contains the Server Authentication object identifier (OID): 1.3.6.1.5.5.7.3.1

The Subject name or the first name in the Subject Alternative Name (SAN) must match the Fully Qualified Domain Name (FQDN) of the host machine, such as Subject:CN=server1.contoso.com.

The host machine account must have access to the private key.

I had recently created my own certificate with my own CA. Check out “certificate_properties.c source file here are the different OIDs defined:

So let’s fire up gnomint and check to see if I was lucky enough to allow this certificate to be used for a “TLS WWW Server”. To check out if the certificate can be used for that functionality, right click on the certificate and select Properties:

Then click on the “Details” tab, expand the “Extensions”, and lastly expand the “Extended Key Usage” section:

Yay! I was lucky enough to leave that option enabled. I was using a wild certificate so the subject name would match as well. Now let’s follow the instructions from the above Microsoft page to import the certificate.

Читайте также:  intel 82579lm настройка vlan

Import a Certificate into the AD DS Personal Store

1. Open Microsoft Management Console (MMC).

From the Run dialogue, enter:

2.Click File, click Add/Remove Snap-in, select Certificates from the available snap-ins, and then click Add:

3. In Add or Remove Snap-ins, click Service account to view the certificates that are stored in the service’s personal store, and then click Next:

4. In Add or Remove Snap-ins, click Local computer, and then click Next.

5. In Add or Remove Snap-ins, click Active Directory Domain Services, click Finish, and then click OK:

6. In the console tree, expand Certificates — Service (Active Directory Domain Services), expand Personal, and then expand Certificates:

7. To import a certificate, right-click the NTDS\Personal folder, click All Tasks, and then click Import:

After the certificate is imported you will see the following in the Snap-In:

Since this a self-signed certificate make sure you follow the instructions laid out in “Setup Your Own Certificate Authority (CA) on Linux and Use it in a Windows Environment” to import your own CA Certificate under the regular Certificate store. Just launch:

and make sure your CA is in the “Trusted Root Certificate Authorities” folder:

Test LDAPS Connection with ldp.exe

Start ldp.exe, go to “Connection” -> “Connect”, and fill out the necessary information and make sure SSL is chosen:

Then click OK and make sure the connection is successful:

Perform LDAPS Query with OpenLDAP tools

If we try the regular search, we will get this error:

Since we are using a self-signed certificate, this is expected. From the man page of ldap.conf, we have the following options:

I had the certificate, but didn’t want to bother with the TLS Verification, so I just ignored it:

The main difference are between SSL and non-SSL openldap’s ldapsearch were:

  • -H to specify the URI of the AD server
  • -x to use simple authentication instead of SASL
  • -LLL to get a more succinct search result

Perform LDAPS Query with MozLDAP tools

Initially the query had the following error:

with MozLDAP it actually uses NSS to verify the SSL certificates and unfortunately you can’t ignore the verification (or I didn’t find a way). So let’s go ahead and generate a brand new NSSDB:

Now let’s put in our CA into the NSSDB:

Now let’s make sure it’s there:

Now let’s do the actual LDAP query with MozLDAP over LDAPS:

Now we have confirmed in many different ways that LDAPS on the AD server is working.

источник

Добавить комментарий

Adblock
detector