I just spent an hour or two in a furious state trying to set up SMTP relay with a G Suite domain, and it was stupidly frustrating because there was one little component stopping everything. Oh the rage!
My intent was simple: SMTP relay using a domain account for authentication and TLS. Should be easy.
When you look at the the instructions for setting up SMTP relay, they do appear on the surface pretty straight-forward:
Go to G Suite > Apps > Gmail > Advanced Settings
Make sure you’re at the top level of the OU structure (you should be)
Add “SMTP relay service” (it gives you a few options, in my case I want to use an account to authenticate, see below)
Then you configure your SMTP relay settings on your application to point to smtp-relay.gmail.com on port 587, input your SMTP authentication and then all done, right?
WRONG! You’re going to get continual authentication errors (Google’s SMTP error code “535 5.7.8”) and Google’s SMTP service will tell you to pound sand and send you to unhelpful help articles about having bad credentials.
You have to perform one more step not mentioned in the Google documentation (here’s where I found this fix): enable “Less secure app access” in your Google service SMTP account settings. Easiest way to get to it is go to Gmail > click on the service account profile > click ‘Manage your Google Account’ (tangent: why is ‘your’ not capitalized?) > then just search on the top for ‘Less secure app access’ and toggle the button to on. It looks like this:
That’s it! After that, SMTP relay will start working correctly.
Maybe this will help prevent some Hulk transformations.
(Update 20191220.1238 – Reworked some parts because I was in a rush last night).
(UPDATE 20190611: This method below is a bit clunky and causes quite a few issues that are unnecessary. I’ve found a new method that I’m going to make a new post for. Hint: in the Wireshark tarball, look at the ‘INSTALL’ file.)
Now for probably really good reasons, there still isn’t a Wireshark 3.0.1 deb package for Debian-Ubuntu distributions, and if you just so happen to be at Sharkfest 2019 running some flavor of Debian/Ubuntu and you’re taking the packet analysis classes, you need to be running Wireshark 3.0.1. Of course, you could just fire up a VM on your laptop and run Windows, or grab that random spare Mac in your bag — why you have a spare Mac in your bag is beyond me — but your only option is to compile from source the Wireshark package.
I’m going to quit yapping about this now and just get to the point.
Compiling and Installing Wireshark 3.0.1 for Ubuntu 18.04
First off, Wireshark is a complicated application, and I am not a developer, so my instructions here are likely flawed. My main intent here is to just share the dependencies needed to get Wireshark 3.0.1 compiled because otherwise you’re going to be running the ninja/make commands, get the dependency error message, Google the dependency package for Ubuntu, install it, then find the next one over and over again — if only someone just posted the dependencies!
That being said, I work with Ubuntu LTS releases, so my instructions here are what I put together for Ubuntu 18.04 on a Ubuntu 18.04 laptop and in a Linux container in Crostini (this is the ‘Linux Apps’ service on Chromebooks, which is my primary device as of late and is a whole other post I hope to do some day).
Another caveat here is that I previously had done an ‘apt install wireshark’, which helped with most of the libpcap depdencies. Ubuntu runs libpcap0.8 1.8.1-6*, but the ‘Beyond Linux’ post says it needs libpcap-1.9 (my install seems to capture fine with 0.8 1.8, but I’m not really capturing with this install, just analyzing).
Lastly, this doesn’t have option components. I’m just trying to get 3.0.1 up and running for the basics.
If there ways to improve this, please comment and let me know!
That should be it! Run ‘wireshark’ and you should be set. Should look something like this:
Bugs I’ve Encountered
Seems that on the Crostini build, some things aren’t working correctly. I’ve built this on my Ubuntu 18.04 laptop with no issues (yet). Some that I’ve found on Crostini:
Interfaces not found for capturing: I’m not really concerned about this because I knew from the get-go that Wireshark with ChromeOS would be spotty, especially with Wireshark. However, if you use the official Ubuntu package, packet capture works fine (although because it’s containerized, you don’t get hardware access for capturing).
No statistic information on interface: another one I don’t care about because I get the data elsewhere (see below).
Edit (20190610): I erroneously said that Ubuntu runs libpcap0.8, inferring that the version was 0.8, but Ubuntu actually runs 1.8.1-6. The Ubuntu libpcap package is called 0.8 and is built and tested for Ubuntu, but that name doesn’t actually reflect the actual version.
A few weeks ago I had the pleasure of attending Microsoft Ignite 2017 in Orlando, Florida, one of the best and well-organized conferences I have ever attended. There were a ton of sessions to attend for people of all backgrounds in IT, so I couldn’t hit them all (thankfully they’re posting the sessions on YouTube).
It’s a juggling act at events like this to strike the balance between personal interest and getting information/training to add value to the organization that sends you, so I focused on Windows 10 Deployment, Azure IaaS, and whatever Powershell nuggets I could find. All three topics are too much for one post alone, so I wanted to dump some thoughts on one that stuck out the most: Windows 10 Deployment.
Creeping from the Old to the New: Windows 10 Deployment
Device deployment in the Microsoft world has been dominated by what they call “traditional IT”, which we in the SCCM/MDT world would just call imaging. The “traditional” method of deploying devices often involved a lot of preconfiguration before the device actually reached the end-users, often with BIOS updates/configs and the tried and true method of wipe and load.
Of course, at Microsoft Ignite, you’re going to get proselytized about the company’s newest technology, and the direction Microsoft is transitioning to is something they call “modern IT”. It’s best summarized in this slide from Michael Niehaus’session on deploying Windows 10:
In practice, what this actually looks like is a bit of gradient between on-premise and cloud-based services, but the direction Microsoft is taking is to move identity services to Azure Active Directory, device management to InTune, applications are deployed from the Windows Store, and updates are managed via Windows Updates for Business. The entire process initiated on end-devices after a user logs into a device with their email and password with an Internet connection, removing the need for special provisioning. The entire process is summarized into what Microsoft calls “Windows AutoPilot“.
However, what I took from AutoPilot and all the deployment sessions was that while Microsoft would love for organizations to move their deployments online and sign-up for that recurring revenue, they know this is still a little ways off and doesn’t offer the feature parity of AD/SCCM. So instead, they’ve designed InTune and SCCM to really work in what they call “co-existence”, which comes from using the old and new methods together as a form of transition (to varying degrees): InTune-SCCM-AAD, or InTune-SCCM-AD, or (insert combo). The idea here is to not go full cloud, but transition to it to some degree.
One of the deployment MVPs who represented Microsoft explained it to me like this. Microsoft’s story about centralized Windows management has been largely one-sided for over 20 years: SCCM or nothing. There was no middle-ground between nothing and SCCM (although you could cobble-up some combination of AD, MDT, and scripts). InTune, AutoPilot, Windows Store — the combination of it all presents a middle-ground, a sort of gradient to centralized management. If you want a lot of control over your devices, continue using SCCM; if you want something simple, you have InTune now.
I think what Microsoft has done is make an interesting case for “modern” deployment, but until their on-premise AD component is deployed and fully-tested, I just don’t see a compelling case to even try InTune yet. The current deployment process, while not perfect, works pretty well, so this would have to be hardware that is proven to work well. Past experience makes me skeptical that hardware will work as well and consistently as SCCM OSD does (then again, I’m not working with users across the globe, so maybe there’s a better case to be made in that scenario).
Modern Windows 10 Deployment and Education
Bringing this closer to the industry I currently work in, Microsoft’s case for Windows 10 deployment and management for education is strong and better than ever before. Windows AutoPilot is indeed a great way to deploy devices (no matter which way you approach it), Azure AD and Office 365 are stellar products, OneNote is awesome (best education tool I’ve seen), Microsoft Teams looks amazing (especially with its takeover of Skype for Business and integration with Microsoft Classroom), and Microsoft’s licensing is making a big change. The classroom tools are indeed there, and management is as easy as G Suite (IMO).
However, I can’t help but ask: has the ship already sailed for a lot of K-12 organizations? I mean, Microsoft certainly has this great product for K-12, but a lot of organizations have already made massive investments in their device purchases, the technology choices they’re using in the classroom, and the email/cloud platform that they’re running applications with. These organizations already have inertia in the direction of these choices, so does Microsoft have enough to unbalance this forward motion?
I personally don’t think so, at least for the G Suite organizations. These organizations chose G Suite (or Google Apps at the time) largely because they could purchase educational devices for cheap, thereby getting more devices into student’s hands, and Google’s services (which users organically learned to use over the years) was free. Around the same time, Office 365 licensing was confusing, and while there were some free options, the service parity for device management just wasn’t there compared to G Suite.
Maybe it’s the Microsoft Ignite kool-aid in my system, but Microsoft has a better case for it’s products than Google with it’s licensing combos, or maybe Microsoft is just better at marketing and promoting it’s platform than Google. In the education world, I hardly ever hear from Google themselves promoting their products, it’s always someone doing something randomly. Microsoft constantly makes contact with my org, but Google — not a peep.
Windows 10 S machines are to be managed from Intune/Intune for Education, with programs available only from the Windows Store, and identity management is handled via Azure Active Directory. Windows 10 S machines prices will start around $189, making these machines definitely competitive with Chromebooks.
But why in the world would a school district choose to purchase these devices?
First off, the timing of this announcement seems a little late. Most schools where I live needed to have their budgets turned in long ago, and as a result have made purchasing decisions already. The machines are either already ordered and on their way, and/or the decision has already been made for the summer infrastructure plans and schools are preparing for the changes. Nothing in Windows 10 S stands out enough to stop the process and rethink what machines need to be deployed.
Second, Windows 10 S seems like it’s stuck in the middle of being like Windows, but also some new Windows Cloud OS. It looks and feels just like Windows 10, but behaves like a Microsoft Chromebook, and if an end-user, thinking that this Windows environment is just like any other Windows environment, they’ll probably find unexpectedly that they can’t install applications, are forced to have Edge as their default browser and Bing as their search engine, and probably won’t find Google Chrome in the Windows Store.
This is a huge problem for most mid-to-large school districts because there is a certain paradigm about how Windows machines are to be used, and administrators have designed their entire management infrastructure around this. Windows 10 S has no on-premise Active Directory domain-join, so that also means no group policy, no certificate enrollment for RADIUS authentication, or any other service that ties into the existing on-premise infrastructure.
As a result, Windows 10 S devices live as a fourth type of device to manage, next to Apple products, Chromebooks, and Windows machines. Windows 10 S devices are, in essence, in some other management world, unless, of course, you start tying together your on-premise devices with Intune/Intune for Education, but that assumes you’re not using a third-party MDM, which would complicate this further.
Even if you’re a small school/school district with limited resources, you’ve probably already moved to Chromebooks as your device of choice. Your email, office suite, and even file management are tied into G Suite now. Students, teachers, and staff are all familiar with G Suite and probably don’t care to uproot their files and teaching methods for Microsoft.
Don’t get me wrong: I think Microsoft has some pretty cool services and features in Office 365, but is it enough to for schools to have a complete paradigm shift and start purchasing cheap Microsoft devices? Not yet, but maybe. Microsoft needs to have a more compelling case that targets teachers and principals because people in information technology already understand what Microsoft has to offer, but sysadmins just maintain and expand the services based on the policies of what the curriculum makers decide.
Google has done an excellent job in giving teachers the tools they need, and they were the first to market for cheap, easy-to-manage devices. As a result, Microsoft has a tough hill to climb, and I just don’t think Windows 10 S is going to help enough to propel Microsoft over the hill, let alone up it.