:awesome:
Most of our laptops get on our wireless with a computer certificate. They're fine.
But some laptops and all our iDevices use a user certificate. That used to be fine, until we started to roll out a certificate that looked kinda like a user cert to the laptops and iDevices, so they got confused and hung when prompted for a certificate in the 802.1X flow of things... or every now and then, they mess up on a re-auth and randomly offer up the wrong cert and get bounced or put into a hung Access-Challenge state.
I get to talk with the PKI team in a little while... I hope they do this: :matrix:
So that I don't have to do this: :developers:
We shall see... :drama:
And for the company of a certain size fun: I'm in the states, they're in Europe, so after my presentation to Asia, I'll catch them as they walk in, using my Lync status lights by their names to cyberstalk them.
Found out that iOS 8.4 doesn't support DH groups of less than 2048 bits... now to see if that's our issue, or if it's maybe related to the new version of MDM that rolled out around the same time as our upgrade to 8.4... which also coincides with the new cert that causes contention on Windows devices - and which may or may not be causing a similar contention on iOS devices... the issue is not as simple as I thought it was in the OP.
Anyone else seeing issues where iDevices are intermittently dropping connections or hanging and not able to access the wireless for a period of time?
Quote from: deanwebb on July 09, 2015, 11:41:02 PM
I'll catch them as they walk in, using my Lync status lights by their names to cyberstalk them.
Ha ha.. Glad to see I'm not the only one that stalks people on Lync... I really do hate it though when they go busy right after I message them. Its OK though... I just wait for it to go green again. I have 3 monitors and its no waste on my desktop.
Lync codes and their meanings:
GREY: Either the guy is totally out, lurking, or deliberately not logged on to Lync. Send email then call him on his mobile to see if he got your email.
YELLOW: He's wandered away, be it to lunch, to go to the printer, to talk with the guy in the next cube, or somewhere his computer is not. Text his mobile then call his mobile to see if he got your text.
GREEN: Fresh meat! That, or he's away from his computer and he forgot to lock it. Best to send an email asking if you can hit him up on Lync and then call his desk phone to see if he got your email. If he does not answer his desk phone, call him on his mobile.
RED: The best Lync color. It means he's in a meeting and needs a distraction. Contact him on Lync directly. :)
Lol. That is spot on here.
so what happened? Did you find a single certificate solution? Or do iDevices play nice now with IOS9? or???
Am I reading this right: so you used to use 802.1X via AD (presumably) for user auth and machine certs for device auth - but this is no good for iDevices?
Most places I seen get around this by not enforcing certs on the iDevice BYOD/guest network and restricting iDevices to the BYOD/guest WLAN. But yes its no good for company owned iDevices that are MDMed hence theoretically deemed secure.
AD certificates on both the Windows and iDevices (via MDM on the mobiles).
No resolution beyond, "We are now aware of this situation." I still see it happening, but for now, most people expect the wireless to be shite so they go to the Guest Wireless.
Tried eap-fast for byod ssid? Meant to work for fruity devices
EAP-FAST makes me gag. :barf: It's EAP-TLS or use the LTE network.
What's so bad about it, it's not That compromised is it?
EAP-FAST is fine if it's using EAP-TLS as an underlying method. But if you're doing that, might as well just use EAP-TLS.
I hate to think what your opinion of (non EAP-TLS inside) PEAP.
Apparently, if the clients are configured to validate server certs and are unable to accept a new CA (which obvs you enforce via GP), its pretty secure (as obviously its a 'genuine HTTPS tunnel')
Quote from: wintermute000 on October 02, 2015, 05:02:17 PM
I hate to think what your opinion of (non EAP-TLS inside) PEAP.
Oh? You mean plaintext?
:haha4:
Mr. Clarkson and I agree, it's a joke. For enterprise security, you really want to have a good PKI server stood up, and the best news is that you can do it with a Windows Server on the cheap. As in free. For all the lads at home wanting to lab up some security, don't just go with self-signed certs and click through the error messages: stand up a Windows server and generate some for yourself, properly. Practice installing them so that you don't fear the whole arcane process.
And, yes, as Wintermute says, we don't allow acceptance of new CAs. Which can be an issue if we change RADIUS servers. That can either be taken care of via a fresh WLAN profile or via a registry entry push to Windows clients to accept the new RADIUS server. It can also be handled if the wireless is set up properly to push its config to the clients.
forgive me if its going over my head, but what do you mean plaintext? Isn't PEAP using a TLS tunnel - granted only authenticating the server cert - and thus the credentials are passing over a tunnel? (like a normal https website)
guess who has to take stupid wireless exams in a few months and learn how to setup 802.1x properly. LOL
going on an Aruba clearpass course on Friday, should be educational
OK, so I was exaggerating. It *is* weaker than EAP-TLS, and I really consider EAP-TLS to be the only security worth doing on a wireless network that you want to keep secure.
I agree, there's no other method that can revoke a client, or authenticate the client
Quote from: wintermute000 on October 06, 2015, 09:09:24 PM
I agree, there's no other method that can revoke a client, or authenticate the client
If you're using PEAP with AD-based policies on the NPS/ACS you can just disable the user or computer account, no?
Poor phrasing, I meant a client device.
protip: EAP-TLS documentation is.... horrific, at least for my levels of google-fu. Compared to reading about routing protocols, the info is all over the place, often ambiguously referencing MS screenshots. Took me half an hour to come to the conclusion that yes, you CAN auth BOTH machine and user certs. However, I can't find the answer to this - can you combine user/pass with a machine cert? Or is that PEAP (user/passs) with EAP-TLS (machine cert) chaining? Or just f--k it and join the queue of people asking our overworked resident wireless guru stupid questions?
Both user and machine can be used, but the 802.1X policy must be written to specify each choice. The certs can be ones that one must first sign into - which involves a local machine logon - but no connection to the wireless will be permitted until that user has signed on to his/her certificate. This wouldn't be cert chaining, but instead requiring that a cert not be offered up until the cert store is active and logged into.
Our firm wants to have wireless come up as the device boots, so we reference a non-interactive cert in our 802.1X wireless logon. However, our VPN requires a cert that involves a logon to the local cert store to activate.
Thanks. I know the difference between user and machine but do you have any links re which certs you need to sign into and which don't . Is it machine doesn't require sign in?
Both kinds can be ones that don't have a sign in. If a cert is used for signing documents or secure emails, they are set to require a user sign-in to activate the cert store, and then possibly a second (redundant) sign-in to activate a cert at the time of usage.
Signing cert description: http://www.entrust.com/pdf-signing-certificates/