Azure App Service Active Directory Authentication Access Denied

We have a web app that we are transitioning from a Azure classic cloud service to an App Service web app. The classic cloud service was on a vnet that contained our domain controllers (regular AD, NOT Azure AD). The App service uses VNET Integration so it is connected to our vnet, and therefore DCs,(essentially via a client vpn).

When we run the code that creates a new AD in the web app, the user is created successfully, but as soon as we try to change anything - set the password, add to a group etc, we get

"Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"

The user we're using to create and edit the account works fine from the cloud service, so its not an AD permissions problem.

To try to simplify debugging, I wrote some Powershell that I could run in the Kudu console to see if I could trap the error:

$DomainControllerIpAddress = "< domain controller IP>"
$domain   = "<domain name>"


$BaseDN=  "LDAP://$($DomainControllerIpAddress)"
$domAdmin = "domain\adminaccount"
$domPass  = "<password>"

$userdn = "CN=TestUser,OU=TestOU,OU=ParentOU,DC=domain,DC=local"

$pass = "<newuserpassword>"

$userobj = New-Object System.DirectoryServices.DirectoryEntry($basedn + "/" + $userdn), $domAdmin, $domPass

$userobj.AuthenticationType = @("Secure","Sealing") # adding this to try to force kerberos makes no difference

$userobj.Invoke("SetPassword",$pass) # this fails in the App service but works fine everywhere else

This code runs fine from my local machine connecting to the same DC as the App Service, and it runs fine from a powershell console on one the the cloud service role instances, but errors from the App service.

The fact we can create the user successfully proves ldap connectivity works, but its beyond me why setting the password gives an access denied error.

I had a engineering level call with Microsoft on this subject. In a nutshell, certain kinds of calls are restricted in app services "for security reasons". The call to SetPassword is one of them. This is not a bug but a deliberate design decision by the app service product managers.

You can run these command if you execute them from a virtual machine. That's what we ended up doing. We spun up VM in an availability set with an internal load balancer. We deployed a very small .Net Core API with security that does nothing but make the LDAP calls for us. Not a very elegant solution but it works.