You are on page 1of 13

Machine certification

Prepared for:
Draaiboomstraat 6
2160 Wommelgem

Prepared by:
Wim De Smet
Version 1.0
Monday, 07 April 2008
Table of Contents


Create certificate at AD 3

Config UAC/SSL for Machine certf 4
Import Root CA cert 4
Configure CRL 5
Configure Host Checker for Machine authentication 6
Attach host check to realm/role 6

Configure OAC client 8
OAC user authentication 8

Logging 10
Succesfull login 10
Failed login 11

SecureLink NV CUSTOMER Page 2 of 13
Machine certificates
We will create machine certificates for the domain workstations. Later we will be able
to use these to do machine authentication via SSL/UAC.

Create certificate at AD

1. Open Active Directory Users and Computers.

2. In the console tree, double-click Active Directory Users and Computers, right-
click the domain name in which your CA lives, and then click Properties.

3. On the Group Policy tab, click Default Domain Policy, and then click Edit.

4. In the console tree, right-click Automatic Certificate Request Settings, point to
(ew, and then click Automatic Certificate Request.


•Computer Configuration/Windows Settings/Security Settings/Public Key
Policies/Automatic Certificate Request Settings

SecureLink NV CUSTOMER Page 3 of 13
5. When the Automatic Certificate Request wizard appears, click (ext.

6. In Certificate templates, click Computer, and then click (ext.

Your enterprise root CA appears on the list.

7. Click the CA, click (ext, and then click Finish.

8. To create a computer certificate for the CA computer, type the following at the
command prompt:

gpupdate /target:Computer

Config UAC/SSL for Machine certf
Import Root CA cert
Before we can begin we need to import the root CA certf in the trusted client CA.

SecureLink NV CUSTOMER Page 4 of 13
Configure CRL
Here we import the root CA certificate, so we can configure the OSCP/CRL settings.
For this setup we have chosen to use CRL checking only.
This means we need to fill in the URL where he can download the CRL list from.
Microsoft CA server will publish this CRL on following URL:
http://mailsrv1.securelink.local/CertEnroll/SecureLink CA.crl
Now you will see how big the CRL is and how many revocation certificates there are.

SecureLink NV CUSTOMER Page 5 of 13
Configure Host Checker for Machine authentication
At the host Checker settings we will create a new policy, this policy will include a
new rule (machine Certificate rule). Now we will be able to enable this host check
policy on the correct realm, so that we can do machine authentication based on


Attach host check to realm/role
You have 2 time periods where you can check the compliancy of the host. First time is
before the assignment of the ip (in the EAP-JUAC tunnel (when done with UAC and
802.1X). The second time is when the user passed the authentication and has given an
ip address. Now the check will be done every given time (you can configure this), if
this check fails the connection will be broken.

SecureLink NV CUSTOMER Page 6 of 13
At above screenshot you see that we evaluate and require/enforce this host checker for

this policy. When you look at the screenshot below, you will see that we recheck the
host check every 5 min.

SecureLink NV CUSTOMER Page 7 of 13
When all this is done, we have user authentication with a certification check. This
means that we not only check if this is a know user, but that also the machine must be
Now we have to configure the 802.1X supplicant.

Configure OAC client
Here we will discus the configuration of the OAC client for user authentication and
certification check.
This setup is straitforward because the certification part is done on the IC like
explained above. At the client side we only need to configure the 802.1X part

OAC user authentication
We will use our Microsoft credentials for authentication, if wanted you can also use a
other username and password if needed.


We made a machine_certf profile which uses Microsoft credential for authentication.
If we go deeper into the methods we use, you will see that for authentication we use
EAP-TTLS, this makes it possible to do the host check before the ip assignment.
EAP-TTLS uses the EAP-JUAC has inner authentication protocol (this protocol is
made by juniper), in this protocol we have the possiblility to do the host check. (Pre
authentication host check)

SecureLink NV CUSTOMER Page 8 of 13
This profile will be attached to the Ethernet adapter.

SecureLink NV CUSTOMER Page 9 of 13
Adapter config

Here we see that the compliancy check is succesfull and that I meet the security

We can look at the logging of the Infranet Controller to see if authentication and
certificate check works.

Succesfull login
2007-11-07 15:54:22 - ic - []
securelink\wdesmet(Test8021X_Realm)[8021X role] - Connected to
0:agentman port 0

SecureLink NV CUSTOMER Page 10 of 13
2007-11-07 15:54:17 - ic - [] securelink\wdesmet(Test8021X_Realm)[8021X
role] - User assigned to vlan (Tunnel-Medium-Type='802' Tunnel-Type='13' Tunnel-
2007-11-07 15:54:17 - ic - [] securelink\wdesmet(Test8021X_Realm)[8021X
role] - Agent login succeeded for securelink\wdesmet/Test8021X_Realm from 00-17-
2007-11-07 15:54:17 - ic - [] securelink\wdesmet(Test8021X_Realm)[] - Host
Checker policy 'Certf_check' passed on host using 802.1X authentication for user
2007-11-07 15:54:17 - ic - [] securelink\wdesmet(Test8021X_Realm)[] -
Primary authentication successful for securelink\wdesmet/SecureLink_AD from 00-

You can cleary see that the Machine certificate check Is done before ip assignment!

Failed login
2007-11-07 15:46:50 - ic - [] SECURELINK\wdesmet(Test8021X_Realm)[] -
Login failed. Reason: NoRoles
2007-11-07 15:46:50 - ic - [] SECURELINK\wdesmet(Test8021X_Realm)[] -
Login failed from 00-17-A4-D6-A2-52 for
SECURELINK\wdesmet/Test8021X_Realm. All roles restricted.
2007-11-07 15:46:50 - ic - [] wdesmet(Test8021X_Realm)[] - Host Checker
policy 'Certf_check' failed on host using 802.1X authentication for user 'wdesmet'.
Reason: '"Machine certificate has been revoked"'.

SecureLink NV CUSTOMER Page 11 of 13
2007-11-07 15:46:50 - ic - [] SECURELINK\wdesmet(Test8021X_Realm)[] -
Primary authentication successful for SECURELINK\wdesmet/SecureLink_AD from

You can now see that I don’t have access anymore, and the client tell’s me that I
failed one or more security policy’s. If I want to know why I can click on the link to
see why:

SecureLink NV CUSTOMER Page 12 of 13
Here we see the reason of the disconnect => Machine Certificate has been revoked!!

SecureLink NV CUSTOMER Page 13 of 13