Kudu: Cannot authenticate against Kudu site when deployed to custom Application Service Environment

[drub0y]

I have a custom Application Service Environment in which I have stood up an Azure Web App instance. When I attempt to access <mywebsite>.scm.<myasedomain>.p.azurewebsites.net, instead of just being able to use the typical portal login process, I am prompted for basic authentication. Fine, I figured maybe portal based login maybe isn't supported for ASEs for some reason, but I know my Deployment credentials^*, so I enter those into the basic auth dialog, but they don't work and I am repeatedly 401'd as if those credentials are no good either. I have no problem doing anything in a standard Azure Web Site deployment, it just isn't working in the ASE.

Is the Kudu site maybe not supported in ASE scenarios yet?

^* For the record I even reset my Deployment credentials, so I'm positive I'm entering the correct user/password for those.

[davidebbo]

Yes, it's a known issue, not related to Kudu but general to scm site. Please see this thread for details and workaround.

[drub0y]

Thanks @davidebbo. I even tried /basicauth and it wasn't working, but naturally as soon as I write this issue up I go back and try one more time with the Deployment credentials and it's working. I have _no_ clue what was going wrong with those, but it's working now, so... yay? :)

I guess the only remaining problem is that it doesn't just work with portal credentials and that's a bit of an issue because I'd like to be able to manage who can use Kudu via the Contributor role stuff in the portal. Is that something you guys are already tracking in an issue that I can follow or would you like me to open a specific issue about it?

[davidebbo]

A fix is on the way for this overall issue. But note that everything should work via deployment credentials. i.e. whoever you grant contributor access to will be able to use theirs.

[kemmis]

So why was this issue closed? It appears that this problem was never fixed, even though you've said almost 4 years ago that a fix is on the way. Is there a better solution to access kudu every time I have to download the publish profile, find the plain-text credentials inside it, and then manually type that into the basic auth popup box? This is problematic on so many levels.

[jcbrooks92]

The new ILB ASEs created using an API after February 2019 or if you create it in the portal now support SSO.

https://docs.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase#ilb-ases-made-before-may-2019

[jonarmstrong]

The new ILB ASEs created using an API after February 2019 or if you create it in the portal now support SSO.

https://docs.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase#ilb-ases-made-before-may-2019

I have issues getting the SSO login to work. The redirect after the SSO login doesn't take me back to the SCM site for the web app. If I use https://webappname.scm.ilbasename.appserviceenvironment.net/basicauth, the sign in with the publishing profile credentials works as expected.

e.g.

https://webappname.scm.ilbeasename.appserviceenvironment.net -> redirect to sso, complete sign in -> redirects to https://ilbasename.appserviceenvironment.net

[jcbrooks92]

You'll need to add a DNS entry for ilbasename.appserviceenvironment.net.

To configure your DNS:

create a zone for .appserviceenvironment.net
create an A record in that zone that points * to the ILB IP address
create a zone in .appserviceenvironment.net named scm
create an A record in the scm zone that points to the ILB IP address

https://docs.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase#dns-configuration

[jonarmstrong]

You'll need to add a DNS entry for ilbasename.appserviceenvironment.net.

To configure your DNS:
create a zone for .appserviceenvironment.net
create an A record in that zone that points * to the ILB IP address
create a zone in .appserviceenvironment.net named scm
create an A record in the scm zone that points to the ILB IP address

https://docs.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase#dns-configuration

What is lacking is that it doesn't call out that you need a 3rd DNS A record which points @ to the ILB IP Address in the zone. The zone can be created without a root record which points back to the ILB .

Thanks for the tip! It really helped!

[jcbrooks92]

My mistake, you're right that it doesn't specifically call it out. It looks like there are two open doc items regarding this confusion so I'm following up to see if we can get this fixed since its not intuitive.

https://github.com/MicrosoftDocs/azure-docs/issues/28508

[holgerjay]

Thanks @jonarmstrong, that helps a lot.

[siddhsc]

@jonarmstrong - Hi Jon, Can you please share the DNS zone settings you used to make this work?
I have tried adding the three DNS records, but the SSO login to SCM site still does not work. It works only if I have an entry for the scm in local hosts file on a vm in same vnet. So I may have missed something in the DNS zone setup.
This would be very helpful, as I am stuck with this setup and unable to find the proper solution.
Thanks in advance!

[siddhsc]

@jcbrooks92 - Hi Jeremy, Any idea when the Microsoft docs would be updated with the correct DNS setup instructions? It would be very helpful.

[jcbrooks92]

@siddhsc are you using private DNS zones? Its possible if everything is working correctly with the host file that your DNS zone is not configured properly. I would recommend a support case to investigate further since you have done some great isolation which will hopefully speed up resolution.

https://docs.microsoft.com/en-us/azure/dns/private-dns-overview

[holgerjay]

@siddhsc - I got this to work by creating the two zones as outlined in the documentation and following @jonarmstrong's recommendation :

• ase_name.appserviceenvironment.net
• scm.ase_name.appserviceenvironment.net
  Then added the following A records to each zone:

@ pointing to the ILB IP
* pointing to the ILB IP

(the @ might not be needed for the SCM zone actually but is needed for the ase zone)

I'm using bind dns server with my test environment, so this looks something like this for the ase zone:

$TTL    86400
@       IN      SOA     dns.ase_name.appserviceenvironment.net. root.ase_name.appserviceenvironment.net. (
                2014112511      ;Serial
                3600            ;Refresh
                1800            ;Retry
                604800          ;Expire
                86400 )         ;Minimum TTL
;Name Server Information
@       IN      NS      dns.ase_name.appserviceenvironment.net.
;IP address of Name Server
dns     IN      A       10.1.0.4
;IP address of ASE
@       IN      A       10.1.1.11
*       IN      A       10.1.1.11

The configuration for the SCM zone is similar.

[siddhsc]

Thanks a lot @jcbrooks92 and @holgerjay for your prompt response.
I had found a way around this issue in the meantime. Like Jeremy suggested it was an issue with my DNS zone configuration only. As local host file entry was working previously. Also I am using a Private DNS Zone.
I actually got it working through some trail and error while adding and removing few records in the DNS zone. Actually once it worked, I tried out many more combinations to see what is the minimum settings needed in this case. Tried with two zones and then with one.

Currently I have setup a single private dns zone with .appserviceenvironment.net.
In this zone, I currently have 3 records added:
A record for * pointing to ILB IP
A record for @ pointing to ILB IP
A record for *.scm pointing to ILB IP

Actually the third record is probably the one which I did not use correctly initially.

I think this is the minimum DNS zone configuration needed, based on my several tests today.

If any of you have other observations, please share.

Thanks once again for your prompt reponse and the suggestions. It was of great help! Cheers!

[suwatch]

This is how the setup that we used for testing. Probably same as what you described above.

[siddhsc]

Hi @suwatch , I suppose your settings are similar to mine. Can you indicate what setting you have in scm folder? That will help further in the comparison.

[suwatch]

Image below. Hope this helps.

[siddhsc]

Thanks @suwatch . I think it is similar configuration to what I have used. Hoping the Microsoft documentation will be updated soon to reflect the exact changes needed in DNS.