Network Admission Control

Jun 17 2008   2:28PM GMT

Certificates - who do YOU trust?

Posted by: Troy Tate
Network Admission Control, Exchange 2007, Outlook Web Access, OWA, Security, certificate authority, digital signatures, Thawte, Verisign

We are currently going through design and implementation of an Exchange 2007 environment in my organization. Our current e-mail architecture is varied and does not have any version of mail services newer than 6 years old. So, we are learning a lot about Exchange and how it can fit our environment of over 2,200 users globally.

Part of our requirements includes providing access to downlevel clients (Windows 2000 and below) as well as access to remote users. This will be easily accomplished through Outlook Web Access (OWA). As you know, OWA login is usually done on a page with an https or secure sockets layer (SSL) address. The SSL encryption is provided by a certificate hosted on that server. The certificate can be self-signed by the server, signed by an authorized certificate authority (CA) in the organization or by a trusted third-party provider like Verisign or Thawte.

If the certificate is self-signed by the server or by an organizational CA, then somehow the clients need to know about the trusted root or they need to accept the warning that the browser gives when they login to the website. You want the users to understand what trust means or take the question out all together. I vote for the latter. Remove doubt that the certificate is from a trusted source.

For the external OWA connections, we are purchasing certificates from a recognized third-party. I have gone through several iterations of getting certificates though since this is my first time getting these for an Exchange environment. There is a particular “flavor” of certificate known as a subject alternative name (SAN) or unified communications certificate. A great article on this can be found here. (Take note of the root website here. It is one of the best and most readable Exchange resources you will find since it comes from the Microsoft Exchange product team.)

So, I am now in the process of getting these SAN certificates and will be implementing them this week so the errors will go away when users login to these portals since they know and trust the root certificate authority.

The next challenge is to address this same issue on internal private OWA servers. We will be implementing a two-tier enterprise CA architecture using an offline root and a single enterprise CA. We will be publishing this through Active Directory so the clients recognize this as an internal trusted root. We are then positioned to use this CA for other uses: digital signatures, S/MIME, 802.1x, device authentication and other uses.

As you can tell, this has been a lot of education and work for my company. We have had some help in these efforts since this is entirely new to us and we have to implement it successfully the first time. I will let you know how things go.

Thanks for your time. Let’s be good network citizens together & practice safe networking!

May 21 2008   1:18PM GMT

Cutting IT corners is not cutting IT

Posted by: Troy Tate
administration, anti-virus, Data security, CIO, DataCenter, DataManagement, Mobile, Security, antivirus, malware, Performance, reporting, tools, policy enforcement, Policy, Network Admission Control

How often does this happen to you? A user is going to travel to another company location and they want to checkout a laptop for the journey. However, they tell you the morning of the travel rather than in advance. So you do not have time to check out the device and ensure that it is really in good operating condition or up to date on patches and anti-virus.

As they say, “Poor planning on your part does not constitute an emergency on mine”. However, this is a real business situation and IT responds to the user’s needs.

We recently had a situation where IT staff at a site gave a laptop to a user for travel. The IT staff cut corners due to time restraints and not understanding the implication of following corporate standards. The outcome of this: the user was given administrative rights on the laptop and non-standard software was installed. The combination of these two events created almost the perfect storm when the user reached their destination at another company facility.

The traveling user’s device created a denial of service (DOS) since it was infected with a virus and was unprotected due to anti-virus protection that had not been updated for over a year. This DOS took down some manufacturing equipment so production stopped. This took away one of the three legs of the information security triad: AVAILABILITY. Users were unable to access the systems or services they needed to do their jobs. The user was also unable to use the travel laptop in this condition.

Needless to say, the problem device was removed from the network and corrective actions were taken.

Both sites now understand why we have the procedures in place that we do. Users are told that they will submit their travel laptop request at least one day in advance. IT will no longer add these users to the local administrators group on the travel laptops. Let’s hope that these actions help reduce the likelihood of this happening in the future.

Network admission control (NAC) is a good method of enforcing policy on devices attaching to the network. However, this takes significant investment in equipment, software, policy creation and enforcement activities. Well, maybe someday I will be able to move in this direction. In the meantime, communication, understanding and enforcement will help all involved, users, IT and management.

Thanks for your time. Let’s be good network citizens together & practice safe networking!