Avoiding the second logon prompt in RemoteApp

[Ephelyon]

This one has bugged me for years, so having today worked out a solution, I thought I'd share it. Tested on Server 2016 but I imagine it should work on 2012 R2 as well.

 

I expect many of us will be familiar with this problem. Educating users on entering DOMAIN\username instead of just their username is not always successful, resulting in a second logon prompt where Web SSO has failed (i.e. on non-domain home computers) that then appears not to recognise their credentials because - for some totally bizarre reason - it defaults to authenticating against the local RDS server instead of against the domain.

 

It turns out RemoteApp is much happier when using the UPN logon format instead of DOMAIN\username, to the extent that you can remove almost all prompts and avoid the second logon prompt entirely by using this format. Problem there? We've come back to the same old question of educating users... so here is a workaround! Let's assume the FQDN of our internal domain is "greenabbey.internal" by way of example...

 

We are editing two files:

 

%WinDir%\Web\RDWeb\Pages\en-US\Default.aspx

%WinDir%\Web\RDWeb\Pages\webscripts-domain.js

 

In Default.aspx, find the following:

 

TSFormAuthTicketInfo objTSFormAuthTicketInfo = new TSFormAuthTicketInfo(HttpContext.Current);

strUserIdentity = objTSFormAuthTicketInfo.UserIdentity;

bPrivateMode = false;

strDomainUserName = objTSFormAuthTicketInfo.DomainUserName;

 

... and replace "false" with "true".

 

In webscripts-domain.js, find this:

 

var strDomainName = "";

 

... and this:

 

var bPrivateMode = document.getElementById("rdoPrvt").checked;

 

... and alter as such:

 

var strDomainName = "@greenabbey.internal";

 

var bPrivateMode = true;

 

Now find this in the same file:

 

strDomainUserName = objForm.elements["DomainUserName"].value;

 

... and insert the following lines after it:

 

if ( -1 == strDomainUserName.indexOf("@") )

{

strDomainUserName = strDomainUserName + strDomainName;

objForm.elements["DomainUserName"].value = strDomainUserName;

}

 

With all of this done, all I got on a fresh installation of Windows 10 1607 in a VM with no customisations whatsoever (i.e. to simulate a home computer) was the single "are you sure you trust this provider" pop-up, which has a tickbox to never see it again. Magic!

 

We are doing a couple of things here:

 

1) Setting Private Mode to work in such a way that it behaves like Public Mode in terms of not remembering the username or storing cookies, but acts like Private Mode when it comes to setting up the RDP connections (i.e. you can tick the box about trusting the provider);

2) Inserting the "@greenabbey.local" UPN tag after the username on submitting the form, so they don't have to do it themselves. The If statement in webscripts-domain.js just makes sure it doesn't insert the UPN tag if there is already an "@" character in the username, e.g. if the user had ticked Private Mode after all.

 

So... only been banging my head against this one for the past 6-7 years!!! I think the edits given above were the only ones I ended up making (after reverting several other attempts). Would anyone with this problem and either Server 2012 R2 or 2016 like to try it out and report back?

 

