我们有一个网络应用程序,我们正在从Azure经典云服务过渡到App Service Web应用程序。经典的云服务是在包含我们的域控制器(常规AD,而不是Azure AD)的vnet上。 App服务使用VNET集成,因此它连接到我们的vnet,因此连接到DC(主要通过客户端VPN)。
当我们运行在Web应用程序中创建新AD的代码时,用户已成功创建,但只要我们尝试更改任何内容 - 设置密码,添加到组等,我们就会
"访问被拒绝。 (HRESULT异常:0x80070005(E_ACCESSDENIED))"
我们用来创建和编辑帐户的用户可以在云服务中正常运行,因此它不是AD权限问题。
为了尝试简化调试,我写了一些Powershell,我可以在Kudu控制台中运行,看看我是否可以捕获错误:
$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服务的错误。
我们可以成功创建用户的事实证明ldap连接可以正常工作,但是除了我之外,为什么设置密码会导致访问被拒绝错误。
答案 0 :(得分:0)
在这个问题上,我曾与Microsoft进行过工程级通话。简而言之,出于安全原因,某些类型的调用在应用程序服务中受到限制。对SetPassword的调用就是其中之一。 这不是错误,而是应用程序服务产品经理的故意设计决定。
如果从虚拟机执行这些命令,则可以运行它们。那就是我们最终要做的。我们使用内部负载均衡器在可用性集中启动虚拟机。我们部署了一个很小的具有安全性的.Net Core API,它除了为我们进行LDAP调用外什么也不做。 这不是一个非常优雅的解决方案,但是可以。