"The specified domain does not exist or cannot be contacted" when signing in to RD Web with UPN username

[_birkoff]

We’re evaluating Duo on our Remote Desktop Web environment in preparations to deploy this to our customers.

Users are encouraged to login with their UPN username (user@domain.com) on RDWeb, but DOMAIN\user also works. This works fine without Duo RD Web installed.

As soon as I install Duo RD Web and try to sign in with my UPN username, an error is shown.
Signing in with DOMAIN\user works fine and shows the Duo enrollment screen.

When I uninstall Duo RD Web, UPN sign-in is succesful again.

Any idea what could be going wrong here?

The specified domain does not exist or cannot be contacted.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.DirectoryServices.ActiveDirectory.Active■■■■undException: The specified domain does not exist or cannot be contacted.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[Active■■■■undException: The specified domain does not exist or cannot be contacted.] System.DirectoryServices.ActiveDirectory.Domain.GetDomain(DirectoryContext context) +788 Duo.DuoBaseHttpMod.GetFdqnFromDomain(String friendlyDomainName, LogBuilder log) +83 Duo.DuoBaseHttpMod.GetUpnUsername(String origUsername, LogBuilder log) +269 Duo.DuoBaseHttpMod.Application_PostAuthorizeRequest(Object source, EventArgs args) +751 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +136 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +195 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +88

[Flyer1]

Does someone know the solution for this problem?

I have the same problem.

[DuoKristina]

@Flyer or @_birkoff:

During Duo RD Web installation did you select the “Use UPN username format” option?

Are your users signing in with the implicit UPN (that matches your AD domain’s DNS name) or an explicit UPN that differs from the AD domain suffix?

Are the users and the RD Web server(s) in the same AD domain or are they in different trusted domains or forests?

Are you using a disjoint namespace?

I suggest you contact Duo Support with the answers to these questions for more extensive troubleshooting if you haven’t already done so.

[Flyer1]

Hi Kristina,

THanks for your reply.

Yes, I did select the “Use UPN Username format”.

We have one main domain and all kind of prefixes… It is a small hosted platform.

User@domain1.com
user@domain2.com
user@domain3.com

are the logon’s of the customers. DUO RDWeb is giving an error that domain1.com, domain2.com and domain3.com are not existing. Without DUO they can logon without any problem.

On that same server, we have also the DUO RDGateway running. The UPN logon using the rdp-client is no problem

[DuoKristina]

@Flyer

if I understand you correctly, you have domain1.com, domain2.com, etc. defined as explicit UPNs for users who all reside in a single domain (so all users share the same implicit UPN as well)?

Example:

1. My Domain’s DNS name is acme.corp.
2. I define the explicit UPN suffix acmecorp.info on that AD domain (because I want the user to have UPNs that match their email addresses).
3. I create a user bob and assign the explicit UPN suffix to that user, so the user can log in as bob@acmecorp.info.
4. The user could also log in to AD with implicit UPN bob@acme.corp.

[Flyer1]

That won’t do the trick.

Because:
user@domain1.com
user@domain2.com
user@domain3.com
have 3 different logon’s on the main domain. Reason, user is already been used by user@domain1.com.

Other words:
user@domain1.com => somedomain\userdomain1
user@domain2.com => somedomain\userdomain2
user@domain3.com => somedomain\userdomain3

But, for me, why is this not a problem on the Duo Gateway setup and is a problem on the rdweb? What makes the connection of Duo gateway and rdweb different?

[_birkoff]

Yes. UPN Format is chosen. The UPN in AD does not match the Domain’s DNS name. Users have user@ourdomain.nl while our AD’s DNS name is ad.ourdomain.nl. So that would be explicit.

Everything is in the same AD domain. not trusted domains or forests here.

UPN logon through RD Gateway works, just like with @Flyer. Just not RDWeb.

[DuoKristina]

@Flyer and @_birkoff - please contact Duo Support to open a case, referencing this forum thread. Be prepared to provide debug output from both RD Web (https://help.duo.com/s/article/1439) and from the Duo RD Web module (https://help.duo.com/s/article/2190) capturing an attempted logon by a user with a vanity UPN. This sounds like a bug in how Duo for RD Web resolves the user using a vanity UPN.

@flyer, the Duo applications for RD Web and RD Gateway have different architectures (as required by the host applications), so while we strive for feature parity on both of those they do not share the exact same code.

[Flyer1]

Will try doing it this weekend. Or try changing our test environment first to see if I can get those logs for you.

[DuoTony]

@Flyer @_birkoff

Was a resolution found on this issue?

[_birkoff]

@DuoKristina We’re using the DuoFree plan as we’re evaluating the product. In our admin portal it states we need to upgrade our plan in order to get support.

How can I submit a case for this issue?

[DuoKristina]

When you contact Support, tell them that you are in a trial and that you are reporting a possible bug, and they will open the case.

ETA: You probably have to contact them directly and not try to use the support link in the Admin Panel. Email and phone info is here: Support | Duo Security

[_birkoff]

I had a private conversation with support. last feedback i got was from february 22nd where they told me they identified the issue as a bug. I didnt receive an update since. I just sent them a follow-up

==
Thanks for your patience on this case.

I have been discussing with our engineering teams and the issue you are running into has been found to be a bug.

This is going to be worked on by the engineering team but at this time I do not have an ETA for a fix. It has been indicated to me that this is not going to be a quick fix unfortunately.