IT 230
Security 2 - Lab 2
Table of Contents – IT230 Security ll (Lab 2)
Part 1:
Lab Overview:
Enterprise Root of the Certificate Authority:
Certificate Revocation List Distribution:
Certificate Auto-Enrollment:
Web-Based CRL Distribution:
Publishing the Certificate Authority:
Installing a Certificate:
Intranet Web and File Share:
Created DNS records:
Access of Intranet Records:
Network Map:
Part 2:
VPN Client Connectivity:
Packet Trace:
Part 3:
NAP Client Connectivity:
NAP Enforcement:
Bibliography:
Personal Observations:
Lab Overview: The purpose of this lab is to properly handle digital certificates to other computers so
they can allow proper remote access and authentication on the network. All security checking is of
course for access protection for any user who needs to gain access to the network.
Enterprise Root of the Certificate Authority: The CA is an organization that issues signed digital
certificates. At first, the CA verifies the client and his/her requested certificate. If the verification
between the CA and the client is successful, the CA then finally sends the signed digital certification.
Within the server roles, you can find out how to setup the CA, to setup and manage the certificates, and
the root CA where the CA trusts need to be authenticated by some other subordinate. So in this lab, we
are installing the highest of the root where we are the ones managing the Public Key Infrastructure (PKI)
of all the certificates.
Certificate Revocation List Distribution: These are the points in which the revocation list adds, modifies,
and removes locations of distributed certificates. Any new locations modified are only affecting the
newly issues certificates, older certificates go back to the previous locations.
- DC names: http://crl.corp.contoso.com/crld/ <CAName> <CRLNameSuffix> <DeltaCRLAllowed>.crl
- Distributed Point: \\app1\crldist$\<CAName> <CRLNameSuffix> <DeltaCRLAllowed>.crl
Certificate Auto-Enrollment: Here you can manage how administrators distribute their certificates. If
you want to manage and monitor certificates, using automation wouldn’t be a good idea. But for this
lab, we used it automatic enrollment to easily give those computers the certificates needed.
Web-Based CRL Distribution: This is where computers connected to the ‘Corpnet’ subnet to access the
CRL. This is done on the APP1 server inside the Internet Information Services (IIS) manager. By adding a
directory, any auto-enrollment of the certificates will be dropped into here.
- Making the folder for the dsitribution point, along with sharing and security permissions.
Publishing the Certificate Authority: This is the most crucial step in distributing certificates. Publishing
them once, may not show up right away. You don’t want to continue publishing new certificates, you
need to be patient, and otherwise there will be problems in verifications. So publish new a CRL, give it a
bit, then go check in the shared folder/point to confirm.
- Setting up for the certificates and confirmed the distribution.
Installing a Certificate: When a client computer joins the domain, the computer receives any domain
information and group policy settings. Like set before, we set the auto-enrollment for digital certificates.
So after the restart of the computer, we can find out whether it was correctly done.
- Confirmed from the distribution
Intranet Web and File Share: So even if the certificate distributed properly, we need to check other
shared resources to confirm connectivity. These shared resources can be like a website or a simple
notepad file to share with.
- Confirmed intranet @ http://app1.corp.contoso.com/.
- Again, confirmed file share in the \\app1\files location.
Created DNS records: This is where the settings of forward look up zones are created. This is where
current computers connected to the network can get automatic addressing.
- New forward lookup zones as well as hosts in the zones.
Access of Intranet Records: Here you want to move the client from the Corpnet to the Internet subnet.
After that is changed, there still needs to be a check that the forward lookup zones are working correctly
and everything else for access is available.
- Access to the web (http://inet1.isp.example.com/) is available and ping tests (Firewall was turned off
on the edge1 server)
VPN Client Connectivity: This is where the user would create a new connection in the workplace called a
Virtual Private Network (VPN) connection. So a VPN is where a large network of computers can have
encrypted access to all resources needed to access.
- Put in IP settings of where you want to go and username/password credentials. NOTE: Make sure the
username and password used are the EXACT SAME as the user created in Active Directory. Otherwise it
will never work. You can’t create a random account or this VPN connected would be insecure.
- Should end up like this, and able to ping virtually anywhere on the network now.
Packet Trace: The trace that I was able to get was from Wireshark’s packet sniffing. When making the
connections, the Point to Point Tunneling Protocol (PPTP) is used to establish the connection. After
everything is established, TCP is then used to transfer the packets needed.
- Here is when the PPTP is started, and then the TCP comes next.
- As above, PPTP was first at 11 seconds, and
then TCP came at 17 seconds. The right is a
PPTP packet, so it encapsulates the PPP and
attached with is IP options of where to send
it through the GRE channel. The bottom
simply shows the TCP at 17 seconds.
NAP Client Connectivity: Setting up the VPN was easy, next is adding encryption to the VPN for
administration reasons. The Network Access Protection allows control over the client’s resources and
identity. So this is either health policies or network polices on the Network Policy Server.
- Created new RADIUS client and changed group policy settings. The Network Access Protection Agent
must be set to automatic. This is done on the DC1 server.
- More settings for the Edge1 server to use.
NAP Enforcement: There is where the testing of whether these settings actually work. After getting the
GPO update on the Corpnet subnet, connect to the Internet subnet and then proceed to connect.
- Settings were updated and checked with ‘netsh nap client show grouppolicy’
- New security settings needing for the VPN. Note: If you see more than one of the same certificate,
please contact your network administrator otherwise there will be a series of network problems. Just
like me and my partner ran into. (We used Seth’s screenshots for the next bit because of connectivity
issues on our side)
4
- This is where the settings from the group policy and the network policy server took place. After
confirming the connection was successful, the NAP will automatically perform these settings. (Again,
these are Seth’s screenshots, all credit goes to him)
Bibliography:
i-230 - 1-Test Lab (Base Configuration Guide) .doc
i-230 - 2-Test Lab (Remote Access VPNs).doc
i-230 - 2 (VPN Guide Ommissions Fix).doc
i-230 - 3-Test Lab (NAP for Remote Access VPN).doc
http://www.namecheap.com/support/knowledgebase/article.aspx/334
http://technet.microsoft.com/en-us/library/cc753296.aspx
http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
http://technet.microsoft.com/en-us/library/cc783910(v=ws.10).aspx
\/ Best tools for PPTP \/
http://flylib.com/books/2/221/1/html/2/images/fig23_04.jpg
http://tools.ietf.org/html/rfc2637
http://www.iwar.org.uk/comsec/resources/standards/germany/itbpm/s/s5076.htm
Personal Observations:
Not much to say other than wow, my group got screwed over at the end. Over 3-4 hours of diagnosing,
checking settings, numbers, and everything else possible, and my certificates would not work as
intended. Even after checking so much, and trying to update my group policy for the client computer,
the Windows Command Line Shell would crash every time I would check for verification from ‘netsh nap
client show grouppolicy’. So that ended up being worse for my issue.
My advice would be doing anything that involves distributing or making certificates, SLOWLY. So matter
how easy it may seem to right click and hit new or publish. I tried issuing more certificates even after I
tried fixing the problem so I could re-create it. But that only lead to nowhere but worse.
Overall this lab went easily as intended. Another thing to point out too is the when you try to connect to
the VPN as a client, be sure to use the active directory username and password. You don’t create an
account here; you simply use the one the network administrator gave you.
And looking onto the next lab, I will be sure to take it slow for all policy and certificate settings. Probably
going to do a clean install as well, because of how many incorrect hashes laying a around that windows
is probably using instead of the proper ones.