Настройка ldap windows server 2012 r2

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

Так, например, операция смены пароля должна обязательно осуществляться через безопасный канал (например Kerberos или SSL/TLS). Это означает, что например, с помощью функции-php, обеспечивающей работу с AD по протоколу LDAP изменить пароль пользователя в домене не удастся.

Защитить данные, передаваемых по протоколу LDAP между клиентом и контроллером домена можно с помощью SSL версии протокола LDAP – LDAPS, который работает по порту 636 (LDAP «живет» на порту 389). Для этого на контроллере домена необходимо установить специальный SSL сертификат. Сертификат может быть как сторонним, выданным 3-ей стороной (например, Verisign), самоподписанным или выданным корпоративным центром сертификации.

В этой статье мы покажем, как с помощью установки сертификата задействовать LDAPS (LDAP over Secure Sockets Layer) на котроллере домена под управление Windows Server 2012 R2. При наличии требуемого сертификата служба LDAP на контроллере домена может устанавливать SSL соединения для передачи трафика LDAP и трафика сервера глобального каталога (GC).

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

Предположим, в вашей инфраструктуре уже развернут корпоративный удостоверяющий сервер Certification Authority (CA). Это может быть как полноценная инфраструктура PKI, так и отдельной-стоящий сервер с ролью Certification Authority.

На севере с ролью Certification Authority запустите консоль Certification Authority Management Console, выберите раздел шаблонов сертификатов (Certificate Templates ) и в контекстном меню выберите Manage.

Найдите шаблон Kerberos Authentication certificate и создайте его копию, выбрав в меню Duplicate Template.

На вкладке General переименуйте шаблон сертификата в LDAPoverSSL, укажите период его действия и опубликуйте его в AD (Publish certificate in Active Directory).

На вкладке Request Handling поставьте чекбокс у пункта Allow private key to be exported и сохраните шаблон.

На базе созданного шаблона, опубликуем новый тип сертификата. Для этого, в контекстном меню раздела Certificate Templates выберем пункт New -> Certificate Template to issue.

Из списка доступных шаблонов выберите LDAPoverSSL и нажмите OK.

На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).

В списке доступных сертификатов выберите сертификат LDAPoverSSL и нажмите Enroll (выпустить сертификат).

Следующее требование – необходимо, чтобы контроллер домена и клиенты, которые будут взаимодействовать через LDAPS доверяли удостоверяющему центру (CA), который выдал сертификат для контроллера домена.

Если это еще не сделано, экспортируем корневой сертификат удостоверяющего центра в файл, выполнив на сервере с ролью Certification Authority команду:
certutil -ca.cert ca_name.cer

Совет. Файл сертификата сохранится в профиле текущего пользователя и в нашем случае имеет имя ca_name.cer.

А затем добавьте экспортированный сертификат в контейнере сертификатов Trusted Root Certification Authorities хранилища сертификатов на клиенте и контроллере домена. Сделать это можно через вручную через оснастку управления сертификатами, через GPO или из командной строки (подробнее здесь).

certmgr.exe -add C:ca_name.cer -s -r localMachine ROOT


Необходимо перезапустить службы Active Directory на контроллере домена, либо целиком перезагрузить DC.

Осталось протестировать работу по LDAPS. Для этого на клиенте запустим утилиту ldp.exe и в меню выбираем Connection-> Connect->Укажите полное (FQDN) имя контроллера домена, выберите порт 636 и отметьте SSL -> OK. Если все сделано правильно, подключение должно установиться.

Примечание. Утилита ldp.exe на клиентах устанавливается в составе пакета Remote Server Administration Kit (RSAT): RSAT для Windows 10, для 8.1.

First published on MSDN on Apr 10, 2017


Step-by-step guide for setting up

LDAPS

(LDAP over SSL)

The guide is split into 3 sections :

1. Create a Windows Server VM in Azure
2. Setup LDAP using AD LDS (Active Directory Lightweight Directory Services)
3. Setup LDAPS (LDAP over SSL)

NOTE : The following steps are similar for Windows Server 2008, 2012, 2012 R2 , 2016. In this article, we will use Windows Server 2012 R2.

Create a Windows Server VM in Azure

Create a VM named “ldapstest” Windows Server 2012 R2 Datacenter Standard DS12 using the instructions here:

Create a Windows virtual machine with the Azure portal

Connect to the VM ldapstest using Remote Desktop Connection.

Setup LDAP using AD LDS

Now let us add AD LDS in our VM ldapstest

Click on Start —> Server Manager —> Add Roles and Features. Click Next.

Choose Role-based or feature-based installation. Click Next.

Select ldapstest server from the server pool. Click Next.

Mark Active Directory Lightweight Directory Services from the list of roles and click Next.

From the list of features, choose nothing – just click Next.

Click Next.

Click Install to start installation.

Once installation is complete, click Close.

Now we have successfully set up AD LDS Role. Let us create a new AD LDS Instance “CONTOSO” using the wizard. Click the “Run the Active Directory Lightweight Directory Services Setup Wizard” in the above screen. And then Click Close.

Choose Unique Instance since we are setting it up for the first time.

Type “CONTOSO” in Instance Name and click Next.

By Default, LDAP Port is 389 and LDAPS port is 636, let us choose the default values — click Next.

Create a new Application Directory Partition named “CN=MRS,DC=CONTOSO,DC=COM”. Click Next.

Using the default values for storage location of ADLDS files- Click Next.

Choosing Network Service Account for running the AD LDS Service.

You will receive a prompt warning about data replication. Since we are using a single LDAP Server, we can click Yes.

Choosing the currently logged on user as an administrator for the AD LDS Instance. Click Next.

Mark all the required LDIF files to import (Here we are marking all files). Click Next.

Verify that all the selections are right and then Click Next to confirm Installation.

Once the instance is setup successfully, click Finish.

Now let us try to connect to the AD LDS Instance CONTOSO using ADSI Edit.

Click on Start —> Search “ADSI Edit” and open it.

Right Click on ADSI Edit Folder (on the left pane) and choose Connect To.. . Fill the following values and Click OK.

If the connection is successful, we will be able to browse the Directory CN=MRS,DC=CONTOSO,DC=COM :

Setup LDAPS (LDAP over SSL)

The Certificate to be used for LDAPS must satisfy the following 3 requirements:

• 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=contosoldaps. For more information, see How to add a Subject Alternative Name to a secure LDAP certificate .

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

Now, let’s use Active Directory Certificate Services to create a certificate to be used for LDAPS. If you already have a certificate satisfying the above requirements, you can skip this step.

Click on Start —> Server Manager —> Add Roles and Features. Click Next.

Choose Role-based or feature-based installation. Click Next.

Select ldapstest server from the server pool. Click Next.

Choose Active Directory Certificate Services from the list of roles and click Next.

Choose nothing from the list of features and click Next.

Click Next.

Mark “Certificate Authority” from the list of roles and click Next.

Click Install to confirm installation.

Once installation is complete, Click Close.

Now let’s create a certificate using AD CS Configuration Wizard. To open the wizard, click on “Configure Active Directory Certificate Services on the destination server” in the above screen. And then click Close. We can use the currently logged on user azureuser to configure role services since it belongs to the local Administrators group. Click Next.

Choose Certification Authority from the list of roles. Click Next.

Since this is a local box setup without a domain, we are going to choose a Standalone CA. Click Next.

Choosing Root CA as the type of CA, click Next.

Since we do not possess a private key – let’s create a new one. Click Next.

Choosing SHA1 as the Hash algorithm. Click Next.

UPDATE : Recommended to select the most recent hashing algorithm since

SHA-1 deprecation countdown

The name of the CA must match the Hostname (requirement number 2). Enter “LDAPSTEST” and Click Next.

Specifying validity period of the certificate. Choosing Default 5 years. Click Next.

Choosing default database locations, click Next.

Click Configure to confirm.

Once the configuration is successful/complete. Click Close.

Now let us view the generated certificate.

Click on Start à Search “Manage Computer Certificates” and open it.

Click on Personal Certificates and verify that the certificate “LDAPSTEST” is present:

Now to fulfill the third requirement, let us ensure host machine account has access to the private key. Using the Certutil utility, find the Unique Container Name. Open Command Prompt in Administrator mode and run the following command: certutil -verifystore MY

The private key will be present in the following location C:ProgramDataMicrosoftCryptoKeys<UniqueContainerName>

Right Click C:ProgramDataMicrosoftCryptoKeys874cb49a696726e9f435c1888b69f317_d3e61130-4cd8-4288-a344-7784647ff8c4 and click properties —> Security and add read permissions for NETWORK SERVICE.

We need to import this certificate into JRE key store since our certificate “CN=LDAPSTEST” is not signed by any by any trusted Certification Authority(CA) which is configured in you JRE keystore e.g Verisign, Thwate, goDaddy or entrust etc. In order to import this certificate using the keytool utility, let us first export this cert as a .CER from the machine certificate store:

Click Start —> Search “Manage Computer Certificates” and open it. Open personal, right click LDAPSTEST cert and click “Export”.

This opens the Certificate Export Wizard. Click Next.

Do not export the private key. Click Next.

Choose Base-64 encoded X .509 file format. Click Next.

Exporting the .CER to Desktop. Click Next.

Click Finish to complete the certificate export.

Certificate is now successfully exported to “C:UsersazureuserDesktopldapstest.cer”.

Now we shall import it to JRE Keystore using the keytool command present in this location:

C:Program FilesJavajre1.8.0_92binkeytool.exe.

Open Command Prompt in administrator mode. Navigate to “C:Program FilesJavajre1.8.0_92bin” and run the following command:

keytool -importcert -alias «ldapstest» -keystore «C:Program FilesJavajre1.8.0_92libsecuritycacerts» -storepass changeit -file «C:UsersazureuserDesktopldapstest.cer»

Type “yes” in the Trust this certificate prompt.

Once certificate is successfully added to the JRE keystore, we can connect to the LDAP server over SSL.

Now let us try to connect to LDAP Server (with and without SSL) using the ldp.exe tool.

Connection strings for

LDAP:\ldapstest:389

LDAPS:\ldapstest:636

Click on Start —> Search ldp.exe —> Connection and fill in the following parameters and click OK to connect:

If Connection is successful, you will see the following message in the ldp.exe tool:

To Connect to LDAPS (LDAP over SSL), use port 636 and mark SSL. Click OK to connect.

If connection is successful, you will see the following message in the ldp.exe tool:

REFERENCES

https://technet.microsoft.com/en-us/library/cc770639(v=ws.10)

https://technet.microsoft.com/en-us/library/cc725767(v=ws.10).aspx

http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate….

https://blogs.technet.microsoft.com/askds/2008/03/13/troubleshooting-ldap-over-ssl/

http://javarevisited.blogspot.com/2011/11/ldap-authentication-active-directory.html

Welcome back to our two-part series on how to enable secure LDAP (LDAPS) communications between client/server applications on Windows Server 2008/2012 domain controllers. In part one, I went over what you should know about LDAPS, your options, and prerequisites. After we understood the concepts of why, where and when we should be looking to use LDAPS, let’s move on to the actual configuration.

Enabling Secure LDAP: Configuring LDAPS

1. Create the right certificate template to issue
First, we need to make sure that your CA is allowed to issue the correct types of certificates. Remember, these must contain the Server Authentication OID 1.3.6.1.5.5.7.3.1.
I’ve described the steps you need to take in order to create such a template in my Creating a Digital Certificate Template for the purpose of Server Authentication in Windows Server 2008/R2/2012 article.
2. Request a certificate for server authentication
To request a certificate from your LDAPS server, do the following on each DC that requires LDAPS connections:

• In Start, type MMC, and then press Enter. If User Account Control prompts it, go ahead and ensure it displays the action you want. After that, select Yes.
• In the MMC console that opens, click File and then click Add/Remove Snap-in.

• Under Available Snap-ins, in Add or Remove Snap-ins, go ahead and select Certificates, and then click Add.

• In the Certificates snap-in, select Computer account and then click Next.

Note: If you plan to have more than one digital certificate for that DC, and if you are using Windows Server 2008/R2/2012, please read this following article BEFORE you proceed: The issue with Active Directory Domain Services (NTDSPersonal) certificate store
If you only plan to have one digital certificate on that DC, please proceed to the next step.

• In Select Computer, select Local. Once you have the correct computer selected, click OK and then click Finish.

• In Add or Remove Snap-ins, select OK.

• In the console tree, expand Certificates (<computer>), right-click Certificates, click All Tasks, and then click Request New Certificate. Note: You cannot do this if you’re connected to a remote DC.

In Certificate Enrollment, click Next.

In the Select Certificate Enrollment Policy, choose Active Directory Enrollment Policy (default) and click Next.

• Select a certificate that allows for server authentication. You may want to use a custom certificate as described in Publishing a Certificate that Supports Server Authentication. Now go ahead and click Enroll.

• The process may take a few seconds to complete. Click Finish in the Certificate Enrollment dialog box. Now you have a digital certificate for the first DC!

• To check your shiny new certificate, in the results pane double-click the certificate that you received to open Certificate properties.

Click the Details tab. In the Field column, go ahead and select Enhanced Key Usage. You’ll want to confirm that the Server Authentication (1.3.6.1.5.5.7.3.1) is listed.

