问题描述
我们有一个Web应用程序，正在从Azure经典云服务过渡到App Service Web应用程序。经典的云服务位于包含域控制器（常规AD，不是Azure AD）的vnet上。 App服务使用VNET集成，因此它连接到我们的vnet，因此也连接到了DC（主要是通过客户端vpn）。
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).
当我们运行创建新代码的代码时在Web应用程序中创建AD，成功创建了用户，但是只要我们尝试更改任何内容-设置密码，添加到组等，我们都会得到
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
访问被拒绝。（来自HRESULT的异常：0x80070005（E_ACCESSDENIED））
"Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"
我们用来创建和编辑帐户的用户可以通过云服务正常工作，因此它不是AD权限问题。
The user we're using to create and edit the account works fine from the cloud service, so its not an AD permissions problem.
为了简化调试，我编写了一些可以在Kudu控制台中运行的Powershell，以查看是否可以捕获错误： / p>
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
此代码在我的本地计算机上运行良好，并连接到与App Service相同的DC，并且它可以从一个云服务角色实例上的Powershell控制台正常运行，但是来自App服务的错误。
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.
我们可以成功创建用户的事实证明ldap连接有效，但我无法设置密码为什么会导致拒绝访问错误。
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.
推荐答案
我在此方面与Microsoft进行了工程级别的通话学科。简而言之，出于安全原因，某些类型的调用在应用程序服务中受到限制。对SetPassword的调用就是其中之一。
这不是错误，而是应用程序服务产品经理的蓄意设计决定。
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.
如果从虚拟机执行这些命令，则可以运行这些命令。这就是我们最终要做的。我们使用内部负载均衡器在可用性集中启动虚拟机。我们部署了一个很小的.Net Core API，它具有安全性，除了为我们进行LDAP调用外，什么也不做。
不是一个非常优雅的解决方案，但是它可以工作。
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.
这篇关于Azure应用服务Active Directory身份验证访问被拒绝的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！