Most of the set up for 802.1x authentication of Wifi clients for Meraki APs using Microsoft NPS RADIUS is pretty straight forward. There are numerous guides on the web such as Meraki's own:
https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise
One thing that isn't well documented is how to make Windows 7 clients actually work. The problem is actually not Meraki related, but due to the RADIUS server not having enrolled a certificate for RAS/IAS use in the domain certificate store and is only seen when you have an AD CA configured. The RADIUS server delivers a certificate which Windows 7 will reject *even if it has been told to ignore server certificate validity* in the SSID config.
The solution is to open the Certificate Template MMC snap-in on the AD CA server system, make a copy of the RAS/IAS template and make sure enrolment and auto-enrolment is enable in it's permissions for 'RAS and IIS Servers'. This will result in the RADIUS server enrolling a new certificate which will be used when RADIUS clients connect - this certificate is properly formed and will work for Windows 7. You can check that this has worked by looking in the Issued Certificates list in the CA MMC plug-in on the AD CA Server - there should be a certificate for the RADIUS server using the template you created above.
Once you do this Windows 7 should start to connect successfully.
Thursday, 3 December 2015
Friday, 13 November 2015
This week's niggles
- Outlook 2016 not previewing Office files. Very annoying but easily fixed with a registry change http://www.outlook-tips.net/tips/outlook-2016excel-files-wont-preview/
- Bluetooth problems in Windows 10 - hard to tell which particular thing fixed it, but my fully up to date Windows 10 with the 1511 update seems rock solid in this respect now. I will test the Wifi stability issues over the weekend at home.
Friday, 25 September 2015
Embracing the Cloud - Cisco Meraki and VMWare's stingy Essentials license
I hate the term 'Cloud' as it refers broadly to an approach that has been around for a long time, so it really is a buzzword and nothing more, but I'll concede that it is simpler to just use the term in the interest of brevity...
In considering replacement network hardware for our cheapish-and-cheerfulish Netgear kit we're faced with a few core options. HP, Dell, Cisco Meraki are in the mix, as are some other less well known players, but for a single IT staff resourced company Meraki is so tempting as to be worth taking the risks associated with a cloud managed system. I have a Meraki AP and an 8 port Meraki switch that I got for free by attending some webinars (cunning strategy, IMO) and they really are so very easy to provision and manage and look good too (not that it matters when they will be mostly hidden away).
There are lots of nay-sayers around using Cloud for one thing or another, and the privacy and security oriented part of me (with it's roots in my early days as a *nix sysadmin) agrees with them all. However, we have taken the plunge for many management and commercial reasons, not least of which being the trend in our industry and our lean approach to IT staffing. So the fact that Meraki is cloud managed is OK with me, in this context. Horror stories about delayed renewals taking networks down merely re-enforce the need to manage one's contracts properly (and are increasingly older stories, so I suspect it is more well managed in general now).
Having said that, we are not a huge operation IT-wise, and our environment on-premise is mostly virtual. This puts us in the VMWare Essentials Plus license band, which suits us almost perfectly, being affordable (though not cheap) and allowing us a HA cluster at our larger site and a single server at the smaller site (so resilience between sites at the application level and at one site at the infrastructure level).
I have always used LAGs to mitigate against bandwidth problems for the VMWare physical connections, though of course the ability for a LAG to mitigate the problem is a lot more limited than people often think. The added resilience is handy too. On our NetGear switches we just set up a LAG and ignore LACP and it just works. On the Meraki switch we are told (by Meraki) that this will not work - their documented method is to enable LACP and use a VMWare distributed switch, which we can't do as the Essentials Plus license doesn't include that feature. Upgrading to a full vSphere license is pretty costly (looks like somewhere around the £5-6K mark, with an associated annual maintenance increase - a lot for one tiny feature IMO).
Meraki theorise that doing the same as we do now, but turning RSTP off on the LAG will work. They warn about the chance of loops, but from my understanding of vSwitches spanning tree is not necessary as the vSwitch prevents loops itself.
Of course, I can't commit to the new hardware without being sure that this will work, so it's time to vmotion all the guests onto one of the two cluster nodes and move the freed up host to my 8 port meraki switch for some testing (I could dredge up enough hardware to build a test system, just about, but I would feel better using my live host and it would be a lot quicker - 1 man IT dept, remember...)
Mind you, I do have an apprentice starting soon, so if I don't get to this before then they could learn a lot by building out a VMWare host.... Hmm.
Whichever I decide I'll post the results of the test here as I cannot find any posts on the Internet saying whether this works (which makes me wonder if many people use Essentials Plus)
UPDATE: I did the testing with the production ESXi host and couldn't persuade the Meraki and the server to work reliably with an aggregated link - ports would shutdown (presumably because the Meraki was trying to use LACP and VMware wasn't) and some VLANs worked but others didn't. What did work was to use "Route based on the originating virtual port" - sadly the Essentials license doesn't include the variant of this that takes load into account, so there's no clever load balancing, but there is some arbitrary spread and at least the links are redundant. The nice thing about this is it requires no configuration on the switch other than making the ports into trunks.
In considering replacement network hardware for our cheapish-and-cheerfulish Netgear kit we're faced with a few core options. HP, Dell, Cisco Meraki are in the mix, as are some other less well known players, but for a single IT staff resourced company Meraki is so tempting as to be worth taking the risks associated with a cloud managed system. I have a Meraki AP and an 8 port Meraki switch that I got for free by attending some webinars (cunning strategy, IMO) and they really are so very easy to provision and manage and look good too (not that it matters when they will be mostly hidden away).
There are lots of nay-sayers around using Cloud for one thing or another, and the privacy and security oriented part of me (with it's roots in my early days as a *nix sysadmin) agrees with them all. However, we have taken the plunge for many management and commercial reasons, not least of which being the trend in our industry and our lean approach to IT staffing. So the fact that Meraki is cloud managed is OK with me, in this context. Horror stories about delayed renewals taking networks down merely re-enforce the need to manage one's contracts properly (and are increasingly older stories, so I suspect it is more well managed in general now).
Having said that, we are not a huge operation IT-wise, and our environment on-premise is mostly virtual. This puts us in the VMWare Essentials Plus license band, which suits us almost perfectly, being affordable (though not cheap) and allowing us a HA cluster at our larger site and a single server at the smaller site (so resilience between sites at the application level and at one site at the infrastructure level).
I have always used LAGs to mitigate against bandwidth problems for the VMWare physical connections, though of course the ability for a LAG to mitigate the problem is a lot more limited than people often think. The added resilience is handy too. On our NetGear switches we just set up a LAG and ignore LACP and it just works. On the Meraki switch we are told (by Meraki) that this will not work - their documented method is to enable LACP and use a VMWare distributed switch, which we can't do as the Essentials Plus license doesn't include that feature. Upgrading to a full vSphere license is pretty costly (looks like somewhere around the £5-6K mark, with an associated annual maintenance increase - a lot for one tiny feature IMO).
Meraki theorise that doing the same as we do now, but turning RSTP off on the LAG will work. They warn about the chance of loops, but from my understanding of vSwitches spanning tree is not necessary as the vSwitch prevents loops itself.
Of course, I can't commit to the new hardware without being sure that this will work, so it's time to vmotion all the guests onto one of the two cluster nodes and move the freed up host to my 8 port meraki switch for some testing (I could dredge up enough hardware to build a test system, just about, but I would feel better using my live host and it would be a lot quicker - 1 man IT dept, remember...)
Mind you, I do have an apprentice starting soon, so if I don't get to this before then they could learn a lot by building out a VMWare host.... Hmm.
Whichever I decide I'll post the results of the test here as I cannot find any posts on the Internet saying whether this works (which makes me wonder if many people use Essentials Plus)
UPDATE: I did the testing with the production ESXi host and couldn't persuade the Meraki and the server to work reliably with an aggregated link - ports would shutdown (presumably because the Meraki was trying to use LACP and VMware wasn't) and some VLANs worked but others didn't. What did work was to use "Route based on the originating virtual port" - sadly the Essentials license doesn't include the variant of this that takes load into account, so there's no clever load balancing, but there is some arbitrary spread and at least the links are redundant. The nice thing about this is it requires no configuration on the switch other than making the ports into trunks.
Friday, 18 September 2015
Domino 9.0.1FP4 vs Backups Exec 2014, round 2
After resisting for a long time I gave up and removed Backup Exec from our production Domino server and set up a separate server just for backups. I didn't want to purchase another Windows license, and whilst I love linux I didn't want to wrestle with IBM's Linux requirements and their Domino install process (none of which is that bad, but there's only one of me here).
So I popped some extra disk space into my network monitor machine, which is recently new and has lots of spare resources and stuck Domino 9.0 on there, which is fully supported by BE.
So I popped some extra disk space into my network monitor machine, which is recently new and has lots of spare resources and stuck Domino 9.0 on there, which is fully supported by BE.
- I now have a pull-only Domino server, with a 30 min schedule. This gives me a 30 minute 'quick recovery' window is someone screws up (well, kinda)
- The production Domino server no longer gets constant errors reported in the DDM - looks like all the fixups and compact clashes were down to BE
- No more disk errors, no more database corruption
- Backups no longer get exceptions and run a bit faster too
So I wish I had done this earlier.
The network monitor is another post waiting to be written. PRTG is a lovely NMS...
Wednesday, 2 September 2015
HP Intelligent Provisioning nightmares
Much like https://supertekboy.com/2013/06/03/hp-intelligent-provisoning-firmware-update-failed/#.VebpBPZVjX8 I am once again unable to get the HP Intelligent Provisioning to apply updates to a brand new HP sever (just a little DL60 this time).
It escapes me just how HP can ship hardware with this kind of problem. I just want my SmartUpdate DVD back, at least it worked!
Tried static IP addresses, DHCP, separate network interface, different port on the back, nothing works.
Sigh.
[UPDATE: giving up and downloading the HP SP DVD]
[UPDATE: amusingly whilst trying to login to the HP Support site, which doesn't seem to want to work, the server started updating. I had to use the 2nd NIC and specifically go into the provisioning set up to change to that NIC even though it was already selected]
It escapes me just how HP can ship hardware with this kind of problem. I just want my SmartUpdate DVD back, at least it worked!
Tried static IP addresses, DHCP, separate network interface, different port on the back, nothing works.
Sigh.
[UPDATE: giving up and downloading the HP SP DVD]
[UPDATE: amusingly whilst trying to login to the HP Support site, which doesn't seem to want to work, the server started updating. I had to use the 2nd NIC and specifically go into the provisioning set up to change to that NIC even though it was already selected]
Sunday, 23 August 2015
The Cloud isn't everything
So what do you do when the cloud document collaboration system you rely on stops allowing logins on a Sunday and support only communicate via email ? On a Sunday when your users need access...
Email them repeatedly and hope they either fix is as a matter of course or actually respond to the emails and look into the problem.
Luckily I keep an onsite backup so at least we can get to the files as a last resort.
This kind of thing is never mentioned when people are pushing 'cloud' solutions. I start from an assumption that things will go wrong hence the onsite backup but many people just drink the koolaid and suffer the consequences.
So much for being on holiday!
[UPDATE: turns out that they had been making a change for another customer on Friday night and they accidentally changed our SAML configuration data, breaking our account. It took a lot of back and forth to get this checked.]
[UPDATE: turns out that they had been making a change for another customer on Friday night and they accidentally changed our SAML configuration data, breaking our account. It took a lot of back and forth to get this checked.]
Friday, 21 August 2015
IBM Domino 9.0.1FP4 and Backup Exec 2014
And here's why you need to keep some kind of configuration/change log, even if you only ever refer to it once a year and there's only one of you in the IT team...
Whilst we don't use IBM (ne Lotus) Domino quite as much as we used to (now we live in the brave new cloud world of Office 365 for email...) we do have several key systems that rely on it.
Now that IBM have finally patched the various SSL and related vulnerabilities it pays to keep the servers on pretty recent versions, especially in an environment like ours which are small enough to be manageable by one person who knows reasonably well how it all hangs together (ehem, that'll be me I guess).
So after letting Domino 9.0.1 FP4 bed in at other IBM customers for a little while I decided to get us updated, particularly as we are seeing some odd issues with database files on one of the servers.
Of course it didn't (but should have) cross my mind that IBM might do something that breaks Backup Exec's backup agent. It really should have. Backup Exec is a ropey product at the best of times, and when you put that together with the increasingly niche (but still quite common) Domino you're asking for trouble.
So I updates and dutifully logged a help desk ticket, tagged as a Domino ticket and marked as a 'change'.
My backups then began to fail. Part of the reason for that was the fact that I had disabled the Backup Exec agent service to allow the FP install and then forgotten to turn it back on again. I turned it back on, and now the backups hang on any attempt to access Domino databases.
Turns out IBM changed something and the Backup Exec agent can't get to the databases any more.
So I compared the backup logs with the 'change log' (er, spiceworks help desk with a custom field to indicate that a ticket was actually a change - it kinda works). And the two things correlated.
Before I made this connection symantec support were kind enough to spend the day on the phone trying to get it to work before I finally pointed out that perhaps it was a Domino version issue. Only version 9.0 of Domino is officially supported.
So I went back to 9.0.1 (no patches) and lo and behold it works again.
So surely I can get back up to FP3, which was, after all, working (though my suspicions were roused about the database corruption I had been seeing...). Er, no. Back up to FP3 and it fails again. So back to 9.0.1 we go and it's working again.
Maybe I can sneak up to FP2, which for some reason requires that I pause the Windows Management Instrumentation service (thank you Google) to install. But no, so back to 9.0.1...
This took most of the day. Now I can try to cram the day's work into the last 45 mins before I have to leave ;-)
Whilst we don't use IBM (ne Lotus) Domino quite as much as we used to (now we live in the brave new cloud world of Office 365 for email...) we do have several key systems that rely on it.
Now that IBM have finally patched the various SSL and related vulnerabilities it pays to keep the servers on pretty recent versions, especially in an environment like ours which are small enough to be manageable by one person who knows reasonably well how it all hangs together (ehem, that'll be me I guess).
So after letting Domino 9.0.1 FP4 bed in at other IBM customers for a little while I decided to get us updated, particularly as we are seeing some odd issues with database files on one of the servers.
Of course it didn't (but should have) cross my mind that IBM might do something that breaks Backup Exec's backup agent. It really should have. Backup Exec is a ropey product at the best of times, and when you put that together with the increasingly niche (but still quite common) Domino you're asking for trouble.
So I updates and dutifully logged a help desk ticket, tagged as a Domino ticket and marked as a 'change'.
My backups then began to fail. Part of the reason for that was the fact that I had disabled the Backup Exec agent service to allow the FP install and then forgotten to turn it back on again. I turned it back on, and now the backups hang on any attempt to access Domino databases.
Turns out IBM changed something and the Backup Exec agent can't get to the databases any more.
So I compared the backup logs with the 'change log' (er, spiceworks help desk with a custom field to indicate that a ticket was actually a change - it kinda works). And the two things correlated.
Before I made this connection symantec support were kind enough to spend the day on the phone trying to get it to work before I finally pointed out that perhaps it was a Domino version issue. Only version 9.0 of Domino is officially supported.
So I went back to 9.0.1 (no patches) and lo and behold it works again.
So surely I can get back up to FP3, which was, after all, working (though my suspicions were roused about the database corruption I had been seeing...). Er, no. Back up to FP3 and it fails again. So back to 9.0.1 we go and it's working again.
Maybe I can sneak up to FP2, which for some reason requires that I pause the Windows Management Instrumentation service (thank you Google) to install. But no, so back to 9.0.1...
This took most of the day. Now I can try to cram the day's work into the last 45 mins before I have to leave ;-)
2 years, four months post treatment
Well I'm still here....
Unless the worst happens I'm switching the blog from health matters to IT matters, so if you subscribe feel free to un-subscribe unless you want to hear my random unedited musing...
Unless the worst happens I'm switching the blog from health matters to IT matters, so if you subscribe feel free to un-subscribe unless you want to hear my random unedited musing...
Subscribe to:
Comments (Atom)