• Repeat this on all the DCs on which you need to enable LDAPS.

Test the LDAP over a TLS Connection

To test if LDAP over TLS works properly, use the ldp.exe tool.
Note: If ldp.exe is not available on your system, you will need to install the Active Directory Directory Services (AD-DS) management tools from the Windows Remote Server Administration Kit (RSAT):
Download Remote Server Administration Tools for Windows 7 with SP1Download Remote Server Administration Tools for Windows 8

• Open a command prompt and type ldp. Click Enter. The LDP application window appears.
• Select Connection, then Connect. The Connect dialog box appears.
• In the Server text box, type the name of your AD server. For this example, type the fully qualified domain name (FQDN) of the DC, just as it appears in the Subject Alternative Name (SAN) of the Digital Certificate.
• In the Port text box, type 636.
• Check the box for SSL.

• Click OK. Now, without the above procedure you will not be able to connect.

After the procedure, note that “Host supports SSL, SSL cipher strength = 128 bits”.

Note: If you try to connect to the right DC but do not use the same FQDN as was listed inside the issued certificate (for example, using the IP address instead), you will not be able to connect using LDAPS.

• Select the Connection menu, click Bind, and then click OK.

The command output should display the user name and domain name that you used for binding, if LDAPS is configured properly. You can start browsing through the AD tree.

If you use the command: netstat -no | find “:636”, you will find the connection to the DC.

Enjoy.

Данная глава руководства администратора рассказывает о
возможности импорта объектов ARTA Synergy из
сторонних каталогов посредством
Active Directory. В ней детально описано как
настроить и эксплуатировать LDAP а рамках
ARTA Synergy.

Для работы с LDAP-каталогами возможно
использовать любой клиент с поддержкой
LDAP-протокола. Одним их таких клиентов
является JXplorer.

JXplorer — кроссплатформенный
LDAP браузер и редактор с поддержкой
безопасности (в том числе SSL,
SASL и GSSAPI), перевода
на многие языки, онлайн-помощью, коммерческой поддержкой,
пользовательскими формами и многими другими возможностями.

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

Рассмотрим его функциональность на примере поиска пользователя в
одном из каталогов.

Для конфигурирования синхронизации используется файл
/opt/synergy/jboss/standalone/configuration/arta/ldap-sync.xml.

ARTA Synergy поддерживает одновременную
синхронизацию с несколькими LDAP каталогами.
Вся конфигурация хранится в одном файле и разделена на секции
(item). Секции же должны иметь уникальный
номер (ID). По умолчанию файл содержит две
секции — первая для OpenLDAP, вторая для
Active Directory. Данные секции указаны для
примера и отключены.

Обозначения тегов:

Конфигурационный файл
ldap-sync.xml с полями
<code> и
<application>

?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration xmlns="http://www.arta.kz/xml/ns/as/ldap-sync"
  <!-- ... -->
  <!-- синхронизация с OpenLDAP -->
  <item>
    <!-- ... -->
    <group>
      <!-- ... -->
      <!-- поле ldap, из которого будет записан код группы -->
      <code>group_code</code>
      <!-- код приложения, куда будет записана группа -->
      <application>app1</application>
    </group>
  </item>
  <!-- ... -->
<configuration>

* - если параметр пуст или отсутствует, в код группы записывается `ldap_$sha1($DN)`, 

т. е. префикс ldap и sha1-хэш от
Distiguished Name объекта. Можно записать в
<code> название атрибута LDAP, из
которого будет взят код группы. При импорте для кода проводится
валидация на уникальность и соответствие правилам кода. Если
валидация не прошла, невалидная группа пропускается, в лог
записывается ошибка, а импорт продолжается.

** - обязательный параметр, может использоваться несколько раз. Код группы в Synergy 

будет сформирован по следующим правилам:

