外部供应商请求将两台计算机加入我方AD Domain，此操作是否属常规做法？

Great question—this is definitely a scenario that can feel counterintuitive if you’re used to standard AD boundary practices, so let’s break this down clearly.

Why the Vendor Might See This as "Normal" #

From their perspective, this request might stem from practicality or past experience:

• Simplified identity integration: If their application relies on your AD users for authentication/authorization, adding their machines directly to your domain eliminates the need for complex cross-domain setups (like ADFS, SAML, or custom auth systems). It’s the quickest way to plug into your existing identity ecosystem.
• Dependency on your AD infrastructure: Their app might need access to your domain resources (file shares, SQL servers using AD auth) or require adherence to your group policies. Joining your domain removes the need to replicate these configurations on their own systems.
• Small vendor habit: Many niche vertical app providers don’t maintain their own robust AD environments. For them, embedding into a client’s domain is a default way to avoid managing separate identity and infrastructure layers.

Why This Feels Unusual to Your Team #

Your gut reaction that this is "not standard" is totally valid—here’s why:

• Critical security boundary risks: Adding external machines to your domain gives them full access to your AD’s identity fabric. If those vendor machines are compromised, attackers could use them as a foothold to pivot into your entire domain.
• Blurred operational responsibility: Who’s accountable for patching, securing, and maintaining those machines? If a vulnerability on their server leads to a breach, does your team take the blame? This creates messy compliance and liability gaps.
• Compliance conflicts: Most regulated industries (finance, healthcare, government) have strict rules about domain assets. External machines joining your domain could violate data protection policies or audit requirements.

Is This Actually a "Common" Practice? #

Short answer: It’s niche, not universal. This approach is only seen in very specific scenarios:

• You have an extremely high-trust, long-term partnership with the vendor (e.g., a managed service provider embedded deeply in your infrastructure).
• Your organization lacks the resources to implement proper cross-domain authentication, and the vendor is offering a quick-fix solution.

For most enterprises, this is not the default. The standard approach is to use cross-domain trusts (preferably one-way, where your domain trusts theirs but not vice versa) or federated identity systems (SAML/OIDC) to enable access without merging domain boundaries.

Recommended Next Steps #

If you want to move forward safely:

1. Dig into the vendor’s actual need: Ask them to clarify why they need to join your domain. Is it just auth? Access to specific resources? Understanding the root need will help you propose alternatives.
2. Push for safer alternatives: Suggest one-way external trusts, ADFS for cross-domain auth, or service accounts for their app to access your resources—all of which avoid the risk of adding external machines to your domain.
3. If you must approve it: Lock down the machines tightly:
   • Place them in a dedicated, isolated OU with strict group policies (disable local admin rights, restrict network access to only necessary resources, enable full audit logging).
   • Define clear SLAs for the vendor to maintain patch levels and security configurations.
   • Conduct regular vulnerability scans on these machines as part of your security routine.

内容的提问来源于stack exchange，提问作者user590028