Google Verification

Wednesday, November 2, 2011

Converged Physical and Logical Access for the Enterprise

What is converged physical and logical access?  Simply put - its the ability to use one credential (USB token, smart card, smart phone, etc..) to gain access to the buildings where we work, and also to computers and networks we use to do our job.

7 or 8 years ago, NIST defined a set of technical standards called PIV (also known as FIPS-201) to address the requirements detailed in Homeland Security Presidential Directive 12 (HSPD-12). The primary purpose of PIV was to define a "Policy for a Common Identification Standard for Federal Employees and Contractors."  PIV defines the policies for how Government employees and contractors identify themselves in order to receive a PIV Card, as well as what information must be collected, and how it is formatted and stored on the card.

The Smart Card Alliance just published a draft document detailing the Commercial Identity Verification (CIV) standard.  It is a first attempt at creating an equivalent PIV standard for the Enterprise.  The document is entitled "The Commercial Identity Verification (CIV) Credential – Leveraging FIPS 201 and the PIV Specifications: Is the CIV Credential Right for You?".  While there is a long way to go before CIV becomes an official standard, it will borrow heavily from the PIV technical specification. It will differ significantly on the policy elements, as it will be up to each organization to define policies to meet their business requirements.

The benefits to the Enterprise of adopting a CIV (or PIV):

- Broad based support for PIV. Drivers are built in to Windows 7, Windows Server 2008R2, Mac OSX 10.5+ and the Blackberry Smart Card Reader.  OpenSC has a P11 interface that can be used for Mozilla and other applications.
- Increased logical security.  Using a certificate is more secure than using a username and password for logging on to computers.
- Increased physical security.  Most proximity based physical access control systems deployed today use technology that can be easily duplicated.  PIV cards cannot be duplicated in the same way traditional proximity cards are today.
- Consolidated control over a user's access.  Users are currently issued credentials from multiple systems (PACS, ActiveDirectory, etc...).  Each of these credentials need to be managed using separate infrastructures and interfaces.

I encourage you to read the paper on CIV.  If you have questions on any of these, please feel free to e-mail me.

Wednesday, August 10, 2011

Clearing certificates from the Global Address List (GAL)

I worked with a company recently to deploy certificates for S/MIME encryption and signing.  They had an old Microsoft PKI that had issued certificates to all of their users, but in traditional fashion - nobody knew who installed it, or who was responsible for it.

After setting them up on our Managed Service Eval, we began issuing certificates to each of their users for testing purposes.  While e-mails would get encrypted OK, nobody could decrypt them.  They got the super informative message from Outlook: "Your digital ID name cannot be found by the underlying security system."  It turns out everyone had one or more Microsoft certificates published to the GAL, but nobody had the corresponding private keys on their computers.

To resolve this issue, we had to remove the old certificates from the GAL, and then publish the correct ones again.  To do this:

  • Open up the Trust Center from Outlook Options
  • "Trust Center Settings..."
  • "E-mail Security"
  • "Settings" (to the right of Default Setting:)
  • "Delete"
  • Close the Settings dialog
  • Select "Publish to GAL..."  It will ask you if you want to remove your existing published settings.
  • Select "Settings" again, and set your default security settings.
  • Select "Publish to GAL..." to publish your latest certificates...

For those that are interested, I've recorded a video of how to do this in Outlook 2010:



Thursday, July 14, 2011

Configuring Smart Card Removal Behaviour

Companies deploying Smart Cards for SCLO want to control what happens when a user removes their Smart Card or token from the computer.  You have four options:
  1. Do nothing (default)
  2. Lock workstation
  3. Force Log-off
  4. Disconnect if a Remote Desktop Services connection.
All companies I work with want the workstation to Lock.  Here is how to configure it.

Microsoft changed the way it handles Smart Card removal in Windows 7.  They introduced a "Smart Card Removal Policy" service that must be running for this to work.  By default this service is configured to start up manually.  To test this locally, open up the Services console (services.msc),find the "Smart Card Removal Policy" service, and change the start up type to "automatic" and start the service.


Next, modify the Local Group Policy for your computer.
  • Open gpedit.msc
  • Expand Computer Configuration --> Windows Settings --> Security Settings --> Local Policies --> Security Options.
  • Edit the "Interactive logon: Smart card removal behavior" policy to perform the desired action.

That is all there is to it!  Of course you will need to configure the Domain Policy to push these changes out to all of your users!

Tuesday, July 12, 2011

Why don't you try Symantec's Managed PKI?

Every day I help companies to deploy certificates across their Enterprises for use by users, devices and applications.  The #1 application for certificates is for securing mobile devices accessing internal company resources.

If you're looking for a PKI, and you don't have the time to figure out how to install and run one yourself, you should have a look at Symantec's cloud based PKI service.  It is a fast and easy way to get up and running with a fully functional PKI for all of your needs.  Whether you need certificates for DirectAccess, 802.1x, SCOM/SSCM, or for your mobile devices - we can do it all.

Symantec offers a free Test Drive that allows you to try the service yourself.  Sign up and give it a try.  If you have questions - don't hesitate to contact me.

Domain Controller Certificates for Win2K8 R2

I thought I would highlight an issue (or requirements) for Domain Controller certificates issued by a Symantec PKI to Windows 2008 R2 domains for SCLO.


If the certificate doesn't contain the necessary OIDs, you will see KDC Event 29 and KDC Event 19 errors in the Event Viewer. 


You require the following OIDs:

EKU OIDs:
Server Authentication(1.3.6.1.5.5.7.3.1) 
Client Authentication (1.3.6.1.5.5.7.3.2) 
KDC Authentication (1.3.6.1.5.2.3.5) 
Smartcard Logon (1.3.6.1.4.1.311.20.2.2)

Certificate template name:
DomainController

KU:
Key Encipherment
Digital Signature


This source for this post came from a Microsoft blog here:
http://blogs.technet.com/b/instan/archive/2011/05/17/smartcard-logon-using-certificates-from-a-3rd-party-on-a-domain-controller-and-kdc-event-id-29.aspx


Finding this information is hard, so hopefully this blog will serve as an additional source for it.

Wednesday, March 2, 2011

Welcome to my blog...

My name is Myles Huffman, and I'm a Principal Technical Specialist with Symantec.  I've been with Symantec for a little under a year, and was with Entrust for 14 years before that.  I have built a strong foundation in authentication, PKI and Smart Cards.

Since 1998, every year was going to be "Year of PKI", and that never really materialized.  There were a variety of factors, but primarily - the market didn't understand what PKI was or what it could do.  As a result, sales people spent a lot of time trying to educate the market on PKI.  Compound this with the fact that very few applications supported certificates natively, and by the early 2000's, PKI became a four letter word that nobody wanted to talk about.

But a funny thing happened; a few years ago, PKI started popping up on company radars again.  This time, companies are calling us, and they're asking us to help them solve their technology challenges with our PKI!  What a difference a decade makes!

Initially the goal of this blog is to act as a central repository for Smart Card Logon (SCLO) configuration and troubleshooting information.  I'm certain it will evolve over time.

I'll start by posting a link to a Microsoft KB article that explains the high level process for configuring smart card logon.  Its a good article that explains the high level requirements. I will use a separate blog post to explain each step in as much detail as possible.

I hope you will find it helpful...