Файл конфигурации представлен в одной их следующих версий:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <configuration
        xmlns="http://www.arta.kz/xml/ns/as/ldap-sync"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.arta.kz/xml/ns/as/ldap-sync ldap-sync.xsd">
    <!-- синхронизация с OpenLDAP -->
    <item>
       <!-- id синхронизации -->
       <id>1</id>
       <!-- домен -->
       <domain>test.ldap.com</domain>
       <!-- синхронизация -->  
       <sync>
            <!-- LDAP хост -->
            <host>10.20.30.1</host>
            <!-- учетная запись для подключения к каталогу LDAP -->
            <user-dn>cn=syncuser,dc=test,dc=ldap,dc=com</user-dn>
            <!-- пароль -->
            <password>password</password>
            <!-- активно, неактивно -->
            <active>false</active>
            <!-- интервал синхронизации в мс -->
            <interval>1800000</interval>
            <!-- расписание синхронизации; параметр указан, поэтому интервал синхронизации игнорируется -->
            <schedules>19:00,00:00</schedules>
            <!-- следовать ссылкам -->
            <referral>ignore</referral>
            <!-- код группы пользователей, в которую будут включены все импортированные пользователи -->
            <defaultGroup>client_access</defaultGroup>
            <!-- предоставлять ли импортированным пользователям доступ в систему, пока позволяет лицензия --> 
            <!-- после превышения лимита пользователи будут импортированы, но у них будет заблокирован доступ в систему --> 
            <defaultAccess>true</defaultAccess>
        </sync>
        <access>
            <!-- группа доступа -->
            <allow>cn=aiusers,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</allow>
            <!-- группа админов -->
            <admin>cn=aiadmin,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</admin>
        </access>
        <!-- пользователи -->
        <account>
            <!-- поле id пользователя, если пусто - будет использоваться md5 от DN (как раньше было), иначе md5 от поля -->
            <id></id>
            <!-- поле логин -->
            <login>cn</login>
            <!-- поле имя -->
            <firstname>firstName</firstname>
            <!-- поле отчество -->
            <middlename>middleName</middlename>
            <!-- поле фамилия -->
            <lastname>sn</lastname>
            <!-- поле почта -->
            <email>mail</email>
            <!-- базовый узел -->
            <base>dc=test,dc=ldap,dc=com</base>
            <!-- фильтр -->
            <filter>(objectClass=inetOrgPerson)</filter>
        </account>
        <!-- группы -->
        <group>
         <!-- поле id группы, если пусто - будет использоваться hashCode от DN (как раньше было), иначе hashCode от поля -->
            <id></id>
            <!-- при импорте игнорировать группы -->
            <importGroups>false</importGroups>
            <!-- поле имя -->
            <name>cn</name>
            <!-- поле члены -->
            <member>member</member>
            <!-- базовый узел -->
            <base>dc=test,dc=ldap,dc=com</base>
            <!-- фильтр -->
            <filter>(objectClass=groupOfNames)</filter>
        </group>
    </item>

    <!-- синхронизация с Active Directory -->
    <item>
        <id>2</id>
        <domain>msad.com</domain>
        <sync>
            <host>10.20.30.2</host>
            <user-dn>Administrator@msad.com</user-dn>
            <password>secret</password>
            <active>false</active>
            <interval>1800000</interval>
            <referral>follow</referral>
        </sync>
        <access>
        <!-- userAccountControl указывает на поле "Активен" в AD, вместо него можно использовать просто группу -->
            <allow>userAccountControl</allow>
            <admin>CN=aiadmin,CN=Users,dc=msad,dc=com</admin>
        </access>
        <account>
            <id>objectGUID</id>
            <login>sAMAccountName</login>
            <firstname>givenName</firstname>
            <middlename>initials</middlename>
            <lastname>sn</lastname>
            <email>mail</email>
            <base>dc=msad,dc=com</base>
            <filter>(objectClass=person)</filter>
        </account>
        <group>
            <id>objectGUID</id>
            <name>cn</name>
            <member>member</member>
            <base>dc=msad,dc=com</base>
            <filter>(objectClass=group)</filter>
        </group>
    </item>
    </configuration>

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <configuration
        xmlns="http://www.arta.kz/xml/ns/as/ldap-sync"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        version= "2"
        xsi:schemaLocation="http://www.arta.kz/xml/ns/as/ldap-sync ldap-sync_2.xsd">
    <!-- Наборы синхронизации, таких может быть несколько -->
    <item>
        <!-- id синхронизации -->
        <id>1</id>
        <!-- домен -->
        <domain>test.ldap.com</domain>
        <!-- синхронизация -->  
        <sync>
            <!-- LDAP хост -->
            <host>10.20.30.1</host>
            <!-- учетная запись для подключения к каталогу LDAP -->
            <user-dn>cn=syncuser,dc=test,dc=ldap,dc=com</user-dn>
            <!-- пароль -->
            <password>password</password>
            <!-- активно, неактивно -->
            <active>false</active>
            <!-- интервал синхронизации в мс -->
            <interval>1800000</interval>
            <!-- следовать ссылкам -->
            <referral>ignore</referral>
        </sync>
        <!-- доступ -->
        <access>
            <!-- группа доступа -->
            <!-- значение userAccountControl в этом поле указывает на поле "Активен" в AD, вместо него можно      
            использовать просто группу
            -->                                               
            <allow>cn=aiusers,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</allow>
            <!-- группа админов -->
            <admin>cn=aiadmin,ou=Groups,ou=People,dc=test,dc=ldap,dc=com</admin>
        </access>
        <!-- пользователи -->
            <user>
            <!-- базовый узел поиска в LDAP -->
            <base>dc=test,dc=ldap,dc=com</base>
            <!-- фильтр -->
            <filter>(objectClass=inetOrgPerson)</filter>
            <!-- По какому полю сравнивать пользователей -->
            <identity>
                <!-- Откуда из Synergy брать поле для сравнения, из учётной записи -->
                <source type="account"/>
                <!-- либо из произвольной карточки
                <source type="personalrecord" id="id личной карточки"/>
                -->
                <!-- Поля для сравнения. Блок id может быть только один в этом блоке. -->
                <id>
                    <!-- Идентификатор поля Synergy. Для типа источника account возможные значения: id, login, email.
                    Для типа источника personalrecord — идентификатор поля формы карточки пользователя.
                    -->
                        <synergy>id</synergy>
                        <!-- Поле id пользователя из LDAP, если пусто - будет использоваться md5 от DN объекта. Eсли указанное поле отсутствует в импортируемом объекте, либо оно является пустым, то импорт этого объекта не производится, о чём делается запись в лог -->
                        <ldap></ldap>
                    </id>
                </identity>
                <!-- Сопоставление полей учётной записи -->
                <account>   
                    <!-- поле логин -->
                    <login>cn</login>
                    <!-- поле имя -->
                    <firstname>firstName</firstname>
                    <!-- поле отчество -->
                    <middlename>middleName</middlename>
                    <!-- поле фамилия -->
                    <lastname>sn</lastname>
                    <!-- поле почта -->
                    <email>mail</email>
                </account>
                <!-- Сопоставление полей карточки пользователя. Блоков personalrecord может быть несколько
                -->
                <personalrecord>
                    <!-- Идентификатор карточки пользователя. Обязательно должен быть непустым -->
                    <id>какой-то id</id>
                    <!-- Блок field указывает на связь поля из LDAP с полем карточки пользователя. Таких блоков может быть несколько -->
                    <field>
                        <ldap>IIN</ldap>
                        <synergy>form-iin</synergy>
                    </field>
                </personalrecord>
            </user>
                <!-- группы -->
                <group>
                    <!-- базовый узел -->
                    <base>dc=test,dc=ldap,dc=com</base>
                    <!-- фильтр -->
                    <filter>(objectClass=groupOfNames)</filter>
                    <!-- поле id группы, если пусто - будет использоваться hashCode от DN (как раньше было), иначе hashCode от поля -->
                    <id></id>
                    <!-- поле имя -->
                    <name>cn</name>
                    <!-- поле члены -->
                    <member>member</member>
                 </group>
            </item>
        </configuration>

Данная глава содержит инструкцию по настройке синхронизации и
разделена на два подраздела:

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

Microsoft active directory servers will default to offer LDAP connections over unencrypted connections (boo!).

The steps below will create a new self signed certificate appropriate for use with and thus enabling LDAPS for an AD server. Of course the «self-signed» portion of this guide can be swapped out with a real vendor purchased certificate if required.

Steps have been tested successfully with Windows Server 2012R2, but should work with Windows Server 2008 without modification. Requires a working OpenSSL install (ideally Linux/OSX) and (obviously) a Windows Active Directory server.

• Create root certificate
• Import root certificate into trusted store of domain controller
• Create client certificate
• Accept and import certificate
• Reload active directory SSL certificate
• Test LDAPS using ldp.exe utility
• Reference

Create root certificate

Using OpenSSL, create new private key and root certificate. Answer country/state/org questions as suitable:

$ openssl genrsa -aes256 -out ca.key 4096
$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Hold onto the resulting ca.key and ca.crt.

Import root certificate into trusted store of domain controller

• From the active directory server, open Manage computer certificates.
• Add the generated ca.crt to the certificate path Trusted Root Certification AuthoritiesCertificates.
• Done.

Create client certificate

We will now create a client certificate to be used for LDAPS, signed against our generated root certificate.

From the active directory server:

