Archive for October, 2010


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

Registry/Diagnostics

Registry/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…

New GPO

New GPO

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 🙂

So running the SBS 2008 BPA, I received a low disk space error, less than 15%. Now I get these errors often, and I have moved everything I could off of the drive, including Sharepoint Content, Redirected Folders, Exchange Databases, Installed Programs such as Microsoft Office.

BPA

BPA

Man, my space IS low, 9 Gb out of 60 Gb free. Let me clean out what I can. I empty all the temp folders, delete some empty folders, some setup logs… Wow, I actually recovered 10 Mb of space. Great.

Then I thought about Windows Server Update Services- I know they keep content somewhere (If you have them set to download and store content, which I do). Drats, that is on D:\ as well. (If you need to move WSUS CONTENT, this is not your post).

What about the database files themselves? I go to C:\WSUS\SUSDB\UpdateServicesDbFiles\ and there they are. Two files:

SUSDB.mdf

SUSDB_log.ldf

*** Stop Update Services Service in Services.mmc ***

Having worked with databases before, I know it is not as simple as dragging and dropping the files. So lets work in SQL.

Goto Start>All Programs>Microsoft SQL Server 2005> and select SQL Server Manager Express.

The program opens, and gives you the Object Explorer. You need to connect to a database instance to work with the database. WSUS uses Windows Internal Database, so let’s connect to that one. You can’t log in with sa, or with Windows Auth even if you are an admin- so enter this in the server name:

\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

Leave it on Windows Auth, and hit connect. Expand Databases, and your looking at quite a few of them, mostly related to Sharepoint. The one we want is SUSDB.

First, and always, BACK IT UP. This can be done by right clicking the SUSDB and selecting Tasks>Back Up. Now you will have to choose your location, medium type, and file name yourself. For me, I picked a removable HDD (A:/) and named the backup…

Backup

Backup

SUSDB.bak

Let that execute, it might take some time (mine took roughly 7 minutes). Once you get the success message, it’s time to move this DB. Since databases have active connections, and moving the files with these connections can break the the entire internet, lets DETACH the database before moving it.

On a side note this can all be done via command line and sqlcmd. I am not comfortable with the language so I just use the GUI.

Go back to SQLMSE and right click the SUSDB again. This time click Tasks>Detach.

Detach

Detach

You get a screen with one line and some check boxes. You can change some of the boxes depending upon your needs, but for this one, we will select Drop Connections and Keep Full Text Catalog, which is selected by default. As you can see the DB has current connections (such as SUS clients).

Drop Connections

Drop Connections

This will detach the DB. Go back to Windows Explorer, and navigate to the C: drive. Grab the entire WSUS folder, and move it to your target drive. I moved mine to D:\WSUS, which is where my catalog is as well. Might want to give it it’s own directory to be safe.

Now we need to re-attach the database. Go back to SQLSME and right-click on instance, in this case, \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query (SQL Server 9.0.4035 – Domain\UserName).

Click Tasks>Attach.

Attach

Attach

Click Add, and navigate to your new database location.

Choose Location

Choose Location

Click ok. Let it work, it will gray out and take a bit.

Attaching

Attaching

Once it is complete, double-check the database file location by right-clicking SUSDB and selecting properties. Select Files on the left, and look at the Path. You should see your new database path listed there.

Path

Path

Your done. Close everything out, and double-check both the SBS Console and the WSUS Console to make sure everything is synchronized and working. That just recovered almost 4 Gb of space on my otherwise picked-clean C: drive.

*** Start Update Services Service in Services.mmc ***

You run the Exchange 2007 BPA, and get a non-default setting like this one:

BPA Alert

BPA Alert

First, I will explain what caused this. You wanted to disable some settings using netsh, namely autotuning level and rss, by entering these commands at the prompt:

netsh in tcp set global autotuninglevel=disabled

This is done fro two reasons. One, it speeds up remote desktop connections, which can be really slow. Second, it comes up in the SBS 2008 BPA as a warning and invites you to run up to 4 netsh commands to change the TCP values. Don’t you love how Microsoft tells us to fix one thing while the fix causes another problem? Hum.

Go to this key, and look at the values. They are probably messed up like mine, though some of them can be messed up and not others. Your keepalivetime key might be some high number like the rest, mine is sixty.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Regedit

Regedit

So now, let’s reverse these settings. These settings are important- you can’t just go into the registry and delete or change the values. Microsoft provides a hotfix that will stop these netsh commands from changing the values- I won’t be running them again, I do not need the hotfix. Hotfix’s and my production server don’t mix well. He hotfix is here.

First, we should restore a backup prior to the change if we have one. I do not, so meh. But I will take this opportunity to MAKE a backup, in case I botch something here. Right click the Parameters folder, and click export. Give it a nice name, like tcpip-param.reg and save it someplace safe. If all else fails we can restore this later.

Microsoft provides a PowerShell script to fix these entries. Let’s see if we can get that to work. Download the script from here. You will have to log in. Ill download it and host it on WordPress. I assure you this file is safe, but if you are unsure get the one from MS. Here is the ps1 file. I renamed it to a .doc. To change it back download it and rename it to netshregfix.ps1. Here is the code it contains. you could also make a new text document, paste in the code, and save it as .ps1

