This started with a warning event log entry on one of my DC’s that I had seen before but finally decided to try and resolve. Log Name: Directory Service Source: Microsoft-Windows-ActiveDirectory_DomainService Date: 12/15/2010 11:17:08 AM Event ID: 2886 Task Category: LDAP Interface Level: Warning Keywords: Classic User: ANONYMOUS LOGON Computer: DC2.<My Domain>.local Description: The security of this directory server can be significantly enhanced by configuring the server to reject SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a cleartext (non-SSL/TLS-encrypted) connection. Even if no clients are using such binds, configuring the server to reject them will improve the security of this server. Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection, and will stop working if this configuration change is made. To assist in identifying these clients, if such binds occur this directory server will log a summary event once every 24 hours indicating how many such binds occurred. You are encouraged to configure those clients to not use such binds. Once no such events are observed for an extended period, it is recommended that you configure 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. 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. So after doing some reading on this I implemented this through GPOs per the instructions in the KB URL in the event log entry. I implemented it on both client and server side each in the appropriate GPO. I also raised the LDAP Interface Event logging to 2 on that DC per the instructions in the event log. After this I started getting a lot of event log entries on the DC like these: Log Name: Directory Service Source: Microsoft-Windows-ActiveDirectory_DomainService Date: 12/15/2010 2:56:41 PM Event ID: 1317 Task Category: LDAP Interface Level: Information Keywords: Classic User: N/A Computer: DC2.<My Domain>.local Description: Internal event: The directory service has disconnected the LDAP connection from the following network address due to a time-out. Network address: 192.168.2.19:54264 Log Name: Directory Service Source: Microsoft-Windows-ActiveDirectory_DomainService Date: 12/15/2010 2:54:11 PM Event ID: 1216 Task Category: LDAP Interface Level: Warning Keywords: Classic User: N/A Computer: DC2.<My Domain>.local Description: Internal event: An LDAP client connection was closed because of an error. Client IP: 192.168.2.19:54345 Additional Data Error value: 1236 The network connection was aborted by the local system. Log Name: Directory Service Source: Microsoft-Windows-ActiveDirectory_DomainService Date: 12/15/2010 2:55:49 PM Event ID: 1535 Task Category: LDAP Interface Level: Information Keywords: Classic User: <My Domain>\martha Computer: DC2.<My Domain>.local Description: Internal event: The LDAP server returned an error. Additional Data Error value: 0000208D: NameErr: DSID-0310020A, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=System,DC=PBJFS,DC=local' These always occurred in the order: event ID 1317, 1216, then 1535. I did some research on these and it seemed mostly related to the fact that I had the event logging set to 2. The IP’s listed in Event ID 1317 were always either the exchange server or my workstation where I used various administration tools. But nothing appeared to be broken either in the admin tools I was using or in the functionality of the exchange server. The text of the “error value” section of the Event ID 1535 log entries varied as did the “user” field. Sometimes the “user” was listed as a computer account name and sometimes as a user account name. Since this KB article http://support.microsoft.com/kb/246717 suggests that the 1216 errors are to be expected with the elevated LDAP Interface Event logging and since these 3 events were appearing together, and also since nothing appeared to be broken, I presumed this was not a problem. However what did appear to be a problem was a number of RPC related errors that started to appear in the event logs on the exchange server. They were more or less sporadic and included these: Event Type: Error Event Source: MSExchange ADAccess Event Category: General Event ID: 2152 Date: 12/15/2010 Time: 2:22:27 PM User: N/A Computer: <My Exchange Server> Description: Process w3wp.exe (AirSync) (PID=3220). An remote procedure call (RPC) request to the Microsoft Exchange Active Directory Topology service failed with error 1753 (Error 6d9 from HrGetServersForRole). Make sure that the Remote Procedure Call (RPC) service is running. In addition, make sure that the network ports that are used by RPC are not blocked by a firewall. Event Type: Error Event Source: MSExchange ActiveSync Event Category: Server Event ID: 1015 Date: 12/15/2010 Time: 2:22:27 PM User: N/A Computer: <My Exchange Server> Description: Exchange ActiveSync experienced a transient error when it tried to access Active Directory information for user "". Exchange ActiveSync will try this operation again. If this event occurs infrequently, no user action is required. If this event occurs frequently, check network connectivity using PING or PingPath. You can also use the Test-ActiveSyncConnectivity cmdlet. More information: Microsoft.Exchange.Data.Directory.ADTransientException: Exchange Active Directory Topology Service on server localhost cannot be contacted via RPC interface. Error 0x6D9. ---> Microsoft.Exchange.Rpc.RpcException: Error 6d9 from HrGetServersForRole at Microsoft.Exchange.Rpc.ADTopology.ADTopoRpcClient.HrGetServersForRole(String[] currentlyUsedServers, ServerRole role, Int32 serversRequested, ServerInfo[]& suitableServers, Int32[]& mapping) at Microsoft.Exchange.Data.Directory.DSAccessTopologyProvider.GetServersForRole(String[] currentlyUsedServers, ADServerRole role, Int32 serversRequested, Int32[]& mapping) --- End of inner exception stack trace --- at Microsoft.Exchange.Data.Directory.DSAccessTopologyProvider.GetServersForRole(String[] currentlyUsedServers, ADServerRole role, Int32 serversRequested, Int32[]& mapping) at Microsoft.Exchange.Data.Directory.DSAccessTopologyProvider.GetConfigDCInfo(Boolean throwOnFailure) at Microsoft.Exchange.Data.Directory.TopologyProvider.PopulateConfigNamingContexts() at Microsoft.Exchange.Data.Directory.TopologyProvider.GetConfigurationNamingContext() at Microsoft.Exchange.Data.Directory.ADSession.GetConnection(String preferredServer, Boolean isWriteOperation, Boolean isNotifyOperation, ADObjectId& rootId) at Microsoft.Exchange.Data.Directory.ADSession.GetReadConnection(String preferredServer, ADObjectId& rootId) at Microsoft.Exchange.Data.Directory.ADSession.Find(ADObjectId rootId, String optionalBaseDN, ADObjectId readId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties, CreateObjectDelegate objectCreator, CreateObjectsDelegate arrayCreator) at Microsoft.Exchange.Data.Directory.ADSession.Find(ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties, CreateObjectDelegate objectCtor, CreateObjectsDelegate arrayCtor) at Microsoft.Exchange.Data.Directory.ADSession.Find[TResult](ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties) at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession.FindBySid(SecurityIdentifier sId) at Microsoft.Exchange.AirSync.ADHelper.TryGetADEntryFromSid(Byte[] sid) at Microsoft.Exchange.AirSync.AirSyncUser.InitializeFromLoggedOnIdentity() at Microsoft.Exchange.AirSyncHandler.Handler.BeginProcessRequest(HttpContext context, AsyncCallback asyncCallback, Object extraData) Event Type: Error Event Source: MSExchange OWA Event Category: ADNotifications Event ID: 54 Date: 12/15/2010 Time: 2:22:29 PM User: N/A Computer: <My Exchange Server> Description: Failed to retrieve the Active Directory system configuration session. Exception message: "Exchange Active Directory Topology Service on server localhost cannot be contacted via RPC interface. Error 0x6D9.". Event Type: Error Event Source: MSExchange Autodiscover Event Category: Web Event ID: 1 Date: 12/15/2010 Time: 2:22:30 PM User: N/A Computer: <My Exchange Server> Description: Unhandled Exception "Exchange Active Directory Topology Service on server localhost cannot be contacted via RPC interface. Error 0x6D9." Stack Trace: at Microsoft.Exchange.Data.Directory.DSAccessTopologyProvider.GetServersForRole(String[] currentlyUsedServers, ADServerRole role, Int32 serversRequested, Int32[]& mapping) at Microsoft.Exchange.Data.Directory.DSAccessTopologyProvider.GetConfigDCInfo(Boolean throwOnFailure) at Microsoft.Exchange.Data.Directory.TopologyProvider.PopulateConfigNamingContexts() at Microsoft.Exchange.Data.Directory.TopologyProvider.GetConfigurationNamingContext() at Microsoft.Exchange.Data.Directory.ADSession.GetConnection(String preferredServer, Boolean isWriteOperation, Boolean isNotifyOperation, ADObjectId& rootId) at Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& responseControl) at Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextResultCollection() at Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextPage() at Microsoft.Exchange.Data.Directory.ADPagedReader`1.<GetEnumerator>d__0.MoveNext() at Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider.SimpleConfigCache`2.Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider.IConfigCache.Freshen(ADSystemConfigurationSession session) at Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider.UpdateCacheCallback(Object stateInfo) So after seeing these errors on and off for a few hours I changed my GPO’s back to no longer require LDAP signing (and ran gpupdate on the DC and exchange server) and since then the exchange error logs have only logged informational events and no errors, which is how it was before I tried to implement the LDAP signing requirement on the DC. This morning I tried researching these RPC errors and everyone seems to be saying they are DNS related. Either that or I have found threads about seeing some of these errors during the exchange setup due to some sort of problem with the account profile used to run setup but that is not relevant to my situation. I am inclined to doubt they are DNS related since there are no errors when I do not require LDAP signing. So what am I missing? Since the more serious issues appear to be on the exchange end I posted this here rather than in an AD related section of the forums. For further info the exchange server (2007) is the only one in the organization and holds the mailbox, CAS, unified messaging, and hub transport roles. It runs on a Server 2003 R2 x64 machine. The local DC’s are Server 2008 R2.

Hi MnM Per your above information, you enable the LDAP singning on the AD server,and the issue occured, right? Per my known, Clients that rely on unsigned SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds or LDAP simple binds over a non-SSL/TLS connection stop working after you make this configuration change. Seems exchange would cotact to AD using RPC, and then the connections were diconnected, that means exchange as a LDAP client to AD server, the requests from exchange server not meet the AD configuration. I would not enable the LDAP signing in a exchange scenario, but not sure that it is not allowed, I would do more research about it, and post more information here. Regards! Gavin TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi MnM, After do more research, AD and exchange ldap research and rpc connection all use the kerberos encryption, the security is enough good for them. And if you enable the ldap signing on AD server, it would also need do some configuration on the exchange server, some information for you: http://support.microsoft.com/kb/935834 That means AD server as a ldap server, and exchange server as a ldap client. Regards! Gavin TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.