I fought FreeRADIUS and FreeRADIUS won

Back to work

So... last I had written, several months ago, I had managed to add my CentOS server to my domain and was going to work on getting FreeRADIUS running there, so I could have my Cisco virtual devices authenticate against it.

Turns out, this was WAY more complicated then I thought it would be.

I'll spare the gory details, but long story short, I don't like the way FreeRADIUS tries to do... a lot of things.

Luckily, I complained about this on IRC, and someone else asked why I wasn't just using TACACS+. The reason I hadn't is because I don't have access to Cisco's TACACS+ server software - and I assumed there wasn't a free implementation of it out there.

As it turns out, when you assume, you may waste several months on a wild and unnecessary goose chase.

TACACS.net

There is indeed a free TACACS+ implementation, available from tacacs.net.

It's also ridiculously easy to set up. In addition to the normal configuration options (IP to bind to, mainly), all I had to do was specify:

authentication.xml

<UserGroup>

<Name>Router Access</Name>

<AuthenticationType>Windows_Domain</AuthenticationType>   

<LDAPServer>outpost-hub.outpost.amateria:636</LDAPServer>

<LDAPUseSSL>1</LDAPUseSSL>

<LDAPUserDirectorySubtree>OU=Accounts,DC=outpost,DC=amateria</LDAPUserDirectorySubtree> 

<LDAPGroupName>Router Access</LDAPGroupName>

</UserGroup>

clients.xml

<ClientGroup Name="INTERNAL">

<Secret ClearText="hidden" DES=""></Secret>

<Clients>

<Client>172.*</Client>

<Client>10.*</Client>

</Clients>

</ClientGroup>

authorization.xml

<Authorization>

<UserGroups>

<UserGroup>Router Access</UserGroup>

</UserGroups>

<ClientGroups>

<ClientGroup>INTERNAL</ClientGroup>

</ClientGroups>

<Shell>

<Permit>.*</Permit>

</Shell>

</Authorization>

And... that's it. In a nutshell, it takes requests from TACACS+ clients in the 172.* and 10.* ranges, looks up user accounts in the "OU=Accounts" DN, and confirms they belong to the "Router Access" LDAP group, and grants them permission to all commands on the router. (I could've made it more granular, but didn't see a need at this point.)

As a bonus, since it runs on a Windows host inside the domain, it can use the host's Kerberos credentials to access ActiveDirectory!

Bringing it online... jk

At this point, I went to configure one of my virtual Cisco routers to use TACACS for login, and... it didn't work.

After some digging, I found that for some reason, my CentOS and Windows Server machines couldn't route to the GNS3 LAN any more.

At this point, though, I decided that the original mesh design I had come up with, was probably overkill for what I was learning at the time. And also that it would probably need redesigning in the future when I learned new stuff.

So I killed the whole setup and went to a single router for now.

Also, I configured the input VTY lines for SSH.

At this point, I found something unusual - which is that trying to actually login to the router in question would hang for about 30-60 seconds, and then fail.

Coincidentally, at the same time, the CPU usage on the GNS3 VM would shoot up to about 100% and stay there. Nothing I seemed to do (switching from SSH to Telnet authentication) seemed to make a difference...

So for now, I'm just assuming that TACACS+/LDAP authentication would be working in a real environment, and moving on - because I've wasted more time on this than I'd like to admit.

I'm not really what I'll be moving on to next, but, we'll see.

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 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.