02-21-2020 01:20 PM
Hello,
I first want to say that if this post is wrongly categorized, please let me know so I can post it in the correct category.
We recently purchased Duo and have slowly started to enroll our users. We’re doing this in phases. Our last phase will be to put the nail in the coffin and disallow any logins if the user is not enrolled. We don’t want to enable that setting yet as it would create absolute chaos. So for right now, it’s not enabled.
We have a Remote Desktop Service (RDS) environment, with a Remote Desktop (RD) web access, RD gateway, RD connection broker, and several RD session hosts. All of these servers run Windows Server 2016 and have the January 2020 cumulative update.
We have Duo working and set up with our RDS environment and has been working quite well for us so far. Since we have Duo working in our environment, we are able to see all authentications against us. We have recently started to see some very strange authentication logs. These authentication logs use the users SID to log in rather than the user names, and they’re at very strange times. The are apparently coming from Microsoft RD Web and have an unknown location with an IP address of 0.0.0.0:
We are getting lots of these. What’s more scary is that some of these SIDs are users who already have Duo enabled and working. So it’s not even prompting the user to allow or deny the login attempt. Now, this could be ended by simply disallowing any user login that’s unenrolled, but we’re not there yet. However to think that it’s happening regardless, is a tad concerning as well. I noticed that my SID was included in the list. I’ve recently changed my password about a week ago, and it still appeared.
Anyway, I hopped on our RD Web server and dug through the events in the event viewer. I found logs at the same time as the timestamps in the Duo authentication log. The logs were:
(2/21/2020 12:38:39 AM) Event ID 4624 - An account was successfully logged on
(2/21/2020 12:38:39 AM) Event ID 4634 - An account was logged off.
These happened at the same time which I thought was odd too.
Has anyone seen SIDs in the Duo authentication log before? Is Duo doing something to our RD servers or vice versa? Is our RD servers interacting idle sessions on our session host? Should we be concerned with anything?
02-21-2020 03:18 PM
Hi SVMax!
Thanks for reaching out to the community !
We’ve seen something similar to this with our OWA protection, which we document here -
https://help.duo.com/s/article/2229?language=en_US
I recommend reaching out to our support team so that we can help determine why you’re seeing this with the RD Web integration. They can be reached at support@duosecurity.com.
Please be sure to email from the address that you use to log in to your Admin Panel so that we know which account you’re working with.
Thanks!
02-24-2020 06:36 AM
Hi @DuoJessica
Thank you for your recommendation but I already reached out to the support team but unfortunately they were not able to help me out, and wanted me to go to Microsoft instead. So I figured I would post something in the community to see if anyone else has seen this issue.
Here is what Duo Support said:
1. Why are SIDs appearing in our authentication log? Duo can’t advise what or who is authenticating into your RD Web instance using the SIDs. Duo is in place to prevent account takeover in the event of a password compromise, however that can only occur if the username passed to us from the application exist as a user in Duo.
2. What is causing these SIDs to authenticate? Duo can’t provide any insight on this issue. I would recommend reaching out to Microsoft to identify why SIDs are allowed as an accepted username format in RD Web
Thanks,
SVMax
12-30-2021 10:48 AM
I know this is old, but I haven’t found the answer to this yet, so I thought I would update the thread. New setup, still bypassing for unknown users. The SIDs match known users in some cases, who have activated phones set up. Not sure why they would still be showing SID login and bypassed as unknown accounts. From 0.0.0.0.
01-06-2022 12:26 PM
Hi @splansing, The Duo integration relies on and sends to the Duo service the username format used to authenticate the user within RD Web/RD Gateway. It is possible to force the Duo integration to translate this to userPrincipalName (UPN) instead using the steps in the FAQ here.
To ensure the username sent aligns with the usernames already enrolled in Duo, verify that the UPN username and sAMAccountName in Active Directory for the users match, and leave Simple Username Normalization enabled for the application. Alternatively, you can add the UPN as an alias to the users if they do not match.
01-06-2022 12:42 PM
Thank you for the feedback. I also switched the 2FA login to required, and have not seen any of these SID logins since. This happened during the initial rollout, before 2FA was required for everyone.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide