SSO with smartcards (UbiKey) and Sophos UTM

You might or might not be correct.   

The core problem is that Microsoft has not provided a coherent way to support 2-factor authentication, so system managers have to bolt a third-party solution onto it.    Different solutions fit different use-cases, so you may need to have multiple solutions (which users will hate) or incompatible solutions (which is your current complaint.)   Microsoft is still living in a world where everyone uses a desktop PC, at work, in an employees-only area, so their concept of two-factor authentication is (a) your desk is in a trusted area and you are a trusted person in that area, so (b) all you need to be authenticated is a username and password.   They are the problem.

However, not every 2-factor solution works for every use-case.   Ask your vendor for his recommendations about remote access.   A single-vendor solution is always easier to support than a multi-vendor solution.   Smartcard-required solutions have limitations as a remote-access solution because they require the user to be at a device that supports that smartcard technology.   A restriction of that type is enforceable in some environments, but is not acceptable in many others.   Your vendor probably has a way to implement the smartcard solution for some contexts, and disable it for other contexts.   UTM might be fully compatible with the smartcard simply by creating an appropriate exception.

We use smartcards as a password substitute for internal use by users who move between devices frequently.   They login with card and password initially, but can reconnect with just the smartcard for a time period that is defined by company policy.  As such, it is really a form of one-factor solution, not two.   Then, we use the UTM OTP feature for 2-factor authentication when they are remote.    I don't know if this is close to what you want or not, but it suggests how different technologies can be made compatible.

UTM supports OTP (free) and DUO (third party product, monthly subscription fee if more than 10 people).  DUO provides a very sophisticated solution for remote access, but I don't think anyone would use it for internal access.

You might or might not be correct.   

The core problem is that Microsoft has not provided a coherent way to support 2-factor authentication, so system managers have to bolt a third-party solution onto it.    Different solutions fit different use-cases, so you may need to have multiple solutions (which users will hate) or incompatible solutions (which is your current complaint.)   Microsoft is still living in a world where everyone uses a desktop PC, at work, in an employees-only area, so their concept of two-factor authentication is (a) your desk is in a trusted area and you are a trusted person in that area, so (b) all you need to be authenticated is a username and password.   They are the problem.

However, not every 2-factor solution works for every use-case.   Ask your vendor for his recommendations about remote access.   A single-vendor solution is always easier to support than a multi-vendor solution.   Smartcard-required solutions have limitations as a remote-access solution because they require the user to be at a device that supports that smartcard technology.   A restriction of that type is enforceable in some environments, but is not acceptable in many others.   Your vendor probably has a way to implement the smartcard solution for some contexts, and disable it for other contexts.   UTM might be fully compatible with the smartcard simply by creating an appropriate exception.

We use smartcards as a password substitute for internal use by users who move between devices frequently.   They login with card and password initially, but can reconnect with just the smartcard for a time period that is defined by company policy.  As such, it is really a form of one-factor solution, not two.   Then, we use the UTM OTP feature for 2-factor authentication when they are remote.    I don't know if this is close to what you want or not, but it suggests how different technologies can be made compatible.

UTM supports OTP (free) and DUO (third party product, monthly subscription fee if more than 10 people).  DUO provides a very sophisticated solution for remote access, but I don't think anyone would use it for internal access.

Have read and thought a lot of your answer...

My goal is to achieve a SSO solution so the user can forget about passwords.

For LAN connected clients it is pretty easy in a Windows domain. Just follow Yubikey instructions how to set it up in a domain.

External users connects either via SSL VPN or via IPSec/L2TP VPN.

L2TP VPN

L2TP VPN using yubikey is harder or maybe impossible? Today I am using Freeradius to authenticate the clients (windows clients in a domain). The Freeradius server requires both a correct client certificate and correct credentials in order to pass authentication.  Perhaps there is a yubikey module to Freeradius which can replace the credential part with a yubikey part?

SSL VPN

Sophos UTM supports OTP for SSL VPN but not without a password. I cannot see why a user password is also required because you also must have the correct client certificate to connect SSL VPN. Isn't a client certificate enough to stop pin code guessing?

Your goal of eliminating passwords is not globally shared.   Two-factor authentication is based on these factors:

• Something you know (password)
• Something you have (cell phone, smartcard, or fob, digital certificate)
• Something you are (biometrics - fingerprint, retina scan, hand scan, implant chip)

Assuming that passwords and cell phones can be stolen, and biometrics might be forged, the goal is to limit the chances that multiple credentials have fallen into the same malicious hands at the same time.

PCI DSS requires two-factor authentication for remote access.   Most every organization needs to accept credit cards, so you cannot get rid of passwords for your remote access users, and still be PCI DSS compliant.

The nearest approximation of that is being deployed on some cell phone applications.  I forget the name for the protocol.   The  phone application registers with the application vendor and is given a digital certificate.   The person authenticates to the phone with a fingerprint (or password backup).   The combination of the two provides a two-factor authentication process which is perceived by the user as easy and acceptable.   The phone is "something you have", the fingerprint or password provides the second credential type.   The protocol makes it one-step for the user.

Just to clarify. A password is is not the same as a PIN code in my world. Even though both are credentials.

For user authentication during computer log in my 2FA-solution, the PIN code is used for user authentication together with a certificate stored on a smart card (in my case Ubikey).

OTP is a kind of PIN code and in Sophos UTM it is used together with a client certificate and the users password to connect SSL VPN when OTP is activated. So my question was why do the users need to use both their passwords and a OTP for connecting SSL VPN when there also is a client certificate involved?

Certainly if Sophos UTM requires the users password besides OTP  for connecting SSL VPN I cannot do anything about it besides creating a change proposal for Sophos UTM. I was just wondering if there is a reason for that.

Maybe we missed something obvious here.

Does your UbiKey function as an LDAP, RADIUS, or TACACS+ authentication server?   My expectation is that it does at least RADIUS, because VMWARE is a huge market and they integrate with RADIUS servers for 2FA.

Groups:

LDAP is preferred, because UTM supports both back-end users and back-end groups.   With RADIUS or TACACS+, UITM does not implement back-end groups, so the groups need to be configured as UTM groups.  

Users:

With RADIUS and TACACS+, you may also have to create UTM user account objects (with back-end authentication) manually.  In my configuration:

• For outbound-only users do not need UTM user objects because webfilter does not require them for AD SSO and LDAP. 
• For remote-access users, a UTM account is needed to track the remote access certificate, but UTM creates this object when they log in to get their OTP token. 

I am not sure that your configuration will have anything to trigger automatic configuration of user account objects.