Day 3.5: ActiveDirectory and CentOS

Getting started... again

So World of Warcraft: Battle for Azeroth dropped last week, and that's been taking up a lot of time that I might otherwise have been using to work on this project... but I hit level 120 on my main, so now I'm spending less time on that.

Anyways. Last time, I had decided I needed to do some reading and figure out the underlying mechanics of tying Cisco devices to ActiveDirectory, which as best I could tell, was going to require a long chain of services including FreeRADIUS, Samba, Kerberos, and ActiveDirectory. Along the way, I decided now would be as good a time as any to transition my CentOS server from using local accounts to using ActiveDirectory user accounts.

I thought this was going to require a whole bunch of manual Samba and Kerberos setup, and thought I had it all figured out... and then when I went to research the actual configuration, I discovered it was actually going to be a lot simpler.

CentOS setup

Red Hat has done a pretty decent job of consolidating core system services into easily managed software packages. Originally, my research suggested I was going to have to configure a handful of different Samba processes running on top of Kerberos, and configure the system by hand... but as it turns out, CentOS has made this a lot easier with two particular services, realmd and sssd. realmd essentially handles the process of connecting the server to an ActiveDirectory domain, and sssd handles interfacing between clients and back-end authentication mechanisms (like ActiveDirectory.)

realmd wasn't installed by default, but it was available through yum, so installing it was easy enough.

Following the documentation, I was able to discover my domain, and then tried to join it:

I could've sworn I saw those packages listed as dependencies when I installed realmd, but apparently not. But, again, easy enough to fix...

# yum install oddjob oddjob-mkhomedir sssd adcli

Oddly, during this process, yum determined that oddjob/oddjob-mkhomedir were already installed (I didn't imagine it!) but the other two weren't, so I opted to install them and then deal with the "missing" packages afterwards.

Impressively, the 28-package install took about 5 seconds.

And, as a pleasant surprise - after installing the two missing packages, it didn't complain at all when I went to join the domain again.

Equally pleasantly was going to test the new implementation, as described in the documentation, and finding that realmd had worked exactly as advertised and had taken care of the entire joining process (including configuring sssd for ActiveDirectory) for me.

(At this point, I also went into the ActiveDirectory Users/Computers tool and set my password not to expire.)

At this point, I wanted to make it even more fancy... and make sure that only designated users could use ActiveDirectory credentials to log into the CentOS server.

So I jumped over to Windows and created a new user group: 

And then used the appropriate realmd commands to block access from anyone except that user group:

First I tested it without adding myself to that user group:

Then added myself through Windows and tried again:

Perfection. And amazingly easy, too.

Next up

Next up is to configure FreeRADIUS to authenticate against ActiveDirectory. I was originally going to make that part of this post, but it's looking complicated and I need to read up before I continue. Until next time...

Day 3.4: DHCP and subnetting

Introduction

In the last entry, I set up a few things:

• Routing between all the virtual routers on the network.
• To do this, I enabled RIP on all the core (Core, Edge, and Access) routers for all the networks in the LAN.
• Configured the Core0 router as the default gateway, and configured RIP to propagate default route information across the network.
• Configured the Win2016 VM with a direct connection to the Internet, since while GNS3 routes traffic internally quickly enough, it's too slow for Internet connectivity. Win2016 still has access to the virtual LAN as well.

Onwards!

Next step is going to be setting up user access and VLANs (which, by necessity, involves configuring DHCP.)

But VLANs first.

Jumping over to my Access1 router, I set up my two user VLANs, which I designated 101 and 102:

Access1(vlan)#vlan 101

VLAN 101 added:

    Name: VLAN0101

Access1(vlan)#vlan 102

VLAN 102 added:

    Name: VLAN0102

Immediate problem: VLANs are apparently stored in Flash memory as opposed to NVRAM... and Access1 is not configured with any Flash memory.

Shut down switch. Go into configuration in GNS3. Add an 8MiB PCMCIA disk. Restart switch.

format flash:

Okay... now I can create my VLANs and update the database.

Next up: configure an IP address for each VLAN interface to use.

Access1(config)#interface Vlan101

Access1(config-if)#ip address 10.100.1.1 255.255.255.0

Access1(config-if)#no shut

Access1(config-if)#exit

Access1(config)#interface Vlan102

Access1(config-if)#ip address 10.100.2.1 255.255.255.0

Access1(config-if)#no shut

Access1(config-if)#exit

Access1(config)#

Since my VLANs aren't crossing multiple switches, I don't need to work about trunking to other switches. All I need to do is configure the appropriate Ethernet ports for the appropriate VLANs. GNS3 tells me in the Topology Summary which VMs are connected to which ports:

Access1#config t

Enter configuration commands, one per line.  End with CNTL/Z.

Access1(config)#int fa3/0

Access1(config-if)#switchport access vlan 101

Access1(config-if)#ex

Access1(config)#

*Mar  1 00:20:00.015: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan101, changed state to up

Access1(config)#int fa3/1

Access1(config-if)#switchport access vlan 102

Access1(config-if)#^Z

Access1#

And...

Access1#show vlan-switch

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

101  VLAN0101                         active    Fa3/0

102  VLAN0102                         active    Fa3/1

All right, VLANs are set. One more thing first, configure each VLAN interface to use the Windows 2016 DHCP server.

Access1(config)#int Vlan101

Access1(config-if)#ip helper-address 10.1.0.100

Access1(config-if)#ex

Access1(config)#int Vlan102

Access1(config-if)#ip helper-address 10.1.0.100

Access1(config-if)#^Z

Access1#

Now to jump over to Windows and set up the DHCP server.

There's a few different options that needed to be set up:

I created a Superscope specifically to cover user VLANs, and then added a Scope for each VLAN to assign IP addresses within that subnet.

I also set a couple different server-wide options to control what gets assigned to all DHCP clients:

The two Router addresses are for the two interfaces of Core0, the DNS server is the IP address of the Windows 2016 VM.

Time to boot up my Windows 8 VM and see if it gets an IP address successfully.

Probably should've taken care of this first. Oh well.

After the VM came up, I discovered I was getting an address assigned by VMware. As it turns out, you have to start the VMs within GNS3 in order for GNS3 to control them.

But when I tried to do that, I got this message:

After a little digging, I discovered that GNS3 "takes control" of pre-configured VMware virtual networks while it's running. I had only configured it to use a single VMnet, and that was already in use by Win2016. After giving it control of several more VMnets and assigning Windows8 to one of those VMnets, I tried again:

I'll take "error messages I don't understand" for $400, Alex.

Oddly, the VM itself started up with no problem, although it had no network connectivity. I tried one more option: the "Allow GNS3 to override non custom VMware adapter," which I finally discovered had a tooltip informing me that this would allow GNS3 to control the network adapters belonging to the VM.

Still nothing.

After doing some research, I found a forum post suggesting that Windows-based clouds (which I did indeed have) were not as reliable as clouds running inside the GNS3 VM. Following the post's suggestion, I added a network adapter to the GNS3 VM, bridged to my home LAN, and rebooted the GNS3 VM.

GNS3 itself apparently did not like that I was changing its VM while it was running, and complained when I tried to add a new cloud. I opted to just restart GNS3 and try again.

Success... except I was now getting that error message when trying to start up Windows 2016.

At this point I noticed that when I was trying to configure VMnets in GNS3, it was trying to start two services related to Netgroup Packet Filter, that appeared to start and then stop. I figured that all my network interface shifting might have broken something on my local machine, so I decided to reboot.

I started up Win2016, so far so good - then the rest of my virtual routers - then Windows 8. All well and good, except... no IP address.

Oops. Apparently I forgot to save my Access1 configuration before restarting.

After rebuilding the configuration... no DHCP.

Time to enable UDP debugging on Access1 and try a DHCP renew:

Access1#debug ip udp
UDP packet debugging is on
Access1#
*Mar  1 00:07:10.863: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=308
*Mar  1 00:07:10.867: UDP: sent src=10.100.2.1(67), dst=10.1.0.100(67), length=308

UDP packets are making it out, but not coming back. Checking on the next hop, InternalEdge2... no UDP packets are coming through, and yet, I can tracert to the DHCP server just fine.

Turning on IP error debugging on InternalEdge2 reveals:

InternalEdge2#debug ip error

IP packet errors debugging is on

InternalEdge2#

*Mar  1 00:31:01.927: IP: s=10.1.0.100 (FastEthernet2/0), d=10.100.2.1, len 337, dispose ip.noroute

There's the problem. I never added my user subnets to the RIP network listing on Access1, and so the rest of the network has no idea how to reach those subnets. Easy fix, at least:

Access1#config t

Enter configuration commands, one per line.  End with CNTL/Z.

Access1(config)#router rip

Access1(config-router)#network 10.100.0.0

Access1(config-router)#^Z

Access1#

Checking the route listing on InternalEdge2 now shows a route to the 10.100.0.0 networks. DHCP renewed, and...

Got it!

Next step

Not sure, really. I'll figure something out.

Day 3.3: Setting up routing

Introduction

Yesterday I built a network of virtual routers in GNS3 and connected my VMs to them. Today I'm going to work on configuring them to actually route traffic around the virtual network.

Getting started

As a reminder, here's what the network looks like right now:

To start out, I figured I should configure Core0 to connect to the Internet. Essentially, I started with the instructions here to set my "external" interface on Core0 (Fa0/0) for DHCP:

Core0#

*Mar  1 00:13:24.639: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 172.20.179.154, mask 255.255.0.0, hostname Core0

Core0#

So far so good - Fa0/0 now has an IP address on my home LAN. Equally importantly, it now has a default gateway assigned for routing traffic out to the Internet.

Core0#ping 75.75.75.75

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 75.75.75.75, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Okay, my bad. The default route forwards out to Fa0/0, but there's no default gateway set.

Core0(config)#ip route 0.0.0.0 0.0.0.0 172.20.0.1 permanent

Core0(config)#^Z

Core0#

*Mar  1 00:24:31.687: %SYS-5-CONFIG_I: Configured from console by console

Core0#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.20.0.1 to network 0.0.0.0

C    172.20.0.0/16 is directly connected, FastEthernet0/0

     172.25.0.0/24 is subnetted, 2 subnets

C       172.25.1.0 is directly connected, FastEthernet1/0

C       172.25.2.0 is directly connected, FastEthernet2/0

S*   0.0.0.0/0 [1/0] via 172.20.0.1

               is directly connected, FastEthernet0/0

Core0#ping 75.75.75.75

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 75.75.75.75, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 60/78/96 ms

Core0#

Much better.

Next step is configuring the rest of the routers to learn routes. At this point, for simplicity, I'm going to use RIP.

Fortunately, GNS3 lets me edit each router's startup-config in a text editor so I don't have to manually enter all the config commands on each router to add:

router rip
version 2
network 172.25.0.0
network 172.26.0.0
network 172.27.0.0
network 172.28.0.0
network 172.29.0.0
no auto-summary

Next up, configure Core0 to propagate its static route via RIP:

Core0(config-router)#default-information originate

A quick check of Core2 confirms that the default route has propagated:

Core2#sh ip rip database

0.0.0.0/0    auto-summary

0.0.0.0/0

    [1] via 172.25.2.1, 00:00:01, FastEthernet0/0

Unfortunately, I can't ping 75.75.75.75 from Core2.

Tracerouting shows that packets are making it to Core1 and no further.

Core2#traceroute 75.75.75.75

Type escape sequence to abort.

Tracing the route to 75.75.75.75

  1 172.25.2.1 64 msec 64 msec 60 msec

  2  *

Oops. Apparently GNS3 Clouds don't work the way I had thought - I need to enable NAT so that Core0 can translate packets between my virtual LAN and my home LAN.

After some quick changes (irrelevant lines omitted):

interface FastEthernet0/0

 ip nat outside

interface FastEthernet1/0

 ip nat inside

interface FastEthernet2/0

 ip nat inside

ip nat inside source list 1 interface FastEthernet0/0 overload

!

access-list 1 permit 172.25.0.0 0.0.255.255

access-list 1 permit 172.26.0.0 0.0.255.255

access-list 1 permit 172.27.0.0 0.0.255.255

access-list 1 permit 172.28.0.0 0.0.255.255

access-list 1 permit 172.29.0.0 0.0.255.255

I can now ping the outside world from Core2.

Next up: configure default route propagation between all core routers with default-information originate.

Even after doing this, route information is not making it to Access1.

After some digging, I discovered that neither Core1 or Core2 was sending RIP updates to Access1 because I'd somehow forgotten to activate that interface on both Core1 and Core2.

After fixing this, I tried to ping 75.75.75.75 from Access1 - it worked, but only with a 40-60% success rate. Same with most other Internet sites I tried.

Problematically, this doesn't appear to happen if I try it from my physical machine, and I don't have this problem with pings anywhere in my home LAN. It looks like the latency within GNS3 - while not a problem as long as I'm inside my own network - is too slow for traffic to the Internet.

This isn't really a problem, except that my Windows 2016 server needs to be able to access the Windows Update service, and it can't do that if packets are constantly timing out.

Fortunately, this should be a fairly easy fix - I can add a second network adapter to that VM in VMware, connect it directly to my home LAN (bypassing GNS3) and set that as the default route for all traffic not headed for my virtual LAN.

So at this point, my W2016 VM has two network connections: SIMULCRON (connected to my virtual LAN) and EXTERNAL (connected directly to my home LAN.)

(It was also at this point that I switched ExtEdge2 back to a two-port router, and added a generic switch connecting the Windows 2016 VM to it, for simplicity configuring the router.)

Here's what my routing table ended up looking like:

Oddly, at this point, I can access the Internet and ping ExtEdge2, but I can't reach the rest of the virtual LAN.

(Sidenote: I discovered during this process that GNS3 doesn't handle editing of startup-config via the text editor very well if you do it while the VND is running.)

Not too soon after, I realized I'd never configured ExtEdge2 to advertise its path to Win2016 (which is on the 10.1.0.0/16 network, rather than the rest of the virtual network, which is a 172.* network.) After adding 10.1.0.0 to the RIP database on ExtEdge2, everything worked perfectly - and I confirmed I can ping from Core0 to Win2016, and back!

Next up...

Next step will be setting up user VLANs, like I planned in the original network diagram.

As an aside, while network performance is fine, Win2016 is struggling to paint the screen when I'm doing command-line stuff. I may also start using VPCS simulators to test network connectivity.

Day 0.3: Building my domain

(NB: I'm posting this out of order since I was "live-blogging" as I went tonight, I need to go back tomorrow and explain what I already did in AWS to get to this point.)

Starting point

So far, I've gotten my VPC and routing configured in AWS, and created an EC2 instance running Windows 2016 Server. I've run Windows Update to bring the server up to date on patches and renamed the server to STARBASE-HUB. I've installed the DNS and ActiveDirectory Directory Services roles on STARBASE-HUB.

Doing work 

Alright, so... the first thing I wanted to do was set up an ActiveDirectory domain to link together my virtual WAN.

I own the domain pyhakon.net. ActiveDirectory is based off of a DNS structure - you don't HAVE to give it a valid domain name to work off of, but since I have one, I figured I might as well. Making a Windows server a domain controller requires that it also be a DNS server, so it made sense to make that domain controller the "root" of my sandbox network. I made my sandbox domain "starbase.pyhakon.net" because I'm a nerd. Accordingly, since this server was going to be the "nexus" of my kingdom, I named it STARBASE-HUB.

I already use AWS Route 53 to handle DNS for pyhakon.net, so all I had to do was add an "A" record for starbase.pyhakon.net pointing to the Elastic IP I have assigned to my DC/DNS server, then delegated authority with an "NS" record for the subdomain `starbase.pyhakon.net` to `starbase.pyhakon.net`. Anything under starbase.pyhakon.net, will now get referred to starbase.pyhakon.net itself for resolution. (I'm not really touching on Route 53 because it's not part of this setup.)

Next order of business was to set up the DNS server on STARBASE-HUB. This means opening up the DNS Manager from the Tools menu of Server Manager.

Right now I just want to set up a basic Primary Forward Lookup Zone for starbase.pyhakon.net. Accepted pretty much all the defaults. After that was done, I added an "A" record for starbase.pyhakon.net and for starbase-hub.starbase.pyhakon.net.

DNS manager showing starbase zone setup, and an nslookup query confirming the host resolves.

I went into Server Manager, which was complaining that I never configured the server as a DC after installing ActiveDirectory.

Next I got asked what I was trying to do with my domain controller: add it to an existing domain, create a new domain within a forest, or a new forest. Simple answer: domains belong to forests, and if you don't have an existing forest, you have to create one.

Next I got asked about the functional level of the new forest/domain and a few other things. Of note is that I can't make this a read-only domain controller because you can only do that if you're adding to a domain where a normal domain controller already exists.

Next I got a warning that it couldn't create a delegation upstream for starbase.pyhakon.net, because the upstream DNS server is not Windows, it's Route 53. This is fine - I already did that delegation manually.

It asked me if I was okay with "STARBASE" as the NetBIOS domain name. Sure.

Asked me to set up a few paths. Defaults were fine.

Review options, and... go.

It pointed out a few warnings, mainly that I should disable "Allow cryptography algorithms compatible with Windows NT 4.0" for security, that I didn't have a static IP address assigned to the machine (which is fine - EC2 will make sure I always get the same IP address) and the previously mentioned DNS error.

Happy with itself, the server rebooted. When I reconnected, RDP complained that it no longer recognized the server (which now identified itself as starbase-hub.starbase.pyhakon.net.) I was okay with this, but now had to wait for the Group Policy Client to set itself up... which takes forever the first time.

Cool. I now have my own ActiveDirectory domain.

What's Next

Next I want to make a new domain within the forest, which is going to control all my VMs running on my local machine. This is going to take some design work, which I'm going to do tomorrow since it's 10:15 now.