• Create a new request.inf definition with the following contents — replacing ACTIVE_DIRECTORY_FQDN with the qualified domain name of your active directory server:

   [Version]
   Signature="$Windows NT$"
  
   [NewRequest]
   Subject = "CN=ACTIVE_DIRECTORY_FQDN"
   KeySpec = 1
   KeyLength = 2048
   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 ; Server Authentication
  

• Run the following to create a client certificate request of client.csr (note: it’s critical this is run from the active directory server itself to ensure correct private key -> certificate association):

   C:> certreq -new request.inf client.csr

Back to our OpenSSL system:

• Create v3ext.txt containing the following:

   keyUsage=digitalSignature,keyEncipherment
   extendedKeyUsage=serverAuth
   subjectKeyIdentifier=hash
  

• Create a certificate client.crt from certificate request client.csr and root certificate (with private key):

   $ openssl x509 
     -req -days 3650 
     -in client.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt 
     -set_serial 01 -out client.crt

• Verify generated certificate:

   $ openssl x509 -in client.crt -text

• Ensure the following X509v3 extensions are all present:

  • X509v3 Key Usage: Digital Signature, Key Encipherment
  • X509v3 Extended Key Usage: TLS Web Server Authentication
  • X509v3 Subject Key Identifier

Accept and import certificate

• From the active directory server with client.crt present, run the following:

   C:> certreq -accept client.crt

• Open Manage computer certificates, the new certificate should now be present under PersonalCertificates. Ensure that:

  • Certificate has a private key association.
  • The «Intended Purposes» is defined as «Server Authentication».
  • Certificate name is the FQDN of the active directory server.

Reload active directory SSL certificate

Alternatively you can just reboot the server, but this method will instruct the active directory server to simply reload a suitable SSL certificate and if found, enable LDAPS:

• Create ldap-renewservercert.txt containing the following:

   dn:
   changetype: modify
   add: renewServerCertificate
   renewServerCertificate: 1
   -
  

• Run the following command:

   C:> ldifde -i -f ldap-renewservercert.txt

Test LDAPS using ldp.exe utility

• From another domain controller, firstly install our generated root certificate ca.crt to the certificate path Trusted Root Certification AuthoritiesCertificates.

• Open utility:

• From Connection, select Connect.

• Enter name of target domain controller.

• Enter 636 as port number (this is the LDAPS port).

• Click OK to confirm the connection works.

• You’re all done!

Reference

• Enable LDAP over SSL with a third-party certification authority: https://support.microsoft.com/en-us/kb/321051
• LDAP renewServerCertificate: https://msdn.microsoft.com/en-us/library/cc223311.aspx
• How to Enable LDAPS in Active Directory (similar outcome to above): http://www.javaxt.com/tutorials/windows/how_to_enable_ldaps_in_active_directory
• DigiCert LDAPS certificate install guide: https://www.digicert.com/ssl-certificate-installation-microsoft-active-directory-ldap-2012.htm

Microsoft Active Directory поддерживает протокол LDAPv3. С его помощью можно авторизовать пользователей из сторонних приложений. Чтобы обеспечить безопасность при передаче учетной информации серверу необходимо использовать LDAPS (SSL). В этой статье мы рассмотрим настройку контролера доме, для обеспечения поддержки SSL.

Для того, чтобы SSL нормально функционировал нам потребуются сертификат. 

Проверяем наличие сертификата

Для начала будет полезно проверить наличие сертификата в вашем домене, для этого запустим на нашем ПК утилиту ldp.exe.

Она не поставляется с Windows 10, чтобы использовать её, вам придется установить компоненты администрирования RSAT.

Нажмите Подключение — подключить, заполните окно аналогично рисунку.

Используйте имя домена, не сервера — тогда сервер для подключения будет выбран автоматически.

Если в ответ вы получили сообщение:

ld = ldap_sslinit("altuninvv.local", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to altuninvv.local.

Это означает, что либо недоступен ни один контролер домена, либо неправильно настроен DNS, либо ПК не является членом домена, либо не установлен SSL сертификат на контролере домена.

Если сообщение похоже на такое:

Established connection to xxxx.xxxxxxxxx.xxx.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: 
...
forestFunctionality: 6 = ( WIN2012R2 ); 
highestCommittedUSN: 2153249; 
isGlobalCatalogReady: FALSE; 
isSynchronized: TRUE; 
ldapServiceName: XXXXXXXX$@XXXXXXXXXXXXX; 
....
supportedCapabilities (6): 1.2.840.113556.1.4.800 = ( ACTIVE_DIRECTORY ); 1.2.840.113556.1.4.1670 = ( ACTIVE_DIRECTORY_V51 ); 1.2.840.113556.1.4.1791 = ( ACTIVE_DIRECTORY_LDAP_INTEG ); 1.2.840.113556.1.4.1935 = ( ACTIVE_DIRECTORY_V61 ); 1.2.840.113556.1.4.2080 = ( ACTIVE_DIRECTORY_V61_R2 ); 1.2.840.113556.1.4.2237 = ( ACTIVE_DIRECTORY_W8 ); 
supportedControl (37): 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.2.840.113556.1.4.801 = ( SD_FLAGS ); 1.2.840.113556.1.4.473 = ( SORT ); 1.2.840.113556.1.4.528 = ( NOTIFICATION ); 1.2.840.113556.1.4.417 = ( SHOW_DELETED ); 1.2.840.113556.1.4.619 = ( LAZY_COMMIT ); 1.2.840.113556.1.4.841 = ( DIRSYNC ); 1.2.840.113556.1.4.529 = ( EXTENDED_DN ); 1.2.840.113556.1.4.805 = ( TREE_DELETE ); 1.2.840.113556.1.4.521 = ( CROSSDOM_MOVE_TARGET ); 1.2.840.113556.1.4.970 = ( GET_STATS ); 1.2.840.113556.1.4.1338 = ( VERIFY_NAME ); 1.2.840.113556.1.4.474 = ( RESP_SORT ); 1.2.840.113556.1.4.1339 = ( DOMAIN_SCOPE ); 1.2.840.113556.1.4.1340 = ( SEARCH_OPTIONS ); 1.2.840.113556.1.4.1413 = ( PERMISSIVE_MODIFY ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.10 = ( VLVRESPONSE ); 1.2.840.113556.1.4.1504 = ( ASQ ); 1.2.840.113556.1.4.1852 = ( QUOTA_CONTROL ); 1.2.840.113556.1.4.802 = ( RANGE_OPTION ); 1.2.840.113556.1.4.1907 = ( SHUTDOWN_NOTIFY ); 1.2.840.113556.1.4.1948 = ( RANGE_RETRIEVAL_NOERR ); 1.2.840.113556.1.4.1974 = ( FORCE_UPDATE ); 1.2.840.113556.1.4.1341 = ( RODC_DCPROMO ); 1.2.840.113556.1.4.2026 = ( DN_INPUT ); 1.2.840.113556.1.4.2064 = ( SHOW_RECYCLED ); 1.2.840.113556.1.4.2065 = ( SHOW_DEACTIVATED_LINK ); 1.2.840.113556.1.4.2066 = ( POLICY_HINTS_DEPRECATED ); 1.2.840.113556.1.4.2090 = ( DIRSYNC_EX ); 1.2.840.113556.1.4.2205 = ( UPDATE_STATS ); 1.2.840.113556.1.4.2204 = ( TREE_DELETE_EX ); 1.2.840.113556.1.4.2206 = ( SEARCH_HINTS ); 1.2.840.113556.1.4.2211 = ( EXPECTED_ENTRY_COUNT ); 1.2.840.113556.1.4.2239 = ( POLICY_HINTS ); 1.2.840.113556.1.4.2255 = ( SET_OWNER ); 1.2.840.113556.1.4.2256 = ( BYPASS_QUOTA ); 
supportedLDAPPolicies (19): MaxPoolThreads; MaxPercentDirSyncRequests; MaxDatagramRecv; MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxBatchReturnMessages; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MinResultSets; MaxResultSetsPerConn; MaxNotificationPerConn; MaxValRange; MaxValRangeTransitive; ThreadMemoryLimit; SystemMemoryLimitPercent; 
supportedLDAPVersion (2): 3; 2; 
supportedSASLMechanisms (4): GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5; 

-----------

Это значит, что SSL сертификат уже установлен посредством Службы сертификатов Active Directory и дальнейших действий не потребуется. 

Установка OpenSSL

В этой статье я буду использовать виртуальный сервер, созданный для цикла статей.

Имя домена — altununvv.local

Имя контролера домена – addc1.altuninvv.local

Виртуальная организация — Altunin Soft

Скачаем свежую версию OpenSSL — вы можете скачать её отсюда — https://slproweb.com/products/Win32OpenSSL.html

Я рекомендую все команды выполнять сразу на сервере, но вы можете так же работать и на вашем ПК, если используете MSYS2.

Те, кто использует, как и я, MSYS2, могут ввести в консоли:

pacman -Sy openssl

Создаем локальный центр сертификации

Создадим папку и назовем её CA.

Создадим в ней файл ca.conf с содержимым:

[ req ]
distinguished_name = req_distinguished_name
req_extensions     = v3_ca

[ req_distinguished_name ]
# Descriptions
countryName=RU
stateOrProvinceName=Magadan region
localityName=Magadan
0.organizationName= Altunin Soft
1.organizationName=IT
commonName=altuninvv.local

#Modify for your details here or answer the prompts from openssl
countryName_default=RU
stateOrProvinceName_default= Magadan region 
localityName_default= Magadan
0.organizationName_default= Altunin Soft
1.organizationName_default=IT
commonName_default= altuninvv.local 
[ v3_ca ]
keyUsage=critical,keyCertSign
basicConstraints=critical,CA:TRUE,pathlen:1
extendedKeyUsage=serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = *. altuninvv.local 
DNS.2 = altuninvv.local

Сгенерируем приватный ключ для CA

openssl genrsa -des3 -out ca.key 4096

Укажите пароль для ключа, в нашем случае это будет Pa$$w0rd: 

Generating RSA private key, 4096 bit long modulus (2 primes)
......................................................................................................................................
........................................................................................................................................
....++++..........................++++e is 65537 (0x010001)
Enter pass phrase for ca.key:

Verifying - Enter pass phrase for ca.key:

Создадим сертификат для нашего CA:

openssl req -new -x509 -extensions v3_ca -days 3659 -key ca.key -out ca.crt -config ca.conf

Просто нажимайте Enter все поля будут заполнены автоматически!

Enter pass phrase for ca.key:
 You are about to be asked to enter information that will be incorporated                                                                                                                                           into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
For some fields there will be a default value,
 If you enter '.', the field will be left blank. 
-----
RU [RU]:
Magadan region [Magadan region]:
Magadan [Magadan]:
Altunin Soft [Altunin Soft]:
 IT [IT]:
altuninvv.local [altuninvv.local]:

Теперь нужно импортировать созданный сертификат в хранилище доверенных CA на нашем контролере домена.

Скопируем файл ca.crt на контролер домена. Откроем PowerShell от имени администратора, перейдем в папку с файлом ca.cert и введем команду:

Import-Certificate –Verbose -FilePath ca.crt  -CertStoreLocation 'Cert:LocalMachineRoot'

VERBOSE: Performing the operation "Import certificate" on target "Item: C:caca.crt Destination: Root".


   PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot

Thumbprint                                Subject                                                                          
----------                                -------                                                                          
D5D1306CFFDAF63EDA10710F13F69C0228005350  CN=altuninvv.local, O=IT, O=Altunin Soft, L=Magadan, S=Magadan region, C=RU 

Сертификат успешно добавлен.

Теперь пришло время создать запрос на клиентский сертификат, который будет использовать контролер домена.

На контролере домена создадим текстовый файл — req.txt

;----------------- request.inf -----------------
[Version]
Signature="$Windows NT$"

;The Subject will need to be your active directory domain name
[NewRequest]
Subject = "CN=altuninvv.local
KeySpec = 1
KeyLength = 4096
Exportable = TRUE
SMIME = FALSE
MachineKeySet = TRUE
PrivateKeyArchive = FALSE
UseExistingKeySet = FALSE
UserProtected = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
;The following will add a subject alternative name of a wildcard cert on *.example.com
;so any ad controller with a hostname of somththing.example.com can use it.
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=*.altuninvv.local&"
_continue_ = "dns=altuninvv.local&"
Выполним запрос на сертификат:
certreq -new req.txt addc1.csr
CertReq: Request Created

Выполним запрос на сертификат:

certreq -new req.txt addc1.csr
CertReq: Request Created

Скопируем созданный файл на свой ПК в папку нашего CA

В папке CA создадим файл v3ext.txt с содержимым:

# v3ext.txt
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names
#Modify for your details. Must include the commonName in the list below also. 
#The *.example.com will allow all Domain controllers with 
#the hostname somthing.example.com to use the cert.
[alt_names]
DNS.1 = *.altuninvv.local
DNS.2 = altuninvv.local

Сгенерируем сертификат для addc1

openssl x509 -req -days 825 -in addc1.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out addc1-server.crt
Signature ok
subject=CN = altuninvv.local
Getting CA Private Key
Enter pass phrase for ca.key:

Введите пароль закрытого ключа: Pa$$w0rd

Скопируем файл с сертификатом addc1-server.crt обратно на контролер домена addc1 и применим сертификат:

certreq -accept addc1-server.crt
Installed Certificate:
  Serial Number: 01
  Subject: CN=altuninvv.local (DNS Name=*.altuninvv.local, DNS Name=altuninvv.local)
  NotBefore: 2/18/2021 5:37 PM
  NotAfter: 5/24/2023 5:37 PM
  Thumbprint: 4721d27e9fe34aaa672d20d68c0ec01fd9f7a82c

Из PowerShell проверим наличие сертификата:

PS C:ca> Get-ChildItem "Cert:LocalMachineMy"

   PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy

Thumbprint                                Subject
----------                                -------
4721D27E9FE34AAA672D20D68C0EC01FD9F7A82C  CN=altuninvv.local

Теперь вы должны перегрузить контролер домена, чтобы все настройки вступили в силу.

Обратите внимание, чтобы подключиться к серверу вы должны указать его полное доменное имя, в нашем случае:

addc1.altuninvv.local

Если ПК входит в состав домена altuninvv.local, вы можете использовать для подключение его имя:

altuninvv.local

Тогда контролер домена для подключения будет выбран автоматически из списка доступных, возможно, это будет работать только, при наличии Службы сертификатов на одном из серверов в AD!

Так как мой ПК не входит в домен altuninvv.local и не использует его DNS-сервера, я прописал в файле

C:WindowsSystem32driversetchosts

строку:

192.168.0.10 addc1.altuninvv.local

Проверяем подключение

Для проверки подключения мы будет использовать утилиту ldp.exe.

Она не поставляется с Windows 10, чтобы использовать её, вам придется установить компоненты администрирования RSAT.

Запустим ldp.exe, откроется окно:

В этом окне выберите подключение – подключить

Введем:

Сервер: addc1.altuninvv.local

Порт: 636

Установим галочку SSL

Нажмем Ок, будет осуществлено подключение и выведена дополнительная информация:

Теперь мы может сделать bind к серверу

Выберите Подключение – Привязка

Заполните поля:

Пользователь: CN=ldap-bind,CN=Users,DC=altuninvv,DC=local

Пароль: Pas#w0rds#1

Установите: Простая привязка

нажмите Ок

 

Будет выведено сообщение:

res = ldap_simple_bind_s(ld, 'CN=ldap-bind,CN=Users,DC=altuninvv,DC=local', <unavailable>); // v.3

Authenticated as: 'ALTUNINVVldap-bind'.

Это означает, что подключение прошло успешно.

Далее выберем пункт меню Вид – Дерево

И в окне выберем — DC=altuninvv,DC=local

Нажмем Ок

Откроется дерево с разделами домена,

Таким образом вы можете просматривать каталог AD через LDAP по SSL.

Заключение

Сегодня мы рассмотрели подключение к контролеру домена AD с использованием протокола LDAP по SSL.

Мы создали свой локальный центр сертификации CA с помощью OpenSSL.

Был выпущен сертификат и установлен на контролере домена.

С помощью утилиты ldp.exe было осуществлено подключение к контролеру домена по SSL.

---

Applies To:

Windows Server 2012, Windows Server 2012 R2 Preview

DoLdapInitialize

ADDS standard ports are opened during DCPROMO mainly LDAP initiation. Ports are opened during dsa init, specifically in ‘ DoLdapInitialize’ — If we stop the ‘Active Directory Domain Service’ in service.msc neither of the port is listening.

My main purpose of this article is ldaps service & msft-gc-ssl service . Port 636 & 3269 are listing after promoting a DC. We can test that using Telnet, PortQuery , Netmon or Wireshark etc. The result below is taken from newly built DC using PortQry.

PortQry output after promoting a DC for SSL ports.

There is fantastic tool called LDP.EXE which was the part of the windows support tools in earlier version of windows OS (2003). Now days if we installed a DC automatically that is available into a DC due to RSAT. We can connect port 389 & 3268 through ldp
but not 636/3269. Those SSL ports are only listened LDAPS when we put the valid certificate into DCs. We need valid SAN, Intended purpose for that certificate (EKU).

LDP.EXE output after connecting the SSL ports.

If your certificate server itself a DC then you no need to worry for SSL ports. Those ports are connected through LDP.EXE.

NETMON capture for SSL Ports

Also Netmon results are taken after putting the valid certificate into a Domain Controller. Used the filter » LDAP». Also you can use «.Protocol.LDAP». You will get the same result. Here I have installed the netmon in DC.

Listening the ldaps Port (636) into the below Capture

Listening the  gc-ssl Port (3269) into the below Capture

Network capture without netmon

Also you can trace without the Netmon/WireShare. Using Netsh but it is applicable Windows 2008R2 and Windows 7 and upper version OS.

For starting the capture.

netsh trace start capture=yes tracefile=cap.etl

For stopping the capture

netsh trace stop

For reading the .etl file you need the netmon anywhere.

Netsh trace will be created two files. see the below snap. For reading the .etl file you need to select the Windows Parser in Netmon.

Cert server into a domain controller is not recommended.

We need additional steps for listening the ssl ports for DCs If cert server in a member server .We need to publish the certificate template into the cert server & that certificate template need to put DC’s local computer->personal or NTDS->Personal store.

Local computer->personal store

NTDS->Personal store

(This store is available only in DC. When we have more than one cert template for Server Authentication, we can use this store for avoiding the conflict)

Publish a cert Template

Here I have used «Kerberos Authentication» template for publishing the new certificate template.

Log into the certificate server . Run » certtmpl.msc» & chose the   Kerberos Authentication Template.

We need to set few properties before publishing a certificate template. Those are marked as green.

Click on Duplicate Templete.

Publish cert in AD.

Allow Pvt. key to be exported.

Subject Name format

After publishing that cert you can check the properties using » certutil -v -template <Template_Name>». Here my cert template name is LDAPSSL. See the following output.

certutil -v -template LDAPSSL

PS C:> certutil -v -template LDAPSSL

  Name: Active Directory Enrollment Policy

  Id: {32376692-6063-4EDC-A375-572FED78C626}

  Url: ldap:

34 Templates:

  Template[21]:

  TemplatePropCommonName = LDAPSSL

  TemplatePropFriendlyName = LDAPSSL

  TemplatePropEKUs =

4 ObjectIds:

    1.3.6.1.5.2.3.5 KDC Authentication

    1.3.6.1.4.1.311.20.2.2 Smart Card Logon

    1.3.6.1.5.5.7.3.1 Server Authentication

    1.3.6.1.5.5.7.3.2 Client Authentication

  TemplatePropCryptoProviders =

    0: Microsoft RSA SChannel Cryptographic Provider

  TemplatePropMajorRevision = 64 (100)

  TemplatePropDescription = Computer

  TemplatePropSchemaVersion = 2

  TemplatePropMinorRevision = 1

  TemplatePropRASignatureCount = 0

  TemplatePropMinimumKeySize = 800 (2048)

  TemplatePropOID =

    1.3.6.1.4.1.311.21.8.1546289.5796744.12012220.14775765.9035062.224.8004685.4056790 LDAPSSL

  TemplatePropV1ApplicationPolicy =

4 ObjectIds:

    1.3.6.1.5.2.3.5 KDC Authentication

    1.3.6.1.4.1.311.20.2.2 Smart Card Logon

    1.3.6.1.5.5.7.3.1 Server Authentication

    1.3.6.1.5.5.7.3.2 Client Authentication

  TemplatePropEnrollmentFlags = 28 (40)

    CT_FLAG_PUBLISH_TO_DS -- 8

    CT_FLAG_AUTO_ENROLLMENT -- 20 (32)

  TemplatePropSubjectNameFlags = 18c00000 (415236096)

    CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS -- 400000 (4194304)

    CT_FLAG_SUBJECT_ALT_REQUIRE_SPN -- 800000 (8388608)

    CT_FLAG_SUBJECT_ALT_REQUIRE_DNS -- 8000000 (134217728)

    CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN -- 10000000 (268435456)

  TemplatePropPrivateKeyFlags = 10 (16)

    CT_FLAG_EXPORTABLE_KEY -- 10 (16)

  TemplatePropGeneralFlags = 20060 (131168)

    CT_FLAG_AUTO_ENROLLMENT -- 20 (32)

    CT_FLAG_MACHINE_TYPE -- 40 (64)

    CT_FLAG_IS_MODIFIED -- 20000 (131072)

  TemplatePropSecurityDescriptor = O:LAG:EAD:PAI(OA;;RPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;RO)(OA;;RPCR;a05b8cc2

bc-4802-a710-e7c15ab866a2;;RO)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;DA)(OA;;RPWPCR;0e10c968-78fb-11d2-90d

0c04f79dc55;;DD)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;EA)(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2

D)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;ED)(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;ED)(A;;CCDCL

RPWPDTLOSDRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;LA)(A;;LCRPLORC;;;AU)

     Allow Enroll        CONTOSOEnterprise Read-only Domain Controllers

    Allow Auto-Enroll   CONTOSOEnterprise Read-only Domain Controllers

    Allow Enroll        CONTOSODomain Admins

    Allow Enroll        CONTOSODomain Controllers

    Allow Enroll        CONTOSOEnterprise Admins

    Allow Auto-Enroll   CONTOSODomain Controllers

    Allow Enroll        NT AUTHORITYENTERPRISE DOMAIN CONTROLLERS

    Allow Auto-Enroll   NT AUTHORITYENTERPRISE DOMAIN CONTROLLERS

    Allow Full Control  CONTOSODomain Admins

    Allow Full Control  CONTOSOEnterprise Admins

    Allow Full Control  CONTOSOAdministrator

    Allow Read  NT AUTHORITYAuthenticated Users

  TemplatePropExtensions =

