Repost from old blog
Well today is going to be a busy day here at the Microsoft Enterprise Engineering Center. At about 11:30 I am going to have lunch some of the RedvsBlue people (http://www.redvsblue.com). Then I have the job of setting up and testing a remote access solution for a customer. Note that the steps below are technical and you should know a little something about Active Directory and PKI before you start.
The problem: How do you provide a customer secure remote access into a scenario?
Solution: Smart cards and Terminal Services on Windows Server 2003! Smart cards keep the Private PKI key stored on the card, and cannot be removed from the card. It requires two-factor authentication. Something you have (the smart card) and something you know (the PIN).
How: First we set up a DC (or 2). Then install cert services on box (domain member). Then install Terminal Services on to another box (aka the Jump box).
We are using the Microsoft Base CSP (http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/Resources/Documentation/windowsserv/2003/all/techref/en-us/w2k3tr_certs_how.asp) on some Amtel Smart cards.
I create user accounts in the Domain for each person that will need remote access. Each Account has a Very LONG and Very RANDOM password. This is because the user will never use a password. They will not be able to use their smart card. Once the users are created make sure that you go in the properties of each user and under the Account tab select the following options: User Cannot change password, Password never expires and Smart Card is required for interactive logon.
Now create a separate Admin account. This will be the account that I use to manage the TS (terminal Services) jump box and issue the smart cards. Make sure it has a secure password.
To issue a smart card the issuing user account must have an Enrollment Agent Cert. To get this cert you must first enable it on the CA. (Open the CA MMC snapin -> select Certificate Templates -> Right-click on Certificate Templates -> Select New -> Select Certificate Template to issue. In the list select Enrollment Agent.
Repeat the steps above to also add the Smart Card Logon Cert. This is the cert that we will put on each Smart Card.
After you have enabled that cert (Enrollment Agent) you must now request it with the user account that will be issuing the Smart Cards. So for my solution that is the separate admin account. I will use runas.exe /u:<domainName>\<adminUser> "mmc certmgr.msc". This will allow me to open the MMC without logging in as that user.
To request the new cert select personal -> right-click on personal -> select all tasks -> select Request new Cert... Once the Wizard opens select Next to start it -> Select Enrollment Agent -> Select Next -> Enter a Name (like SC enrollment Cert) -> Select Next -> then Select Finish to issue the cert.
Now we will need to make sure we have our smart card reader installed on the machine that has our enrollment Cert and http access to the CA. With all of the above done you can now open a web browser to http://<CA Machine Name>/certsrv/certsces.asp (note: that you might have to add this site to your trusted sites to get the Active X control to load).
From this browser window we can select the type of Cert we want to put on the Smart Card. We are going to use Smart Card Logon Cert. You will need to select the Microsoft Base Smart Card Crypto Provider as your CSP. The Administrator Signing Certificate is the Enrollment Cert that we requested earlier. At this point you can select any user in the domain to issue a smart card for.
One thing to note is that when you have a smart card for user account it does not matter if the user changes their password. The smart card will allow the user to be authenticated without a password. So make sure that you keep accounts that have the Enrollment Agent Cert secure.
In the future I will also write about how to use the AD to further secure the Solution.