Category: Error

Checking the server for errors as is customary every morning, I open up server manager and see a few warnings and a few errors on the server roles.

ADDS Error

ADDS Error

 Lets investigate the warning on Active Directory Domain Service (ADDS) first. A quick examination of the event log leads me to event 2886.

Event 2886

Event 2886

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.

They further go on to describe the problem in these words:

The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL)LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASLs may include protocols such as Negotiate, Kerberos, NTLM, or Digest.

Unsigned network traffic is susceptible to replay attacks in which an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures packets between the client and the server, changes the packets, and then forwards them to the server. If this occurs on a LDAP server, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client.

If you don’t understand these security features and what SASL bind or LDAP simple binds are- then imagine it simply as clients accessing and communicating with the AD using plain english, which anyone could eavesdrop on. You certainly don’t want anyone listening to your AD.

In order to see if your clients are using these communication methods, we need to turn up the logging level for LDAP Interface Events, and then wait to see if we get any error messages. I would suggest monitoring these events for a few days before making changes- blocking these binds will cause a client using them to disconnect, and better to work on that proactively.

Open Regedit (Start>Run>Regedit) and navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics



You will see that this key has listed a bunch of diagnostic features, all set to zero. You can enable the logging for each of these events by changing the number to anything up to 5. A list of what each number does can be found here.

Change the value of 16 LDAP Interface Events to 2 by double clicking it and changing 0 to 2, and hitting enter.

Now keep your eye on the Event Log for event ID 2889, which will contain the IP Address of the client connecting with these binds.

Alternately, if you disable these binds, the server will post one log event every 24 hours with ID 2888.

After a few days, or hours, or no time depending upon how patient you are, you may check the Event Log and find these entries, or not. To make things easier you could create a custom log in event viewer, and filter in only event id’s 2886, 2888, and 2889.

LDAP Event Log

LDAP Event Log

As you can see, my filter is only finding event id 2886, which is the security for the bind warning. I am not seeing any 2888 or 2889, which would mean that clients were connecting using these binds. So let’s go ahead and correct the security vulnerability less privilege is more.

To do this, we need to configure the server to REQUIRE LDAP signing. This is done by Group Policy. Microsoft recommends that you make this change in the Default Domain Policy– yet I do not touch that one. So I am going to make a new GPO and link it in the domain, then apply it to all computers. You can make the changes to the Default Domain Policy if you want.

Open up GPMC from Start>All Programs>Administrative Tools>Group Policy Management.

Right click your domain, and click Create a GPO and link it here…



Name it something appropriate, like LDAP Signing.

Then open the GPO by right clicking it and selecting Edit. Now drill down to:

Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options.

Right-click on Domain Controller: LDAP Server Signing Requirements and select properties.

Check off Define this Policy Setting.

Select Require Signing in the drop-down box.

Require Signing

Require Signing

Click ok and accept the warning. You can follow the link to Microsft’s KB article describing what is going on.

Basically, older clients might be configured to use these unsigned binds, pretty much pre XP Pro SP2. If all of your clients are updated or using newer Windows versions, you don’t have to worry about configuring them to start signing. If you have older clients, and don’t know how to change them- you might want to leave this setting alone.

This is a good setting to change to lock down your server, and close unneccessary vulnerabilities in the path between client and server. A hacker might be able to intercept a unsigned packet and change it, then forwarding it to your server. The server would read the packet and execute actions based on the hackers unsigned packet.

As always if you break your network, it’s not my fault 🙂

You get a non-default setting when you run the Exchange 2007 BPA. It says:Disk timeout on server SOLACESERVER.solace.local is not set at the default of 10 seconds. This is normal if third-party storage software is installed. Current timeout value is 30 seconds.

As the message says, if you use some type of storage software, leave this be. I do not use any of this software, so I want to change it back to default. not that it might cause damage, but if it shows up here then it is a possability. As always make sure you backup and do this on a test server or in mock. I have no test server and I am daring, so I am going to do it during lunch on a Wednesday.

The setting is documented here.

Microsoft tells us to:

To revert to the default configuration
1.Open a registry editor, such as Regedit.exe or Regedt32.exe.

2.Navigate to:


3.In the right pane, delete the TimeOutValue entry. Alternatively, double-click the TimeOutValue entry and set it to one of the following values:

On a non-clustered server, set the value to 10.

On a clustered server, set the value to 20.

If your hardware manufacturer recommends a different value for either a clustered or non-clustered system, use the value from your hardware manufacturer instead.

4.Close the registry editor, and then restart the computer for the change to take effect.

So let’s do what they tell us. Ill add some screen shots.

This is what the current registry entry looks like.

Before Change

Before Change

Double click it. Change to 10. It should look like this now:

After Change

After Change

I would like to point out this warning:

Installing host bus adapters (HBA) or other storage controllers can cause this key to be created and configured. When you install or reinstall these drivers, the TimeOutValue registry value is overwritten with the value that is required by those drivers. You may have to contact the hardware vendor to determine the correct TimeOutValue registry value for your configuration.

Read it carefully. I HAVE installed a HBA as well as a storage controller. I looked up the values for my HP Proliant, and they should be at thirty. I will leave this entry alone and safely ignore it from within the BPA.

You run the Exchange 2007 BPA and see the following information (warning) items:

Junk Store threshold is currently configured to move messages to recipient’s Junk folder when they have a Spam Confidence Level (SCL) value of 8. This is the default value for the Junk Store threshold. However, the recommended value is 4. You can configure SCL thresholds by using the Set-OrganizationConfig cmdlet in the Exchange Management Shell.

SCL Warning

SCL Warning

Following the link on the BPA, which takes you here, tells us the correct setting for the SCL Junk Threshold is 4. Im good with Microsoft recommendations, more so if it stops errors. You can change this number depending upon your organization and your desire to block out spam. The lower the value, the more “spam” is blocked, including what Exchange thinks is spam and may be good mail. I have had issues with spam in the past, 4 sounds way better than 8.

This is done by the Exchange Management Shell. Open it up from the start menu, the navigate to the scripts folder by typing in the command:

cd “C:\Program Files\Microsoft\Exchange Server\Scripts” including quotes.

Simply type in:

set-organizationconfig -scljunkthreshold 4



SCL Junk Threshold

SCL Junk Threshold


If you get no error, the issue is solved. If too much good mail is being trapped in spam folders, change this to 5 or 6. If you want more mail captured- spam is getting through- change this to 3. Personally I would not go higher than 3, and if you go that high make sure you enable a transport rule to give mail sent from your users a rating that will allow it through.

%d bloggers like this: