Pivoting through SSH with dynamic port forwarding.

Pivoting through SSH with dynamic port forwarding. Just a quick post about how we can pivot to an internal/dmz network through a host via SSH. This is a classic example of how we might want to pivot through one host to get to an internal or dmz network using SSH as a tunnel. We can essentially tunnel our traffic of this SSH tunnel via the compromised host to an inside network.

The scenario… A picture paints a thousand words… Essential our ‘Hkali’ machine is on the outside. Our Ubuntu Server is in the internal/dmz, this is going to be our pivot point.

So in this scenario the firewall is only allowing inbound access to our Ubuntu server, on port 22  from our attack box running Kali2.0 ‘HKali’. So from Hkali all we can see is port 22 open on 192.168.100.10. We suspect from our initial enumeration that other servers might be in this network. However, we want to check out the rest of the subnet ie ‘WS2K32’ and ‘meta’ to see whats actually there. Imagine we have compromised the ubuntu server already and have gained login details.

Starting at our attacking machine we will SSH into ‘Ubuntu’. In order to be able to forward traffic for any TCP port on through our SSH tunnel we will want to take advantage of Dynamic port forwarding and specify the ‘-D <port>’ command. This uses ‘Dynamic’ port forwarding feature of SSH. This will allow us to send other tools with Kali to localhost:1234 and thus onward onto any route able networks the ‘Ubuntu’ server can see.

Our command would look similar to the below:

ssh root@192.168.100.10 -D 1234

Before we go any further there are some useful additional options we can pass on the ubuntu server in the SSH command, these being below. However the minimum we need to specify is just the -D for dynamic forwarding:

-f: Sends the process to the background. If you do this you will have to kill the process ID rather than just closing the terminal window as it will already be closed. This is easy enough use ‘ps aux | grep ssh’ to get the process ID then ‘kill <ID number>’.
-C: Compresses the data before sending it through the tunnel, mixed success with this, so experiment.
-q: Uses quiet mode.
-N: Tells SSH that no command will be sent through once the tunnel is up.

If we take a look at our local network connections we can in fact see our ssh connections and also our localhost listening on port 1234.

netstat -antp ssh dynamic ports

We can now use a socks proxy or equivalent to proxify our traffic through the SSH tunnel and onward to the inside network. For this we will use proxychains. Lets look at how we could do this using a socks4 proxy. First a look at our proxychains configuration. Lets open up /etc/proxychains.conf and ensure the the following line is set in the last line. (note the port should be whatever you used in the SSH command after the ‘-D’.

dynamic port forwarding SSH proxychains

Now we can proxify something like nmap through to the internal network. Bear in mind we can only proxify full TCP connect commands. So UDP traffic/tools such as snmp-check won’t work – however, we can proxify udp in an alternative way, I describe this here. Some tools won’t play nice with proxychains, so play around in your lab and experiment.

Enjoy!

 

Facebooktwittergoogle_pluspinterestlinkedinmail

Tunnel snmp-check and other UDP traffic over SSH

Today I will be walking you through how to tunnel snmp-check and other UDP traffic over SSH.

In this example we are tunnelling UDP over SSH to circumvent firewall rules on the outside. Our firewall rules are only allowing access into the other side of the firewall to TCP port 22 on a Ubuntu server. We don’t have access to any other TCP or UDP ports. The only method of communication into the environment is via SSH to our Ubuntu server. We will use this server as jump/pivot point for other traffic. Imagine we have earlier identified through cdpsnarf using SSH dynamic port forwarding and proxychains another router, we want to enumerate this further. Our next goal in this case is to try and enumerate SNMP UDP port 161 on target router with a public community string. This example could also be applied to all sorts of UDP traffic such as DNS for example were we want to tunnel our local DNS requests to a server behind a firewall. Zone transfer maybe?tunnel snmp-check and other UDP over SSH

Attack machine: Kali Linux 192.168.200.2
Pivot Server: Ubuntu 192.168.100.10
Target: GNS3 Cisco Router 192.168.100.100

We are going to do this by sending our local UDP traffic through netcat (handling UDP) into a fifo process back into netcat (handling TCP), through the ssh tunnel then in reverse the other end. Yes I know bit of a brain teaser! You can read more about fifo files here, they are similar to pipe in linux. In essence we are sort of writing the output to a file (without actually writing anything) then sending it on its merry way through netcat via TCP then down the tunnel. Its best we see this in the flesh with an example.

We begin on the Attack machine by running up the ssh connection, here we are forwarding TCP port 6666 on localhost to TCP 6666 on the remote pivot server:

Then on the Pivot Server we create a fifo file for netcat to talk too:

On the Attack machine we do similar:

In second terminal on the attack machine:

Run up ‘netstat -au’ to verify snmp is listening on the local machine.

UDP netstat connections

We can then simple run snmp-check to localhost.

snmp-check over SSH

 

Looking further down the information we discover the following:
snmp-check over SSH another netowrk

 

Another network interface, is this possibly the internal network and route to DA..? Maybe in the next post…

Bingo UDP and snmp-check over an SSH tunnel, awesome!

Facebooktwittergoogle_pluspinterestlinkedinmail

Windows Event Forwarding – Free Tools!

Windows Event Forwarding is a powerful tool and is also free unlike most SIEM options. Being able to log certain events back to a logging server is important, getting the right events logged is also equally important, and not being swamped with the wrong events. You really do need to know if someone is messing with your Domain Admins group or an LSSAS proccess on a member server.

In this post we will walk through setting up WEF (Windows Event Forwarding) in a lab environment to demonstrate how we can have better visibility over important security events in the domain. All without having expensive SIEM products, ie using what we already have.

For a bit of background, WEF has been part of Microsoft Operating systems for a while, being supported in Windows 7 right up to 2012 R2. Events can be either source initiated, ie sent from a client, DC or member server to a collector. Alternatively be collected by the event collector server itself. The idea here being that when an important event gets written to the Windows event log (Client or Member Server) it also gets forwarded to a certal logging server and thus the IT admins or security team get alerted to the event in some manner such as email. I posted a while back about doing this for Cisco kit with a Ubuntu 14.04 server utilising rsyslog for event collection posted here. 

So our lab will utilise GNS3 as it gives us a good visual representation as to what we are working with:

WEF LAB Network Diagram

As you can see, a pretty simple lab setup a Domain Controller (DC1) a couple of member servers (NPS and WEF-Collector) and client machines (W71, W72 and W73). We won’t worry too much about ESW1 or R1 at the moment these were just left over from an 802.1x lab I had been working on, the topology is just a flat 10.0.x.x network. The events will be written to our WEF-Collector Windows Server 2012 R2 machine.

First we will setup our Event collector server WEF-Collector. We will want to ensure WinRM the Windows Remote Managment service is started and Event forwarding is setup. Open an administrative prompt and type ‘winrm qc’ (you may find it is already configured as below):

WEF WinRM qc

Now to enable event forwarding on WEF-Collector our event collector. Go to the event viewer, select ‘subscriptions’ you will get a pop up – select ‘yes’ as we do want to enable event forwarding to start automatically if the server is restarted.

WEF Event Forwarding 'Subscriptions'

Now lets look how we can forward events to the collector ‘WEF-Collector’.

First we need to give the local Network Service principal rights to read the security log, we run the following ‘wevtutil gl security’ on machine in the lab to grab the channel access string (this will be used in our GPO):

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

WEF Event log enable

Thanks to Jessica Payne with this article for discribing this section.

We will then append the string with (A;;0x1;;;NS) so it reads:

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)

This line is essentially where the permissions on the log are stored.

Now we will create a GPO so we can apply the settings to our clients and servers that we want to push events from, this will tell the clients and severs where to check for subscriptions and where to send events to ie ‘WEF-Collector’. We will initially want ot set two policies:

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Forwarding>Configure target subscription manager:

WEF GPO Subscription Manager

Note: Instructions are in the text of the GPO iteslf however in summary we want the FQDN, URL path, port and refresh time. Clearly checking every 10 seconds is overkill however for the lab its ideal.

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Log Service>Security> Configure log access:

WEF GPO Log Access

This is where our channel access string comes into play.

Our GPO should look like this:

WEF GPO Summary

Now link the GPO to our AD structure to enable it.

Now our clients and servers are configured, lets configure some example subscriptions:

Logging Domain Admin changes sounds like a good idea, this is event ID 4728 and 4729. Start in the Event View, under Subscriptions select create subscription and fill in details like so:

WEF creating subscription to monitor domain admin group changes

Next select ‘Source computer initiated’, and in this case we are going to add DC1. Next we are going to go into the Select Events option and configure like so:

