Monitor ASA VPN sessions via SNMP

This took me way too long to research so I’m putting this here in case anyone can use it.

I have an ASA 5520 that is used for IPSEC, Anyconnect, and Clientless WebVPN vpn clients. I was asked to track total # of sessions for the migration of licenses. Since there was a Nagios Monitor onsite, I hoped to add an snmp check for the total number of WebVPN sessions (Anyconnect and clientless).

Cisco has the ASA MIBs located here:
ftp://ftp.cisco.com/pub/mibs/supportlists/asa/asa-supportlist.html

The oid values you need are as follows:

crasIPSecNumSessions .1.3.6.1.4.1.9.9.392.1.3.26.
crasWebvpnNumSessions .1.3.6.1.4.1.9.9.392.1.3.35.

Drop the MIB into the shared mib folder on the nagios host in usrsharesnmpmibs
I had some issues with the Cisco MIB, I haven’t tried on another nagios host yet, but the OID values worked just fine for my purposes.

In nagios, create the check_snmp lookup, I opted for a new command:

 define command{
        command_name    check_snmp_cisco_oid
        command_line    $USER1$/check_snmp -H $HOSTADDRESS$ -P 2c -C communityname -o $ARG1$ -w $ARG2$ -c $ARG3$
        }

Then define the services for the host:


define service{
        use                     generic-service
        host_name               ASA5520
        service_description     Total Number of Web SSL VPN sessions
        check_command           check_snmp_cisco_oid!.1.3.6.1.4.1.9.9.392.1.3.35.0!50!75
        }
define service{
        use                     generic-service
        host_name               ASA5520
        service_description     Total Number of IPSEC VPN sessions  
        check_command           check_snmp_cisco_oid!.1.3.6.1.4.1.9.9.392.1.3.26.0      
        }

OpenSwan Error – One Way Traffic with Cisco ASA

Openswan 2.6.37

Symptom: OpenSwan to Cisco ASA Site to Site Tunnel has one way traffic.
Description: The Ipsec Tunnel builds, both the openswan host and the ASA show the tunnel up but traffic only flows from the ASA into Openswan, traffic does not flow back from openswan. No errors were shown in the auth.log.

Solution: It turns out that the issue was related to the openswan ipsec conf file for this connection. The Leftid and rightid were setup as shown here in the problematic conf file:

conn tunnel-to-HQ
  left=10.1.0.50
  leftid=@openswan
  leftsubnet=10.1.0.0/24
  right=PUBLIC.IP.OF.ASA
  rightid=@asa
  rightsubnet=10.2.0.0/24
  .
  .

  auto=add

This conf file would would just fin for an Openswan to Openswan IPSEC tunnel. But for an ASA to Openswan tunnel, it failed to pass two way traffic.

The simple fix was to replace the leftid and rightid with the IP addresses of the 2 peers as shown below:

conn tunnel-to-HQ
  left=10.1.0.50
  leftid=10.1.0.50
  leftsubnet=10.1.0.0/24
  right=PUBLIC.IP.OF.ASA
  rightid=PUBLIC.IP.OF.ASA
  rightsubnet=10.2.0.0/24
  .
  .
  auto=add

The secrets file should reflect the IP addresses in the conf for this PSK setup:

10.1.0.50 PUBLIC.IP.OF.ASA: PSK "123456789"

Restart the tunnel and traffic flowed normally.

How to Log IPTABLES Dropped Packets to Syslog

Simply, I want to have IPTABLES log whenever it drops a packet.

To log all dropped incoming packets, add these entries to the bottom of your IPTABLES rules:

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

To log all dropped outgoing packets, add these entries to the bottom of your IPTABLES rules:

iptables -N LOGGING
iptables -A OUTPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

To log all dropped packets, incoming and outgoing:

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A OUTPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

All items will be sent to the local syslog.

How to Remove Old Computer or User accounts from a Windows Domain

Any admin knows that there are always computer and user accounts in AD that become stale and unused. It’s good practice to remove these old accounts from AD.

Here’s how I do it.

From any Domain Controller, open a command prompt and try the following.

 
dsquery computer -inactive 8 -limit 3000 

