如果我example.com的 DNS 后缀搜索列表中有内容，我打开浏览器并输入，www那么浏览器将与操作系统对话，操作系统再与 DNS 对话；如果www解析失败，我的操作系统将从我的后缀搜索列表中附加项目，直到成功为止；www.example.com如果成功，我就会得到一个将我的请求发送到的 IP。
但是，查看我的浏览器发送的请求，主机标头设置为，www因为这是地址栏中输入的内容，即使这不是最终解析为 IP 的 FQDN。这意味着，如果 Web 服务器使用主机名绑定，它必须监听www以及 FQDN www.example.com，否则它将无法识别该请求是它应该处理的请求。
是否有任何浏览器具有自动从操作系统获取已解析的 FQDN 的功能/是否有任何设置可以调整以启用此功能？如果没有这样的功能，是否有原因（例如，操作系统可能出于某种安全原因不公开已成功解析的 FQDN 的信息？），或者这种情况太小众以至于任何人都无法实现？
我有一个应用程序网关，我的后端设置配置了健康探测，允许状态 200-499 为健康（我之所以包含4xx系列代码，是因为某些解决方案的站点根目录返回 404，而其他路径下有内容，而某些站点会自动为未经授权的用户返回 403 / 我不希望这些影响后端健康状态 / 我希望我的解决方案尽可能通用，这样我就可以重复使用一系列站点上的相同设置，以尽量减少新站点加入时的工作量）。
但是，我的后端健康状况显示我的一个站点正在返回HTTP 463状态代码（因此后端仍然健康，但此响应是意外的）。此外，如果我导航到与此后端关联的侦听器的 URI，我会陷入 301 重定向到/来自同一站点。我确实配置了重定向：
/到/login.aspx。这使用相对路径，因此不受 AppGW 的主机名或前端与后端协议的影响。然而，即使我删除这些功能，仍然会得到相同的行为。
同一 AppGW 上的其他站点以相同的方式设置，但没有这个问题。
我有一个用于测试重定向的 PowerShell 脚本：Get-HttpUrlRedirects。如果我们假设配置为example.com，则运行的预期输出Get-HttpUrlRedirects -Url 'http://example.com' -Verbose将是：
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/login.aspx]
Url StatusCode
--- ----------
http://example.com/ 301
https://example.com/ 302
https://example/login.aspx 200
而实际输出是：
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
Url StatusCode
--- ----------
http://example.com/ 301
https://example.com/ 301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/ 301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/ 301
VERBOSE: Redirecting to [https://example.com/]
# etc - I hit ctrl + C to terminate when I see this loop occurring
如果父域的 DNS 服务器没有为子域提供 NS 记录，子域使用与父域不同的名称服务器是否有效？
例如：
Resolve-DnsName -Name example.com -Type NS -Server 1.1.1.1返回ns1.example.com；ns1.example.com的权威名称服务器也是如此example.com。Resolve-DnsName -Name subdomain.example.com -Type NS -Server 1.1.1.1返回ns2.example.com；ns2.example.com的权威名称服务器也是如此subdomain.example.com。我希望它ns1.example.com包含 NS 记录集，用于subdomain.example.com告诉客户端“我不管理此子域的 NS 记录，对于这些记录，请与其名称服务器交谈”。即我希望能Resolve-DnsName -Name subdomain.example.com -Type NS -Server ns1.example.com回来ns2.example.com。
注意：如果子域使用与其父域相同的 NS 服务器，我不会期望对上述内容做出回应。
（Resolve-DnsName只是一个nslookup命令，其中Name参数是要获取的 FQDN，Server是要查询的名称服务器，并Type允许我们指定我们要查找的 DNS 记录的类型）。
我的理解是否正确，或者子域可以与其父域拥有不同的名称服务器，而无需其父域托管子域的 NS 记录吗？
我们的 MS Dynamics 365 for Finance and Operations 存在间歇性问题，浏览实例的用户偶尔会看到以下错误：
The site can’t be reached
Check if there is a typo in EXAMPLE.operations.dynamics.com
If spellling is correct, try running Windows Networkk Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN
用户使用正确的 URI/主机名。
通常，此问题会在大约 30 分钟后自行解决。我们在生产（EXAMPLE.operations.dynamics.com和测试EXAMPLE.sandbox.operations.dynamics.com）中都看到了这一点。
经调查，如果我尝试使用我们的公司 DNS 服务解析 FQDN，则无法解析；确认浏览器的错误；但是当我们针对公共 DNS 服务（例如 CloudFlare 1.1.1.1）进行解析时，通常会正确解析。注意：我们还发现远程工作的用户（不使用我们公司的 DNS 服务）也有同样的问题/这里他们的 ISP 的 DNS 服务显示无法解析 FQDN。
我认为这个问题与 DNS 有关，并且 CloudFlare 的 DNS 通常更可靠，因为它们缓存 DNS 条目的时间更长（或者因为它们的服务器更频繁地受到攻击，这使得它们更有可能缓存条目）。
具体来说，当解析我们环境的 FQDN 时出现问题时，我通常可以根据 CloudFlare 的 DNS 和 MS 的该子域的权威名称服务器来解决它（如您所料）...但尝试获取该子域的权威名称服务器来自其父域的权威名称服务器的子域失败；例如，请参阅下面突出显示的 2 个错误：
这是我对 DNS 理解的问题（意味着问题的根本原因需要我们进行更多调查），还是 MS 实施的配置问题？
注意：我已就上述问题联系了 MS 支持，但支持 Dynamics 的团队是应用程序支持团队，因此无法协助解决 DNS/基础设施相关问题，也无法将我的票证转给可以提供帮助的团队。
当通过我们的 Exchange 365 服务发送邮件时，这些邮件可以成功通过，但如果我们查看邮件标头，我们会发现发件人和收件人位于我们的租户中，邮件实际上没有通过 SPF；而如果我们将邮件发送给第三方（例如 Gmail 地址），则 SPF 是正确的。
具体来说，我们看到内部发送的邮件显示为具有该ip6:2603:1000::/24范围内的 IP（例如2603:10a6:400:49::16...并且该 IP 未在spf.protection.outlook.com.
同样，当检查发送给第三方的邮件标头时，我们会看到邮件标头中包含 DKIM 选择器。对于发送到我们租户内其他邮箱的邮件，不存在此类标头。
其他人多年来一直在报告同样的情况。和其他人一样，我也曾与微软的支持人员交谈过，但这种情况对他们来说是不符合剧本的，所以这让我无处可去。
我的猜测是，当邮件在租户内时，MS 不关心 SPF/DKIM，因为他们知道这些邮件是有效的，所以他们不会过滤它们。但是，我找不到任何文档来确认这一点，这似乎是错误的（例如，如果您的邮件客户端有自己的逻辑来验证这些，它如何知道信任它们）。这是一个令人沮丧的问题，因为在调查真实的电子邮件问题时，很难判断未通过这些检查的邮件是否表明存在真正的问题，或者，由于有效的邮件也未通过这些检查，我们正在寻找错误的地方。
当通过Azure 门户创建新 VM 时，我们只能看到Datacenter Edition，但文档似乎明确表示这Standard Edition是 Azure 中的有效选项；尽管你必须为此创建自己的形象。
奇怪的是，既然支持标准版，却没有默认图像。这是否只是微软试图通过使该路径更方便来鼓励人们使用更昂贵的选项，或者是否有一些技术原因导致标准版不可用 OOTB（例如，虽然可以使用它，但是否存在重大限制，建议反对这个）？
在研究这个问题时，大多数帖子都会导致Hybrid Benefit，但我的理解是，此选项适用于拥有本地服务器的地方，允许您对 Azure VM 和本地设备使用相同的许可证；或者允许您使用之前购买的许可证，以避免再次为 Azure 中的许可证付费。我对此不感兴趣；而在直接在 Azure 中创建的新 VM 中，我们只需要标准版提供的功能，并且不想为我们不使用的功能支付更多费用。
在我们创建自己的Windows Server 2022 Standard Edition形象以避免这种额外成本之前，我希望了解是否有进一步的影响。
"The issuer of this certificate could not be found."我已经通过 AD 证书服务创建了一个证书，但尽管 PFX 中存在完整的链，但它还是出现错误。
我使用标准模板从我们组织的 AD 证书服务服务器创建了一个代码签名证书code signing，并导出创建的证书（带有可导出的私钥）。
尽管我们的根证书在所有公司设备上都受到信任，但我们在使用此证书签署代码时遇到了问题。
经过调查，如果我将 PFX 转换为 PEM（文件扩展名为.CER）并在文本编辑器中打开它，我可以看到 PEM 文件中列出的客户端、中间和根证书。但是，如果我双击此 CER 文件（即在 中打开它crypto shell extensions），证书路径选项卡仅显示客户端证书并将证书状态显示为"The issuer of this certificate could not be found."。
查看客户端的颁发者，它正确命名了中间证书。
如果我将中间证书和根证书从 PEM 文件复制到自己的证书中，将其另存为 .CER 并打开它，则中间证书和根证书会正确列出。客户端的与中间体的issuer完全匹配；issued to并且客户端的与中间体的issuer完全匹配。subject name
要将 PFX 转换为 PEM，我正在使用openssl.exe pkcs12 -in "mycert.pfx" -out "mycert.cer" -nokeys -passin "pass:mypassword"
如果将 Azure 防火墙的 DNS 代理与同一防火墙后面的内部 DNS 服务器一起使用，对外部 DNS 记录的请求会发生什么情况（即，这是否会导致无限循环，其中 DNS 服务器从公共 DNS 服务器请求记录，但此请求被FW并发送回内部DNS服务器）？
我们在 Azure 中有一个安全集线器/vwan，其中所有 vnet 间流量都通过防火墙，我们网络的所有入口和出口流量也是如此。
我们希望在防火墙上启用DNS 代理，以允许我们在规则中使用 FQDN。
我们也在我们的固件上指定了自定义 DNS 服务器（根据MS Docs 的屏幕截图，这似乎是可以接受的。在屏幕截图中，它们使用内部 IP 和 MS 的特殊168.63.129.16IP。对于我们来说，我们有 2 个域控制器的内部 IP ，并且这些设置是有条件转发到168.63.129.16那些我们拥有带有私有 DNS 区域的私有端点的域。
我担心的是，启用 DNS 代理后，由于从我们的 DC 到互联网的流量会经过此防火墙，它是否会拦截它们对公共 DNS 的查询并导致无限循环，从而导致任何对外部 DNS 信息的请求失败（一旦之前有任何请求）缓存条目过期）？
同样，对 168.63.129.16 的请求（通过条件转发器）是否也会被视为发送至互联网并因此被拦截？
文档中的屏幕截图意味着我们可以168.63.129.16在防火墙上添加 DNS 服务器...但这是否会被视为与其他 DNS 服务器的循环（即，对内部区域的请求有时会失败，因为不168.63.129.16知道我们的内部区域超出了 Azure 私有 dns 区域，但有时在访问我们的内部 DNS 服务器时会返回预期的响应），或者是否存在某种优先顺序，仅当168.63.129.16我们的内部 DNS 服务器没有记录时才会联系？
如果这种无限循环是可能的，那么正确的解决方法是什么？我们是否只是将来自 DC 的出站流量路由为下一跳0.0.0.0/0（这会影响所有流量，而不仅仅是端口 53），还是有更好的解决方案？
类型microsoft.authorization/roledefinitions可以通过 Azure 资源图使用吗？
我希望查询 Azure 资源图以获取具有特定权限的所有角色。环顾四周，我发现microsoft.authorization/roledefinitions这似乎是一个很好的起点；它记录在此处tables，并在/ 下列出，Azure Resource Graph Explorer双击它会添加看起来| where type == "microsoft.authorization/roledefinitions"很有希望的行。
但是，当我运行下面的 Kusto 时，这种类型不会显示：
Search-AzGraph -query @'
resources
| where type startswith "Microsoft.Aut"
| distinct type
'@
响应很简单：
type
----
microsoft.automation/automationaccounts
microsoft.automation/automationaccounts/runbooks
不过，我确实有权查看角色定义；因为运行Get-AzRoleDefinition会产生一个结果列表。
我还需要做些什么才能使这种类型通过 Kusto 可见吗？或者它根本还不能通过 ARG 获得？
我们注意到我们的人力资源系统存在一个问题，用户请求请假，此批准会发送给他们的经理，当他们的经理单击链接以批准它时，他们会看到一条错误消息，说明请假已获批准......这似乎是因为Outlook向HR系统的approval URI发送GET请求，以检查链接是否恶意；但在这样做时，它批准了员工的休假。注意：此 GET 请求甚至在电子邮件被预览之前发送/不是由收件人用户的任何操作触发。
人力资源系统是第三方，支持不力，所以他们无法证实我们对发生的事情的理论......但是，我已经通过从包含链接的外部电子邮件地址发送邮件进行测试我支持的网站（但不在 Outlook 的已验证域列表中）。查看我服务器上的日志，我看到在这封测试邮件到达我的邮件客户端后的片刻（我没有点击链接，甚至没有预览邮件的内容），果然一个 GET 请求出现在我的日志中，来自一个属于MS（根据 IP 上的 whois）。
这看起来很糟糕......但是我们与其他具有单击链接的系统一起工作（用于批准，以及许多包含unsubscribe链接或verify my email单击即可工作的链接/不需要手动跟进的电子邮件）和我们似乎没有类似的问题；在所有这些情况下，网站所有者似乎不太可能将与 SafeLinks 相关联的 MS IP 列入黑名单（尤其是好像它很容易绕过一样，恶意行为者也可以使用这种技巧来躲避安全链接保护）。
我在 Azure 的 Windows Server 2019 DataCenter 上的 IIS 10 中托管了一个 ASP.Net 站点。此站点仅启用了 Windows 身份验证。
当我直接访问该站点 ( http://mysite-backend.example.com ) 时，系统会提示我输入凭据，之后一切都按预期进行。当我通过 App Gateway（配置为私有 IP）（https://mysite.example.com）访问该站点时，系统会提示我输入凭据，然后再次提示我请求其他资源（托管在同一个服务器上）站点，对任何子文件夹没有特殊规则）。我反复收到提示，直到我单击取消，此时我在 Chrome 的网络日志中看到资源请求的 401。
我遇到此问题的资源之一是对favicon.png. 如果我直接访问该资源（https://mysite.example.com/favicon.png）一切正常，但是当我访问该站点的页面时，浏览器会将该资源作为页面资源的一部分发送，我看到了错误。这意味着该资源是可访问的；但是关于它在“交易”中的处理方式的一些事情引起了问题。
我尝试过使用不同的浏览器，包括全新安装/来自不同的客户端设备，以确保没有任何缓存导致问题。此外，我还Disable Cache检查了 F12 网络设置，以确保我在两个站点之间进行完整的请求/公平比较。
后端池只有 1 个节点。后端设置说使用后端池的主机名而不是前端的主机名——所以从网络服务器的角度来看，请求看起来很相似。
在 Web 服务器的安全事件日志中，我看到4625使用我的测试用户名登录失败（事件 ID）；确认请求正在使用正确的用户名发送到后端服务器（并且我一直非常小心以确保我始终输入正确的密码/已经做了很多次以消除人为错误的可能性/都尝试过使用并覆盖保存的密码）。如果我尝试太多次，我的测试帐户就会被锁定（即在 AD 中该lockedout属性设置为true）；之后所有请求都会收到 401 响应（可以理解）。
我检查了 App Gateway 日志以确认它没有阻止任何内容。我还为此站点设置了一个自定义 WAF 规则，并将其设置为detection only模式以确保它不会阻止请求；以防万一某些东西被阻止但没有记录。
我在后端服务器上启用了状态 401 的失败请求跟踪；显示 401 来自：
-MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName: IIS Web Core
Notification: AUTHENTICATE_REQUEST
HttpStatus: 401
HttpReason: Unauthorized
HttpSubStatus: 2
ErrorCode: Access is denied. (0x80070005)
ConfigExceptionInfo
注意：我在给定时间段内在同一设备上测试时，被阻止的资源（即获得 401 响应）通常是一致的；但如果我在不同的日子或在不同的设备上进行测试，我可能会看到不同的资源被阻止。我第一次在任何设备上进行测试（大部分情况下）时，我看到POST对页面的两个 xhr 请求/subfolder###/Search失败，然后在该设备上进行了几次测试后，其他资源似乎被污染了。这感觉就像它们是主要原因 - 但随后会导致会话出现问题。
我正在尝试访问后端站点的源代码，以更好地了解这些搜索端点在其中编码的内容，以了解这是否可能导致问题。
同时，非常感谢这里的任何人的任何想法......提前致谢。
更新：直接调用搜索端点也会导致 HTTP 200 / 有效响应：
$resp = Invoke-RestMethod -Method Post -Uri 'https://mySite.example.com/subfolder###/Search' -Form @{recordsToTake=25;recordsToSkip=0;sortColumn='CategorieName';sortDirection='Ascending'} -Credential $cred -StatusCodeVariable sc;"Status $sc";$resp
我们有一个包含 11 个包含的域；SPF 验证失败也是如此，因为它超出了限制。大多数查找都是针对第三方资源的，因此扁平化 SPF 记录并不理想；我们宁愿确保在第三方更新他们的记录时动态更新。
其中一个查找是我们尚未找到文档的遗留值；所以我们不确定它是否是必需的......我们在删除它之前会四处询问，但它是一家有很多死胡同和裂缝的大公司，需求所有者隐藏在其中，所以检查这些东西需要时间。
我们认为对于超过 10 次查找的记录来说，超过 10 次查找只是一个问题；即使总数更多，在此之前的所有值都应该成功。因此，如果我们可以将未知查找移到末尾，这将降低我们关心的事物受到影响的风险。
这个假设是否正确/当总共有 10 个以上的 SPF 查找时，前 10 个 SPF 查找是否有效？
如果是这样，第 11 条记录是什么 - 即查找是先计算广度，先计算深度，还是未指定因此取决于提供者？
防火墙能否通过检查传入请求来提高 SFTP 服务的安全性（例如，阻止仅使用 SFTP 时不需要的任何 SSH 命令？
我最近在我们的庄园里发现了一个虚拟机，它有一个公共 IP 用于向互联网公开 SFTP（即 SSH；不是 FTPS）和一个 HTTPS 服务。
我希望将网站放在 Azure App Gateway 后面，让它执行 SSL 卸载，然后通过 HTTP 在内部将请求路由到后端 VM。
由于 SFTP 和 HTTPS 服务共享相同的主机名，我必须在 Azure 防火墙上指出，然后将端口 22 上的请求路由到 VM，并将 80/443 上的请求路由到应用程序网关（80 上的请求只会得到一个HTTP 301 重定向到 HTTPS 端点；443 上的那些将被路由到后端，如上所述）。
由于我们在公众和虚拟机之间设置了防火墙，因此最好使用它来进一步提高安全性......它只会在端口 22 上转发到虚拟机，所以这是一个胜利（例如阻止 RDP），并且它为我们提供了诸如客户端 IP 白名单之类的选项（尽管对于我们不需要的用例，因为我们可以从任何地方获得合法连接）。
但是我想知道应用网关的防火墙是否有类似 OWASP 规则的东西用于 HTTP，它可以检查 SSH 流量并阻止任何看起来可疑的东西。
我的猜测是没有，因为 SSH 将使用只有 VM 和客户端知道的密钥的 RSA 加密；不是防火墙......但我没有深入研究 SFTP/SSH，所以可能有一些我没有想到的选项可以进一步提高解决方案的安全性？
我有一个运行自定义容器的 Azure 应用服务。当我将路径绑定到 Azure 文件共享时，我的容器停止工作。查看Container Issues日志，我看到错误：[BYOS] Custom storage volume(s) failed to initialize: [/var/LWASFiles/Sites/my-app/a3484543-39f9-45a3-816b-9524640dfd50].
我的自定义容器定义了一个卷/var/www/html/v3/uploads。
我正在尝试将其映射到 Azure 文件共享，该共享位于与托管 ASE 相同的 vnet 中的存储帐户上，规则允许 ASE 的子网与端口 137、138、138 和 445 上的文件共享之间的流量.
托管 ASE 配置有内部负载平衡器（即它是私有 ASE）。
存储帐户配置了专用终结点。
卷在应用服务的设置 > 配置 > 路径映射下映射，使用有效密钥和与容器上的卷路径匹配的装载路径。
在添加路径映射之前，应用服务按预期运行。
添加路径映射后，容器无法启动/我能找到的唯一异常信息来自Container Issues日志，根据上面的摘要。
如果我删除路径映射，问题仍然存在，即使在强制重启之后也是如此。解决此问题的唯一方法是删除并重新部署应用服务。
它通过专用终结点成功连接到 MySql DB（Azure Database for MySQL 服务器）。
使用dig {privateEndpointFqdn}我能够证明存储帐户的私有端点已正确解析（与 MySQL 一样；如您所料）
使用tcptraceroute {privateEndpointFqdn} {destinationPort}我能够证明我可以连接到端口 445 上的存储帐户（以及端口 3306 上的 MySQL 数据库）。
注意：我无法连接到端口 137、138 或 139 上的存储帐户，尽管通过 NSG 允许使用与上述 445 相同的入站和出站规则；尽管我怀疑 CIFS 不再需要这些端口（我只是在第一次遇到问题后才将这些端口作为以防万一的措施添加，以防它们在某些帖子中提到它们以某种方式相关）。
我通过 SSH 进入容器来运行上述测试，因此命令是从其上下文中运行的。注意：因为添加路径映射后无法启动容器，所以这些测试是在创建应用服务之后添加路径映射之前执行的。
我已经增加到WEBSITES_CONTAINER_START_TIME_LIMIT它的最大值：1800
我的容器暴露了 80 端口（即容器应用服务支持的默认端口之一）；并且网站在路径映射不存在时工作，所以这不应该是问题。我也设置WEBSITES_PORT为80，仅用于腰带和大括号。
WEBSITES_ENABLE_APP_SERVICE_STORAGE设置为false（尽管我也尝试将其设置为true，以防万一/它没有任何区别，所以我恢复为false）。
我的文件共享有几 GB 的数据。我已经尝试创建一个没有内容的相同文件共享并映射到该文件共享（在重新创建应用程序服务并证明它有效之后立即；以确保我的测试不受较大文件共享的后遗症的影响）。这给出了与较大文件共享相同的问题。
我的容器的映像是从 Azure 容器存储库加载的。
该图像基于ubuntu:21.04
我已经包含了azure-cli和cifs-utils包（我认为这仅在从容器执行挂载操作时才需要，而不是从 AppService 的配置中；但我想涵盖所有假设）
托管 ASE 位于该UK South区域中（存储帐户/所有资源也是如此）。
注意：这是我在 App Service 中运行容器的第一次体验；所以PEBKAC绝对是一种可能。
任何建议或故障排除建议将不胜感激。谢谢。
是否可以将动态通讯组配置为包含某个人的所有直接下属，以及递归的所有直接下属？
为了获得直接报告，我相信我们只是运行：
Set-DynamicDistributionGroup -Identity 'SomeManagersDirectReports' `
-RecipientFilter "((RecipientType -eq 'UserMailbox') -and (Manager -eq 'CN=SomeManager,OU=Users,DC=domain,DC=example,DC=com')"
但是要递归地获取经理、他们的直接下属和他们的报告，我能想到的唯一方法是运行类似下面的内容来生成成员列表，然后使用它来动态更新（静态）通讯组。
# very rough code to demo thinking... Haven't yet considered things like character escaping /
# circular loops / other fun things which may be found in the wild...
[string]$FirstPersonDn = 'CN=SomeManager,OU=Users,DC=domain,DC=example,DC=com'
[System.Collections.Generic.List[string]]$newMembers = [System.Collections.Generic.List[string]]::new()
[System.Collections.Generic.List[string]]$members = [System.Collections.Generic.List[string]]::new()
$newMembers.Add($FirstPersonDn)
while ($newMembers.Count) {
$members.Add($newMembers)
$newMembers = $newMembers | %{Get-AdUser $_ -properties DirectReports} | % DirectReports
}
Update-DistributionGroupMember -Identity 'SomeManagerAndTheirReportsRecusive' -Members $members
在应用程序网关上添加第二个多站点 HTTPS 侦听器时，出现以下异常：
无法将配置更改保存到应用程序网关“MyAppGateway”。错误：必须为应用程序网关中的证书 'MyResourceGroup/providers/Microsoft.Network/applicationGateways/MyAppGateway/sslCertificates/myCertificateName'>MyAppGateway/myCertificateName' 指定 Data 或 KeyVaultSecretId。
无论我是为两个侦听器使用相同的证书（SAN 列表涵盖不同的域），还是为每个侦听器配置单独的证书，都会发生此错误。
一旦遇到此错误，我就无法以任何方式更新应用程序网关/唯一的解决方法似乎是删除它。
这是一个已知问题，还是我做错了什么？我正在按照此处描述的步骤进行操作；只有我对初始 SSL 证书使用自签名证书（即，而不是让 LetsEncrypt 颁发初始证书/因为它无论如何都会被覆盖）。当我为单个站点执行此 POC 时，一切都按预期工作；所以这个问题似乎与我对多站点功能的使用有关（即有不同的 FQDN 指向应用程序网关的共享公共 IP，然后根据主机标头值将请求路由到不同的后端）。
我正在寻找使用基础架构即代码创建许多 Azure 策略。
MS 文档建议的结构如下：
.
|
|- policies/ ________________________ # Root folder for policy resources
| |- policy1/ ______________________ # Subfolder for a policy
| |- policy.json _________________ # Policy definition
| |- policy.parameters.json ______ # Policy definition of parameters
| |- policy.rules.json ___________ # Policy rule
| |- assign.<name1>.json _________ # Assignment 1 for this policy definition
| |- assign.<name2>.json _________ # Assignment 2 for this policy definition
| |- policy2/ ______________________ # Subfolder for a policy
| |- policy.json _________________ # Policy definition
| |- policy.parameters.json ______ # Policy definition of parameters
| |- policy.rules.json ___________ # Policy rule
| |- assign.<name1>.json _________ # Assignment 1 for this policy definition
| |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|
这是有道理的，但我见过的所有策略定义示例都包括参数定义；policy.parameters.json所以如果只是复制信息，我看不到拥有单独文件的价值。
有没有办法避免这种重复？例如，通过让policy.json文件引用policy.parameters.json文件而不是复制其内容，或者通过这种复制是否增加了一些价值？
（规则文件也会出现同样的情况；我假设该部分的答案是相同的......）
从 Azure 社区策略存储库：
策略文件包括以下几行：
"parameters": {
"tagName": {
"type": "String",
"defaultValue": "DateCreated",
"metadata": {
"displayName": "Tag Name",
"description": "Name of the tag, such as 'Date'"
}
}
}
参数文件完全复制了在上面的参数部分找到的内容（几乎；在这种情况下，描述略有不同，但这感觉像是一个错误而不是一个理由）：
{
"tagName": {
"type": "String",
"defaultValue": "DateCreated",
"metadata": {
"displayName": "Tag Name",
"description": "Name of the tag, such as 'DateCreated'"
}
}
}
为什么 NetBios 过滤会影响 SMB3/连接到端口 445 的能力？
一些用户（包括我自己）在从其家庭连接访问托管在 Azure Files 中的文件共享时遇到问题，收到以下错误。
Windows 无法访问 \myStorageAccount.file.core.windows.net\my-share\
检查名称的拼写。否则，您的网络可能有问题。要尝试识别和解决网络问题，请单击诊断。
错误代码：0x80070035
找不到网络路径
运行在线端口测试myStorageAccount.file.core.windows.net显示端口 445 已打开。
从我的本地机器运行Test-NetConnection -ComputerName 'myStorageAccountName.file.core.windows.net' -port 445会失败；尽管我的本地设备的防火墙软件没有阻止连接。
最终我发现原因出NetBios filter在我的路由器上；启用此功能后，与 Azure 文件共享上的端口 445 的连接失败；禁用它所有工作。
我的路由器文档还提到此过滤器会影响 SMB：
启用 NetBIOS 过滤器
出于安全原因，FRITZ!Box 中的 NetBIOS 过滤器默认开启。它会阻止 NetBIOS 数据包，这些数据包通常不需要在 Internet 中进行通信。仅当您使用必须与 Internet 交换 NetBIOS 数据包的应用程序时才禁用此过滤器。例如，SMB 访问 Strato HiDrive 就是这种情况。
我不确定这是否归结为路由器过滤逻辑中的一些错误，或者是否还有更多事情发生。
如果相关，我们启用了 RBAC 过滤（例如，我的帐户Storage File Data SMB Share Elevated Contributor分配了角色），并在我们的文件共享上启用了 AD ACLS（如John Savill 视频中所述）......尽管我认为那些不应该用于简单的端口测试？
我们希望提高活动目录中数据的标准化和质量。在这样做时，我们发现 ; 的格式不一致distinguishedName。CN特别是本身的格式。我们通常在一个法律实体（顶级 OU）内具有合理的（尽管从未 100%）一致性，但在这些实体中，使用了各种格式。最常见的是：
GivenName + ' ' + Surname例如“约翰·贝文”Surname + ', ' + GivenName 例如“贝文，约翰”string.ToUpper(SURNAME) + ' ' + GivenName例如“贝文约翰”sAmAccountName例如“ukjlb023”关于什么是好的格式，或者在做出这个决定时需要考虑的因素，是否有任何指导方针？
givenName您必须将附加值附加到许多条目以避免除了最稀有名称之外的所有条目的冲突）。Surname + ', ' + GivenName包含一个逗号，它是 中的一个特殊字符DN，因此必须进行转义。通过避免 CN 中的特殊字符，我们从而限制了软件/查询/脚本中的错误的影响（这样做还有一个缺点，因为这些错误更容易被忽视）。givenName放在第一位会有一些小的性能优势。John \"JB\" Bevan（在 DN 中需要转义字符，但在 CN 中不需要）。我的假设是正确的，还是其中任何一个只是过度思考问题/解决方法？
还有其他需要考虑的因素吗？
注意：有一个相关的问题：https ://stackoverflow.com/questions/7814569/what-do-people-use-for-cn-with-inetorgperson-in-ldap-directories - 虽然这集中在“如何避免碰撞”讨论的一部分。
我正在尝试使用远程桌面登录到托管在 Azure 中的 Dynamics 365 AOS 服务器，使用环境的LCS页面上显示的RDP 文件和凭据。
Dynamics 365 AOS 服务器是一个Windows Server 2016 Datacenter Edition盒子。
当通过Windows Server 2012 R2服务器访问它时（即 RDPing 到服务器上，然后从 LCS 下载 DFO365 RDP 文件到该机器上并在“代理”服务器上运行 RDP 客户端）一切正常，但尝试直接从我的Windows 7 SP1机器访问失败。一位也在跑步的同事Windows 7 SP1遇到了完全相同的问题。
我的公共 IP（即通过访问WhatsMyIp可以看到）被列入 RDP 白名单（通过 LCS Maintain> Enable Access）。
直到上周中旬，我自己和我的同事都能够在此 VM 上进行 RDP。
通过“代理”服务器，我能够查看远程 Dynamics 365 AOS 服务器上的事件日志。查看Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational事件日志，我可以看到我的连接尝试命中此服务器，因为有警告消息指出：The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP:123.45.67.89) has been disconnected.（其中123.45.67.89与我的公共 IP 地址匹配）。警告两侧还有其他几个信息事件：
The server accepted a new TCP connection from client 123.45.67.89:58177.Connection RDP-Tcp#4 createdInterface method called: PrepareForAcceptInterface method called: SendPolicyDataPerfCounter session started with instance ID 4The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP:123.45.67.89) has been disconnected.Interface method called: OnDisconnectedThe server has terminated main RDP connection with the client.During this connection, server has not sent data or graphics update for 0 seconds (Idle1: 0, Idle2: 0).Channel rdpinpt has been closed between the server and the client on transport tunnel: 0.Channel rdpcmd has been closed between the server and the client on transport tunnel: 0.Channel rdplic has been closed between the server and the client on transport tunnel: 0.The disconnect reason is 14这些事件重复 3 次，意味着 MSTSC 在报告失败之前进行了 3 次连接尝试。
环顾网络，我看到提到了一些证书和关键问题。我注意到有 120,078 个文件C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys，包括一个开头的 f686aace6942fb7f7ceb231212eef4a4_ ( TSSecKeySet1 )。不过，我没有尝试删除或修改任何这些，因为不知道会产生什么影响/没有看到任何解释为什么这些修复应该起作用。我的直觉是该目录中的大量文件可能与该问题有关。
有谁知道什么可能会阻止这些连接尝试/允许连接通过需要什么？
我们在 Windows 2008 R2 服务器上有一些应用程序，通过 RemoteApp 提供，通过来自 TS-Web 的链接。这些应用程序多年来一直以这种方式运行（我认为大约 8 年）。
我们的一个用户在登录时遇到问题，它在“配置远程会话”阶段挂了几分钟，然后没有解释/错误等退出。我们已经完成了所有明显的修复（禁用位图缓存，删除本地缓存，确保低分辨率，删除她的配置文件，检查没有 TS 服务器保存她的配置文件的副本，检查防火墙是否关闭或有所需的例外等，但没有任何乐趣。我们还确认该问题仅发生在她的帐户在她的机器上的独特组合。
由于我们有一个服务器场，并且登录需要几分钟，所以我还没有能够及时捕获她使用 procmon 的登录尝试以获取线索......
为了更深入地挖掘（并避免更换或重建她的整个机器的不雅解决方案），我想了解更多关于幕后发生的事情......
在 RDP 连接期间会发生什么；即当系统说configuring remote session，实际发生了什么（也对其他阶段感兴趣；尽管只是出于学术原因）？
是否创建了任何可能为故障提供线索的日志/您是否需要在某处启用此日志记录？注意：我检查了事件日志，但目前看不出她（失败）的尝试与任何其他用户的尝试没有区别。