At the moment we can see that DC1 hasn’t yet checked in as the ‘Source Computers’ column is still ‘0’.

Once DC1 has checked in to see if there are any subscriptiosn for it we can see that the ‘Source Computers’ column is now 1, we can check the status by clicking on ‘Runtime status’. Here we can see DC1 is ready and waiting to send events:

WEF Runtime Status

If we now generate some events on our DC by removing and adding the user ‘Bob’ to the ‘Domain Admins’ group we can see the following two events have been logged in the ‘Forward Events’ section under the ‘Windows Logs’:

Clearly this is only based on two event ID’s however hopefully demonstrates what can be done takeing this example and expanding it, creating multiple subscriptions based on certain filters and IDs.

I hope this helps demonstrate WEF and how we can get much better visualisation into whats happening on the network for security events.

Facebooktwittergoogle_pluspinterestlinkedinmail

VLAN tagging in Kali Linux 2.0

Connecting to Trunked Ports!

Just a quick post on how to configure VLAN tagging in Kali Linux 2.0. If we have a trunk port presented to us, how do we utilise it?

To setup vlan tagging in Kali Linux 2.0 is pretty straight forward, to set the scene and demonstrate this further we need a lab. The below lab is our ‘test.local’ environment set up in GNS3. There are 3 vlans, 10 20 and 30. 10 and 20 are routable, vlan 30 is isolated from 10 and 20. In the lab we have a ‘router on stick’ configured  at R4, fa0/1 is sub interfaced with vlans 10 and 20. utilising DHCP, vlan 10 for servers and vlan 20 for clients. All devices in vlan 30 are statically assigned IP addresses and not routable to the 10 and 20 vlan networks.  In all switches there are a variety of 802.1q trunked and access ports.

The idea of the lab is that vlan 30 can’t talk to vlan 10 or 20. However as a trunked port is presented to the Kali vm, it will be able to communicate to all vlans.

This is how it looks:

VLAN tagging in Kali Linux 2.0 - switch configuration

Lets look at how we would configure Kali to test all hosts in the different vlans, first via CLI and then via GUI in Network Manager:

As you can see with the current trunk connection we can’t access any of the networks, however a quick Wireshark does reveal we can see traffic and the different vlans…

First lets open up ‘/etc/network/interfaces’ in nano and add our interfaces. The idea is very similar to a cisco router we are essentially sub interfacing our network connection in the interfaces file:

Save our file and then simply bring up the sub-interfaces with ‘ifconfig XXX up’ where XXX is our subinterface:

We can now access all of our vlans in question.

Further to this, if we set off a ping to each network and Wireshark the trunk connection we can see our tagged packets. Hooray.

The Gui is even easier, lets configure it via the Network Manager. We will do this via opening up our network connections/Network Manager, simple click on the ‘+’ sign, select ‘VLAN’ fill in the details on the vlan tab as well as the ‘IPv4Settings’ tab:

And there you have it.

I hope this helps someone!

Facebooktwittergoogle_pluspinterestlinkedinmail

Creating a Windows 7 Logon Banner Legal Notice message at Logon via GPO

Windows 7 Logon Banner

This is just a super quick post to reference an earlier video which I created which demonstrates how to add an interactive Windows 7 logon banner legal notice to work/domain joined client machines. This can be achieved via group policy object. A user would need to click ‘OK’ to accept the message before logging onto the machine.

This is a CIS (Center for Internet Security) benchmark for Windows 7 machines the rationale is that it is important to notify and warn unauthorized users attempting to gain access to carry out an attack on the computer by notifying them of the consequences of what they are about to do and any legal ramifications.

Facebooktwittergoogle_pluspinterestlinkedinmail

Microsoft LAPS (Local Administrator Password Solution) Deployment

Password re-use… ah such a bad idea.

During a penetration test one of the most common vulnerabilities I see is the local administrators account having the same password used across all client machines in the estate, usually one for servers and one for clients. So a classic scenario I see a lot goes something like this; a vulnerability is identified in an environment lets say a nasty remote code execution, it gets exploited giving SYSTEM level privileges, you then dump creds from the box and boom you have the local administrators password, even if you don’t get the clear text password you might get the hash. You use the creds/hash with something like hydra or medusa to try a few more workstations in the environment, and hey presto your screen lights up with successful smb authentications. You now have the ability to move laterally across the network logging into workstation after workstation either dumping more creds with mimikatz or stealing tokens with incognito until you reach a domain admin account.

