Archive for the ‘Security’ Category

Boost your internal PKI/Microsoft CA security with FREE green Extended Validation SSL in 15 minutes or close your eyes until 2016!

One of the new CAB Forum baseline requirements is that all SSL certificate issuers are to stop issuing SSL certificates with internal host names and IP addresses. Currently it is possible to get internal host names in public certificates until 2016, but after 1. July it will be shortened to 2015. But keep reading and you will remove this threat today, instead of waiting to 2015-2016.

Normal usage of SSL certificates

Most companies with a medium to large infrastructure, use an internal PKI solution like Microsoft Certification Authority for identity and encryption on internal workstations and accounts. They will also use internal CA to issue certificates for server systems that are only accessed by internal computers where Root CA trust can be controlled automatically thru GPO or similar.

But external facing websites and server systems use public external CA issued SSL certificates, to ensure trust by all units including mobile units and external computers.

(did you see the padlock in the above image?)

Example of attack

It makes sense to prevent easy attacks on the identity part of SSL security for internal systems. Any internal website would be easy to replace with a fake site or do a man in the middle attack with a real external publically trusted SSL certificate that includes the internal host names. Example: an internal password management portal on https://mypassword.abc-organization.local. The intruder gets a certificate issued to www.notyours.dk including a SAN name “mypassword.abc-organization.local”. It would be easy for the intruder to setup a fake website to harvest passwords with a real SSL certificate that all clients would trust equally to their internally issued SSL certificate on the existing system. Clients would see the padlock with no visible changes. Read the rest of this entry »

Why you can no longer just have one SSL certificate with all the servernames included.

Internal server names in publically recognized SSL certificates are about to become just as extinct as Sharks in Chinese waters.

The CA / Browser forum has decided to implement changes to SSL requirements, that will phase out all use of internal server names in public SSL certificates. The CA / Browser forum includes all the major certificate authorities and browser developers, so the change will be forced upon everyone.

The negative impact

It especially hits small to medium businesses with just a few servers. I.e. Exchange, Lync and Small Business Server, where a single SAN certificate including both public and internal server names, will save them both time and resources otherwise needed for reconfiguration, internal PKI solutions and/or reverse proxy and similar systems to allow usage of a separate internal and external SSL certificate on a single website/service.

Exchange 2010 will by default use a single website and configure it self to use its internal FQDN i.e. exchangeserver01.fairssl.local and external FQDN i.e. webmail.fairssl.dk for this one website/SSL certificate. The change will require a change in configuration or systems surrounding the Exchange 2010 environment to continue working without both names in one SSL certificate.

SBS 2011 on the other hand has received the functionality to use split DNS to use the external server name both internally and externally, this not much mentioned change may have something to do with Microsoft being on the CA / Browser forum board, so they would have known about this change for a while.

Larger companies typically have more resources and will have an easier time separating internal and external SSL certificates, without having to buy new solutions like Forefront TMG, SSL offloaders, Internal PKI, etc. But my guess is still that a large number of them will still need to change some configuration to avoid problems with internal server names.

Why?

The reasoning behind this phase out is to secure against Man-in-The-Middle (MTM) attacks, where it is possible to pretend to be an internal server via a publicly recognized SSL certificate. Even thou it is a highly unlikely way to attack most systems, the theoretical possibility is enough to spark the change. I just wish they had been a little more giving on the deadlines.

My personal recommendation to my customers with SSL certificates containing internal server names Read the rest of this entry »

The difficulties of installing an SSL certificate on a ZyXEL ZyWall USG 300 firewall (if even possible!)

Having spent some time trying to install an SSL certificate from a trusted certification authority on this product, I felt I should share my findings as they might save someone else the headaches and time I had to spend on this.

For reference I used a ZyXEL ZyWall USG 300 with Firmware version: 2.20(AOE.6) / 1.11 / 2011-10-05 11:51:34

I assume this information is the same for pretty much all versions of ZyWall products, but I can not confirm this from own testing as I only had access to one edition.

About Intermediate SSL certificates

All certificates today that want to enjoy the WebTrust approval must use intermediate issuing certificate authorities, this means that a root certificate is no longer allowed to directly issue server certificates for customers. This makes good sense security wise, as it is much harder for a hacker to gain access over the root certificate when it is not online and in case of a compromise, it should be sufficient to close the intermediate, without having to "remove/uninstall" the root from every client in the world.