4 Extensions:

  Extension[0]:

    1.3.6.1.4.1.311.21.7: Flags = 0, Length = 30

    Certificate Template Information

        Template=LDAPSSL(1.3.6.1.4.1.311.21.8.1546289.5796744.12012220.14775765.9035062.224.8004685.4056790)

        Major Version Number=100

        Minor Version Number=1

  Extension[1]:

    2.5.29.37: Flags = 0, Length = 2b

     Enhanced Key Usage

        KDC Authentication (1.3.6.1.5.2.3.5)

        Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

        Server Authentication (1.3.6.1.5.5.7.3.1)

        Client Authentication (1.3.6.1.5.5.7.3.2)

  Extension[2]:

    2.5.29.15: Flags = 1(Critical), Length = 4

    Key Usage

        Digital Signature, Key Encipherment (a0)

  Extension[3]:

    1.3.6.1.4.1.311.21.10: Flags = 0, Length = 33

    Application Policies

        [1]Application Certificate Policy:

             Policy Identifier=KDC Authentication

        [2]Application Certificate Policy:

             Policy Identifier=Smart Card Logon

        [3]Application Certificate Policy:

             Policy Identifier=Server Authentication

        [4]Application Certificate Policy:

             Policy Identifier=Client Authentication

   TemplatePropValidityPeriod = 1 Years

  TemplatePropRenewalPeriod = 6 Weeks

CertUtil: -Template command completed successfully.

PS C:>

Find that Template from computer store using «certutil -store my». See the below snap.

Find the Template Details using «V» switch.

Enabling/Disabling CryptoAPI 2.0

Enabling CryptoAPI 2.0 Diagnostic Logging

Disabling CryptoAPI 2.0 Diagnostic Logging

More details for Troubleshooting PKI Problems on Windows

Troubleshooting PKI Problems on Windows

PKI Info; those are stored in AD ; See the following Snap.using ADSIEDIT.MSC

Also you can see the ADCS info using DSSITE.MSC

Some key Points.

1. Cert Templates are stored in AD (Configuration Partition).
2. Enterprise Certificate Server in a Domain controller is enabled LDAPS(636) & GC SSL(3269) ports for all the Domain controller)
   1. [Due to Certificate Template  Domain Controller]
3. If all Sub CAs host the same certificate templates for enrolment those servers we can use for Redundancy & fault tolerance.
4. Also you can use Certificate server cluster for Redundancy & fault tolerance.

PKI Events.

(Snap is taken from Windows Server 2008 PKI — Brian Komar)

Certificate Server Registry Key (Path)

We are used «certutil -setreg» for changing those keys.

___________________________________________________

Some Useful Links

1. How to enable LDAP signing in Windows Server 2008
2. TroubleshootingLDAP Over SSL
3. Reading LDAP SSL Network Traffic with NetMon 3.4 and NMDecrypt
4. How to decrypt an SSL or TLS session by using Wireshark
5. How to enable LDAP over SSL with a third-party certification authority
6. Certutil Examples for Managing Active Directory Certificate Services (AD CS)
   from the Command Line
7. Configure SSL/TLS on a Web site in the domain with an Enterprise CA
8. What’s New in AD CS and PKI?
9. How to add a Subject Alternative Name to a secure LDAP certificate
10. Custom Certificate Request in Windows Vista
11. Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Server 2008 Certification Authority
12. Publish certificates in a foreign Active Directory forest
13. Exporting Certificates using CertUtil
14. VPN Client Compatibility with Windows 7 and Windows Server 2008 R2
15. Online Responder Installation, Configuration, and Troubleshooting Guide
16. LDAP client tracing… using Tracelog
17. HowTo: Determine if a user has logged on via smart card