4

I've been tasked to setup a secure platform, where I've been asked to assign personal SSL certificates to administrators, and have the server only allow persons into the administration areas that have these specific certificates.

We're running Windows Server 2008 R2 Web, with IIS 7.5. I know how to turn the SSL certificate requirement on and off for the administration areas; but I can't work out how to have X many certificates mapped to X many administrators being able to access the specific areas.

I'm not sure of the terminology to be able to google this stuff, which doesn't help my searching; I can only find outdated stuff.

(I've got another question on this on Server Fault, but they said to go here.)

3 Answers 3

9

Here's some high level design things to plow through first. There's a couple of ways to skin the cat, and how you set it up will impact the long term sustainability of this system.

Issuing and Managing Certificates:

So, you'll definitely need to issue each administrator his certificate. As per usual, Microsoft plays well with Microsoft, so if you have your own CA set up already for issuing server SSL certificates (or domain controller certificates), then leveraging it might be an easy way to do this. You'll need to think through:

  • How you get the certificates to admins

  • How admins store their certificate - for example, software certs are easy to create - and the private key gets stored in a file, but if you switch from machine to machine doing your job, how do you keep that private key safe? on a USB? USBs are easy to loose! Imported into each browser on each system? That's putting the key pair a lot of places. Putting the certificates on smart cards or other hardware tokens is more expensive, but more secure. But then you have to be sure that the admins have a smart card reader on each machine! This stuff can really impact your security policy and should get figured out before you spend the time setting up the system.

  • How are admin certificates terminated? The typical PKI process is revocation by the CA, but that assumes that your servers have a way to check certificate status via either CRL or OCSP. IIS servers can do that (google "certificate status check" or "certificate status validation") but it almost certainly takes some configuration at both your CA and the server. You may also want to stand up an OCSP server, if you haven't already.

  • how are certificates authenticated - you'll want to set up your IIS trust store to include the CA that is issuing your admin certificates. This is a big reason to have a CA sign your certificates... if you do not, you need to configure every trust store to trust the self-signed end entity certificate and that is a maintenance nightmare.

How is privilege assigned?

A CA is usually used to issue a variety of certificates, only some of them are admin certificates. How you design privilege assignments has a big impact on how well all this stuff works. Here's some options:

  • make it a special quality of the issued certificate - for example, include the word "Administrator" in the Distinguished Name when you create and sign the Administrator certificate. Look for that field when the admin logs in. That may involve some custom code at the server. Advantage - no extra centralized checking, Disadvantage - must have a way to consistently issue certificates, must revoke certificates when an admin leaves his position, must check certificate status.

  • configure privileges in Active Directory - as @M'vy's links say - there's ways to configure AD (or any LDAP server) to affiliate users (authenticated by certificates) with privileges (ie, being an admin) - this makes the setup eaiser to change - the user can have 1 cert, which he uses for admin stuff. This privilege can be disconnected when the user is not an admin, or other criteria can be added via AD. Means configuring your AD and your IIS server to check it. Adds some complexity to user setup, as now the admin needs a cert AND a setup in the Active Directory server.

  • Statically configure at the server- keep a list of trusted admin certificates at the server, and check this list - that's the AD-free way listed on the links form @M'vy - that works fine for a small operation with no AD server, but it gets troublesome if you have to manage lots of servers, as each server needs an update every time an admin joins or leaves.

Any or all of these options will work - it's just a question of how frequently you change admins, how many servers you have to manage, and what you want the process to be. Thinking all that out will save you much pain in the long run.

Here's some hit words for researching this stuff: - to force user SSL based login with a digital certificate - "SSL client authentication", "client auth", "TLS client authentication/auth", - for more configuration help - "cert(ificate) store", "trusted certs", - for certificate status checking - "CRL check", "OCSP check", "cert status check", "cert verification/validation" - for configuring privileges "role based access control", "privilege management",

And couple those with the software you are trying to configure.

5

I'm not familiar with IIS so I hope what I've found is not the outdated results you already found.

But what you need is to set up a Certificate Authority and issue a certificate per User. I found this site talking about how to do it. The the mapping seems to be done between certificate and AD(??) users. You can check here and here about the so-called one-to-one mapping.

Hope this helps.

1
  • Aside from IIS 6 vs IIS 7, those links look good.
    – Steve
    Jul 27, 2011 at 14:56
0

Do you have a Public Key Infrastructure already setup? If this is a new deployment, you may want to backup a bit and really think about HOW you want to do this. Otherwise you'll be managing separate silos of Certificate Authorities.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .