Ошибка ldap 81 0x51 сервер отключен

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Im exeprence replication errors bettwen site to site replication.

Repadmin can’t connect to a «home server», because of the following error. Try
specifying a different
home server with /homeserver:[dns name]
Error: An LDAP lookup operation failed with the following error:

LDAP Error 81(0x51): Server Down
Server Win32 Error 0(0x0):
Extended Information:

This error occurs if I’m connected by the main WAN line (satilite), but if I change to backup line wokrs fine.

I was in the way to troubleshooting this issue with Netowrk TEAM, and they ask me wich ports are use when replication occurs so they can troubleshoot it.

I will kindly ask your help and add on this issue and also if you could provide details about all ports and flow of the replication.

Thanks in advance

Answers

You need to check couple of the options to fix this issue.

1. Check DNS settings on NIC (preferred should be itself if it holds DNS role)

2. Repadmin /replsum at elivated command prompt. If you notice any errors work on that.

3. Add Antivirus exceptions for SYSVOL, NTDS folders

4. Restart Netlogon, DNS and ipconfig /flushdns & ipconfig /registerdns

5. If none of the above options doesn’t work, provide us ipconfig /all and DCDiag /v logs for better understanding about the issue.

This article should help:

It mentions the ports used for various services.

Richard Mueller — MVP Directory Services

If the replication is working fine with backup line then it seems the issue somewhere with routing or ports of main line. You may refer the following article for AD replication ports.

If still issue persist, post dcdiag /q and repadmin /replsum or replication error events to assist you further.

Abhijit Waikar.
MCSA | MCSA:Messaging | MCITP:SA | MCC:2012
Blog: http://abhijitw.wordpress.com
Disclaimer: This posting is provided «AS IS» with no warranties or guarantees and confers no rights.

You have to start that the traffic on your main WAN connection is not filtered. Active Directory ports used for AD replication should be opened in both directions: http://technet.microsoft.com/en-us/library/bb727063.aspx

You can use PortQryUI to check the filtering.

Of course, you should also check that the routing is correctly set for this connection. This can be checked using ping requests / responses (I suppose that ICMP traffic is not blocked).

Note also that AD replication behind a NAT device is not supported. That is why you will need to check if one of the routers used or the main WAN connection is using NAT. If it is the case, you will need to disable it (In your case, with a dedicated site to site connection, NAT should not be required).

Of course, dcdiag and repadmin commands should provide you with more details about the issue.

This posting is provided «AS IS» with no warranties or guarantees , and confers no rights.

• Edited by Mr X MVP Sunday, December 2, 2012 3:19 PM
• Marked as answer by Yan Li_ Thursday, December 6, 2012 2:23 AM

Portquery is free tool from the MS which can be downloaded and installed to verify the necessary ports are opened or not.
PortQryUI — User Interface for the PortQry Command Line Port Scanner (GUI version)
http://www.microsoft.com/en-us/download/details.aspx?id=24009

Agreed with MX regarding the DCs used with NAT are not supported configuration.
How to design AD and DNS System with NAT Networks
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/9fc98b8e-df73-4133-a87c-44c550225fce

Hope this helps

Disclaimer: This posting is provided «AS IS» with no warranties or guarantees , and confers no rights.

Did you see below article from the DS team.

DCDIAG Advertising test with error 81

Awinish Vishwakarma — MVP

Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

Im exeprence replication errors bettwen site to site replication.

Repadmin can’t connect to a «home server», because of the following error. Try
specifying a different
home server with /homeserver:[dns name]
Error: An LDAP lookup operation failed with the following error:

LDAP Error 81(0x51): Server Down
Server Win32 Error 0(0x0):
Extended Information:

This error occurs if I’m connected by the main WAN line (satilite), but if I change to backup line wokrs fine.

I was in the way to troubleshooting this issue with Netowrk TEAM, and they ask me wich ports are use when replication occurs so they can troubleshoot it.

I will kindly ask your help and add on this issue and also if you could provide details about all ports and flow of the replication.

Thanks in advance

Just as an add I will like to mention that I have try the following :

If I test smb connection from both side and this happens:

Server b to a : \servernamesysvol connection fail

If I change to line backup all works.

You need to check couple of the options to fix this issue.

1. Check DNS settings on NIC (preferred should be itself if it holds DNS role)

2. Repadmin /replsum at elivated command prompt. If you notice any errors work on that.

3. Add Antivirus exceptions for SYSVOL, NTDS folders

4. Restart Netlogon, DNS and ipconfig /flushdns & ipconfig /registerdns

5. If none of the above options doesn’t work, provide us ipconfig /all and DCDiag /v logs for better understanding about the issue.

This article should help:

It mentions the ports used for various services.

Richard Mueller — MVP Directory Services

If the replication is working fine with backup line then it seems the issue somewhere with routing or ports of main line. You may refer the following article for AD replication ports.

If still issue persist, post dcdiag /q and repadmin /replsum or replication error events to assist you further.

Abhijit Waikar.
MCSA | MCSA:Messaging | MCITP:SA | MCC:2012
Blog: http://abhijitw.wordpress.com
Disclaimer: This posting is provided «AS IS» with no warranties or guarantees and confers no rights.

You have to start that the traffic on your main WAN connection is not filtered. Active Directory ports used for AD replication should be opened in both directions: http://technet.microsoft.com/en-us/library/bb727063.aspx

You can use PortQryUI to check the filtering.

Of course, you should also check that the routing is correctly set for this connection. This can be checked using ping requests / responses (I suppose that ICMP traffic is not blocked).

Note also that AD replication behind a NAT device is not supported. That is why you will need to check if one of the routers used or the main WAN connection is using NAT. If it is the case, you will need to disable it (In your case, with a dedicated site to site connection, NAT should not be required).

Of course, dcdiag and repadmin commands should provide you with more details about the issue.

This posting is provided «AS IS» with no warranties or guarantees , and confers no rights.

• Edited by Mr X MVP Sunday, December 2, 2012 3:19 PM
• Marked as answer by Yan Li_ Thursday, December 6, 2012 2:23 AM

Portquery is free tool from the MS which can be downloaded and installed to verify the necessary ports are opened or not.
PortQryUI — User Interface for the PortQry Command Line Port Scanner (GUI version)
http://www.microsoft.com/en-us/download/details.aspx?id=24009

Agreed with MX regarding the DCs used with NAT are not supported configuration.
How to design AD and DNS System with NAT Networks
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/9fc98b8e-df73-4133-a87c-44c550225fce

Hope this helps

Disclaimer: This posting is provided «AS IS» with no warranties or guarantees , and confers no rights.

Just checking in to see if the suggestions were helpful. Please let us know if you would like further assistance.

If you have any feedback on our support, please click here .

Cataleya Li
TechNet Community Support

Did you see below article from the DS team.

DCDIAG Advertising test with error 81

Awinish Vishwakarma — MVP

Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

I have done with above troubleshooting and everything is fine, but issue is still persist. whenever I run «repadmin /replicate dest-ADC1 source-DC01 » it’s giving me error «LDAP Error 81(0x51): Server Down Server Win32 Error 0(0x0):» as per you I proving ipconfig /all and dcdiag result. please have a look and help me.

ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : DC1
Primary Dns Suffix . . . . . . . : rk19.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : rk19.com

Ethernet adapter Ethernet0:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physical Address. . . . . . . . . : 00-0C-29-59-41-83
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::98ac:492b:fccb:b411%12(Preferred)
IPv4 Address. . . . . . . . . . . : 172.16.0.3(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.16.0.1
DHCPv6 IAID . . . . . . . . . . . : 301993001
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-93-61-78-00-0C-29-59-41-83
DNS Servers . . . . . . . . . . . : ::1
172.16.0.3
172.16.0.9
NetBIOS over Tcpip. . . . . . . . : Enabled

DCDiag

Directory Server Diagnosis

Performing initial setup:
Trying to find home server.
Home Server = DC1
* Identified AD Forest.
Done gathering initial info.

Doing initial required tests

Testing server: Default-First-Site-NameDC1
Starting test: Connectivity
. DC1 passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-NameDC1
Starting test: Advertising
. DC1 passed test Advertising
Starting test: FrsEvent
. DC1 passed test FrsEvent
Starting test: DFSREvent
There are warning or error events within the last 24 hours after
. DC1 failed test DFSREvent
Starting test: SysVolCheck
. DC1 passed test SysVolCheck
Starting test: KccEvent
. DC1 passed test KccEvent
Starting test: KnowsOfRoleHolders
. DC1 passed test KnowsOfRoleHolders
Starting test: MachineAccount
. DC1 passed test MachineAccount
Starting test: NCSecDesc
. DC1 passed test NCSecDesc
Starting test: NetLogons
. DC1 passed test NetLogons
Starting test: ObjectsReplicated
. DC1 passed test ObjectsReplicated
Starting test: Replications
. DC1 passed test Replications
Starting test: RidManager
. DC1 passed test RidManager
Starting test: Services
. DC1 passed test Services
Starting test: SystemLog
. DC1 passed test SystemLog
Starting test: VerifyReferences
. DC1 passed test VerifyReferences

Running partition tests on : ForestDnsZones
Starting test: CheckSDRefDom
. ForestDnsZones passed test CheckSDRefDo
Starting test: CrossRefValidation
. ForestDnsZones passed test CrossRefVali

Running partition tests on : DomainDnsZones
Starting test: CheckSDRefDom
. DomainDnsZones passed test CheckSDRefDo
Starting test: CrossRefValidation
. DomainDnsZones passed test CrossRefVali

Running partition tests on : Schema
Starting test: CheckSDRefDom
. Schema passed test CheckSDRefDom
Starting test: CrossRefValidation
. Schema passed test CrossRefValidation

Running partition tests on : Configuration
Starting test: CheckSDRefDom
. Configuration passed test CheckSDRefDom
Starting test: CrossRefValidation
. Configuration passed test CrossRefValid

Running partition tests on : rk19
Starting test: CheckSDRefDom
. rk19 passed test CheckSDRefDom
Starting test: CrossRefValidation
. rk19 passed test CrossRefValidation

Running enterprise tests on : rk19.com
Starting test: LocatorCheck
. rk19.com passed test LocatorCheck
Starting test: Intersite
. rk19.com passed test Intersite

Источник

ldp.exe LDAPS Cannot open connection Error 81

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

I would have expected more debug output. This looks like it’s from the very end of the TLS negotiation process, right when it fails. It would be helpful to see what led up to it.

However, as far as I can tell, it looks like the failure is in some way related to TLS renegotiation. The «waiting for close_notify or alert» indicates that the connection already considers itself closed, and it’s just waiting for either the socket to be closed or an SSL alert message with additional information, and the «state 3» indicates that it’s in the process of attempting to renegotiate the session.

Immediately after that, you can see that it reads data, but it’s not able to interpret it, and that leads to the «fatal, unexpected_message». It follows that by invalidating two existing TLS sessions, closing the connection, and throwing the exception that the LDAP SDK catches and wraps with its own LDAPException.

All of this is happening inside Java’s TLS processing code, and the LDAP SDK doesn’t really have much more control over or insight into what’s going on. Without debug information from earlier in the process, I can’t really say what caused the failure. I also don’t know why inserting a delay would change things. However, it does look like there had already been a couple of TLS sessions that had been successfully established. Given that there is a renegotiation in progress, maybe it’s related to an attempt to reuse a session that’s being destroyed or invalidated.

You mention that you’re using a custom socket factory. That also raises some questions:

• Does that socket factory do anything unusual? Might it be invalidating sessions?
• Might there be a thread safety problem in that socket factory that you had been protected from by defaulting to not allowing concurrent socket factory use in unrecognized JVM implementations in earlier versions of the LDAP SDK? Does the problem still occur if you call LDAPConnectionOptions.setAllowConcurrentSocketFactoryUse(false)? Perhaps injecting the delay has a similar effect to reducing contention and avoids the thread safety problem.
• Do you see the problem if you take your socket factory out of the picture?

It also sounds like it only happens in one specific environment. It would obviously be good to look at what might be different in that environment, and especially related to the server’s TLS configuration, whether you have any networking equipment in the picture that might do weird things (especially something that might involve TLS, like a load balancer that acts as an SSL endpoint).

All of this is just speculation based on a few pieces of information, but it’s really about all there is to go on right now.

so, I it’s been about week since my last update — sorry.  Been stumped by this a while now obviously, but it only just now came to be pressing, as our CEO got a new Blackberry and we weren’t able to access the BES controls… likely due to this LDAP issue.  (It was configured to used windows authentication)

Following up on your last comment britv8 — the [isGlobalCatalogReady is false] was apparently false because those DCs did not have the global catalog enabled.  I’ve since enabled it on those servers for a better control group with fewer variables as I try to determine what is going on here.  I am still getting the LDAP errors.

Here’s what I’ve found thus far:

——————————————————————————————————

every DC gives the same error message response to:  repadmin /showreps /all /verbose («LDAP error 81 (Server Down) Win32 Err 58»)

——————————————————————————————————

nltest /dsgetdc:wcnb /force /gc 

every DC passes this test, and advertises the same flags: with the exception of the PDC which includes that flag: (GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE)

——————————————————————————————————

AD Replication Status Tool on my first scan revealed no errors in the replication status collection details, but did show a connection error of some sort — I’ve been unable to get that error message since I refreshed the replication status at any time.

——————————————————————————————————

Both my primary and secondary (at primary site) failed a [Netdiag /test:DNS].  error message as follows:

————-

DNS test . . . . . . . . . . . . . : Failed

[WARNING] Cannot find a primary authoritative DNS server for the name

‘<mydc2>.’. [WSAEADDRNOTAVAIL ]

The name ‘<mydc2>.’ may not be registered in DNS.

[WARNING] Cannot find a primary authoritative DNS server for the name

‘<mydc2>.’. [ERROR_TIMEOUT]

The name ‘<mydc2>.’ may not be registered in DNS.

[WARNING] Cannot find a primary authoritative DNS server for the name

‘<mydc2>.’. [WSAEADDRNOTAVAIL ]

The name ‘<mydc02>.’ may not be registered in DNS.

[WARNING] Cannot find a primary authoritative DNS server for the name

‘<mydc02>.’. [WSAEADDRNOTAVAIL ]

The name ‘<mydc02>.’ may not be registered in DNS.

[WARNING] Cannot find a primary authoritative DNS server for the name

‘<mydc2>.’. [ERROR_TIMEOUT]

The name ‘<mydc2>.’ may not be registered in DNS.

[WARNING] The DNS entries for this DC are not registered correctly on DNS server ‘0.0.0.0’. Please wait for 30 minutes for DNS server replication.

[FATAL] No DNS servers have the DNS records for this DC registered.

————-

an alternate site DC passed with warning as follows:

————-

DNS test . . . . . . . . . . . . . : Passed

PASS — All the DNS entries for DC are registered on DNS server ‘<alternate site DC IP>‘ and other DCs also have some of the names registered.

[WARNING] The DNS entries for this DC are not registered correctly on DNS se

rver ‘<PDC IP Address>’. Please wait for 30 minutes for DNS server replication.

————-

The other 3 DCs passed.

——————————————————————————————————

I’ve checked that each DC (IPV4) is looking to itself for primary DNS, and the PDC as it’s alternate.

In the process I notice that the PDC and the primary site alternate DC both have IPV6 enabled, and accompanying tunnel adapters.  (Some post that I have read have me leaning to this as my next direction in this investigation.)

——————————————————————————————————

While investigating DNS (which I am still learning) I noticed that one <mylocaldomain>_msdcs>GC>_sites was missing along with the tcp>_Ldap entry.

Restarting the Net Logon service seemed to resolve this missing site, without affecting the other errors already 

——————————————————————————————————

Any suggestions are greatly appreciated.  Thanks!

Was this post helpful?
thumb_up
thumb_down

Название ошибки
Номер
Пояснения/причины

LDAP_SUCCESS
0 (x’00)
Успешное завершение запроса.

LDAP_OPERATIONS_ERROR
1 (x’01)
Произошла ошибка операции.

LDAP_PROTOCOL_ERROR
2 (x’02)
Обнаружено нарушение протокола.

LDAP_TIMELIMIT_EXCEEDED
3 (x’03)
Превышено ограничение по времени LDAP.

LDAP_SIZELIMIT_EXCEEDED
4 (x’04)
Превышено ограничение по размеру LDAP.

LDAP_COMPARE_FALSE
5 (x’05)
Операция сравнения вернула «ложь».

LDAP_COMPARE_TRUE
6 (x’06)
Операция сравнения вернула «истину».

LDAP_STRONG_AUTH_NOT_SUPPORTED
7 (x’07)
Сервер LDAP не поддерживает строгую аутентификацию.

LDAP_STRONG_AUTH_REQUIRED
8 (x’08)
Для данной операции требуется прохождение строгой аутентификации.

LDAP_PARTIAL_RESULTS
9 (x’09)
Возвращены только частичные результаты.

LDAP_REFERRAL
10 (x’0A)
Указывает, что в ответе присутствует отсылка LDAP. Данное сообщение будет содержать один или несколько LDAP URL, по которым клиент должен перенаправить последующие операции для получения данного DN.

LDAP_ADMINLIMIT_EXCEEDED
11 (x’0B)
Указывает на то, что какие-либо ограничения, установленные на стороне сервера на количество записей, возвращаемое при поиске, были превышены.

LDAP_UNAVAILABLE_CRITICAL_EXTENSION
12 (x’0C)
Указывает на то, что элемент управления или правило соответствия, запрашиваемые в операции, не поддерживаются данным сервером.

LDAP_CONFIDENTIALITY_REQUIRED
13 (x’0D)
Конфигурация данного сервера требует обеспечения какой-либо формы конфиденциальности (TLS/SSL или SASL) при выполнении подсоединения с предоставляемым DN, например, определённая на глобальном уровне или в разделе database директива security может требовать соблюдения некоторой формы SSF при выполнении simple_bind или операции обновления.

LDAP_SASL_BIND_IN_PROGRESS
14 (x’0E)
Данный сервер в настоящий момент выполняет SASL-подсоединение и в этом контексте запрашиваемая операция является неверной.

15 (x’0F)
Не используется.

LDAP_NO_SUCH_ATTRIBUTE
16 (x’10)
Указанный в запросе атрибут не присутствует в записи.

LDAP_UNDEFINED_TYPE
17 (x’11)
Указанный в запросе тип атрибута был неверным.

LDAP_INAPPROPRIATE_MATCHING
18 (x’12)
Указывает на то, что правило соответствия с расширяемым фильтром соответствия не поддерживается для указываемого типа атрибута.

LDAP_CONSTRAINT_VIOLATION
19 (x’13)
Указываемое в операции значение атрибута нарушает некоторые ограничения.
Возможные причины:
1. Строка слишком большой длины.
2. Неверный тип — строка записывается в числовой атрибут.
3. Неправильное значение, например, атрибут может принимать только определённое значение, либо одно из набора значений.

LDAP_TYPE_OR_VALUE_EXISTS
20 (x’14)
Указываемый тип атрибута или значение атрибута уже присутствует в записи.
Возможные причины:
1. При добавлении записи — один или несколько атрибутов в LDIF (или операции добавления/замены) для записи в точности совпадают (дублируются).

LDAP_INVALID_SYNTAX
21 (x’15)
Было указано неверное значение атрибута.

22 — 31
(x’16 — x’1F). Не используются.

LDAP_NO_SUCH_OBJECT
32 (x’20)
Указанная запись не существует в каталоге (DIT).

LDAP_ALIAS_PROBLEM
33 (x’21)
Псевдоним в DIT указывает на несуществующую запись.

LDAP_INVALID_DN_SYNTAX
34 (x’22)
Был указан синтаксически неверный DN. Может также возникнуть, если Вы используете файл в формате LDIF (dn: cn=xxx и т.д.) с утилитой ldapdelete, которой требуется только указание простого DN.

35 (x’23)
Зарезервировано и не используется в LDAPv3 (LDAPv2: LDAP_IS_LEAF — указанный объект является листовым, то есть у него нет дочерних объектов).

LDAP_ALIAS_DEREF_PROBLEM
36 (x’24)
Возникла проблема при разыменовании псевдонима. Смотрите также описание ошибки 33.

37 — 47
(x’25 — x’2F). Не используются.

LDAP_INAPPROPRIATE_AUTH
48 (x’30)
Была указана проверка подлинности, которую невозможно осуществить, например, была указана LDAP_AUTH_SIMPLE, а у записи нет атрибута userPassword.

LDAP_INVALID_CREDENTIALS
49 (x’31)
Были предоставлены неверные учётные данные, например, неправильный пароль.
Дополнительный текст: unable to get TLS Client DN (невозможно получить DN клиента TLS).
Возможные причины:
1. Не предоставлен сертификат клиента в случае, если директива TLSVerifyClient установлена в ‘demand’.
2. Не предоставлен сертификат клиента в случае, если директива TLSVerifyClient установлена в ‘never’. В этом случае данное сообщение об ошибке не является фатальным и обслуживание клиента продолжается.

LDAP_INSUFFICIENT_ACCESS
50 (x’32)
У данного пользователя недостаточно прав доступа на осуществление запрашиваемой операции.

LDAP_BUSY
51 (x’33)
Данный сервер (DSA) слишком занят, чтобы выполнить запрашиваемую операцию.

LDAP_UNAVAILABLE
52 (x’34)
DSA недоступен. Он может быть, например, остановлен, поставлен на паузу или находится в процессе инициализации.

LDAP_UNWILLING_TO_PERFORM
53 (x’35)
Данный сервер (DSA) не желает выполнять запрашиваемую операцию.
Дополнительный текст: no global superior knowledge (нет сведений о глобальном вышестоящем каталоге) — имя записи, которую собираются добавить или модифицировать, не находится ни в одном из контекстов именования и у сервера нет правильной отсылки на вышестоящий каталог.
Возможная причина: не задан атрибут olcSuffix (директива suffix в slapd.conf) для DIT, на которое идёт ссылка.
Дополнительный текст: Shadow context; no update referral (теневой контекст (реплика); отсылки для выполнения обновлений не указано) — DIT, в которое собираются вносить изменения, является репликой в режиме «только для чтения», и, из-за отсутствия директивы updateref, невозможно возвратить отсылку.
Возможные причины:
1. Была попытка произвести запись в реплику «только для чтения» (в конфигурации syncrepl потребитель всегда в режиме «только для чтения»).
2. В конфигурации syncrepl multi-master в файле slapd.conf возможно пропущена директива mirrormode true.
3. Если slapd при запуске использовал файл slapd.conf, а директория slapd.d (cn=config) также существует, то при последующих модификациях DIT могут возникать ошибки с выдачей этого сообщения. В частности, в FreeBSD требуется наличие явного указания в rc.conf (slapd_cn_config=»YES») для принудительного использования slapd.d.

LDAP_LOOP_DETECT
54 (x’36)
Выявлено зацикливание.

54 — 59
(x’37 — x’3B). Не используются.

LDAP_SORT_CONTROL_MISSING
60 (x’3C)
В стандартах не используется. Только для Sun LDAP Directory Server. Сервер не получил требуемый элемент управления сортировки на стороне сервера.

LDAP_RANGE_INDEX_ERROR
61 (x’3D)
В стандартах не используется. Только для Sun LDAP Directory Server. Результаты запроса превысили диапазон, указанный в запросе.

62 — 63
(x’3E — x’3F). Не используются.

LDAP_NAMING_VIOLATION
64 (x’40)
Указывает на то, что данный запрос содержит нарушение именования в отношении текущего DIT.

LDAP_OBJECT_CLASS_VIOLATION
65 (x’41)
Произошло нарушение объектного класса при использовании текущего набора схемы данных, например, при добавлении записи был пропущен обязательный (must) атрибут.

LDAP_NOT_ALLOWED_ON_NONLEAF
66 (x’42)
Операция на нелистовой записи (то есть той, у которой есть дочерние записи) не разрешается.

LDAP_NOT_ALLOWED_ON_RDN
67 (x’43)
Операция над RDN, например, удаление атрибута, использующегося в качестве RDN в DN, не разрешается.

LDAP_ALREADY_EXISTS
68 (x’44)
Данная запись уже существует в этом DIT.

LDAP_NO_OBJECT_CLASS_MODS
69 (x’45)
Не разрешена модификация объектного класса.

LDAP_RESULTS_TOO_LARGE
70 (x’46)
Только C API (черновой RFC). Результаты слишком велики и не могут содержаться в данном сообщении.

LDAP_AFFECTS_MULTIPLE_DSAS
71 (x’47)
Указывает на то, что операцию необходимо выполнить на нескольких серверах (DSA), а это не разрешено.

72 — 79
(x’48 — x’4F). Не используются.

LDAP_OTHER
80 (x’50)
Произошла неизвестная ошибка.
Возможная причина:
Попытка удаления атрибута (особенно в cn=config), удаление которого запрещено.
Дополнительный текст: olcDbDirectory: value #0: invalid path: No such file or directory
Возможная причина: перед инициализацией новой базы данных директория для её размещения должна существовать.

LDAP_SERVER_DOWN
81 (x’51)
Только C API (черновой RFC). Библиотека LDAP не может связаться с LDAP-сервером.

LDAP_LOCAL_ERROR
82 (x’52)
Только C API (черновой RFC). Произошла некоторая локальная ошибка. Обычно это неудачная попытка выделения динамической памяти.

LDAP_ENCODING_ERROR
83 (x’53)
Только C API (черновой RFC). Произошла ошибка при кодировании параметров, отправляемых на LDAP-сервер.

LDAP_DECODING_ERROR
84 (x’54)
Только C API (черновой RFC). Произошла ошибка при декодировании результатов, полученных от LDAP-сервера.

LDAP_TIMEOUT
85 (x’55)
Только C API (черновой RFC). При ожидании результатов было превышено ограничение по времени.

LDAP_AUTH_UNKNOWN
86 (x’56)
Только C API (черновой RFC). В ldap_bind() был указан неизвестный метод аутентификации.

LDAP_FILTER_ERROR
87 (x’57)
Только C API (черновой RFC). Операции ldap_search() был предоставлен неправильный фильтр (например, количество открывающихся и закрывающихся скобок в фильтре не совпадает).

LDAP_USER_CANCELLED
88 (x’58)
Только C API (черновой RFC). Указывает на то, что пользователь прервал запрошенную операцию.

LDAP_PARAM_ERROR
89 (x’59)
Только C API (черновой RFC). Процедура ldap была вызвана с неверными параметрами.

LDAP_NO_MEMORY
90 (x’5A)
Только C API (черновой RFC). Выделение памяти (например, с помощью malloc(3) или другого механизма динамического выделения памяти) вызвало сбой в процедуре из библиотеки ldap.

LDAP_CONNECT_ERROR
91 (x’5B)
Только C API (черновой RFC). Библиотека/клиент не может соединиться с LDAP-сервером, указанным в URL.

LDAP_NOT_SUPPORTED
92 (x’5C)
Только C API (черновой RFC). Указывает на то, что в запросе используется функция, не поддерживаемая данным сервером.

LDAP_CONTROL_NOT_FOUND
93 (x’5D)
Только C API (черновой RFC). Запрашиваемый элемент управления не найден на данном сервере.

LDAP_NO_RESULTS_RETURNED
94 (x’5E)
Только C API (черновой RFC). Запрашиваемая операция завершилась успешно, но никаких результатов возвращено (получено) не было.

LDAP_MORE_RESULTS_TO_RETURN
95 (x’5F)
Только C API (черновой RFC). Запрашиваемая операция завершилась успешно, но должны быть возвращены дополнительные результаты, которые можно уместить в текущее сообщение.

LDAP_CLIENT_LOOP
96 (x’60)
Только C API (черновой RFC). Клиент выявил зацикливание, например, при следовании по отсылкам.

LDAP_REFERRAL_LIMIT_EXCEEDED
97 (x’61)
Только C API (черновой RFC). Сервер или клиент превысил какое-либо установленное ограничение при следовании по отсылкам.

Recently I run into the problem where Exchange return with the error:

“An Active Directory error 0x51 occured when trying to check the suitability of Server…”

Weird thing this happened not for all commands. It was somehow randomly, but this caused several issues:

• prompt for credential (which was the most ugly side effect!)
• errors in scripts
• CmdLets didn’t return all values
• …..

When I first saw this error I had a déjà-vu. Last year I had a very long running case with Microsoft, where I had the very similar errors. But back in time Exchange 2010 on Windows Server 2008 R2 was affected. After several Gigabyte of network and LDAP traces it turned out to be an ICMP issue on the OS level:

The LDAP check is using ICMP to evaluate whether the server is up or down. And there was a bug in the ICMP stack, which result in an 0x51 LDAP error even the server was up and healthy. Read this KB for more information.

But now I started seeing this for Exchange 2013 CU10 on Windows Server 2012 R2.

How bad is it?

First I needed to know if this happens on a few server or on all. Therefore I needed to crawl the event logs across all Exchange servers for the EventID 2070. To speed things up I wrote the following function:

function Collect-Events (){
param(
    [Parameter(ValueFromPipeline=$True,ValueFromPipelineByPropertyName=$true,Position=0)]
    [Alias('fqdn')]
    [string] $computername = $env:computername,
    [parameter( Mandatory=$false, ValueFromPipelineByPropertyName=$false,Position=1)]
    [string]$EventID = '2070',
    [parameter( Mandatory=$false, ValueFromPipelineByPropertyName=$false,Position=2)]
    [string]$Eventlog = 'Application',
    [parameter( Mandatory = $false, ValueFromPipelineByPropertyName=$false,Position=3)]
    [DateTime]$StartTime = $((Get-Date).AddHours(-12)),
    [parameter( Mandatory=$false, ValueFromPipelineByPropertyName=$false,Position=4)]
    [ValidateSet("Critical","Error","Warning","Information","Verbose")]
    [string]$Severity
    )
process
    {
        Write-Host "Processing $Computername....."
        If ($Severity) {
        switch ($Severity) {
            "Critical"      {$level = 1}
            "Error"         {$level = 2}
            "Warning"       {$level = 3}
            "Information"   {$level = 4}
            "Verbose"       {$level = 5}
        }
            Get-WinEvent -ComputerName $Computername -FilterHashtable @{logname=$Eventlog;id=$EventID;StartTime=$StartTime;Level=$level} -ErrorAction SilentlyContinue
        }
        Else {
            Get-WinEvent -ComputerName $Computername -FilterHashtable @{logname=$Eventlog;id=$EventID;StartTime=$StartTime} -ErrorAction SilentlyContinue
        }
    }
}

This function has already the correct Event Log(Application) and EventID(2070) predefined. Now you can easily search across your Exchange servers. The following example search for EventID 2070 within the last 2 hours:

$2070 = Get-ExchangeServer | Collect-Events -StartTime (Get-Date).addhours(-2)

It turned out to be a general issue and not only on a few servers. Feel free to use this function to search for different events.

Root cause

After turning on logging for MSExchange ADAccess I could see the servers were heavily using Out-of-Site DC’s and GC’s. Shortly I’ve found the following KB, which explained a lot:

https://support.microsoft.com/kb/3088777

Before you start panic: This is only an issue in larger environments with multiple AD sites! Smaller ones shouldn’t be affected. Just to get an idea: In my case we have over 280 AD sites across the globe and not always the needed network bandwidth and latency, which is in general okay as in our scenario Exchange shouldn’t contact the most of them.

How to fix?

To fix this issue and change the behavior you just have to follow the KB article and edit the file Microsoft.Exchange.Directory.TopologyService.exe.config, and restart the service MSExchangeADTopology.

I have to admin just to restart this service sounds easy, but in the end you have to reboot the server. Not always all depending services could be gracefully restarted with MSExchangeADTopology service.

Conclusion

This change was made in CU6. From Microsoft perspective I understand why the change was made. Cloudwise it makes sense, but for larger on-premise installations this could really cause issue.

I hope this helps someone!