Dsquery is an invaluable tool and can do much more than just this. We tell dsquery to look for computer accounts that are currently inactive for 8 weeks and to limit the display to 3000 entries. Setting the -limit to 0 would return all entries.

If you would simply like to count them:

dsquery computer -inactive 8 -limit 3000 | find /c "-" 

This example should also return inactive computer accounts, older than 8 weeks. In this case, we query for stale passwords on computer accounts instead. This should return the same results as the ‘inactive 8’ flag in the previous example.

dsquery computer DC=domain,DC=com -stalepwd 56 -limit 0 

Now that we know what computers need to be removed, lets disable them instead of deleting them. Just in case.
Just pipe the information to dsmod to modify their status:
dsquery computer DC=domain,DC=com, -stalepwd 56 -limit 1400 | dsmod computer -disabled yes

Now just sit and wait for maybe a week or two, if no-one calls to report problems, you’re OK to delete the accounts.
To remove the disabled accounts:

dsquery computer DC=fs31,DC=vwf,DC=vwfs-ad –disabled | dsrm 

And You’re done!

Enabling HTTPS access to OwnCloud

This document can be used for Owncloud Ver 8 and Ubuntu Server 14.04.

If you are running owncloud and have it facing the public internet, you should really be enforcing https communication. Even if it is internal only, enforcing https is a good idea. Since owncloud runs on top of apache2, enabling https is pretty easy. There are lots of tutorials available for this. I have added this here for easy reference.

To start, you need to have a cert issued from a known authority or you create a self signed cert. If you plan on using WebDAV with IOS, I have found that a cert from a known authority works where a self signed certs cause issues. You can thank apple for that.

Since we are using certs, you need openssl modules if you don’t already have it installed.

You should have a public cert, private key, and a root-CA from the issuing Authority.
Copy your public cert PEM file into /etc/ssl/certs/my-public-cert.pem
Copy your private key file into /etc/ssl/private/my-private-key.key
Copy your CertAuth-Rootca.crt file into /usr/local/share/ca-certificates

This command will read in the Root-CA Cert and add it to the trusted list for this server.

sudo update-ca-certificates

Note: For some installations, you need to use “sudo dpkg-reconfigure ca-certificates” instead which calls update-ca-certificates

Now that the CA is trusted, enable the needed apache plugins:

a2enmod rewrite && a2enmod headers && a2enmod ssl

Create an apache virtual host:

nano /etc/apache2/conf-available/owncloud-ssl.conf

Add the following to the new file.   This will forward requests from port http port 80 to https port 443 ensuring all communication is encrypted.    The virtual host 443 is setup with the certificates specified.   The mod_headers is an best practices entry from owncloud for a more secure server.

<VirtualHost *:80>
    RewriteEngine on
    ReWriteCond %{SERVER_PORT} !^443$
    RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
</VirtualHost>
<VirtualHost *:443>
    ServerName 127.0.0.1
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/my-public-cert.pem
    SSLCertificateKeyFile /etc/ssl/private/my-private-key.key
    DocumentRoot /var/www/owncloud

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    </IfModule>
</VirtualHost>

Next we enable the new conf file:

a2enconf owncloud-ssl.conf

Restart apache:.conf

sudo service apache2 restart

Now access owncloud over https://servername . Notice “/owncloud” is not requried in the URL because of the Document Root entry in the conf we added to apache. Navigate to the Admin page and enable the “Enforce HTTPS” option. Enforce HTTPS can only be enabled while accessing the page via https.

HTTPS Enforcement on OwnCloud

HTTPS Enforcement on OwnCloud

All clients can now use https://servername to access the cloud. Http access is no longer available for clients making the server more secure.

Exchange 2010 List ActiveSync Devices removed from Quarantine and other States

Exchange 2010 has this feature in active sync where the admin can setup rules to allow certain devices to connect via ActiveSync Access Rules. Device Access Rules can be setup so that only certain devices can connect and all other devices will be quarantined until an admin can act on it.