There are in fact a few ways in which we can contain or should I say slow down lateral movement by an attacker, one being to use a different local administrators password on every device, I’m going to walk through how we can achieve this using Microsoft LAPS (Local Administrator Password Solution). This essentially allows you set a unique local administrators password on every workstation in the domain. Thus stopping password reuse and pass the hash type attacks. Granted this is only half the problem solved however does shutdown this avenue of attack.

OK, how do we set this up?

A quick search on google for LAPS and you will find the free download from Microsoft.

Go ahead and download the 32 & 64 bit downloads as well as the ops guide for reference.

For this demo I’m going to be using the trusty Blue Team Security lab in GNS3, you can see from the below diagram we have our Domain Controller and a few windows 7 clients to play with, great:

LAPS works by having what Microsoft refers to as clients and management computers within your domain. Passwords are stored in Active Directory as a computer object attribute this does mean that the password is stored in clear text. However transmission is encrypted. Management computers and its user will have the ability to fetch the password of any given client, so its important to delegate this responsibility carefully i.e to a specific security group. The msi we downloaded is the same for both client and management computers, the install has different options selected for each type. The default options being for clients. For the management computers I’m going to use ‘W71’ this is a standard Windows 7 Pro domain joined client.  For the client computers we are going to use W74 and W72, again just standard domain joined Windows 7 Pro builds.

When we talk about management machines we are talking about user admin machines so where your helpdesk or second line staff can access.

There are a couple of pre-requisites; the first is a schema update which adds two new attributes to AD these are to store the password and timestamp for password expiry. The second are some permissions that need to be setup for our clients and the users that can see these attributes.

Let’s first install the management software and tackle the schema update.

On our management computer lets go ahead and double click on the msi in my case 64 bit so ‘LAPS.x64’

Click Next.

Accept the End-User License Agreement and click next.

Select the ‘Managment Tools’ and select to install to all the computer and click next.

That it management install complete.

Onto our scheme update, open up an elevated PowerShell prompt with an appropriate scheme admin account, import the module and then update the schema like below:

Import-module AdmPwd.PS

Update-AdmPwdADSchema

Onto our permissions. Basically, the client machines need to be able to update the password and timestamp expiry attributes. Using the module that we have previously imported, or in the same window as before run:

Set-AdmPwdComputerSelfPermission -OrgUnit <name of the OU to delegate permissions>

In the Blue Team Security lab this would be on the ‘PCs’ OU:

So the command would be:

Set-AdmPwdComputerSelfPermission -OrgUnit PCs

Next we will create a User Group that we can assign read permissions for the new attributes. This will essentially allow the new group and its users the ability to read the password field of the computer objects. In this case I have created a group called ‘LAPS Admins.’ The comand is:

Set-AdmPwdReadPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>

In the Blue Team Security Lab our command would be:

Set-AdmPwdReadPasswordPermission -OrgUnit PCs -AllowedPrincipals ‘LAPS Admins’

The same again for the expiry field:

Set-AdmPwdResetPasswordPermission -OrgUnit PCs -AllowedPrincipals ‘LAPS Admins’

Managing clients; telling them we want to control their local administrator password is done through group policy. The policy we want to configure is a computer policy under administrative templates called LAPS, this will have been imported when the management computer software was installed. Using our management machine, in our group policy management console we want to create a new GPO under the container where our client machines are, just like below:

The settings we want to configure are to initial switch on the password management this is called ‘Enable local admin password management’ funnily enough and we want to enable it. Next is the ‘password settings’ this looks like, and has the below configuration options, as you can see we have a fair amount of control over the password to configure it securely. What you see below is the default settings:

Its probably worth noting if you have changed the local administrators account name via policy (and you should!), then you will need to specify the new account name in the policy ‘Name of administrator account to manage’, enable the policy and specify the new name. This policy is only needed if you have renamed the account.

Next up is installing the client side software. I’m going to manually install this however in the enterprise you will probably use SCCM or GPO to deploy to your client machines. I will perhaps demonstrate this in my next post.

Over on our client the install takes all the default values from the same msi that we used for the management computers. I won’t bore you with additional screenshots, just know that it is a next, next, next, finish situation and installed successfully on my client machine W72.

Once the above GPO has had time to take effect on our client machine we can verify the password in AD and through the fat client installed on the management computer. First in Active directory users and computers you can view the password by navigating to the computer object in question (W72 in this case) selecting the attribute editor and scrolling down to the value ‘ms-Mcs-Adm-Pwd’ this value is our new password the one below it is the expiry time (you will need to have selected ‘Advanced Features’ to view the attribute editor on the computer object) and be viewing with the appropriate rights (ie be part of in our case the LAPS Admins group):

On the management machine with the account ‘Adam’ which is a member of the ‘LAPS Admins’ group through the fat client UI (which does require DotNet4).

Just to demonstrate if we log in with ‘Bob’s account on the same management computer and try to use the same LAPS UI tool the following expected results are shown, not the bob is not a member of the ‘LAPS Admins’ group and so the password is blank, ace!

And for the die hard CLI users you can of course use powershell to retrieve the password with the appropriate account of course:

You can now try out your new unique local administrators password. Now even if the box has been compromised an attacker will struggle to crack the likes of the above password and secondly won’t be able to reuse the hash to authenticate to another machine. Remember to test out in your lab before in production. I hope this has been informative.

Facebooktwittergoogle_pluspinterestlinkedinmail

Resizing a VirtualBox Linux disk.

Resizing a Linux Disk in VirtualBox

I came across a need to expand the hdd on Linux virtual machine, as I had run out of space. I thought I would share my experience by walking through the steps I took in resizing a VirtualBox Linux disk for the Debian based OS that I had. The process involves expanding the virtual image file then using GParted to expand the partition. This is actually relatively painless. My particular disk image was in VMDK that I needed to increase by an additional 10Gb. I actually tested this out for a non trivial virtual machine first, this is how I got on:

First like me if your using a VMDK you will need to convert the disk image to either a VDI or VHD file. This can be done at the command line (with Admin privs) like below. If you try to expand the a VMDK with VirtualBox you get a nice error as below:

converting VMDK to VDI

 

The next stage is optional: Take the new VDI file and create a new virtual machine using the new HDD file. I personally would then boot the machine just to check it boots and everything is in order however this is optional, while I was there I took a quick snip of the HDD space. /dev/sda1 is 29Gb we will increase to 40Gb.

VDI image size

Resize the VDI file at the command line (with Admin privs) like below:

VirtualBox VDI resize

 

At this point the vm will still boot just fine, however the hdd partition won’t have increased. We will need to extend the partition using a program like Gparted. So we mount the GParted ISO into the guest CD drive. You will also need to enable EFI from the system page in order to boot into the latest GParted GUI, this will need to be unchecked after we have finished to boot back into our Debian os.

live boot gparted

Start the vm, allow GParted to boot. Select the first option and allow GParted to continue to load, accept the default settings pressing ‘enter’ three times.

 

live boot gparted 1

Once booted into GParted you will be presented with the following screen:

live boot gparted 2

We need to remove ‘/dev/sda2’ (the swap file and recreate it later) in order to extend the partition into the unallocated space. Once this is complete we can then select ‘/dev/sda1’ select ‘Resize/Move’ from the menu, drag the slider bar all the way to the right hand side like below and select ‘Resize/Move’.

live boot gparted 4

Select ‘Apply’ from the menu, and after a short pause we can see all operations were successful. Once this is complete close the ‘Apply pending operations’ and shutdown.

live boot gparted 5

Remember to disable the EFI option in the VirtualBox machine settings for our Debian based system. Boot the machine up and recheck the size; voila, we can see our /dev/sda1 is now 39Gb!

After size

Facebooktwittergoogle_pluspinterestlinkedinmail

Ubuntu 14.04 Syslog Server

A quick and simple Ubuntu 14.04 Syslog Server with rsyslog for Network Devices.

In this post I going to run through creating a quick a simple Ubuntu 14.04 Syslog Server. Logging events is an important part of secure network configuration. The messages provided by devices such as switches, routers, firewalls and number of other devices provide a huge amount of information to systems administrators when a specific event has occurred and steps need to be traced. This could be for diagnosing a problem or looking at the activity of a potential attacker. When syslogging is setup it allows system administrators to respond better to incidents due to having the information readily available. Shipping the logs off to a remote server allows them to be safely stored without fear of them being deleted due to an attacker compromising the device but also the device being restricted due to small amount of storage space usually allocated.

In this post we are going to setup a syslog server on Ubuntu 14.04. Ubuntu uses rsyslog for its logging you can read all about this here, I’m just going to cover some of the basics to get you up and running, the idea here being that you have something to work on and take to the next level.

The below network diagram whilst may seem overly complicated, serves us well for this scenario and gives us our network and devices that we want to collect data from. In this scenario we want to collect logs from the routers. The platform we are going to test this out in is GNS3, truth be told it was a lab I had machines active for so though, meh… why not drop a syslog server in.

Ubuntu Syslog Server Network

There are essentially three steps I’m going to walk you through:

1. Configure the /etc/rsyslog.conf to accept remote incoming UDP syslog messages
2. Create and configure a conf file in /etc/rsyslog.d/30-cisco.conf. This is a new file we are going to create which specifies some rules on what we want to do with our messages if they come from different devices. You can add the rules to the rsyslog.conf file however creating a seperate conf file is the neater option in my opinion.
3. Change permissions of the /var/log/ directory so syslog user can make changes, create files etc.
4. Restart rsyslog with : sudo service rsyslog restart.
5. Test with our Cisco devices.

So taking our completely standard Ubuntu 14.04 install find our rsyslog.conf file in /etc/ and uncomment the following lines with our favourite text editor in my case ‘nano’:

If you scroll down towards the bottom of the file we can see that it references to use all ‘conf’ files under /etc/rsyslog.d/ including where the default rules are kept in 50-default.conf.

Create/touch a new file calling it ’30-cisco.conf’, since we are only collecting syslog info for cisco devices on this occasion we shall chose this name. Append the file with the following lines of code:

The above code sets up a template which creates the ‘cisco’ directory and also a log file using the hostname of the device the messages have come from.

From here we set the permsisions of the log directory for syslog service with ‘cd /var && sudo chown syslog:syslog log’

Restart the rsyslog service:  ‘service rsyslog restart’

All that is left to do is configure our cisco devices to ship logs off to our syslog server. For a typical cisco router or switch we can simple do this from a conf t prompt with ‘logging x.x.x.x’ also setting desired trap levels with: ‘logging trap debugging’ for example.

There it is, a simple syslog server, as said previously this is just something to get you started with. The next level to think about is rotation of log files, backups secure transfer of the log files through TLS which rsyslog supports.

Facebooktwittergoogle_pluspinterestlinkedinmail

Cisco AAA Authentication with RADIUS against Active Directory 2012 NPS

AAA and RADIUS through the Network Policy Server (NPS) role in Windows Server 2012 R2

I thought I would cover a quick post to demonstrate setting up Active Directory authentication for a Cisco router or switch IOS login. This will be using AAA and RADIUS through the Network Policy Server (NPS) role in Windows Server 2012 R2 to authenticate users in Active Directory on Cisco IOS devices.

As with all my labs a picture paints a thousand words so here is the GNS3 Network topology we will be using, this is also being used for 802.1x which will be covered in later post:

Cisco AAA Authentication with RADIUS against Active Directory GNS3 Topology

So here is quick run down on the gear we will be using just for this lab:

R1: Cisco IOS (C7200-ADVENTERPRISEk9-M), Version 15.2(4)S4

Server 2012 DC: Windows Server 2012 R2 ( Active Directory Domain Services and Network Policy Server role.

Just to demonstrate a lab as simple as the below could also be used to test this:

radius lab

Active Directory Configuration:

I will be assuming that AD and the NPS role have already been installed. Prior to jumping into the NPS configuration you will need to create an AD group for the users that will be logging into the Cisco equipment, add a couple of test users to this group. In my case I have simply created a group called ‘Radius’ and have added the user ‘Adam’.

Open the NPS console.

Right click on the NPS(Local) tree node and select ‘Register server in Active Directory’:

Now create the Radius clients, in our this case this is R1:

Radius Clients, New

New Radius Client Settings

New Radius Client Advanced Screen

 

Now we need to configure the Network policy:

New Network Policy

New Network Policy name

Add our ‘Radius’ AD group. You can tighten the control here by specifying further conditions such as the ‘friendly name’ (R1)  or the local IPV4 address of the radius client, in a production environment you would want to lock this down further for now we are just going to add the the user group to authenticate:

New Network Policy - Add

Grant Access for this group:

New Network Policy Access Granted

Configure the appropriate authentication methods:

New Network Policy - Configure Authentication Methods

Change the Standard Radius Attributes by removing ‘Framed-Protocol – PPP’. Edit the ‘Service-Type’ value to ‘Login’:

New Network Policy - Standard Radius Attributes

Add a Vendor specific attribute, this allows the radius server to pass the privilege level though the cisco router which we shall see later in the debugging. The value needs to read ‘shell:priv-lvl=15′.

You can create several policies for the different privilege levels. For example you could create a group in AD called ‘Cisco Users Priv 1’, associate this group to a policy and in the below option use the value ‘shell:priv-lvl=1′. When that user logs in the policy will match that user and the NPS use the matched policy passing privilege level 1 through to the router or switch.

New Network Policy - Vendor Specific Radius Attributes

Then Finish:

New Network Policy - Finish

Cisco IOS configuration

Create a a user with privilege level 15, we wil use this as our fall back should the router not be able to contact the radius server it will use the local AAA database.

Enable AAA:

Now we will setup the main parts to the radius configuration, tell the switch we would like to use radius and the group RAD_SERVERS:

Specify the radius server that we would like to use in our case 10.0.0.2 is our NPS, the auth and acc ports and also the secure key we used:

Specify that for  the default login  for authentication an authorization that we want to use the group called RAD_SERVERS that we have just created and if that fails we use the local database. This is particularly important so we do not lock ourselves out on the router:

All together this looks like the below:

We can test simply by logging out and back in.

Troubleshooting

It obviously goes without saying you need to test the authentication to the Radius server, exit right out of the console and log back in using your AD credentials.

If all has been configured correctly you should be able to login. its also worth testing the fall back option configured for local AAA authentication. We can do this just simply stopping the NPS service then try the local credentials, again all being configured correctly you should be able to login.

There are a few useful debugging commands we can use  to monitor and troubleshoot the authentication these being:

This time when we login we can see the debug information for an attempted login, it should look similar to this, note the highlighted area’s:

radterm

I hope this has been informative.

Facebooktwittergoogle_pluspinterestlinkedinmail

IPV6 and RIP GNS3 Lab

I decided to to look into configuring a quick simple IPV6 lab in GNS3 using RIP. I put together the following lab using the RIP routing protocol for ease of use. The lab consists of  3 routers multiple interfaces, 3 subnets, 3 PC’s and switches for endpoint connectivity, I find its easier to use the virtual switches if I want to expand the lab later. The routers are the using the c7200-adventerprisek9-mz.152-4.S4 image and the PC’s are simply the virtual PCs (VPCS) from GNS3 again for ease of use. I do normally prefer to connect an actual operating system as PC’s as I find it more realistic however as we are just testing connectivity and routing the VPCS option is a good fit here and light on system resources.

Below is the simple topology:

RIP and IPV6 lab
RIP and IPV6 lab

Some of the basic configuration for RIP and IPV6 is show below for R1. This can then be replicated across the other routers and interfaces changing the IPV6 subnet ID and Interface ID as you go along. Using Global IPV6 addresses with a made up subnet ID.

Straight in the configuration starting in global configuration mode on R1:

R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 address 2001:db8:6783:120::1/64
R1(config-if)#no shutdown

Verify the interface:

verify the ipv6 interface configuration.
verify the ipv6 interface configuration.

Note the new IPV6 Link Local address that has been automatically assigned to the interface when it was brought up, the closest thing to explaining for now is the 169.254.x.x/16 address asinged by APIPA. The Link Local address is made of the first 10 bits (identifiable as the Link Local FE80) the other 54 bits being Zeros (::) and the remaining 64 bits being made up of the MAC address and FFFE slotted in the middle. 🙂

Onto the routing:

R1(config)#ipv6 router rip RIP1
R1(config)#int fa0/0
R1(config-if)#ipv6 rip RIP1 enable

The router will then advertise its routes through the enabled interface for RIP1 using rip and likewise for R2 and  R3. Once R3 has been configured 30 seconds later a quick check of the routing table from R1 should display:

IPV6 rip routing table
IPV6 rip routing table

We can see the advertised routes for rip, also notice that the advertised route is via its IPV6 Link Local address starting with FE80.

A quick check from PC3 to R1 and PC4 further verifies  connectivity through IPV6 and rip configuration:

Checking IPv6 endpoint connectivity from PC3 to PC1.
Checking endpoint connectivity from PC3 to PC1.

Interesting, more to come from IPV6 in the future for sure.

Facebooktwittergoogle_pluspinterestlinkedinmail