NetshRegFix.doc

MD $env:UserProfile\Desktop\TcpIpParametersBackup
REG Export HKLM\System\CurrentControlSet\Services\TcpIp\Parameters $env:UserProfile\Desktop\TcpIpParametersBackup\Backup.Reg

Get-Item "HKLM:\System\CurrentControlSet\Services\TcpIp\Parameters" | ForEach-Object {
Set-ItemProperty -Path $_.pspath -Name "TcpTimedWaitDelay" -value 60 -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "DisableTaskOffload" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "EnablePMTUBHDetect" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "EnablePMTUDiscovery" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "KeepAliveInterval" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "KeepAliveTime" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "Tcp1323Opts" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "TcpFinWait2Delay" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "TcpMaxDataRetransmissions" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $_.pspath -Name "TcpUseRFC1122UrgentPointer" -ErrorAction SilentlyContinue
}

Write-Output "You must reboot your server for the changes to take effect"

Save the file to someplace easy to navigate to, I chose C:\. Now open Windows PowerShell. Start>Run> PowerShell.

Type in cd C:\ to navigate to where the file is. If you placed it in another location, go there.

Now type NetshRegFix.ps1

PowerShell Error

PowerShell Error

*** Before you do this step, scroll down to the next bold, asterisk’d item. You do not need to install this update- though you can if you do not have the PowerShell 2.0 yet. ***

You get an error, as if PowerShell does not even recognize that this is a script. Well, let’s update PowerShell. Go to http://support.microsoft.com/kb/968929 and select your OS. Download the MSU and install it.

It will install a “hotfix”.

Windows Update

Windows Update

Ah crap. Need to restart. So much for doing this during lunch. Ill do it at 5:30 when everyone is gone.

Restart

Restart

*** Continue from here, to complete running the script in PowerShell v1.0. ***

Wait wait. What about just running the script? Go to C:\ and double-click NetshRegFix.ps1. It opens up in Notepad. Let’s open it up in PowerShell.

Click open with, browse for program. Navigate to c:\Windows\system32\windowspowershell\v1.0\ and select powershell.exe.

Now go back to the file and double-click it. A screen flashes- did it complete? To check, go to the registry setting tcp/ip>Parameters. It should look like this:

End Result, Regedit

End Result, Regedit

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:

HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue

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.

This informational item appears under the non-default settings tab of the Exchange BPA. This happens when you customize the generation of SMTP addresses. The alert is not dangerous, and you can safely ignore it.

BPA

BPA

Let’s see what setting is causing this alert, make sure it is configured correctly, and describe what the setting is doing.

Open up Exchange Management Console and then drill down to organization Config>Hub Transport>E-Mail Address Policies. In my Exchange, I have 2 policies. In a default setup, there will only be one policy (Default Policy), and you will not get this BPA error.

Policies

Policies

Let’s explore my added setting,and what it does. I double-click my added policy which is called Windows SBS Email Address Policy. Alternately, if you are creating an additional policy you would click New Email Address Policy in the right menu.

The first page is the name of your policy. This is merely for tracking- name it whatever you want. Under that is the scope of the policy. You can set up policies to apply to only certain aspects of your AD. Mine is set to All Recipient Types (Including user account, room, contact, and equipment addresses).

Introduction

Introduction

You can further apply conditions. I do not use any but here is a scenario. You have two departments in your company: Sales and Shipping. You have two-handled email domains and they are user@salescompany.com and user@shippingcompany.com. Now when you add a new user to Exchange, you would set the conditions to identify the user’s department. If the user was in Shipping, it would automatically generate the address of username@shippingcompany.com.

Conditions

Conditions

This would be a waste of time for a small company such as mine that uses one AD container for all departments, but in larger companies this can be valuable- imagine managing email addresses manually when working with 10,000 users over the span of several companies, locations, and departments.

The next page is Email Address Policies- this is where you tell Exchange how to formulate the email addresses. I have mine set to %g.%s@company.org. The %g and %s are variables that the AD uses to identify item characteristics, in this case first and last name. When I add a user John Doe, it generates an email address John.Doe@company.com.

Policy

Policy

I could have edited the default policy which would have given me no warning, but I try to never edit defaults. In this case, if there was an error with this portion of Exchange I could delete or disable the policy without affecting email generation.

Another default setting in Exchange is under the email address tab of a users properties. Near the bottom there is a box ticked that says Automatically update email address based on recipient email address policy. If this box is ticked, changes here will affect email addresses. So get this setting right, and the addresses will be right as well.

User Properties

User Properties

Half way down this page is a table of variables and what they mean. If you are an AD guru, I am certain you can also use custom AD attributes in generation.

On the next page, set your time frame- I set mine to immediately. Let Exchange process the command and apply this to your selected recipients, and you are done.

Schedule

Schedule

You will notice the rule having a priority of 1, while the default has a priority of Lowest: This means that the new or other policy is applied before/instead of  default.

If you have problems with this policy, simply remove it.

%d bloggers like this: