Kategoriarkiv: Security

802.1x with Windows Deployment Service

A common problem with 802.1x enabled networks is to enable the deployment of new workstations. In a Microsoft infrastructure this is done through system center configuration manager and also called Windows Deployment Service.

The overall problem is that a PC is unknown at the time of installation and dont have any supplicant installed / configured. Thereby in a 802.1x enabled network the client would either end up in a guest vlan or be limited by a dACL enforced ingress on the switch interface. This would cause the PC not being able to load the installation image, programs and joing the specific AD domain.

A working solution for Windows Deployment Service in a 802.1x enabled network.

Proccess of the 802.1x authentication:
1. 802.1x EAP messages is being sent to the client for authentication.
2. If 802.1x times-out the switch contienues to MAB authentication.
3. If MAB also fails the authentication server will send a dACL to the switch who then applies in ingress on the client interface. The dACL is specified with the PC ip address as source.

Process of the Windows Deployment Service
1. PC is booting on the network via F12.
2. PC is downloading the initial boot image from SCCM distribution point using tftp.
3. WinPE is starting up the boot image.
4. WinPE is starting downloading the real image from SCCM.
5. Windows Deployment Service now executes the image from the task sequence within it.
6. Windows Deployment Service installs the third party 802.1x supplicant.
7. Installation is complete and validation of the PC is now handled through the third party supplicant.

Since we are dealing with a basic windows operating system starting from point 3 to 6, we are able to execute scripts and enable services within Windows.
However from point 1 to 2 we do have a challenge as we dont have anyway of talking with the PC.
Looking at the process of the 802.1x and if there is no response from the PC and MAB fails, a dACL will be downloaded and applied to the switch port. This is the first place we need to make sure the PC stays able to download the boot image. Therefore make sure the following is added to the dACL:

-remark permitting SCCM Boot Image
-permit udp any any eq tftp
-permit udp any any eq 4011
-permit udp any any range 49152-65535

These 3 permits will keep the PC able to finish the download from SCCM.

Once the download is complete WinPE will start and this is were the tricky part starts. Since we are dealing with a very basic windows operating system we have the possibility to enable built in services. Amongst others the native 802.1x supplicant in Windows called: dot3svc

By enabling the use of the service the PC will start replying to authentication messages from the switch. Also called EAP messages. But before it will reply it needs to be configured. This cannot be done on the fly and therefore this needs to be done on a seperate PC where the XML configuration can be extracted.

In the winPE startup a simple vb script is run where we are importing 2 XML files:

Run "cmd /c copy """ & ScriptPath & "lanprofile.xml"" ""%SYSTEMDRIVE%\windows\system32\lanprofile.xml"" /Y", 0, True
Run "cmd /c copy """ & ScriptPath & "userinfo.xml"" ""%SYSTEMDRIVE%\windows\system32\userinfo.xml"" /Y", 0, True
Run "cmd /c net start dot3svc", 0, True
Run "cmd /c netsh lan set autoconfig enabled=yes interface=""Ethernet""", 0, True
Run "cmd /c netsh lan add profile filename=""%SYSTEMDRIVE%\windows\system32\lanprofile.xml"" interface=""Ethernet""", 0, True
Run "cmd /c netsh lan set eapuserdata filename = ""%SYSTEMDRIVE%\windows\system32\userinfo.xml"" allusers=yes interface=""Ethernet""", 0, True
Run "cmd /c netsh lan reconnect interface =""Ethernet""", 0, True
Run "cmd /c del ""%SYSTEMDRIVE%\windows\system32\userinfo.xml"" /Q", 0, True

Now the PC will listen but also send a EAP authentication message out to the switch. The switch will then start a new 802.1x authentication process and based on the policy set on the authentication server a new dACL will be downloaded. In our example:

-Remark Permit Any
-permit ip any any

Once WinPE has finished the download of the real image the PC restarts. This causes the link on the switch to go down and re-initialize. This means the a new authentication process will start again and since WinPE is no longer booting but Windows deployment services is, then the first task that Deployment Services should execute is the same script that WinPE did.

After Windows Deployment Services has finnished all the regular installation of programs the last task is to install our third party 802.1x supplicant. In this example we are using Cisco AnyConnect.

Just after the successfull installation of Cisco AnyConnect a reboot is needed. But before executing the reboot a new script needs to be run disabling the native supplicant so when the PC boots up the Cisco AnyConnect will reply to any EAP messages.

Run "cmd /c netsh lan delete profile interface="Ethernet""", 0, True
Run "cmd /c net stop dot3svc", 0, True

You should now be able to see in the log of the Authentication server that the new “known” PC is validated through the configuration you have choosed wether it is certificate, machine or user based.

IP DHCP Snooping

One of the nice layer 2 security features that Cisco provides is DHCP Snooping. I will here provide a simple example of how it can be used.

In short terms, the DHCP snooping is securing that only DHCP offers can come from trusted ports. So it is the network administrators task to secure that the ports pointing to the server is trusted and known.

The setup that I will explain is showed on below picture


This is a very simple setup. The clients and servers are in the same VLAN. So we will only focus on the Access switch since we are dealing with layer 2 technology.

On the access switch we need to enable the IP DHCP Snooping feature.

Access-Switch(Config)#ip dhcp snooping

When the feature is enabled, the switch will set DHCP Snooping on all VLANs.

If you are using Windows DHCP Server, it is important that you disable the option82.

Access-Switch(Config)#no ip dhcp snooping information option

The DHCP Server was connected to the port Gig 1/0/1. So we need to tell the switch that it is alright to recieve DHCP offers inbound on this connection.

Access-Switch(Config-if)#ip dhcp snooping trust

Now the clients will be able to optain IP addresses from the server.

But why have we done this, the smart thing with DHCP Snooping is that if a user brings a small router o similar with them from home and connects it to the network, by default then if they are in the same VLAN, the clients could get IP addresses from the new “Rouge” DHCP server.

When DHCP Snooping is turned on and the port is not trusted, then all packages containing a DHCP Offer will be dropped when it reaches the port.

Securing only SSH access is allowed

As all IT guys are aware of it is extremely important to secure the data that we are sending over the network. No matter if it is normal file transfer or management traffic to our network devices.

This configuration will have the goal of securing the management access will use SSH to communicate instead of telnet witch is sending the traffic in a non secure way.

First thing we need is a bit of basic configuration. hostname, domain name and a local admin user.

Hostname router
IP domain-name example.org
Username cisco privilege 15 secret cisco

Based on the hostname and domain name, we can tell the Cisco IOS unit to create a self-signed certificate. This is then used to secure managment traffic from the management PC to the unit.

crypto key generate rsa modulus 2048

Besides using SSH the goal is not to use the local admin user, so therefore it is necessary to create a AAA login method to ask a radius server to authenticate the management users. If the radius server is down the fallback should be the local user database

aaa new-model
aaa authentication login default local
aaa authentication login RWGROUP-Auth group radius local
aaa group server radius RWGROUP-Auth
 server name Server1
 server name Server2
radius server Server1
address ipv4 auth-port 1645 acct-port 1646
key xxxxx
radius server Server2
address ipv4 auth-port 1645 acct-port 1646
key xxxxx
ip radius source-interface Vlan500

Last thing witch is needed is the configuration of the VTY lines. This can be made even more secure by applying the access-class command to secure what networks are able to get access to the VTY lines.

line vty 0 4
 login authentication Radius-Auth
 transport input ssh
line vty 5 15
 login authentication Radius-Auth
 transport input ssh

To use the access-class, it is needed to create an ACL permitting the IP subnet from witch management traffic will come from. In this example there is only 1 class B subnet

access-list 10 permit

Under the VTY lines the access-class is then defined in an inbound definition.

line vty 0 4
access-class 10 in
line vty 5 15
access-class 10 in