Tag Archive: security

I just developed some IT Security Policies for my small company. These will of course vary greatly depending upon your needs, applications, structure, and operations. I am posting a copy of the document up here in case someone wants to download it as a template, and go through sentence by sentence to fit it to their own company. Use these policies as you will, word for word if you want.

It Policies

It Policies

I take no credit for the Templates I used to create my policies, and I did in some instances copy word for word from the template. I will take credit for any changes that you see. the original templates can be found on SANS website at http://www.sans.org/security-resources/policies/

Very good site, very good templates. Thanks guys!

Here it is-

Generic IT Security Policy Whole

You you run the MSBSA and you gt an error stating that some user account have non expiring password. the security analyzer notes that this is a security violations: all accounts should have expiring passwords. Some account are excluded from this rule- use your best judgement here. i have a service account for SQL that is used in a connection string for a private database we use. This database is strictly internal, so I have it set to keep the same password, thus negating changing the connection string.

Password Expire

Password Expire

I have blanked out the actual user names as they are server service account names.

Account Error

Account Error


If you have a similar situation, we can exclude accounts from this scan by editing NoExpireOk.txt, and adding the accounts. I know for a fact that the warning is on the server account. I am going to exclude this from future scans, as this setting is set up by SBS 2008 itself and does not warrant changing.

Navigate to NoExpireOk.txt- I had a hard time finding the file. It is located in the MSBSA installation directory. Mine is D:\Program Files\Microsoft Baseline Security Analyzer 2\NoExpireOk.txt

Open it with Notepad.

Add the user account listed in the warning to the file.

Close and save it.

Now I will only recommend using the MSBSA as a tool to help you find security holes- do not use this to change every feature of your network. Some settings it scans and normal errors. I have all of my domain workstations secured with a local Administrator account. this is a strong password, and I set it to non-expiring. I can’t be bothered with changing these local passwords, as well as all of my personal and service accounts, as well as helping users change theirs. there are errors with folder permissions for SQL- leave those alone, they are set by the system. The list goes on- do not take it to the bank, but use it as a guideline for major issues.

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 🙂

I used to use Register.com as my trusted certificate provider. They issue a certificate which you install on the server. This certificate lets users connecting to remote web workplace that your server is legitimate, secure, and trustable. Without this certificate, users can sometimes get security warnings that vary by web browser. The IE error looks like this:

SSL Error IE

SSL Error

This is only a warning, and can be disregarded in cases where we know the server is safe. the problem with this is that end-users often do not understand the massage, or even do not read it. When they see this page they call support and complain about the internet being broken. Another bad thing about this error page is that to continue on to the site, you need to hit the red button. Be design, we associate red with stop, not continue.It is easy to get a certificate. We turn in some paperwork to a trusted authority, and they send us a certificate, which we then install. You server, upon creation, generates a private key. This key is what the trusted authority generates your SSL certificate on.My problem with Register.com is that I reinstalled my server. even though I have the same exact configuration, my private key was changed. Which means that my SSL was invalid. And Register.com was reluctant to issue me a new key. They had the special of $15 when I first bought it, though it is now $24. You get what you pay for, but in this case the simplest and cheapest the best. So after shopping around I see Comodo’s Positive SSL, only $9.95.So go to the Comodo website, and click to purchase a 1-year Positive SSL.
You will notice the address bar, displaying both a green color, https and a locked symbol. this is what we will achieve with the SSL.
Alright, lets generate our CSR for this website. On your server, open Windows SBS Console. Navigate to Network>Connectivity, and click Add a Trusted Certificate on the left.
SSL Choice

SSL Choice

There is a little disclaimer, click next. Select that you wish to buy a certificate from a certificate provider. The other option is for if you already have your certificate, and just need to install it. Click next.

Fill in the correct info in all of the boxes. This is an important step, and wrong information here might very well ruin the validity of a SSL Certificate. Enter all fields correctly, and write it down for later. Remember that the SSL is accompanying your domain name, which is mycompany.mysuffix. Mine is blankhealthcare.org, and my server added the prefix remote for my RWW and remote services. So I will enter remote.blankhealthcare.org in the Issued To: box, because this is the site I am securing. I blanked out the field to preserve confidentiality.
Verify SSL

Verify SSL

On the next screen, your CSR is generated. You need to copy all of that information that is in the gray box, including the title “—–BEGIN NEW CERTIFICATE REQUEST—–“. Hit the copy button. To be on the safe side, I also save it to a file, and put that file in a safe backup location.


