Active Directory Architecture and Management Questions

Direct answer

Stop using one account for two jobs and stop letting privileged credentials touch low-trust machines. The organizing idea is tiers: Tier 0 is whatever controls Active Directory (domain controllers and Domain Admins), Tier 1 is servers, Tier 2 is workstations, and a higher tier's credentials never sign in to a lower tier. Give every administrator a standard account for email and browsing and separate administrative accounts for administration. Confine the accounts that control Active Directory (AD) to hardened privileged access workstations (PAWs, locked-down PCs used only for administration) and to domain controllers (DCs), and enforce that with logon restrictions, the Protected Users group and authentication policy silos. Randomize local administrator passwords with Windows LAPS (Local Administrator Password Solution), keep break-glass credentials (emergency administrator accounts used only when the normal ones fail) in a vault with check-out, make elevation temporary where tooling allows, and alert on the events that show the model being bypassed. Roll it out gradually, starting with the smallest group of accounts that controls the whole directory. Steps 1 to 3 below need only accounts and Group Policy you already have; steps 4 to 8 add one control each and can follow as the pilot succeeds.

The model

Microsoft's current guidance is the enterprise access model, which builds on the older AD tier model. In the tier model, Tier 0 (accounts and systems that control AD, such as DCs and Domain Admins) must never expose credentials to Tier 1 (servers) or Tier 2 (workstations), because a compromised lower tier would otherwise yield the keys to the top. The enterprise access model expands Tier 0 into a control plane, splits Tier 1 into a management plane and a data and workload plane, and splits Tier 2 into user access and application access. For an on-premises AD redesign, the three-tier view is still the working picture for who may sign in where.

Steps, in order

1. Inventory who holds privilege. List members of Domain Admins, Enterprise Admins and Schema Admins with Get-ADGroupMember -Identity 'Domain Admins' -Recursive, and find protected accounts with Get-ADUser -LDAPFilter '(admincount=1)'. Find services running as Domain Admins and replace them with accounts scoped to one job (for example group managed service accounts, or gMSAs: service accounts whose long random password Windows rotates automatically).
2. Split accounts. Each administrator gets a standard account, plus an administrative account for each tier they truly operate. Only Tier 0 accounts are in Domain Admins, and only a few people need one.
3. Block credential exposure with user rights. In Group Policy on Tier 1 and Tier 2 machines, add the Tier 0 administrator group to Deny log on locally (and the matching deny rights for Remote Desktop and network access). Deny log on locally takes precedence over Allow log on locally.
4. Protected Users for human Tier 0 accounts. Members cannot use NTLM (an older challenge-response sign-in protocol), cannot use DES or RC4 (older encryption types) in Kerberos, only AES (the modern encryption type), cannot be delegated, and cannot renew a TGT (ticket-granting ticket) beyond a 4 hour lifetime. Requirements: domain functional level Windows Server 2012 R2 or later. Never add service or computer accounts. Test with a pilot administrator first, because highly privileged members face the same restrictions and can be locked out, for example when an account has no AES keys until its password is reset.
5. Authentication policy silos to limit where Tier 0 accounts can sign in. A silo is a container of accounts with a policy attached. For example, the policy can say that a Tier 0 account may sign in only from domain controllers and the administrative consoles; a password or smart-card sign-in from any other computer then fails. Start unenforced: in audit mode the DC writes events without blocking anything, so you can see who would break. Event 305 means a Kerberos TGT request would have been denied because the device did not meet the policy, and 306 means a service ticket would have been denied. They appear in the AuthenticationPolicyFailures-DomainController log under Applications and Services Logs, Microsoft, Windows, Authentication, which is disabled by default and must be enabled first.
6. Windows LAPS so no two machines share a local administrator password. It rotates the password, stores it in AD (it can be encrypted, which needs domain functional level 2016 or later) and lets authorized staff read it. Setup is Update-LapsADSchema once per forest (adds the attributes that hold the password), Set-LapsADComputerSelfPermission on the OU (lets each computer write its own password), Set-LapsADReadPasswordPermission for the groups allowed to read, and Get-LapsADPassword to retrieve.
7. Vault and just-in-time. Store break-glass accounts in a vault with check-out and dual approval. Use a privileged access management tool for time-boxed elevation so nobody holds standing membership.
8. Monitor. Alert on any addition to protected groups, on any Tier 0 sign-in from a non-Tier 0 host, and on password resets of high-value accounts (event 4724). The silo audit-mode events (305 and 306, step 5) show what enforcement would block. Protected Users has no audit mode: its restrictions apply as soon as an account joins the group, and the ProtectedUserFailures-DomainController log (under the same Authentication log folder, disabled by default, so enable it first) records the sign-ins that were refused.

Worked example

An organization has 40 administrators, all working daily with Domain Admins accounts. Of them, 6 run AD, 20 run servers and 14 run desktops.

• Standard accounts: 40.
• Tier 0 accounts: 6. Tier 1 accounts: 20. Tier 2 accounts: 14.
• Administrative accounts: 6 + 20 + 14 = 40. Total accounts: 40 + 40 = 80.
• Domain Admins membership drops from 40 to 6 standing members, and to zero standing members once just-in-time elevation is in place, apart from the vaulted break-glass accounts.
  One administrator, Priya (illustrative names), shows the change. Before: priya, a Domain Admins member, used for email, browsing and server sign-in. After: priya (standard account, email and browsing only) and priya-t1 (she is one of the 20 server administrators, so this account administers servers and is not in Domain Admins). A Tier 0 administrator would instead hold one Tier 0 account such as maria-t0 (Domain Admins, signs in only from the privileged workstation), which is how each of the 40 administrators holds exactly one administrative account here and the total stays at 80. An administrator who genuinely works in two tiers needs one account per tier, and the count rises by one for each.

The cost is 40 more accounts to manage and a workstation for the 6 Tier 0 administrators; the benefit is that a phished desktop session no longer contains a Domain Admins credential.

Trade-offs and pitfalls

• Protected Users and silos can lock out the very administrators you are protecting. Pilot with two people, keep a vaulted break-glass account that is excluded from the restrictions, and test sign-in to a DC after each step.
• Service accounts in Domain Admins break when you enforce restrictions. Find them in step 1, before enforcing.
• PAWs and separate accounts add friction. Pay for it with automation (LAPS, vault check-out) so the secure path is also the easy path.
• LAPS password encryption needs domain functional level 2016 or later. Below that, passwords are stored in clear text and protected only by AD permissions, so plan the functional level before relying on it. Enroll every machine, because an unmanaged one still shares a password.

What would flip the plan: in a small environment with 3 administrators, skip silos at first and do steps 1 to 4 and 6, because the cost of silo operation exceeds the risk reduction at that size.

Direct answer

Delegate by function, to groups, on OUs, with the narrowest rights that do the job. An organizational unit (OU) is a container in the directory that holds accounts. Helpdesk gets Reset Password (an extended right: a named special permission for one action, rather than a plain attribute read or write) and write access to two attributes (lockoutTime for unlock, pwdLastSet for forcing a change at next sign-in), inherited only by user objects in the OU that holds ordinary staff. Server operations get create, delete, reset and property rights on computer objects in the server OUs only, and no right to change permissions. Domain Admins keep the rights they already have, because the design only adds access control list (ACL) entries and never removes or blocks inherited ones. Privileged accounts are protected from the helpdesk by the AdminSDHolder mechanism (explained in the section on why helpdesk cannot touch privileged accounts) and by keeping them out of the delegated OU. Verify with an ACL export, a negative test matrix, and auditing.

Terms: an access control entry (ACE) is one allow or deny rule inside an ACL. Delegation here means granting ACEs on an OU. The Delegation of Control Wizard in Active Directory Users and Computers creates the same ACEs that dsacls shows.

Structure

• Groups: GG-Helpdesk and GG-ServerOps (global groups, hence GG), both holding people through a role-based process.
• OU=Staff,DC=corp,DC=example holds ordinary user accounts.
• OU=Servers,DC=corp,DC=example holds server computer accounts.
• Administrator accounts live in a separate OU that has no helpdesk ACEs.

The ACEs

Reading the permission letters (from the dsacls reference; letters are concatenated with no spaces, so CCDC is CC plus DC):

The dsacls permission statement is principal:permissions;object-type-or-property;inherited-object-type. An ACE set on a container is inherited by objects inside it unless blocked: /I:S means child objects only, /I:T (the default) means the object and its children, and the inherited-object-type part (;user) limits inheritance to that object class.

That is 3 ACEs for helpdesk and 3 for server operations. Row 4 uses the default /I:T because creating and deleting children is a permission on the container itself. No row includes WD (change security information) or WO (change owner), so neither group can grant itself more.

Optional explicit deny entries, as a guard against a later over-broad grant. A deny overrides an allow, so keep them few and document them:

dsacls "DC=corp,DC=example" /I:S /D "CORP\GG-Helpdesk:SDDT;;user"
dsacls "DC=corp,DC=example" /I:S /D "CORP\GG-Helpdesk:WP;member;group"

The first denies helpdesk deleting user objects (SD deletes an object, DT deletes an object with its children). The second denies writing the member attribute of groups, which stops helpdesk adding anyone to any group. Test them before relying on them, because a deny at the domain root also blocks any legitimate group-membership rights you grant helpdesk later.

Why helpdesk cannot touch privileged accounts

The AdminSDHolder object (CN=AdminSDHolder,CN=System in the domain) holds a template ACL for protected accounts, meaning members of groups such as Domain Admins. Microsoft's list of protected accounts and groups also includes Account Operators, Backup Operators, Print Operators and Server Operators, among others, so members of those groups are out of the helpdesk's reach too. The Security Descriptor Propagator (SDProp) is a background task that copies that template onto each protected account, switches off inheritance on it and sets its adminCount attribute to 1 (a marker meaning the account is protected). So an ACE that OU=Staff would normally pass down never reaches a protected account: its ACL is replaced by the template, which has no helpdesk entry. SDProp runs on the DC that holds the PDC emulator role, by default every 60 minutes. Two caveats:

• There can be up to 60 minutes between adding someone to a protected group and the ACL reset. Move administrators out of delegated OUs when you promote them.
• After removal from a protected group the account keeps adminCount = 1 and its locked-down ACL, so former administrators stay unreachable by helpdesk until someone cleans them up deliberately.

Do not block inheritance on the delegated OUs, because that would drop the Domain Admins and SYSTEM entries.

Verification

1. Export the ACLs. dsacls "OU=Staff,DC=corp,DC=example" with no other parameters lists the ACEs. Save the output before and after, and diff it. Expect exactly the 3 helpdesk entries added. Illustrative, abridged output (layout varies by Windows version; look for the principal, the property or right named after SPECIAL ACCESS for, and the READ PROPERTY, WRITE PROPERTY or CONTROL ACCESS lines under it):

Access list:
Allow CORP\GG-Helpdesk
                    SPECIAL ACCESS for lockoutTime
                                       READ PROPERTY
                                       WRITE PROPERTY
Allow CORP\GG-Helpdesk
                    SPECIAL ACCESS for pwdLastSet
                                       READ PROPERTY
                                       WRITE PROPERTY
Allow CORP\GG-Helpdesk
                    SPECIAL ACCESS for Reset Password
                                       CONTROL ACCESS

Those three blocks are the three helpdesk ACEs (rows 1 to 3 of the table), and no block contains Change security information or Change owner.
2. Negative tests with a test account in each group:

That is 6 actions for 2 groups, 12 results, of which 3 are Allowed and 9 are Denied. Any other pattern means an ACE is missing or too broad.
3. Audit. Turn on the Audit User Account Management subcategory. Event 4724 shows each reset with the Subject (who) and Target Account, and event 4738 shows user changes. Alert on any 4724 whose target is a protected account, and review all resets against the helpdesk ticket queue.
4. Procedures. Helpdesk verifies identity before every reset, uses a one-time password, and the membership of both groups is reviewed on a schedule, because the technical delegation is only as good as who sits in the groups.

Trade-offs and pitfalls

• Delegating to individuals, or to broad groups such as Account Operators, is hard to review. Use dedicated groups and keep the ACE list short enough to read.
• Generic All (GA) on computers is faster to write but includes the right to change permissions, so it lets server operators escalate. The explicit list above does not.
• A deny at a high level is powerful and hard to debug. Prefer not granting a right over denying it, and keep denies as a documented backstop.

Direct answer

Build it on Microsoft Entra self-service password reset (SSPR: the user proves who they are in the cloud and picks a new password without calling the help desk) with password writeback, which carries the new password back to on-premises Active Directory (AD, the Windows directory that holds the user accounts). Verify users with two registered authentication methods, write the password back through an outbound-only encrypted channel to an agent that calls AD's own set-password API (so AD's password rules still apply), and stop social engineering by protecting the registration step, keeping privileged accounts out of the self-service path, and notifying people about every reset.

The picture

In a hybrid directory each person has two linked accounts: a cloud account in Microsoft Entra ID (Microsoft's cloud directory) and an on-premises account in AD, matched by the sync service. SSPR changes the password on the cloud account. Writeback is the step that makes the same change on the on-premises account, so the person ends up with one password that works in both places.

Design

How users are verified

1. Set the number of methods required to reset to two (the setting accepts one or two).
2. The methods SSPR supports are Microsoft Authenticator notifications, hardware or software OATH tokens (devices or apps that generate one-time codes), SMS, voice call and email one-time passcode. Authenticator cannot be the only method when one is required, and when two are required enable at least two further methods beside it.
3. Turn on Require users to register when signing in so nobody stays unregistered, and set the reconfirmation interval (0 to 730 days, where 0 means never) to something like 180 days so stale phone numbers are caught.
4. Do not build a path that depends on facts an attacker can look up (birthplace, school). Administrator accounts are even stricter: a two-gate policy that prohibits security questions applies to them automatically.

How the password reaches AD

1. The user submits the new password. It is encrypted with a public key created at setup and sent over HTTPS to a tenant-specific Azure Service Bus relay (a cloud message relay protected by a randomly generated password that only your on-premises installation knows).

2. The on-premises agent already holds an outbound connection, so no inbound firewall rule is needed; all traffic is outbound on port 443. It decrypts the message and finds the user through the cloudAnchor attribute (the attribute the sync engine uses to link a cloud user back to its on-premises object).

3. It calls the AD DS SetPassword API, so the on-premises history, complexity, age and password-filter rules (extra rules that password-filter software adds on the DCs) are enforced and the user gets an immediate answer. If the writeback service is down the user is told the reset cannot be done right now, and an undelivered message expires after several minutes.

4. The AD account used by Entra Connect needs: Reset password, Change password, write on lockoutTime, write on pwdLastSet (all applied to descendant user objects) and the extended right Unexpire Password on the root of each domain. Set the domain policy Minimum password age to 0 if users may reset more than once a day. Permission changes can take an hour or more to replicate.

   Why each right is there. Microsoft's tutorial lists these rights without a reason per line; in plain terms: Reset password lets the account set a new password without knowing the old one, which is what an SSPR reset is. Change password covers a change where the user supplies the old password. Write on lockoutTime (the attribute AD uses to hold an account's locked-out state) is what lets the option Allow users to unlock accounts without resetting their password clear a lockout. Write on pwdLastSet (the attribute that records when the password was last set) and the Unexpire Password right let a reset mark the password as freshly set, so an account whose old password had expired is not still treated as expired. Minimum password age of 0 matters because a nonzero age would refuse a second reset inside that window.

Four controls against social engineering

How the protected-group limit works. Microsoft's note says the writeback service account cannot change passwords for members of protected groups (for example Domain Admins, Enterprise Admins, Schema Admins, Administrators and Account Operators; the full list is in Microsoft's protected-accounts appendix). The mechanism is AdminSDHolder, an object that holds the template permissions for protected accounts and groups. A process called SDProp runs every 60 minutes by default on the PDC emulator and resets the permissions on every protected account to match that template, and inheritance is switched off on protected accounts. So the rights you granted the writeback account at the top of the domain never reach those accounts. Administrators can still change their password in the cloud, but cannot use writeback to reset a forgotten on-premises one.

Worked example

Priya forgets her password. She opens the SSPR page, answers a captcha, approves an Authenticator notification and enters a code from her OATH token (two methods). She types a new password. AD checks it against its policy; if it fails the policy she is told at once. If it passes, her cloud and on-premises passwords are the same within seconds. Mallory phones the help desk knowing Priya's birthday and employee number. Neither is an accepted factor, the desk cannot issue a TAP without the manager callback, and a successful reset would also email Priya.

Trade-offs and pitfalls

• Resetting from the Microsoft 365 admin center or with PowerShell version 1 or 2 is not written back; use the Entra admin center or the Graph API so admin resets stay consistent.
• If inheritance is disabled on user objects the write permissions never reach them and writeback fails for those users.
• On-premises policy wins even when the cloud policy is weaker, so a user can see a rejection the cloud would have accepted.
• After a reset, NTLM (an older challenge-response sign-in protocol) network logons can keep working with the old password for five minutes (default, when the domain remembers two or more passwords); do not read that as a failed reset.

Direct answer

Make the web application a delegating service using constrained delegation (Kerberos lets the service obtain tickets to one named back-end service for the signed-in user), preferably the resource-based form, and never unconstrained delegation. First ask whether the SQL queries need the end user's identity at all. If they do, the web application's account, its Service Principal Names (SPNs, the names Kerberos uses to find a service's account) and the SQL account's delegation settings must all be right. If the two services are in different domains, classic constrained delegation cannot work and resource-based delegation can.

Why a plain service account is not enough

The user signs in to the web application (hop 1), and the web application then calls SQL (hop 2). The web application receives proof of the user's identity for itself only. NTLM cannot carry the identity across the second hop, so Kerberos delegation is required. That is the double-hop problem.

A user-by-user trace. Alice signs in to the web application with Kerberos (hop 1), so the application holds a ticket proving Alice to the application, and nothing usable at SQL. For hop 2 the application, running as CORP\webapp$, asks the domain controller's Kerberos service for a ticket to MSSQLSvc/sqlhost in Alice's name. The domain controller checks one list: in classic delegation, whether the SQL SPN is in the front end's allowed-to-delegate-to list; in resource-based delegation, whether the front end is named on the SQL account. If yes, SQL sees CORP\alice. If no, the request is refused and SQL sees either a failed Kerberos login or an NTLM fallback with the application's own identity.

The three delegation types

Microsoft's description of the 2012 change: it moves the decision about trusting a delegating front end from the front end's domain administrator to the resource owner. Concretely, classic delegation is edited on the front end's object, and changing it needs the "Enable computer and user accounts to be trusted for delegation" right, which Domain Admins hold by default. Resource-based delegation is edited on the SQL account's object, so the SQL owner alone decides which front ends may reach it, without involving the front end's administrators.

Same domain: steps

1. Run the web application's pool or service as a group managed service account (gMSA, a domain account whose password the directory rotates); IIS application pools and Windows services can use one.
2. Register the SQL SPN on the account that runs SQL Server, for example setspn -S MSSQLSvc/sqlhost.corp.example.com:1433 CORP\sqlsvc. If the SPN is missing or wrong, Kerberos is not used at all, so delegation cannot happen.
3. Configure delegation to exactly that SPN (classic), or set the allowed front end on the SQL account (RBCD). For classic, edit the front end's object. In Active Directory Users and Computers this is the Delegation tab with "Trust this user for delegation to specified services only"; in PowerShell:

# Classic: set on the FRONT END account (here the gMSA 'webapp'); lists the one SPN it may delegate to.
Set-ADServiceAccount -Identity 'webapp' -Add @{ 'msDS-AllowedToDelegateTo' = 'MSSQLSvc/sqlhost.corp.example.com:1433' }
Get-ADServiceAccount -Identity 'webapp' -Properties 'msDS-AllowedToDelegateTo' | Select-Object Name, 'msDS-AllowedToDelegateTo'

Illustrative read-back (not a captured run): webapp with {MSSQLSvc/sqlhost.corp.example.com:1433} in the second column means the front end may delegate to that service and nothing else. For RBCD in one domain, use the same Set-ADUser ... -PrincipalsAllowedToDelegateToAccount form shown in the cross-domain section, with both accounts in the same domain.
4. If the web application authenticates users by a method other than Kerberos (forms login, certificates), it needs protocol transition. Example: Bob types a username and password into a web form, so the application never receives a Kerberos ticket for Bob. It must ask the domain controller to produce a ticket for Bob without his password, and the domain controller only does that for a front end that is allowed to. Classic constrained delegation needs the Trusted-to-Authenticate-for-Delegation setting for that (in Users and Computers: "Use any authentication protocol" instead of "Use Kerberos only"; in PowerShell Set-ADAccountControl -Identity 'webapp$' -TrustedToAuthForDelegation $true). With RBCD the KDC (Key Distribution Center, the domain controller's Kerberos service) always allows it, so the back end can still tell how the user was authenticated: the ticket carries one of two well-known SIDs. S-1-18-1 (authentication authority asserted identity) means a domain controller verified the user directly. S-1-18-2 (service asserted identity) means the front end vouched for the user through protocol transition. A back end can require S-1-18-1 in an access check for sensitive data, so that a user who was only vouched for by a service is refused.
5. Protect the users: members of Protected Users (a built-in group whose members get hardened sign-in rules, including that their credentials cannot be delegated) and accounts marked "Account is sensitive and cannot be delegated" cannot be delegated. That is a feature, and administrators will see failures through this application.

If the services are in different domains

Classic constrained delegation restricts the account to a single domain. Resource-based delegation lets the owner of the SQL account in domain B list the front-end account from domain A:

# Front end: gMSA "webapp" (domain A). Back end: SQL Server service account "sqlsvc" (domain B).
# Delegation is configured on the BACK END object and lists the front end that may impersonate users to it.
$front = Get-ADServiceAccount -Identity 'webapp' -Server 'dc01.a.example.com'
Set-ADUser -Identity 'sqlsvc' -Server 'dc01.b.example.com' -PrincipalsAllowedToDelegateToAccount $front

# Read it back from the back-end object.
Get-ADUser -Identity 'sqlsvc' -Server 'dc01.b.example.com' -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object Name, PrincipalsAllowedToDelegateToAccount

This script was parse-checked with PowerShell 7 and its cmdlets and parameters checked against Microsoft Learn. It was not run, because it needs the ActiveDirectory module and two real domains. It assumes the domains already trust each other.

Verify it works

Run a test through the web application, from a client other than the SQL server, and read the connection that SQL sees:

SELECT c.auth_scheme, s.login_name
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s ON s.session_id = c.session_id
WHERE c.session_id = @@SPID;

You expect KERBEROS and the end user's name. Illustrative result for a test as Alice (not a captured run):

auth_scheme  login_name
-----------  ----------
KERBEROS     CORP\alice

If the first column says NTLM, or the login name is the application's account, the Kerberos second hop did not happen. SQL Server's own documentation notes that local connections use NTLM, so test remotely.

Trade-offs and pitfalls

• If the queries do not need per-user identity, have the application use its own identity and enforce per-user rules in code (the trusted subsystem model: the database trusts the application's identity, and the application decides who may do what). That removes delegation entirely.
• Delegation lists grow stale: audit them, and remove entries when an application is retired.
• Clocks, DNS and a correct SPN are the usual failures, not the delegation setting.

Direct answer

Create a one-way, outgoing forest trust from the forest that owns the resources (the trusting forest) to the partner's forest (the trusted forest). Make DNS name resolution work first, switch the trust to selective authentication, and then grant the Allowed to Authenticate permission only on the specific server computer objects the partner may use. A forest is the top-level security boundary of Active Directory, so the goal is to open one narrow door and keep every other door locked.

A trust points the opposite way from the access it allows: if users in partner.example must reach a file server in corp.example, corp.example trusts partner.example. That is an outgoing trust on the corp.example side.

Build it in this order

1. Prerequisites. A forest trust is built and used with the DNS names of both forests; Microsoft's trust documentation states that access by NetBIOS name across a forest trust is not supported. Selective authentication on a forest trust needs the trusting forest, where the shared resources live, at the Windows Server 2003 forest functional level or higher (the forest functional level is a setting that records the oldest Windows Server version allowed on the forest's domain controllers and unlocks forest-wide features). The minimum rights are Enterprise Admins in the trusting forest, or Domain Admins in the forest root domain.

2. Name resolution. Each forest's DNS servers must be able to find the other forest's domain controllers. Microsoft's prerequisites for creating a forest trust list three arrangements: a shared root DNS server whose root zone delegates to both namespaces (with the root hints of all DNS servers updated), conditional forwarders in each namespace (a DNS server forwards queries for one named domain to a chosen server), or secondary zones in each namespace with zone transfers. With no shared root, prefer conditional forwarders: they are simpler to troubleshoot, and a secondary zone copies every host record of the partner zone to you.

# Run on a DNS server in corp.example. Mirror the command in partner.example.
# 10.50.0.10 and 10.50.0.11 are the partner's DNS servers (example addresses).
Add-DnsServerConditionalForwarderZone -Name "partner.example" `
    -MasterServers 10.50.0.10,10.50.0.11 -ReplicationScope "Forest"

# Prove the partner's domain controller locator records resolve before building the trust.
# An SRV (service locator) record is a DNS record that names the servers offering one service.
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.partner.example" -Type SRV

The _ldap._tcp.dc._msdcs.<domain> name is the service locator (SRV) record that domain controllers register so clients can find them. If it does not resolve, the trust wizard will fail, so fix DNS before anything else.

A healthy answer looks like this (illustrative output, not a captured run):

Name                                   Type TTL Section NameTarget          Priority Weight Port
----                                   ---- --- ------- ----------          -------- ------ ----
_ldap._tcp.dc._msdcs.partner.example   SRV  600 Answer  dc1.partner.example 0        100    389

Read it as: NameTarget is a partner domain controller that clients can use, and Port 389 is the directory (LDAP) port it listens on. A failure prints an error such as "DNS name does not exist" instead of a table, which means your DNS server cannot find the partner's records yet.

3. Create the trust. netdom trust cannot create a forest trust between two forests. Use Active Directory Domains and Trusts: right-click the forest root domain, open Properties, and use the Trusts tab to run the New Trust Wizard. Choose a forest trust, one-way outgoing from corp.example, and select selective authentication when the wizard asks for the authentication level. A one-way trust has two sides, an outgoing side in corp.example and an incoming side in partner.example: with administrator credentials for both forests the wizard can create both sides in one pass (the Sides of Trust page), otherwise the partner's administrator creates the incoming side.

4. Selective authentication. The default for a forest trust is forest-wide authentication, which lets any user in the partner forest authenticate to any server in your forest. Selective authentication reverses that default: nobody from the partner authenticates anywhere unless explicitly allowed. If you did not pick it in the wizard, set it from the command line, then read the state back (run without a value, the same switch displays the current setting). Microsoft documents the set command at Learn (Enable Selective Authentication over a Forest Trust):

netdom trust corp.example /domain:partner.example /SelectiveAUTH:Yes /userD:PARTNER\adminaccount /passwordD:*
netdom trust corp.example /domain:partner.example /SelectiveAUTH

To see the whole trust the way a reviewer would, read it from PowerShell on a DC in corp.example:

Get-ADTrust -Filter * | Format-List Name,Direction,ForestTransitive,SelectiveAuthentication,SIDFilteringQuarantined,TrustType

Name                    : partner.example
Direction               : Outbound
ForestTransitive        : True
SelectiveAuthentication : True
SIDFilteringQuarantined : False
TrustType               : Uplevel

(Illustrative output, not a captured run.) Read-out: Direction : Outbound means corp.example trusts the partner, which is the direction you want; ForestTransitive : True marks a forest trust (transitive means the trust extends to every domain in both forests, not just the two root domains); SelectiveAuthentication : True is the goal state, and False means any partner user can still authenticate to any server; SIDFilteringQuarantined : False is normal for a forest trust because quarantine is the external-trust setting mentioned below.

5. Grant the one door. On each computer object that the partner needs (for example FS01), grant Allowed to Authenticate to the specific partner group, such as PARTNER\Project-Readers. The permission lives on the computer object in Active Directory, not on the server's own file permissions. In Active Directory Users and Computers on the trusting side: open View and tick Advanced Features, find the computer object (the Computers container or wherever it lives), right-click it and choose Properties, open the Security tab, click Add, type the partner group, then tick Allow beside Allowed to Authenticate and click OK. The same dialog is where you later audit who holds the door.

• For Kerberos, grant it on the computer account when the service runs as Local System or Network Service. If the service runs as a domain service account, grant it on that account.
• For NTLM (the older challenge-response sign-in protocol), grant it on the computer account even if the service uses a domain account.
• By default only Account Operators, Administrators, Domain Admins, Enterprise Admins and SYSTEM can edit this permission.

Why the other servers stay out of reach

When a partner user asks for a Kerberos service ticket (the credential a client presents to one specific server), the request reaches a domain controller in your forest. With selective authentication on, that domain controller tags the request with the Other Organization SID and checks Allowed to Authenticate on the target computer object. A SID (security identifier) is the unique ID Windows stores in a sign-in token for each user and group, and the Other Organization SID (S-1-5-1000) is a fixed, well-known one that means "this user comes from outside our forest". No permission means no service ticket, so the server is never contacted. A server such as FS02, where nobody granted the permission, is unreachable even if its share permissions were sloppy.

Add two more layers, because authentication is not authorization:

• Put the partner group, not "Authenticated Users", on the share and NTFS permissions of FS01. Microsoft recommends removing the default Authenticated Users access on shared resources in the trusting forest, since a partner user who is let in still receives that SID once the member server authenticates them. The reason is that Authenticated Users (S-1-5-11) is a well-known group Windows adds to the token of every account that signs in successfully, whichever forest it comes from. "Let in" (passed Allowed to Authenticate) and "allowed to read" (share and NTFS permissions) are separate checks, so any share that grants Authenticated Users admits every partner user who gets through the door.
• Keep the permission group-based and owned by the resource owner, so adding or removing a partner person is a membership change in their forest.

SID filtering, UPN suffixes and name routing

• SID filtering removes any SID from a request that does not belong to the trusted domain. It is already on by default for forest trusts. Its effect on a partner: users migrated into their domain with SID history (old SIDs kept on the account) lose access that was granted to the old SID, and a universal group (a group usable anywhere in a forest, with its membership held in the global catalog) works only if it was created in the trusted domain. Do not apply SID filter quarantine (/quarantine) to a forest trust; that setting is meant for external trusts. Leave /enablesidhistory off unless you trust the partner's administrators, and read its state with netdom trust corp.example /domain:partner.example /enablesidhistory.
• UPN suffixes (the part after the @ in a user principal name) are routed by the forest trust. If both forests use the same suffix there is a name-suffix conflict, and the conflicting entry stays disabled until the other side's entry is disabled. List the routed suffixes with netdom trust corp.example /domain:partner.example /namesuffixes and fix the overlap before the trust goes live.

Safe test and post-implementation audit

1. Test with two partner accounts: one inside Project-Readers, one outside. The member opens \\FS01\share; the non-member is refused at the ticket stage. Both are refused on FS02.
2. Verify the trust with netdom trust corp.example /domain:partner.example /verify /userd:PARTNER\adminaccount /passwordd:*.
3. Audit after go-live: list trusts with Get-ADTrust -Filter *, re-read the selective authentication and SID history settings, and review which computer objects carry Allowed to Authenticate and for whom. Repeat on a schedule, because the permission list is the real boundary.

Trade-offs and pitfalls

• A forest trust is transitive (it reaches every domain of both forests, not just the two forest root domains), so without selective authentication the exposure is the whole of your forest, not one server.
• If you grant only the computer object and forget the service account (Kerberos with a domain service account), users get repeated access denied even though the share looks right.
• Selective authentication can confuse users who browse the partner network and see access denied on servers that used to open; tell them in advance.
• If you only need to share files with a handful of people, a trust may be too much: a managed file-share or guest-invitation product avoids joining the two directories at all. Choose the trust when the access is ongoing, uses Windows authentication, and needs Kerberos.