119 lines
3 KiB
Plaintext
119 lines
3 KiB
Plaintext
|
Trust Test Plan
|
||
|
---------------
|
||
|
|
||
|
|
||
|
1. Preparation
|
||
|
|
||
|
Configurations needed:
|
||
|
- two or more DCs
|
||
|
- on each DC, make Administrator the current account and be sure to have TcbPrivilege
|
||
|
- on each DC, create a test user account
|
||
|
|
||
|
To automate these steps, use \\scratch\scratch\cristiai\trust\luok.cmd
|
||
|
(luok.cmd requires buildnum.exe, arights.exe and logontst.exe in path)
|
||
|
|
||
|
Depending on the relationships desired between these DCs (parent child,
|
||
|
same enterprise) one or more demote/promote operations (using dcpromo or
|
||
|
an equivalent command line tool) might be needed between test cases.
|
||
|
|
||
|
1.1 Required executables:
|
||
|
trustdom.exe
|
||
|
arights.exe
|
||
|
logontst.exe
|
||
|
|
||
|
From idw:
|
||
|
buildnum.exe (only for luok.cmd)
|
||
|
|
||
|
2. Basic Test Case Scenario
|
||
|
|
||
|
Basically, for each domain and different modes of trust links, the test
|
||
|
users from the other machines will be logged on the current domain.
|
||
|
|
||
|
The steps are:
|
||
|
- set trust links, if necessary (because sometimes trusts are implicitly
|
||
|
defined, by example if there is a parent-child relationship between
|
||
|
those domains)
|
||
|
- for a given domain:
|
||
|
- preparing to logon a user from another domain, grant that user
|
||
|
the InteractiveLogonRight (using arights.exe)
|
||
|
- test logon for that user
|
||
|
- at the end, you can reset the trust links to the status prior to the
|
||
|
test; take care not to delete trusts not set up by the test, like
|
||
|
child-parent trusts
|
||
|
|
||
|
3. Notation
|
||
|
|
||
|
Domain names in uppercase only.
|
||
|
|
||
|
X ----> Y
|
||
|
- one way trust from X to Y, i.e. users from Y can log to X but not the
|
||
|
other way; such a trust link is outbound on X and inbound on Y; it is
|
||
|
listed by a 'trustdom X -list' command as "Y ,O,T_uplevel,_,_,_"
|
||
|
(or T_downlevel, depending if the machines involved are NT5s or NT4s)
|
||
|
|
||
|
X <---> Y
|
||
|
- two way trust; it is listed by a 'trustdom X -list' command as
|
||
|
"Y ,B,T_uplevel,_,_,_"
|
||
|
|
||
|
X=P(Y)
|
||
|
- X is parent for domain Y
|
||
|
|
||
|
[A,B,C]
|
||
|
- domains A, B, C are in the same enterprise
|
||
|
|
||
|
A\User
|
||
|
- user account from domain A
|
||
|
|
||
|
B:A\User
|
||
|
- attempt to logon user A\User on domain B
|
||
|
|
||
|
Text after // is used as a comment.
|
||
|
|
||
|
4. Test Cases
|
||
|
|
||
|
Sanity check: on each domain you can perform a local logon with the
|
||
|
local user account (don't forget to grant it locally too the
|
||
|
InteractiveLogonRight)
|
||
|
So, for each domain you can perform a "DOM:DOM\User = PASS"
|
||
|
|
||
|
4.1 Using Two Domains:
|
||
|
|
||
|
4.1.1 No trust link between A and B
|
||
|
A:B\User = FAIL
|
||
|
B:A\User = FAIL
|
||
|
|
||
|
4.1.2 A ---> B
|
||
|
A:B\User = PASS
|
||
|
B:A\User = FAIL
|
||
|
|
||
|
4.1.3 A <--> B
|
||
|
A:B\User = PASS
|
||
|
B:A\User = PASS
|
||
|
|
||
|
4.2 Using Three Domains:
|
||
|
|
||
|
4.2.1 Separate enterprises (i.e. [A] [B] [C])
|
||
|
Logon must succeed depending only on the existance of the trust between
|
||
|
the two domain involved, no transitivity
|
||
|
|
||
|
That is for A <--> B --> C,
|
||
|
A:B\User = PASS // because of A <--> B
|
||
|
A:C\User = FAIL // no transitivity
|
||
|
|
||
|
B:A\User = PASS // because of A <--> B
|
||
|
B:C\User = PASS // because of B ---> C
|
||
|
|
||
|
C:A\User = FAIL
|
||
|
C:B\User = FAIL
|
||
|
|
||
|
4.2.2 [A,B,C] and B=P(A)
|
||
|
All combinations must pass, that is:
|
||
|
A:B\User = PASS
|
||
|
A:C\User = PASS // due to transitivity inside the enterprise
|
||
|
|
||
|
B:A\User = PASS
|
||
|
B:C\User = PASS
|
||
|
|
||
|
C:A\User = PASS // due to transitivity inside the enterprise
|
||
|
C:B\User = PASS
|