How to enable Windows Server 2008 R2 to issue SAN certificates

The Certificate Authority in Windows 2008 R2 cannot issue Subject Alternative Name certificates in it’s default configuration.  Therefore if you include a SAN entry (like for Exchange) the CA will issue your certificate, but omit all the SAN entries

To allow your CA to issue SAN certificates you need to run the following from an administrative command prompt:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

This is not necessary on a Windows 2012 and above.

 

Symantec Data Insight 4.5 Overview

Symantec recently released version 4.5 of their Data Insight product.  In a nutshell, Symantec Data Insight allows an organization to:

• Identify who works with and owns their data
• Understand what unstructured data they have
• Maintain regulatory compliance for information access, use and retention
• Ensure information is protected from exposure to unauthorized individuals
• Review permissions on data and suggest changes

What’s New?

• Self-service portal allows data owners to remediate incidents directly without necessarily involving IT.
• Reporting enhancements
• Deep integration with Symantec Enterprise Vault and Symantec Data Loss Prevention
• Data Insight can infer ownership of a file and then add that intelligence to Symantec DLP
• Allows you to utilise Symantec EV’s file archiving and retention management capabilities when remediating incidents

To sum it all up, if you need to reduce the effort you spend on securing your data, enhance your data protection levels as well as achieve / prove compliance then Symantec Data Insight will go a long way to assist you in achieving those goals.

My Customer Service Rules

I've spent the last decade of my career dealing with customers, both directly and indirectly.  I've made my fair share of mistakes, and I also did a lot of things right.  Whilst I still have a lot to learn about customer service (I am technical, not sales after all) I also have some rules that I believe one should unflinchingly abide by.  These are, in no particular order:

1. Never lie.  Not to your customers, not to your colleagues, not to anyone.
2. If you make a mistake, be accountable.  Everyone makes mistakes and most people of worth respect and appreciate honesty.
3. The quickest way to lose the respect of your peers and customers is to point fingers and trying to apportion blame.
4. Get to know your customer and their business.
5. Listen.  Understand the problem from the customer's point of view, not just a technical one.
6. You expect to be paid like a professional, so act like one.  Do not become too "friendly" with the customer and do not swear in front of them. Ever.
7. "It's not my problem" does not exist in your vocabulary.  If it's not within your domain then help the customer resolve it by roping in someone who can.
8. Always notify the customer when you are about to make changes.  E-Mail is only sufficient if the customer acknowledges the mail, otherwise follow up with a phone call.
9. Only stick to the communicated changes.  If you tell the customer you're rebooting the mail server, do not reboot the file server as well.
10. In that vein, always make sure your customer does not get caught by surprise by always communicating updates.
11. Stick to your appointments - if you say will show up at 9 then you show up at 9.  If you can't then you let the customer know in advance via a phone call - e-mail is not acceptable.
12. Share your knowledge with the customer.  This will not make you redundant, it will allow you to provide value further up the chain.
13. You exist to serve the customer and their needs (within reason).
14. Speak to your customers often, no less than once a month.  In the services industry "Out of sight, out of mind" holds very true.
15. Always protect yourself, the customer and your relationship by agreeing on things up front.  This includes costs, scope of work and handover / success criteria.  Do not negotiate these after the fact.
16. Whenever possible work for and with people you respect. When you do, even the stressful times are easier to deal with.
17. Pre-sales is an art, and the paint brush is 'why.'  Keep asking until you get to the root.
18. Never, ever, bad-mouth another customer or vendor in front of a customer.  Always focus on and sell your strengths.
19. Lastly, no-one who ever bought a drill needed a drill...they needed to make a hole.  I cannot stress enough how important this concept is.

H323 traffic failing to traverse a Fortigate firewall

Had a scenario recently where a Polycom video conferencing device just wouldn’t work when sat behind a Fortigate firewall.  This was despite all the necessary TCP ports being forwarded to the device, as verified by Polycom support.

What we were seeing is that one could dial the VC but it would just ring and never make the connection.  Time to debug the traffic on the Fortigate – this is what I saw:

id=13 trace_id=74 msg="vd-root received a packet(proto=6, x.x.x.x:1720->x.x.x.x:63665) from lan."
id=13 trace_id=74 msg="Find an existing session, id-02237475, reply direction"
id=13 trace_id=74 msg="SNAT x.x.x.x->x.x.x.x:1720"
id=13 trace_id=74 msg="run helper-h323(dir=reply)"

The “run helper” sequence kicked in as soon as one attempted to pick up the call on the VC.  In Polycom’s case they suggest explicitly disabling any h323 helpers, so that is exactly what I did.  I did it like so:

1. From the cli, execute “config system session-helper”.  This will give you the following output (below is redacted)
   edit 2
           set name h323
           set port 1720
           set protocol 6
       edit 13
           set name sip
           set port 5060
           set protocol 17
2. Now delete these helpers by executing
   config system session-helper
   delete 2
   delete 13
   end
3. Enter the following commands:
   config system settings
   set sip-helper disable
   set sip-nat-trace disable
4. Lastly we disable RTP processing:
   config voip profile
   edit default
   config sip
   set rtp disable

Your h323 and SIP traffic should now traverse your Fortigate without issue.  In my experience this has only happened with Polycom devices, Microsoft Lync works fine without modification.

Fortigate SSL VPN Client cannot resolve FQDNs

Recently had a customer complain that he cannot access documents on his file server when connected via SSL VPN. Closer inspection showed that the customer was trying to access the fileserver by hostname “\\fileserver” as opposed to “\\fileserver.corp.local”.

The fix seemed to be simple, implement a DNS search suffix. Unfortunately there is no such option in the GUI, so I had to set it via command-line.

Set DNS search suffix using CLI

config vpn ssl settings
set dns-suffix corp.local
end

Set Client DNS Server in the GUI

Navigate to VPN –> SSL –> Settings –> Tunnel Mode Client Settings.  Specify the DNS Server setting and enter the IP addresses of your corporate DNS servers.

Your Fortigate will now append the “corp.local” suffix to all non-qualified hostnames.  This was tested on FortiOS 5.06, 5.07 and 5.2

SCCM 2012 R2 Collection Queries

After spending a considerable amount outside of the Microsoft ecosystem I recently found myself running a project where I had to deploy SCCM 2012 R2 for a customer.  I immediately caught myself wishing I made notes of my basic collection queries during my prior deployments.  Consequently I decided to document them in one place now:-)

All Dell Systems

select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceID where SMS_G_System_COMPUTER_SYSTEM.Manufacturer like "Dell%"

All Server Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM.SystemRole = "Server"

All Workstations

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM.SystemRole = "Workstation"

All Domain Controllers

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.PrimaryGroupID = "516"

Removing persistent proxy settings

This is one of those things that I find I constantly have to google.  Oftentimes app traffic will just not flow correctly, more often than not the issue is with an outdated proxy setting.  What trips one up here is the fact that this proxy is not listed in your IE proxy settings.  The issue is that the winhttp proxy component has been set – below is how we can manipulate it.

View Current Proxy Settings

• Windows Vista / 7 / 8 command line: netsh winhttp show proxy
• Windows XP command line: proxycfg

Reset Proxy Settings

• Windows Vista / 7 / 8 command line: netsh winhttp reset proxy
• Windows XP command line: proxycfg /d

Simple fix to a potentially frustrating problem!