I have been receiving an error message (Event ID 2887, below) on our Windows 2008 Domain Controller. I followed instructions to enable LDAP error logging and after doing so end up with a set of LDAP error logs (Event ID 1216, below).
I ran dcdiag on the domain controller and received the following:
Starting test: KccEvent
An Warning Event occurred. EventID: 0x800004C0
Time Generated: 11/22/2010 05:34:26
Event String:
Internal event: An LDAP client connection was closed because of an error.
……………………. DC passed test KccEvent
The time indicated by this warning event corresponds to the most recent event ID 1216.
I then found instructions to run the following commands (IPconfig /flushDNS; IPconfig /registerdns; Net stop netlogon; Net start netlogon) which I did on both the domain controller and on the server indicated by the event ID 1216. But after doing so, event ID 1216 continues to occur.
Could somebody please suggest a next troubleshooting step? To confirm, I am looking to resolve the cause of the Event ID 1216 occurrences, not to just turn them off.
Thanks in advance for any assistance!
******* Event ID 2887 ********
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 11/21/2010 9:00:31 PM
Event ID: 2887
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: dc.domain.com
Description:
During the previous 24 hour period, some clients attempted to perform LDAP binds that were either:
(1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or
(2) A LDAP simple bind that was performed on a cleartext (non-SSL/TLS-encrypted) connection
This directory server is not currently configured to reject such binds. The security of this directory server can be significantly enhanced by configuring the server to reject such binds. For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.
Summary information on the number of these binds received within the past 24 hours is below.
You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the «LDAP Interface Events» event logging category to level 2 or higher.
Number of simple binds performed without SSL/TLS: 2
Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: 0
***************************
******* Event ID 1216 ********
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 11/22/2010 5:34:26 AM
Event ID: 1216
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: N/A
Computer: dc.domain.com
Description:
Internal event: An LDAP client connection was closed because of an error.
Client IP:
192.168.1.xx:yyyyy
Additional Data
Error value:
1236 The network connection was aborted by the local system.
Internal ID:
c0602f0
***************************
If you run a fully patched Windows Server Essentials 2016, you’ve probably been seeing this event in your daily Health Report since around March 2020:
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 3041
Task Category: LDAP Interface
Level: Warning
Description:
The security of this directory server can be significantly enhanced by configuring the server to enforce validation of Channel Binding Tokens received in LDAP bind requests sent over LDAPS connections. Even if no clients are issuing LDAP bind requests over LDAPS, configuring the server to validate Channel Binding Tokens will improve the security of this server. For more details and information on how to make this configuration change to the server, please see https://go.microsoft.com/fwlink/?linkid=2102405.
This is best explained in KB article 4520412. That article includes descriptions of new events.
There are two group policy changes and a registry change. I’m making the group policy changes in the existing Domain Controllers > Default Domain Controllers Policy GPO. The path for both policies is Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. I’m making the following changes for now:
- In that group policy path, change “Domain controller: LDAP server signing requirements” from None to Require Signing.
- In the same group policy path, change “Domain controller: LDAP server channel binding token requirements” from Undefined (= Never) to Defined and “When Supported”
- In the registry, change “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics16 LDAP Interface Events” (logging level) from 0 to 2
The last one—increasing the logging level—is important as it should allow identifying any clients that are attempting “to bind without a valid CBT” (event 3039). The binding should still be allowed since #2 is set to “When Supported”.
Once I’ve identified and remedied unsuccessful LDAP connections, I should be able to change #2 to “Always”.
Update July 31, 2020
One day later, I’m seeing several 1216 events like this:
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 7/31/2020 2:15:29 AM
Event ID: 1216
Task Category: LDAP Interface
Level: Warning
Description:
Internal event: An LDAP client connection was closed because of an error.
Client IP:
[::1]:53936
Additional Data
Error value:
1236 The network connection was aborted by the local system.
Internal ID:
c060420
MSKB 246717 is not an exact match, but it sounds like those events are just showing up because I increased the logging level, not because of tighter LDAP security. To be sure, I’m going to temporarily set server signing back to “None” (option 1 above).
Update August 1, 2020
As expected, even with LDAP signing set to None, the 1216 events continue. So they are unrelated to the signing requirement and solely a byproduct of the increased logging level. Setting signing back to Require Signing.
Update August 8, 2020
The only warning/error events I’m seeing in the Directory Service log are the 1216s. However with the increased logging, that 1MB event log is only storing about one day’s worth of events. Increasing the Directory Service event log to 10MB.
Update August 17, 2020
No warnings or error in the event log other than the 1216s mentioned above. I’m changing signing to Always. If no new errors appear in the event log in a few days, I’ll reduce the logging level back to 0.
I am trying to analyze the reason for exceptions/ failures during the Ldap search. I am performing operations using JNDI on Active directory domain controller.
Here is the background for the things that I am trying to do:
- Using SASL (
Kerberos authentication) using JAAS (KRB5LoginModule) to generate aLoginContext. - Once the login is successful,
LoginContextinstance has the authenticated subject which has the kerberos ticket (TGT) populated in itsPrivateCredentials - After that, I generate the LdapContext using GSSAPI using the above authenticated
Subject. - Once the
LdapContextis generated, I use it to perform JNDI operations (mostly search using paging)
- Till now everything is fine and LdapContext is generated correctly
- Some details of the Active Directory Domain Controller settings:
- The lifetime of the TGT is set to be
1 hour - The lifetime of the service ticket(
TGS) is set to be 10 minutes (required due to some constraints, but this is how it is)
Now the Scenario:
-
Using the the
LdapContextcreated above, it starts querying the domain controller using thepagingcontroland things work smooth for certain amount of time or certain amount of searches (lets say this so that I don’t want you all to misguide that this might actually involve time, just consider this occurs after (approx.) regular intervals — those intervals could be time or searches -
When it goes to get the next page after a certain interval, the search fails with :
Caused by: javax.naming.CommunicationException: Connection reset at com.sun.jndi.ldap.LdapCtx.getSearchReply(LdapCtx.java:1920) ~[?:1.8.0_73] at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.getNextBatch(AbstractLdapNamingEnumeration.java:130) ~[?:1.8.0_73] at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:217) ~[?:1.8.0_73] at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189) ~[?:1.8.0_73] ... 10 more Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:209) ~[?:1.8.0_73] at java.net.SocketInputStream.read(SocketInputStream.java:141) ~[?:1.8.0_73] at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) ~[?:1.8.0_73] at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) ~[?:1.8.0_73] at java.io.BufferedInputStream.read(BufferedInputStream.java:345) ~[?:1.8.0_73] at com.sun.jndi.ldap.sasl.SaslInputStream.readFully(SaslInputStream.java:166) ~[?:1.8.0_73] at com.sun.jndi.ldap.sasl.SaslInputStream.fill(SaslInputStream.java:123) ~[?:1.8.0_73] at com.sun.jndi.ldap.sasl.SaslInputStream.read(SaslInputStream.java:90) ~[?:1.8.0_73] at com.sun.jndi.ldap.Connection.run(Connection.java:860) ~[?:1.8.0_73] at java.lang.Thread.run(Thread.java:745) ~[?:1.8.0_73]
At the same time, I see following event logs on Active Directory domain controller: EventId: 2889
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2889
Task Category: LDAP Interface
Level: Information
Keywords: Classic
User: ANONYMOUS LOGON
Computer: myad01.example.lab
Description:The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without
requesting signing (integrity verification), or performed a simple bind over a clear text (non-
SSL/TLS-encrypted) LDAP connection.
Client IP address: X.X.X.X:56260
Identity the client attempted to authenticate as:EXAMPLEAdministrator
Binding Type:0
I also see a log with EventID: 1216. The details are as follows:
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1216
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: N/A
Computer: myad01.example.lab
Description:Internal event: An LDAP client connection was closed because of an error.
Client IP:X.X.X.X:56244
Additional Data
Error value: 1236 The network connection was aborted by the local system.
Internal ID: c060420
My understanding: Whenever (after some interval) it goes to get the next page the ldap connection is invalidated by the server ( as suggested by the event id 1216) due to which I am getting the CommunicationException . My question is Why am I getting this after certain interval and not immediately? Is it because the validity of the kerberos and service tickets is over?
If this is the case, then how should I design to overcome my paging issues? Because, after getting communication exception, if I create a new LdapContext and set the paging control I get following exception as expected:
javax.naming.OperationNotSupportedException: [LDAP: error code 12 - 00000057: LdapErr: DSID-0C090B0B, comment: Error processing control, data 0, v3839 ]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source) ~[?:1.8.0_201]
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) ~[?:1.8.0_201]
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) ~[?:1.8.0_201]
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source) ~[?:1.8.0_201]
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) ~[?:1.8.0_201]
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source) ~[?:1.8.0_201]
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source) ~[?:1.8.0_201]
at javax.naming.directory.InitialDirContext.search(Unknown Source) ~[?:1.8.0_201]
It is really important for me to have both the support — SASL(kerberos) for authentication and GSSAPI for LdapContext creation. Also, Paging is important as the data is huge and we can’t have any restrictions on ticket validity as I can’t control the cutomers’ environments!
Please provide me with pointers on how to debug this issue further and suggest a proper way or a workaround (sorry for this, but need it anyway) to solve this issue.