This works well for companies that only issue certain devices (i.e. blackberries) and want to block all android/iPhones from using Active sync. However, there are always exceptions. Especially when the CEO wants to use his iPhone. So the Admin can explicitly allow the CEO’s iPhone to connect. However, the GUI interface does not report on what devices are allowed, which met policy, which are given individual exemptions.

Here’s how I discovered how to get that info using Exchange PowerShell:

This command will list all active ActiveSync devices that have been issued an individual examption.

Get-ActiveSyncDevice -filter {DeviceAccessStateReason -eq 'Individual'}

The DeviceAccessStateReason can also include:

DeviceAccessStateReason

The reason for the device’s access state. Available values include:

  • Global   Caused by to the global access setting
  • DeviceRule   Caused by a device access rule
  • Individual   Caused by an individual exemption.
  • Policy   Caused by Exchange ActiveSync security policies
  • Upgrade   Caused by the upgrade of the user’s mailbox. This is a temporary state that is designed to give the device a chance to upgrade prior to being controlled by the rules and access settings.

 

 

The same Cmdlet can be used to filter on any of the attributes of the Active Sync Item:

Attribute Description
FriendlyName The name that the user called their mobile device
DeviceId A unique identifier used by Exchange ActiveSync to identify each device’s partnership
DeviceImei  The International Mobile Equipment Identity (IMEI) number of the mobile device
DeviceMobileOperator The mobile operator to which the mobile device was last connected
DeviceOS    The name and version number of the operating system that is running on the mobile device
DeviceOSLanguage    The language used by the operating system
DeviceTelephoneNumber The last four digits of the phone number
DeviceType    The device family. If you want to control access for all device models in a device family, you can create a device access rule for that device family. See Create a New Device Access Rule.
DeviceUserAgent    The device’s network protocol name, which characterizes the client to the server
DeviceModel    The device model. If you want to control access for a specific device model, you can create a device access rule for that device model only. See Create a New Device Access Rule.
FirstSyncTime    The date and time the device first requested to connect with Exchange ActiveSync. This field provides an idea of how old the device partnership is. If you want to get more information about the latest device connections, you can view the mobile device information from the user’s mailbox or user settings, or use the Get-ActiveSyncDeviceStatistics cmdlet. For more information, see Get-ActiveSyncDeviceStatistics.
UserDisplayName    The name of the person who is using the device
DeviceAccessState The access state of the device: Allowed, Blocked, Quarantined, or DeviceDiscovery. The last value indicated the device is temporarily quarantined while it is being identified by Exchange ActiveSync.
DeviceAccessStateReason The reason for the device’s access state. Available values include:

  • Global   Caused by to the global access setting
  • DeviceRule   Caused by a device access rule
  • Individual   Caused by an individual exemption.
  • Policy   Caused by Exchange ActiveSync security policies
  • Upgrade   Caused by the upgrade of the user’s mailbox. This is a temporary state that is designed to give the device a chance to upgrade prior to being controlled by the rules and access settings.
DeviceAccessControlRule   The name of the rule that is affecting the device’s current access state, if any
DeviceActiveSyncVersion  The version of the Exchange ActiveSync protocol used by the given device

For a Summary of the Active Sync Devices, try the following command:

Get-ActiveSyncDevice | Group-Object -property DeviceType

To view a count of devices of each device model, run the following command:

Get-ActiveSyncDevice | Group-Object -property DeviceModel

All these values are stored in AD and could also be queried via an LDAP search or a well-formed dsquery|dsget command.

AD attribute for MSAccessState

AD attribute for MSAccessState

Setup L2TP IPSEC VPN on Ubuntu

Having an L2TP/IPSEC VPN comes in very handy if you have a Macbook, iOS device, or run Stock Android and want to be able to remotely access your network from on the road. L2TP over IPSEC is a better choice than PPTP which is now considered insecure. Plus L2TP/IPSEC is supported natively by those devices, so no additional client software would be needed unlike OpenVPN.

To get started, let’s imagine a small network that runs on a fairly standard private address range. 192.168.1.0/24. This setup would be run on an internal Ubuntu Server that is networked to the internal network you wish to access. In this example, you only need 1 network card.

Forward Ports
Since the server resides on the internal network behind a router or firewall, you will need to forward certain ports to the server from your perimeter device for this to work.

You need to forward
UDP 500
UDP 4500
ESP Traffic (protocol 50)
AH Traffic (protocol 51)

ESP and AH are not ports, they are protocols. Most comsumer routers can’t forward these protocols, so you may be forced to use a “Forward All traffic” option to the internal server or use a “Internal DMZ Host” setup that can be found on many device. Test it out and find the best option that works for you.

 

Install IPSEC

sudo aptitude install openswan

Openswan is the package that provides the IPSEC functionality. You can use it for site to site VPNs using Preshared Keys, certificates, or other back-end auth mechanisms. In this setup, I’ll keep it simple and just use a Pre-Shared Key (PSK). A PSK with id and password would be good enough for most people who want to securely access a small or home network.

Edit the file /etc/ipsec.conf so that it looks like this
SANITY CHECK: Make sure you keep the spacing intact under the config headers and conn headers. You might get format errors without it…

version 2.0

config setup
  dumpdir=/var/run/pluto/
  nat_traversal=yes
  virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
  oe=off
  protostack=netkey
  keep_alive=10

include /etc/ipsec.d/*.conf

Edit the /etc/ipsec.secrets file and add in the following to the bottom of the file:

 
include /etc/ipsec.d/*.secrets

Now lets setup the files that define the Connection.
Create/edit a file and call it /etc/ipsec.d/road-warrior.conf

conn L2TP-PSK-noNAT
  authby=secret
  pfs=no
  auto=add
  keyingtries=3
  rekey=no
  ikelifetime=8h
  keylife=1h
  type=transport
  left=IP.ADDRESS.OF.SERVER 
  leftprotoport=17/1701
  right=%any
  rightprotoport=17/%any

conn L2TP-PSK-NAT
  rightsubnet=vhost:%priv
  also=L2TP-PSK-noNAT

Next, Create/edit a file called /etc/ipsec.d/road-warrior.secrets

IP.ADDRESS.OF.SERVER %any: PSK "YourPreSharedKey"

Next, for OPENSWAN to function correctly, you need to run to following at the bash prompt:

for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done

echo 1 > /proc/sys/net/ipv4/ip_forward

To verify the OPENSWAN config use the IPSEC VERIFY command. Your output should match the output below.

root@opk-dfw-vpn01:/etc/ipsec.d# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.2.0-51-virtual (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [OK]
        [OK]
        [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

Lastly, restart the IPSEC service

/etc/init.d/ipsec restart

 

Install L2TP

Next up we need to install an L2TP package. L2TP works with IPSEC in that L2TP provides the Tunnel, where IPSEC provides the encryption.

Install the L2TP package:

sudo aptitude install xl2tpd

Edit the /etc/xl2tpd/xl2tpd.conf

[global]
ipsec saref = yes

[lns default]
ip range = 10.10.10.2-10.10.10.200  
local ip = 10.10.10.1
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

The IP range is used by the L2tp Tunnel. You want to be sure that this range does not overlap with any internal network subnet. The Server IP address should not be part of the ip range.

 

Install PPP

The final piece of this setup is the user authentication. Every user can share a PreSharedKey, but each user should have a unique ID/PW.

Install PPP

sudo aptitude install ppp

Edit/create /etc/ppp/options.xl2tpd

require-mschap-v2
ms-dns 4.2.2.1
ms-dns 4.2.2.2
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

Change the DNS servers to fit your needs. These servers are public, but you could just as easily use your private DNS in there as well.

Now add users by editing /etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
user1           l2tpd   user1password           *
user2           l2tpd   user2password           *

sudo /etc/init.d/xl2tpd restart

Now setup your remote device with the proper servername, PSK, and id/pw and give it a test.

Final Note, if your OpenSwan doesn’t startup correctly after a reboot, you probably need to add the following to run on startup:

Edit /etc/rc.local to contain:

iptables --table nat --append POSTROUTING --jump MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart

 

Troubleshooting:
If you run into trouble:

  • Look at the logs. “tail -f /var/log/syslog /var/log/auth.log” These will give you a lot of insight.
  • Double check that the ports are forwarded. The logs would show an inbound connection of some kind if the ports are open.
  • Double check the PSK matches on client and server
  • From logsd, Server Sends MR2 and waits for MI3 forever indicated ports are partially open, check the perimeter device.
  • The Command IPSEC whack –status” gives you a lot if instant info on the configuration. Plus it’s nice output to GREP for other scripts.

Finally, here are some little facts that threw me for a loop the first time I played with openswan and I wished someone would have pointed out to me when I started:

  • in the road-warrior.conf file, Right and Left simply differentiate the 2 sides of the VPN. You could switch the values for left and right without any issues. There is no difference.
  • Traffic leaving the OpenSwan server into the internal network will masquerade as the Server’s IP. All VPN traffic will look like it originates from the Server if you take a packet capture from any internal target.
  • You can have many *.conf files and *.secrets files as needed. You can mix Road Warrior confs with Site to site confs on the same host. Each with it’s own secrets file. No problem.

Good Luck.

Check for 32 bit vs 64 bit Microsoft OS in Windows Batch File

This is a usable example showing how to check for a 32 bit OS vs a 64 bit OS in MS windows within a batch file.

This is very useful when deploying certain applications through MS Group Policy.

Example from a .bat file:

@echo off
Set RegQry=HKLMHardwareDescriptionSystemCentralProcessor
REG.exe Query %RegQry% > checkOS.txt
Find /i "x86" < CheckOS.txt > StringCheck.txt
If %ERRORLEVEL% == 0 (
   CALL --32bit install goes here--
) ELSE (
   CALL --64bit install goes here--
)

The code simple checks the contents of the Registry entry then looks for the entry ‘x86’ indicating a 32 bit installation.
The batch file will leave the checkOS.txt in place on the end user machine.

Contents of the checkOS.txt file would look something like this:

HKEY_LOCAL_MACHINEHardwareDescriptionSystemCentralProcessor
    Component Information    REG_BINARY    00000000000000000000000000000000
    Identifier    REG_SZ    Intel64 Family 6 Model 37 Stepping 2
    Configuration Data    REG_FULL_RESOURCE_DESCRIPTOR    FFFFFFFFFFFFFFFF0000000000000000
    ProcessorNameString    REG_SZ    Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
    VendorIdentifier    REG_SZ    GenuineIntel
    FeatureSet    REG_DWORD    0x21193ffe
    ~MHz    REG_DWORD    0xa64
    Update Signature    REG_BINARY    000000000D000000
    Update Status    REG_DWORD    0x7
    Previous Update Signature    REG_BINARY    000000000D000000
    Platform ID    REG_DWORD    0x10

Loading MS Certificate Server CRL to F5 BIGIP 11.3

I was asked to manually load a Certificate Revocation List (CRL) from an MS Server 2008 R2 Certificate Server to a F5 BIPIP appliance for use when authenticating client certificates.

Having a CRL loaded as a local file into the BIGIP is probably the easiest way to get it to check a CRL since you are avoiding the use of MS Enterprise/Datacenter Servers with OCSP. I also had various issues that the F5 tech support could not explain with CRLDP and MS cert services. So the CRL is an easy fix for a lab environment. I also could not find the proper method to do this in the online knowledge-base for F5’s product either.

For starters, you need to get a copy of the CRL from your MS Certificate Server.

Download CRL

1) Browse to http://SERVERNAME/CertSrv Sign in if needed.
2) Click on Download a CA certificate, certificate chain, or CRL.
3) Select DER format and click on Download Latest Base CRL
4) Save the file to your machine.

Load the CRL to the BIGIP
1) Open up your BIGIP Admin Gui
2) Navigate to Sytem -> File Management -> SSL Certificate List -> Import
3) From the Import Type PullDown, Select ‘Certificate Revocation List’
4) Enter in the Name you want use when referencing this File in BIGIP. Select Create New or Overwrite as needed.
5) Use the Browse Button to select the cert file called ‘certcrl.crl’
6) Click Import to finish the Process.
Import CRL to F5 BIGIP

Now that the CRL is imported, it can be used in any SSL Client Profile in the Certificate Revocation List (CRL) Dropdown.

This CRL is static. Any newly revoked certs on the MS Server will, of course, not be seen by the F5 until the CRL file is updated.

MS Windows 2008 r2 Server and OCSP Online Certificate Status Protocol

I’ve been using a F5 BIG IP in a test lab as a VPN concentrator using client certs as part of the Authentication of the client. We have a windows 2008 r2 domain controller on the inside LAN running MS Certificate Services. The 2008r2 host is running as the Certificate Authority (CA) and is used to issue the client certs that are used in the Auth process.

The key here is that the BIG IP must have access to the Certificate Revocation List (CRL) from that 2008 r2 CA. So I started looking into Online Certificate Status Protocol (OCSP) and with a little research was able to find the bits needed to get the 2008 r2 server to operate as a OCSP Responder so that the BIG IP could query and list revoked client certs thus preventing those bad certs from being used by clients to establish a VPN Session.

The steps here are to:
1) Setup the MS Certificate Services with an OCSP Certificate Template.
2) Allow the CA to support OCSP responder services.
3) Setup an OCSP Responder
4) Create a Revocation Configuration

So, I started with a working 2008 r2 host.

Setup the MS Certificate Services with an OCSP Certificate Template.
1) Open the Certificate Templates snap-in.
2) Right-click the OCSP Response Signing template, and then click Properties.
3) Click the Security tab. Under Group or user name, click Add.
4) Click Object Types, select the Computers check box, and then click OK.
5) Type the name of or browse to select the computer hosting the Online Responder or OCSP responder services, and click OK.
6) In the Group or user names dialog box, click the computer name, and in the Permissions dialog box, select the Read and Enroll check boxes. Then click OK.

Allow the CA to support OSCP responder services.
Note that the Online Responder must be running 2008 R2 Enterprise or 2008 R2 Datacenter

1) Open the Certification Authority snap-in.
2) In the console tree, click the name of the CA.
3) On the Action menu, click Properties.
4) Click the Extensions tab.
5) In the Select extension list, click Authority Information Access (AIA), and then click Add.
6) Specify the locations from which users can obtain certificate revocation data, such as http://computername/ocsp.
7) Select the Include in the online certificate status protocol (OCSP) extension check box.
8) In the console tree of the Certification Authority snap-in, right-click Certificate Templates, and then click New Certificate Templates to Issue.
9) In Enable Certificate Templates, select the OCSP Response Signing template and any other certificate templates that you configured previously, and then click OK.
10) Double-click Certificate Templates, and verify that the modified certificate templates appear in the list.

Setup an OCSP Responder
An OCSP responder is basically a 2008 r2 Enterprise or Datacenter server Running the Online Responder role service in the Active Directory Certificate Services.

1) Open the Certification Authority snap-in.
2) In the console tree, click the name of the CA.
3) On the Action menu, click Properties.
4) Click the Extensions tab.
5) In the Select extension list, click Authority Information Access (AIA), and then click Add.
6) Specify the locations from which users can obtain certificate revocation data, such as http://computername/ocsp.
7) Select the Include in the online certificate status protocol (OCSP) extension check box.
8) In the console tree of the Certification Authority snap-in, right-click Certificate Templates, and then click New Certificate Templates to Issue.
9) In Enable Certificate Templates, select the OCSP Response Signing template and any other certificate templates that you configured previously, and then click OK.
10) Double-click Certificate Templates, and verify that the modified certificate templates appear in the list.

And Finally, Create a Revocation Configuration
Microsoft has this information available here.

 

If you plan on using this Online Responder to answer requests from non-MS sources, you may need to set a few additional options for NONCE support and ‘allow all valid requests’.

1) Open Server manager
2) Navigate to Roles -> Active Directory Certificate Services -> Online Responder
3) Highlight Revocation Configuration
4) Right click on the Revocation Entry From the center column and select ‘Edit Properties’
5) In the Properties Window, click the Signing Tab
6) Here you can enable NONCE Support if needed.
7) ‘Use any valid OCSP signing

Additional MS OCSP Options

MS OCSP Options to allow all valid OCSP requests and to enable NONCE support

certificate’ will allow non-MS hosts to use this responder for lookups.