(Oh, and I've also found that if any educated users do use the DOMAIN\username format for the initial sign-in, they will be prompted a second time when initiating an RDP connection but this time it will accept their password, without the need to enter a domain this time!)

 

EDIT: You may need to clear cookies on your testing workstation too!

Edited January 24, 2017 by Ephelyon

[deano]

Well I never... I used to stop the need for domain name in 2008 but it never worked since 2012. I will have a play later

[Ephelyon]

(Just to watch - if you're on 2012 or 2012 R2, the latter does things differently. I wouldn't recommend this method if you're not on R2 or 2016.)

[ITGURU]

I have a 2012 R2 RemoteApp Server - I made a change which let the users login to the main page without requiring the domain name, however when launching Apps, it still insisted on requiring domain\username

 

How do I remove the need for entering the domain name only when launching apps?

[Ephelyon]

That is the problem the instructions above should hopefully correct.

 

I would revert your original change first, then try these instructions - taking backups of the files in question at every stage of course.

 

The various solutions floating around on the web seem to be about removing the need to type the domain name (in DOMAIN\username format) on the initial sign-in screen, but this doesn't then carry over to launching apps, as you say. My original post changes the logon name to use UPN format but without users needing to type anything extra, and then for some reason I don't understand, RemoteApp seems much happier for SSO, even without being domain-joined...

[FN-GM]

If you make sure the certificate matches your collection name (can be specified manually in powershell) and use IE, it won't prompt for credentials twice.

 

Only works on IE though

[gshaw]

Will be interesting to see how the logon prompts behave when I publish RD via Azure AD Application Proxy. Hoping the delegated Kerberos with will make it SSO but we shall see.

 

Nice find on the UPN trick, remember that double logon driving me nuts on the 2008 version as well.

[ITGURU]

If you make sure the certificate matches your collection name (can be specified manually in powershell) and use IE, it won't prompt for credentials twice.

 

Only works on IE though

 

How does this work with UCC certificates? My RemoteAPP url is one of the additional Subject Alternate names so we always get the prompt for certificate mismatch but still lets us continue if allow it.

[FN-GM]

How does this work with UCC certificates? My RemoteAPP url is one of the additional Subject Alternate names so we always get the prompt for certificate mismatch but still lets us continue if allow it.

 

Its not just the URL that needs to match, its the published name. I used this to change it, confirmed as working on 2016

 

https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80

 

It also gets rid of those annoying certificate error messages. I just set the published name the same as my URL.

[Ephelyon]

Ah, yes, sorry - as @FN-GM says, that's something else I did, although it didn't fix it by itself. Subject alternative names should be fine also. So, instructions for that:

 

Let's assume our external FQDN for remote access is "remote.greenabbey.org.uk", we have a certificate for RemoteApp and other RDS services that matches that name and our server's internal IP address is 172.16.253.120. Run the attached script on your RDS box (specifically, the Connection Broker if the roles are not centralised) with the following syntax:

 

.\Set-RDPublishedName "remote.greenabbey.org.uk"

 

Then edit the hosts file on that server in:

 

%WinDir%\system32\etc\hosts

 

... and add the line:

 

172.16.253.120 remote.greenabbey.org.uk

Set-RDPublishedName.ps1

[ITGURU]

Its not just the URL that needs to match, its the published name. I used this to change it, confirmed as working on 2016

 

https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80

 

It also gets rid of those annoying certificate error messages. I just set the published name the same as my URL.

 

Is there a powershell command to check what the current URL is set as?

[Ephelyon]

You can tell by what comes up in the certificate prompt for the users.

[FN-GM]

Is there a powershell command to check what the current URL is set as?

 

Not sure, but you can see it when you connect. You can also see it in the server manager GUI under RDS.

[ITGURU]

Not sure, but you can see it when you connect. You can also see it in the server manager GUI under RDS.

 

On the prompt, the gateway server address is correct, but the publisher address shows the UCC Certificate main name for the certificate. So is that the one I change using the powershell?

[ITGURU]

Running the script has now changed the remote computer and gateway server to the correct names, but the Publisher one is still the main name on the certificate, not one of the SAN names..

..

[Ephelyon]

(Oh, and I've also found that if any educated users do use the DOMAIN\username format for the initial sign-in, they will be prompted a second time when initiating an RDP connection but this time it will accept their password, without the need to enter a domain this time!)

 

UPDATE!

 

This is apparently not the behaviour for all clients. My clean Win10 test environment was fine, but then a colleague's Win7 school laptop didn't like having e.g. "GREENABBEY\[email protected]" as the username and would prompt twice without accepting the latter, so I've now corrected for this too.

 

In webscripts-domain.js, just above the previous edit beginning with if ( -1 == strDomainUserName.indexOf("@") ), insert this:

 

if ( -1 != strDomainUserName.indexOf("\\") )

{

strDomainUserName = strDomainUserName.substring( strDomainUserName.indexOf("\\") + 1, strDomainUserName.length );

objForm.elements["DomainUserName"].value = strDomainUserName;

}

 

So that section of the code should now look like this:

 

strDomainUserName = objForm.elements["DomainUserName"].value;

if ( -1 != strDomainUserName.indexOf("\\") )

{

strDomainUserName = strDomainUserName.substring( strDomainUserName.indexOf("\\") + 1, strDomainUserName.length );

objForm.elements["DomainUserName"].value = strDomainUserName;

}

if ( -1 == strDomainUserName.indexOf("@") )

{

strDomainUserName = strDomainUserName + strDomainName;

objForm.elements["DomainUserName"].value = strDomainUserName;

}

strPassword = objForm.elements["UserPass"].value;

 

This should ensure that, regardless of whether the user enters "username", "GREENABBEY\username" or "[email protected]" for the initial sign-in, it will go down as "[email protected]" and should work fine!

Edited January 26, 2017 by Ephelyon

[ITGURU]

my default.aspx code seems to be different or the bprivatemode entry.

 

TSFormAuthTicketInfo objTSFormAuthTicketInfo = new TSFormAuthTicketInfo(HttpContext.Current);

strUserIdentity = objTSFormAuthTicketInfo.UserIdentity;

bPrivateMode = objTSFormAuthTicketInfo.PrivateMode;

strDomainUserName = objTSFormAuthTicketInfo.DomainUserName;

[Ephelyon]

Apologies, my error. Just change the "objTSFormAuthTicketInfo.PrivateMode" to "true". Think I must've come back to it after trying a lot of other edits and assumed what I'd changed to "true" must have originally been "false".

 

Could a mod perhaps edit my original post to reflect this please?

[ITGURU]

Apologies, my error. Just change the "objTSFormAuthTicketInfo.PrivateMode" to "true". Think I must've come back to it after trying a lot of other edits and assumed what I'd changed to "true" must have originally been "false".

 

Could a mod perhaps edit my original post to reflect this please?

 

I have searched the file but no results for objTSFormAuthTicketInfo.PrivateMode

[ITGURU]

do you mean I change:

 

bPrivateMode = objTSFormAuthTicketInfo.PrivateMode;

 

TO

 

bPrivateMode = TRUE ?

[Ephelyon]

Yes

 

(Lowercase "true", though, and don't forget the semicolon at the end!)

[ITGURU]

Thanks, now working without need for entering the domain or credentials twice, or if prompted can enter without prefixing the domain!

However, for the access i'm using a UCC certificate and the remoteAPP external URL is not the main certificate name, it is one of the SAN names so I receive the 2 certificate errors below as part of the access.

Anyone know how to remove these prompts?

thanks.

[gshaw]

@ITGURU check out a script called RDPublishedName that should sort it. Just done the same on my RDS setup, see the latest post on my blog for details...

 

https://gshaw0.wordpress.com/2017/02/02/server-2016-rds-via-azure-ad-application-proxy-end-to-end-guide/

[ITGURU]

@ITGURU check out a script called RDPublishedName that should sort it. Just done the same on my RDS setup, see the latest post on my blog for details...

 

https://gshaw0.wordpress.com/2017/02/02/server

 

Will it apply to server 2012 r2 also?

Also, is it possible to add text above the username box on the login screen to advise they no longer need to prefix their username with the domain?

When clicking submit can the @DomAin bit be included, but not shown in the username field?

[Ephelyon]

If you follow the instructions in my later post beginning with "Update!", they will ensure that the username taken forward will always be in UPN format, whether it's entered on its own or with the DOMAIN\ prefix.

 

No, I don't believe there's a way for the @DomAin suffix not to be shown, though of course it's only brief (unless their Internet is dreadful, of course)...