Solved! Go to Solution.
By nature, the 2FA process requires user interaction (unless there is somethign that i haven't come across yet, which is possible; but all the environments i have seen require the user to put in a token value, ACK a request, answer a question, or do something that shows it is a valid login attempt.
Certificate authentiction is the only item we have that will allow for near-seamless user login; however, 2FA, but its nature, will require some interactions.
You could use an Anonymous Server in your Realm.
1. Create and Anonymous Server under Auth Servers
2. Create a new Realm using the your Anonymous Server. Apply your Host Check policy to this Realm.
3. Create a Sign-In Policy. Select "User picks from a list of authentication realms" and only select the Realm where you're using the Anonymous Server.
Tried it out on my test appliance and it worked flawlessly. Then I turned it all off. ;-)
You could make this more secure by using client certificates. A Microsoft Certificate Authority is pretty simple to set up. And, if you have AD, you could then use GPO to automagically distribute the client certificates.
Thanks to both of you for pointing me in the right direction!
I actually stumbled into the Cert Server option under Auth servers not long after posting and set up a quick test. It definitely does work as a proof of concept and if you have the network connect launching via GINA it's a silky smooth way to stick clients on your network with minimal interaction.
We already have a certificate authority up and running, so tying it to a user cert wasn't a big deal. The big nasty downside I ran into however is that you still don't hit AD for the authentication. In other words if I have a remote user who gets canned they can still tag into the VPN using the locally installed cert despite having a disabled account. Not that the average user would really be able to do much, but it's a hole none the less and not one I'll be recommending anytime soon.
Well couldn't you use the certificate revocation function to disable / revoke the certs for users who were let go? That way you could still use it and yet protect your network also.
I'm toying around with that now... I think my username template needs some love.
We tried revoking the certificate on the certificate server, however it looks like the cert auth server within Juniper is just checking to see whether the connecting client computer has a certificate that matches the criteria defined in the username template field , and not checking the actual certificate server for whether that certificate is still approved.
Now I'm no certificate expert, and honestly have only been in charge of our SSL implementation for a few months so I'm way behind the learning curve. But that looks to be the issue.
While we are at it, is anyone out there good with the certificate user name template strings? It's pretty much greek to me, it looks like it's similar to an LDAP query, but the syntax is different enough to throw me. We are currently using a basic <certDN.CN> string and while I know that's likely the issue most of the testing I've done has had similar results or broken authentication completely.
Are you using one of the "Client certificate status checking" options under Configuration --> Certificates --> trusted Client CAs --> <Your Client CA Certificate>?
You sir are both gentleman and scholar!
There was a checkbox under the trusted certificate properties that read Verify Trusted Client CA. It was of course, not checked....I'll do some testing with this later today and post the results assuming I'm not wrapped up in meetings all day.
Are you aware of a way to use this solution with certificate authentication? To stay in compliance with security policies we have to keep two factor authentication, but we are looking for a way to get NC to automatically connect our remote users.