In the next window, it asks if you have the cert, or will add it later. I just leave this box open. Now go back to the Comodo site and paste your CSR in the box they request it in. Select your software from the drop down box. In the case of SBS 2008 it will most likely be IIS 7.x and greater. Click one year.
I left the first 3 free upgrades in effect, and did not check the last one. No one will be purchasing on my site. Total cost is $9.95, excellent. Hit next.
This next step can be tricky. If you use an external domain to host your website, which then forwards email to your box using MX, the associated email accounts can be tricky. I do a little tricking myself. There is no address admin@mydomain.org, but Ill create a user really fast. then I grant myself full access permissions, and have the email sent there. I access it, and then shut down the account. You can have it sent to any of the other addresses in the list, though I would not suggest messing around with any important emails accounts such as postmaster, hostmaster, or webmaster.
Fill in your info. I am going to glaze over this part- if you don’t know how to fill in your own company information in a webform, press Ctrl-Alt-Del, select lock workstation, and go home for the afternoon.
Fill in credit info.
Click make payment.
They will confirm, and send out a few emails. One email is important. They mail a validation code to the mailbox you specified during set up. Go to Exchange Management Console. Expand user configuration, mailbox. Right click on the account for Admin (or whichever you specified. Click Full Access Permissions. Add yourself. You must be an Exchange Admin to do this. Now log into OWA, in in the top right corner, click your user name. in the box that appears, enter the name of the account you wish to open. Then read the email.
Copy down the validation code.
Click the link to enter the code, and paste it into the box. You will receive a confirmation.
Wait for the email to be sent. It can take a little while to arrive.
EDIT: At this point, after I validated I waited for one hour. I know the process takes a while, but I was eager to apply the certificate. So I entered a live chat on the Comodo website. After being transferred to a tech named “Jake”, he stopped responding. I gave him 8 minutes to reply to my question, before I hung up and emailed EVValidation. They received my ticket at 12PM….
Go back to the Add a Trsuted Certificate Wizard, and click next. You will see boxes to enter your certificate information.
Import Certificate
I open the email from Comodo that states my cert is attached, and save the zip file to my desktop. I then extract the folder to my desktop. Again, I blanked out my external domain name. The files inside of the zip are here:
Certificate Files

Certificate Files

I then follow a link in my email, oto make sure I am adding these correctly. I am not sure which cert is which, so Ill read up. The how to is here.
So I open IIS 7, click Server Certificates, and browse to my new files on the desktop. They are not in .cer format, so the wizard does not see them.
Wait a minute…. forget Comodo’s how to guide. Let’s go back to the Add a Trusted Certificate Wizard from the SBS console. Select Locate file. Click on the correct cert. this cert will be your domain name .crt. Mine is remote_blankhealthcare_org.crt.
Click that file, click next, and watch the wizard complete. Alternately you can copy the certificate text from the end of the email, and place it into the box provided instead of choosing the file.
Add Completion

Add Completion

When you head back to the connectivity tab of the SBS console, you will now see your certificate status as trusted- that means it is working correctly. There are 3 other certificates included in the zip file, let’s add those now. To do this, click Start>Run. type mmc.exe. When the MMC opens up, click file, Add/Remove snap-in.
Select Certificates, click add.
Click Computer account and Finish.
Click ok.
Expand Certificates.
Right click Intermediate Certificates, and select All Tasks>Import.
You will now select and Import two of the certificates in the zip file. the one titled
  • Intermediate CA Certificate – UTNAddTrustServerCA.crt -and-
  • Intermediate CA Certificate – PositiveSSLCA.crt
  • Once selected hit next until the wizard finishes, you shouldn’t have to change anything.

    You will also import your Root CA certificate, but instead of into Intermediate Certificates, Import this one into Trusted Root Certification Authorities.

    Now reset IIS and lets check it. Start>Run>type in iisreset. Now navigate to your site. Once on the site, click the lock next to the address bar. Click view certificate. the certificate should be listed as issued by Comodo and should be named PositiveSSL.

    Browser Certificate

    Browser Certificate

    Your done!

    Now Comodo offers some other stuff with the certificate for free, let’s set that up quickly, and also backup our certs and private keys so that if we crash we can reset this.

    You can sign up for HackerProof on the site linked in your email. I will opt to not sign up, as it seems a PC scan. I do not want a web service scanning my server, which already has antivirus anyhow.

    Lets backup our Private Key, then our Certificates. To back up your certificates, I suggest adding them to a zip file. Encrypting that zipfile with a backup. Then placing this zipfile on an encrypted and secure drive, preferrably offsite.

    To export your private key, go to certificates mmc. Drill down to the certificate you just installed. Right click and select Export. Include private key and anything else you wish. Password protect it, and save it in a secure location.

    You can insert the SSL Site Seal into your web site if you wish. I added mine to my background image, and disabled the link.

    EDIT: The SSL package that we just installed is the positiveSSL, which is the basic package for a SSL Certificate. Included in the $9.95 purchase is the EVSSL, Extended Validation. This must be completed by printing the two forms in the email. You must sign and enter your incorporation data, then fax them to Comodo. They will then validate your company, and issue you another more secure SSL, which can be installed the same way. This will give you the green security bar and lock icon.

    %d bloggers like this: