How To Add Google Workspace As An IDP In Arista AGNI

As I begin my journey into learning more about Cloud RADIUS/Authentication/PKI, I’m finding that configuring the integrations between various cloud services is:

The Worst gif from Parks and Rec

The particular issue I encountered today was adding Google Workspace as an IDP in AGNI so that AGNI can do directory lookups against your users in Google Workspace.

While the AGNI documentation I’ve used has been pretty decent overall, in this instance it was lacking. So I figured I’d make my own documentation (because I will definitely forget the steps!) and share it with the world. Hopefully it saves someone else some time!

Prerequisites

  • Google Workspace Admin Access
  • AGNI Admin Access
  • Google Cloud Access

Google Workspace API

Login to your Google Admin (admin.google.com) with the appropriate credentials

Login to console.cloud.google.com

  • Open APIs and Services and select Enabled APIs & Services
  • Create a new project
  • Give it a name and select the Organization and Location (my lab is all under the same level) – YMMV if you are doing this in a Production Environment
  • Enable the Admin SDK API by clicking Enable APIs and services then search for Admin SDK API. Select it and Enable.

Next we are going to create a set of Service Account and Key that will eventually be used to query our Google Workspace Directory

  • Click Credentials, Create credentials, and select Service Account
  • Add a Service Account name and description (Account ID will auto generate) and then Create and Continue
  • Click Continue on the 2nd step (do not assign any roles) and then Done on the last step (do not assign user access)
  • With the service account created, we can now add an API key
  • To do so, click your newly created Service Account
  • Next click Keys, Add Key, and Create New Key
  • Select JSON and Click Create
  • This will create the JSON file and prompt you to download that file to your computer

Congrats you have completed Part 1!


GOOGLE ADMIN CONSOLE CONFIGURATION

Now that we have a service account and a key, we need to allow that account to have the appropriate access to our Google Workspace Directory. For this part you will need to open the JSON file you downloaded and grab the Client ID from the file

  • Open the Google Admin console and select Security -> Access and Data Control – > API Controls and then select Manage Domain Wide Delegation
  • Click Add New, enter your Client ID (from the JSON file), and copy/paste these lines below (can do all one chunk) into the OAuth Scopes, and click Authorize

This was the part I had to find the hard way – I couldn’t find any documentation from Arista on what permissions I needed. I ended up finding them in Reporting-> Audit and investigation -> OAuth log events. In there it showed my failed access attempts (after doing the AGNI configuration below) and thankfully it listed exactly what resources I was being denied.

Onto Part 3!


AGNI IDP CONFIGURATION

Before you begin this part, you will need a piece of information from the Google Admin Console: your Customer ID

  • To get the Customer ID – go to Account -> Account Settings -> and note the Customer ID

Next login to AGNI where will configure Google Workspace as an IDP

  • Click Identity Provider and then Add in the upper right hand corner
  • Fill out the follow fields
    • Name
    • Domain Name – must match your Workspace domain
    • Identity Provider – Google Workspace
  • Enable Identity Information Synchronization and fill out the following fields
    • Customer ID (What you grabbed from your Google Admin Console at the beginning of this section)
    • Account Email
      • Note – I’m unsure exactly what email has to be used here. In my lab I just used my normal admin account (same account used to create the API credentials). In a production environment you would likely want to use a service account or generic account email instead of an individual. This account most likely would need admin credentials of some sort. If you figure out an answer – drop me a reply!
    • In the Upload Service Account Credentials – click Update Service Account and add your JSON file that you downloaded back in Part 1
    • Sync Interval (Optional)
      • Set this to whatever you like – default is 24 hours which may or may not be suitable for your environment. You can always manually sync at any time.

THE MOMENT OF TRUTH…

  • Click Verify and hopefully you will see something like this

If you get this: congrats you successfully added Google Workspace as an IDP

If you get a failure message – I’d encourage you to first look at the Google Admin Console logs I mentioned above: Reporting-> Audit and investigation -> OAuth log

Hopefully at least one other person finds this helpful and that it saves them the time I lost figuring out a lot of this the hard way!

Cheers!

CWNE Video Submission

Since I posted my CWNE essays, I figured I’d also post my submission for the long form content portion of the CWNE application as well. I chose to do an instructional video presentation on how to use the Scapy Python library to find the name of hidden SSIDs.

Fun fact: I did the whole thing (including a live demo) in one take and didn’t have to do any editing/splicing/etc. Probably my proudest achievement of the whole process 🙂

CWNE Essays

In response to Andrew McHale’s (@Mac_wifi) call on Twitter for CWNE’s to post their essays I decided to post mine here for future CWNE applicants to use if they are looking for examples on how to structure their essay.

I used Scott Lester’s examples (@theITRebel) from his website when I first started looking at how to approach building my essays and so hopefully Andrew’s initiative will encourage more of us to do the same. You can find more links to essays on Mr. McHale’s website – http://mac-wifi.com

One side note – I think sharing these helps in a couple of ways.

First – it allows applicants to see what a successful essay looks like in regards to structure/format/length/etc. When students start writing a thesis for post-grad work, they have hundreds of thousands of examples to work from (plus classes on how to write them). A 1000 word essay is a long ways from a thesis but there is some art to being concise while still getting your point across and being limited in word count means you can’t fluff your way out with sheer word count.

Secondly, the more examples that are out there the less likely that someone gets away with plagiarism. It’s tough to say it’s yours if the original copy has already been published for the world to see.

Without further ado – here are links to my three essays!

7 Ways to fail at making the most of #WLPC

I recently said goodbye to Phoenix and my now yearly trek to the Wireless Lan Professionals Conference (WLPC). After three years of attending I finally feel like I’m getting the hang of making the most of my week there. With the conference getting bigger and bigger each year, I thought it might be fun to discuss a few things I’ve learned over the years that keep attendees from getting the most out of the conference.

Direct inspiration for this write up comes from the fantastic Cisco Live presentation – 7 ways to fail as a wireless expert (by Steven Heinsius)

1.) Don’t take a boot camp

If you are not coming a few days early to WLPC for a boot camp you are really missing out on some fantastic classes. This year they ran the gamut from CWNP classes (CWAP/CWSP/CWDP/CWNA), to vendor offerings from Cisco and Ekahau, as well as classes developed directly by your wireless peers like the Python class from Jake Snyder and Ryan Adzima. Be warned – the boot camps are generally brain-melting since they cram a typical 4 day class into 3 days. The instructors though are top-notch and they will do their best to make sure that the material sticks.

My Advice: If you get push back from the $$$ people in your org, pitch the extra training cost as a screaming deal. Rooms, meals, an exam voucher (usually) as well as the potential for useful toys tools are all included in the cost. Most of these trainings done standalone usually run 2.5k to 3k without the rooms/meals and typically involve travel of some sort. If your boss is already going to send you to WLPC they might as well take full advantage of your time down there!

Continue reading “7 Ways to fail at making the most of #WLPC”

What I learned about Microsoft DHCP load balancing, Meraki APs, and IP Helpers

Cliche time – You learn something new every day…
… and today I learned about how the seconds elapsed field in DHCP packets can affect the DHCP DORA (Discover/Offer/Request/Acknowledgement) process – particularly when using a load-balance failover config on Microsoft DHCP servers.

Background:

  • 2 Microsoft DHCP servers with DHCP scopes setup for load-balance (50/50)
  • Meraki APs
  • AP Management VLAN gateway configured on core Nexus switch (and branch routers) with one IP helper address pointed towards DHCP server 1 (This will be important)
  • Greenfield wireless deployment

Problem:

Some (but not all) new Meraki APs were not getting DHCP IP addresses when they got plugged into the network.

Troubleshooting:

I love troubleshooting DHCP because it is a straightforward, structured process.

Continue reading “What I learned about Microsoft DHCP load balancing, Meraki APs, and IP Helpers”

9800-CL – Lessons Learned and First Impressions

Cisco recently announced their new Catalyst 9800 WLC platform and with all the changes I was itching to install the new cloud version to play around.

Well…after many trials and tribulations (all user error!) I was able to get a working instance up and running successfully. As of this post I’m waiting to make a couple of changes to our UCS environment to get some more vlans available but I’ve got enough of a setup to get a 3700 AP and clients joined.

So today I wanted to just highlight a few things I learned the hard way during installation and setup and to provide an initial look at the new GUI for those that haven’t had the opportunity or ability to spin up their own. On to the fun stuff!

Continue reading “9800-CL – Lessons Learned and First Impressions”

Getting DCA Channel Change counts with Python

First blog post (and it’s long) so let’s just get down to brass tacks…

I recently had a minor panic attack when I was looking at all the fancy stats that show ap auto-rf 802.11a “ap name” gives you on a Cisco WLC. All 3 of my controllers were showing hundreds, if not thousands, of channel changes for a vast majority of the associated APs. My first thought was that there was something in my RF environment causing Dynamic Channel Assignment (DCA) to constantly be changing the channel plan. From what I could recall though, Cisco had designed DCA to keep cascading channel changes from rippling though the entire wireless environment. The numbers were indicating otherwise though.

A small sampling of random AP’s across sites large and small was turning up a large number of high channel change counts regardless of site. I decided that I wanted to see what my channel changes looked like for each AP. We have almost 500 AP’s so running the above command on each AP wasn’t the best use of time plus I was having to go into Cisco Prime to look up each AP’s physical location. So with the problem at hand I decided it was…

…PYTHON TIME!!

Continue reading “Getting DCA Channel Change counts with Python”