Below is an email conversation (only slightly edited for sharing publicly) that I had with Stephan from Duo earlier in the year. I am posting it here as I think it would be of interest to the Duo Community and perhaps help garner support for what I think is a missing feature in Duo.
______________________________________________
Duo is truly a very robust and configurable solution. We are current planning a pilot at our company. The one feature that is sorely missing is the existence of a “remember me” feature for Windows login. The same is true for that of RDP logins. As I wrote below, if it’s all or nothing, we have to very reluctantly elect to not at all protect Windows logins with Duo. This is highly disappointing and a glaring omission from Duo’s otherwise comprehensive protection.
I do understand that cookies can’t be saved at that stage of pre-login. [A colleague] said that he spoke to the Duo folks at the recent DattoCon convention. He said that he suggested that Duo could use the IP address to identify a computer and allow it to pass through without Duo challenges on subsequent login attempts. Although it is possible to spoof an IP address, at least give the admins the option to rely on IP addresses to facilitate the “remember me” functionality for Windows logins if they so chose. And if for some reason, this specific approach still wouldn’t work, you have a bunch of clever people over there. I suspect you could figure out a way to make it work.
Although the absence of this functionality probably will not stop us from becoming Duo customers, it has been very close to doing so. Instead of a very strong feeling that we’re comprehensively protecting our users, my feeling would be better described as mediocre. I urge you to prioritize the development of this feature. Duo and its customers – both current and potential – will all benefit.
Thanks,
Eli
Hi Eli,
First, I completely understand your concern and you are far from the only person who has them. I’ll try to technically break down all the reason we are where we are right now here so hopefully everyone has a complete understanding of how this works.
- As you mentioned, remembered devices works by setting a cookie, which is not possible in the win logon process (no browser).
- No way to whitelist based on IP right now.
The ultimate reason both of these things are impossible is because the winlogon tool lives in something called the Windows Secure Desktop, which by design is a type of desktop that is completely out of scope of other application access. We didn’t necessarily choose to do that, but are somewhat forced into it. As architected by Microsoft, the actual Windows login is a subtype of the Secure Desktop, and to interact with that process, Duo has to live at that same layer, because as mentioned the Secure Desktop has no access to applications that live outside of it.
It is true that even in that space, we do have visibility into the IP of the machine, but only as reported by Windows. This is a problem for a couple reasons. It is sometimes inaccurate, and NAT becomes a problem. In essence, when logging into a local machine we only see the LAN address, or when logging into a machine on the same LAN via RDP we also only see a LAN address because of NAT. We don’t support whitelisting private IPs for security reasons. For example, were I to phish your credentials and stole a company laptop (the common concern behind Duo for winlogon) and you had whitelisted a local IP in a policy, I could accidentally or deliberately bypass 2fa. I could potentially be on an open wifi network and get assigned the same private IP via DHCP (unlikely but possible), or an actual malicious actor could just put the machine on a network with a deliberately small DHCP pool.
Simply summarized, we are a bit hamstrung by Microsoft architecture and we’ve deliberately limited one feature for security.
All that said, we have a dev team solely focused on Microsoft integrations and they are constantly looking for another way to solve for this. I expect that in the future we’ll see more login tools because of webauthn and Windows Hello. This is a bit speculative on my part but I know that our internal teams are investigating these tools as a possible path to solving these issues.
Hopefully this helps makes things a little more clear, and helps ease your concerns that it’s not being addressed. Please let me know if you have any more questions.
Regards,
Stephen
Stephan, instead of crippling Duo’s protection on Windows login, it would be far better to allow the admins to make the determination whether to trust IP addresses as reported by Windows. We would rather enable such a feature, even if its benefit isn’t rock-solid, than completely leave Windows logins unprotected. (And the other extreme of requiring Duo authentication on each and every Windows login / screen unlock would be an unacceptable burden to users.)
By way of analogy, Duo clearly states that SMS authentication isn’t really trustworthy, nonetheless, your documentation says:
We view text messages as better than not having any two-factor authentication, since it still blocks attackers that can’t attack SMS technology.
Granted, the IP reported by Microsoft might be the local IP, but when the request gets sent to your web servers at Duo, you are definitely getting the public IP of the computer. So you do, in fact, have that information. I would never expect you to whitelist a private IP as you mentioned.
And regarding RDPing into a computer remotely, and it causing the same IP to show up on your servers even though the person (attacker) is remote, I agree that’s a concern, but let the client decide if we want to care about that. For example, if I know that RDP is not enabled on my users laptops, then I am fine requiring Duo when outside the corporate office, but not requiring it when inside. Leave the decision to us.
Instead of making the decision for administrators, empower them – along with a warning – to make their own security choices.
Thanks,
Eli
)