So most professional products around that uses SSL certificates must be able to install both a server certificate and the intermediate issuing certificate, because the client only knows the root certificate, it needs the server to give it both.

Installing SSL certificates on ZyXEL ZyWall USG 300 (the good part)

Go into Configuration -> Object -> Certificate

Some things to have in mind when installing Read the rest of this entry »

Active Directory Shadow Group Script – will let you spend less time on updating group memberships

Introduction
If you are just looking for a free shadow group script, either click here for a nice simple one or go to the bottom of this post for the full AD administrated script.

I was looking into Shadow Groups, inspired by a customer migrating from Novell to Active Directory. Apparently in Novell you can use Organizational Units as security groups, and by just moving a user to another OU when they change departments, they will automatically update their security permissions given by their department OU placement.

So what is so great about shadow groups you might ask. Simply put if you have OU's for departments, where you place users depending on department membership, shadow groups, will shadow the members of the OU in the security group, I assume that is where the name shadow group comes from. This allows you to setup security permissions for a group that is linked to an organizational unit. So when you move user A from department sales, into department accounting, the user A will automatically be removed from the sales security group and added to the accounting security group, effectively updating user A's permissions automatically. Saves time for large organizations, now a user moving OU does not need to have his groups manually updated.

The first hit on google was a blog post by John Policelli (MVP) explaining shadow groups is not a new type of group in Active Directory, it is rather a concept, when you automatically update the members of a security group from the objects placed in an Organizational Unit. Also he points out that this automatic synchronization is not an existing feature in Windows Server, we need to add it our self. The example he uses with dsquery, dsget and dsmod, works if you manually set it in a script for each OU/Group, I was looking for something easier to manage, that preferably did not require editing of the script that needed to run. I strongly believe scripts that can be maintained from Active Directory will always have a longer life time, since less updates and potential errors happen in the script.

After some more searching I found an article by Jakob H. Heidelberg (MVP and fellow Dane) this one also had a good explanation about what Shadow Groups are and also a download link to a simple VBScript to populate a group with the users in an Organizational Unit. If You are looking for a script to feed the OU and Group and then update the group from the users of the OU, that script will do you just fine and I would recommend you take a look at the article and script he wrote, as it is simpler and less prone to errors by being simple.

My idea of a Shadow Group Script Read the rest of this entry »

How to disable administrative shares on workstations thru Group Policy and avoid spending time on pesty virus infections

Large companies sometimes have problems with a virus that realy loves administrative shares on other workstations (i.e. c$ and admin$), it will try and break into theese to spread it self directly. The easy option ofcourse being kill the virus or even better harden administrative users and not use administrator rights for normal users! But untill that is an easy, non-political and not so time consuming task, why not disable the administrative shares on the workstations alltogether?

Seems like a perfect thing to do with Group Policy, unfortunately the setting is non-existing default in Group Policies, so by finding the registry key we need to change, a small custom administrative template will do the trick. This could also be used for other registry changes needed with group policy.

We might also want the option to easily enable the administrative shares later, might be used by applications, services, automated installations, etc. Heres is how to do it quick and easy. Read the rest of this entry »

How to get external SAN UC SSL certificates that work with OCS 2007 R2 and avoid having to read 100 blog posts!

Been reading up on external and internal DNS names used by OCS 2007 R2 ? Your head stopped spinning yet? So you've decided on what FQDN's to use, next step order some SSL certificates, should be easy enough right, You allready figured out You need SLL certificates that are Unified Communications Certificates (UCC) enabled. In my example I will use GlobalSign Domain Validated SAN's, if I needed multiple domains for example for @sole.dk and @soleit.dk, I would choose GlobalSign Organisation Validated SAN's instead.

For a GlobalSign SSL certificate to be UCC enabled, it must use SAN domains, no other way of enabling it. So no point in spending lots of budget on seperate SSL certificates for each service. SAN Subdomains are also quite alot cheaper than buying seperate SSL certificates.

One of the tricky parts of Office Communications Server 2007 R2 and SSL certificates, is that You can not use one single SAN SSL for all services, if You intend to use port 443 for all services!

Why would we only use port 443 ? Read the rest of this entry »