[翻译]基于RODC的身份验证过程 RODC, 子网, 控制器, 计算机

ghjconan

原文链接：http://technet2.microsoft.com/wi ... 8c5e1d9db71033.mspx  Appendix B

以下场景帮助解释了基于RODC的身份验证过程。在这个场景中：
用户Bob想要登录到名称为BOB_WS的工作站。
安装BOB_WS工作站子网由一台RODC提供服务。
Bob的用户账户被允许在RODC上缓存凭据，但是凭据当前还没有缓存。
计算机账户BOB_WS被允许在RODC上缓存凭据，但是凭据当前还没有缓存。
Bob尝试在工作站（BOB_WS）上登录。首先，必须从域控制器处获得TGT。在本场景中TGT的获得过程如下图所示

1.        RODC在分支机构宣告成为KDC。这意味着当BOB_WS搜索域控制器来认证Bob的登录请求时，它将找到并使用RODC作为KDC。BOB_WS 的Kerberos认证包准备了TGT请求并将它发送给RODC
2.        RODC收到来至BOB_WS的TGT请求。因为RODC不知道Bob的账户密码，所以不能为Bob创建TGT。随后RODC将TGT请求传递给运行Windows Server 2008的可写域控制器。
3.        运行Windows Server 2008的可写域控制器验证请求。
4.        随后结果返回给RODC。如果Bob提供了正确的凭据，那么结果就是获得TGT。如果Bob的凭据验证失败，将会导致一条错误信息。在这个场景中，如果Bob在登录时输入了正确的用户名及密码，那么验证过程将获得成功。
5.        同时，可写域控制器返回TGT给RODC，它也向RODC计算机账户msDS-AuthenticatedToAccountList属性添加了Bob账户的相对可分辨名称（distinguished name，DN）。RODC创建了一条Bob已经被验证的记录。
6.        随后RODC将结果传递给BOB_W S。
7.        在RODC将TGT发送回BOB_WS以后，它也向可写域控制器请求将Bob的凭据复制至它的活动目录数据库的副本区（replica）
8.        当可写域控制器收到将Bob的凭据复制到RODC的请求时，它会检查密码复制策略来查看RODC是否被允许缓存Bob账户的凭据。
9.        如果检查表明凭据能被缓存，那么可写域控制器将会允许复制Bob账户的凭据至RODC。
10.        在可写域控制器发送RODC请求的凭据的同时，可写域控制器在RODC计算机账户的msDS-RevealedList属性中写入Bob账户的相对可分辨名称（DN）。这创建了一条说明Bob的账户凭据已被缓存在RODC上的记录。
11.        RODC在活动目录数据库的用户的合适属性中储存了Bob的凭据。


此时：
在可写域控制器上有一条允许复制Bob的凭据至RODC的记录。
Bob账户凭据在RODC上已被缓存。
Bob拥有可写域控制器产生的TGT。

[ 本帖最后由 ghjconan 于 2007-7-19 11:21 编辑 ]

ghjconan

下一步，Bob必须得到一张服务票据使得BOB_WS能够工作，如下图所示：

1.        BOB_WS将Bob的服务票据（service ticket）请求发送至RODC。这个请求包含了可写域控制器颁发的TGT。
2.        RODC不知道可写域控制器使用的公共krbtgt账户密码；因此，它必须传递服务票据请求至可写域控制器。但是RODC上缓存着Bob的凭据。因此，因此它能满足Bob的服务票据请求。结果是，当可写域控制器成功的响应了传递的请求，RODC返回一条Kerberos错误信息而不是为BOB_WS请求的服务票据。这条错误消息说明Bob在服务票据请求中使用的TGT将不在有效而新的TGT必须被颁发。
3.        当收到这条错误消息后，BOB_WS放弃可写域控制器颁发的TGT。并重新向RODC请求新的TGT。
4.        RODC上有Bob的凭据缓存，因此，它准备了TGT并使用它自己的krbtgt密码进行签名。
5.        随后RODC将新的TGT发送回BOB_WS。
6.        BOB_WS再次将Bob的服务票据请求发送至RODC。现在，服务票据请求包含了RODC颁发的TGT。
7.        RODC处理服务票据请求。因为它没有BOB_WS计算机账户的凭据缓存，它不能创建服务票据。它必须传递服务票据请求值可写域控制器。
8.        可写域控制器收到来自RODC的服务票据请求。随后可写域控制器进行了一下几步
　　1. 验证TGT。（可写域控制器之所以能验证TGT是因为它知道RODC特定的krbtgt账户密码。）
　　2. 根据密码复制策略决定是否允许RODC缓存Bob帐号的凭据。RODC只被允许创建允许在RODC上缓存凭据的账户的TGT。
　　3. 对Bob账户的成员关系进行评价并准备服务票据的特权认证证明（Privilege Authentication Certificate ，PAC）部分。它不使用由RODC准备的TGT的PAC部分。这防止了权限提升万一RODC遭受威胁以及在TGT的PAC部分中放置欺诈信息。
9.        可写域控制器创建服务票据并将它发送回RODC。
10.        随后RODC将服务票据传递给BOB_WS。
11.        Bob能够在BOB_WS上开始工作。
12.        在RODC将服务票据发送回BOB_WS后，也向可写域控制器请求将BOB_WS的凭据复制至它的活动目录数据库的副本区（replica）
13.        当上游域控制器收到复制BOB_WS账户凭据至RODC的请求时，它会检查密码复制策略来查看RODC是否被允许缓存BOB_WS账户的凭据。
14.        如果凭据能被缓存，那么可写域控制器允许BOB_WS的账户凭据被复制到RODC。
15.        同时，可写域控制器将请求的凭据发送给RODC，可写域控制器向RODC计算机账户msDS-RevealedList属性写入了BOB_WS账户的相对可分辨名称（distinguished name，DN）。这在RODC上创建BOB_WS凭据被缓存的记录。
16.        RODC在活动目录数据库的用户的合适属性中储存了BOB_WS的凭据。

此时：
Bob已经登录至BOB_WS工作站，他能够请求服务票据来访问位于服务器上的资源，同样的方式他为自己的工作站请求服务票据。
如果Bob访问的任何计算机允许在RODC上缓存凭据，RODC缓存凭据就如同它处理服务票据请求一样。
RODC缓存了BOB_WS计算机账户的凭据。
可写域控制器创建了一条记录并像RODC显示BOB_WS计算机账户的凭据。

[ 本帖最后由 ghjconan 于 2007-7-19 11:21 编辑 ]

ghjconan

当Bob下次尝试登录到BOB_WS工作站时，RODC将不必联系可写域控制器来处理登录请求因为它已经缓存了Bob账户及BOB_WS计算机账户的凭据，如下图所示：

1.        RODC在分支机构宣告成为KDC。这意味着当BOB_WS搜索域控制器来认证Bob的登录请求时，它将找到并使用RODC作为KDC。BOB_WS 的Kerberos认证包准备了TGT请求并将它发送给RODC
2.        RODC收到来自BOB_WS的TGT请求，因为已经知道Bob账户的密码，它能够为Bob创建TGT。RODC创建TGT时将使用它自己的krbtgt账户。
3.        RODC将TGT发送回BOB_WS，BOB_WS在与Bob登录会话关联的票据缓存中存储了TGT。
4.        为了能在BOB_WS上工作，Bob需要服务票据来获得访问。在BOB_WS上的认证包准备TGT请求并将它发送至RODC。
5.        RODC收到来自BOB_WS的服务票据请求，并且因为已知BOB_WS计算机账户的密码，它能够为Bob创建服务票据来访问BOB_WS。当创建TGT时，RODC使用它自身的krbtgt账户。
6.        RODC将服务票据发送回BOB_WS，BOB_WS在与Bob登录会话关联的票据缓存中存储了服务票据。
7.        Bob能够在BOB_WS上开始工作。

重要：
本场景展示了在分支机构中为计算机账户缓存密码的重要性。如果一个计算机账户的密码没有缓存并且到可写域控制器的WAN链路不可用，在分支机构中的用户将不能登录计算机因为用户无法收到计算机账户的服务票据。

Anders

ghjconan
英文链接有时候在变动。能不能把翻译的英文在中文后转帖到论坛上，这样可以有时候，方便我们英文学习等:$

[ 本帖最后由 Anders 于 2007-7-22 17:30 编辑 ]

ghjconan

呃，因为technet那里使用的框架页面，如果复制地址栏的地址有可能出问题，如果复制右侧页面地址的话，大概就没什么问题了……

一楼的那个链接是有效的，只不过RODC的部署文档实在很长，复制过来只会让人晕吧……

Anders

我觉得RODC的所有英文原始文档好长，因为他没有给每段都分目录，对照你翻译的学习英语起来找起来也比较麻烦，所以如果就复制你翻译的Appendix B这几小段还行吧，放在你翻译好的中文后面，这样就方便看了。

[ 本帖最后由 Anders 于 2007-7-22 17:44 编辑 ]

ghjconan

Appendix B: How the authentication process works with RODCs
The following scenario helps explain how the authentication process works with RODCs. In this scenario:

• User Bob wants to log on to a workstation named BOB_WS.

• The subnet where BOB_WS workstation is installed is serviced by an RODC.

• Bob’s user account is allowed to cache credentials on the RODC, but the credentials are not cached yet.

• The BOB_WS computer account is allowed to cache credentials on the RODC, but the credentials are not cached yet.


Bob tries to log on to workstation BOB_WS. First, the TGT must be retrieved from the domain controller. The TGT retrieval process in this scenario is shown in the following illustration.

1. The RODC is advertised as the KDC for the branch office. This means that when BOB_WS searches for a domain controller to authenticate Bob’s logon request, it finds and uses the RODC as a KDC. The Kerberos authentication package of BOB_WS prepares a TGT request and sends it to the RODC.

2. The RODC receives the TGT request from BOB_WS. Because the RODC does not know the password for Bob‘s account, it is not able to create the TGT for Bob. The RODC forwards the TGT request to a writable Windows Server 2008 domain controller.

3. The writable Windows Server 2008 domain controller authenticates the request.

4. The result is returned to RODC. If Bob supplies correct credentials, the result is a TGT. If Bob's credential validation fails, the result is an error message. In this scenario, if Bob enters a valid user name and password when he logs on, the validation succeeds.

5. At the same time as the writable domain controller returns a TGT to the RODC, it also adds the distinguished name (also known as DN) of Bob‘s account to the msDS-AuthenticatedToAccountList attribute of the RODC computer account. This creates a record that Bob was authenticated by the RODC.

6. The RODC then passes the result to BOB_WS.

7. After the RODC sends the TGT back to BOB_WS, it also asks the writable domain controller to replicate Bob’s credentials to its replica of the Active Directory database.

8. When the writable domain controller receives the request to replicate Bob‘s credentials to the RODC, it checks the Password Replication Policy to see if the RODC is permitted to cache the credentials for Bob's account.

9. If the check indicates that credentials may be cached, the writable domain controller allows replication of Bob’s account credentials to the RODC.

10. At the same time that the writable domain controller sends the credentials that the RODC requested, the writable domain controller writes the distinguished name of Bob‘s account to the msDS-RevealedList attribute of the RODC computer account. This creates a record that the credentials of Bob’s account are now cached on RODC.

11. The RODC stores Bob’s credentials in the appropriate attributes of his user account in the Active Directory database.


At this moment:

• The writable domain controller has a record that it has allowed the replication of Bob’s credentials to the RODC.

• The credentials of Bob‘s account are cached on RODC.

• Bob has the TGT that was generated by the writable domain controller.


Next, Bob must obtain a service ticket for BOB_WS to be able to work on it, as shown in the following illustration.

1. BOB_WS sends Bob’s request for the service ticket to the RODC. The request contains the TGT that was issued by the writable domain controller.

2. The RODC does not know the password of the common krbtgt account that the writable domain controllers use; therefore, it must forward the service ticket requests to a writable domain controller. But the RODC has Bob’s credentials cached; therefore, it can satisfy Bob’s requests for service tickets. As a result, after the writable domain controller successfully responds to the forwarded request, the RODC returns a Kerberos error message rather than the requested service ticket to the BOB_WS. This error message indicates that the TGT that Bob used in the service ticket request is no longer valid and that a new TGT must be issued.

3. After receiving this error message, BOB_WS discards the TGT that was issued by the writable domain controller, and it requests a new TGT from the RODC.

4. The RODC has Bob’s credentials cached, therefore, it prepares a TGT and signs it with the password of its own krbtgt account.

5. The RODC then sends this new TGT back to BOB_WS.

6. BOB_WS sends Bob’s service ticket request to the RODC again. Now, the service ticket request contains the TGT that was issued by the RODC.

7. The RODC processes the service ticket request. Because it does not have the BOB_WS computer account credentials cached, it cannot create the service ticket. It must forward the service ticket request to a writable domain controller.

8. The writable domain controller receives the service ticket request from the RODC. The writable domain controller:

[quote]1. Validates the TGT. (The writable domain controller can validate the TGT because it knows the password of RODC-specific krbtgt account.)

2. Determines whether the Password Replication Policy allows the RODC to cache credentials for Bob’s account. The RODC is allowed to create TGTs only for accounts that are allowed to cache credentials on it.

3. Evaluates the membership of Bob’s account and prepares a Privilege Authentication Certificate (PAC) portion of the service ticket. It does not use the PAC part of the TGT that was prepared by the RODC. This prevents elevation of privileges in case the RODC is compromised and places fake information into the PAC portion of the TGT.

9. The writable domain controller creates a service ticket and sends it back to the RODC.

10. The RODC then forwards the service ticket to BOB_WS.

11. Bob can start working on BOB_WS.

12. After the RODC sends the service ticket back to BOB_WS, it also asks the writable domain controller to replicate BOB_WS credentials to its replica of the Active Directory database.

13. When the upstream domain controller receives the request to replicate the BOB_WS account credentials to the RODC, it checks the Password Replication Policy to determine whether the RODC is allowed to cache the credentials for the BOB_WS account.

14. If the credentials may be cached, the writable domain controller allows replication of the BOB_WS account credentials to the RODC.

15. At the same time that the writable domain controller sends the RODC the requested credentials, the writable domain controller writes the distinguished name of the BOB_WS account to the msDS-RevealedList attribute of the RODC computer account. This creates a record that the credentials of BOB_WS are now cached on RODC.

16. The RODC stores the credentials of the BOB_WS computer in the appropriate attributes of its computer account in the Active Directory database.


At this moment:

• Bob is logged on to the BOB_WS workstation, and he can request a service ticket to access resources that are located on servers, the same way as he requested service tickets for his own workstation.

• If any of the computers that Bob accesses is allowed to cache credentials on the RODC, the RODC caches it as it processes a service ticket request.

• The RODC caches the credentials of the BOB_WS computer account.

• The writable domain controller creates a record that it revealed the credentials of the BOB_WS computer account to the RODC.

When Bob next tries to log on to the BOB_WS workstation, the RODC will not have to contact the writable domain controller to process the logon request because it has already cached credentials of Bob’s account and the BOB_WS account, as shown in the following illustration.

1. The RODC is advertised as the KDC for the branch office. This means that when BOB_WS searches for a domain controller to authenticate Bob’s logon request, it finds and uses the RODC as a KDC. The Kerberos authentication package of BOB_WS prepares a TGT request and sends it to the RODC.

2. The RODC receives the TGT request from BOB_WS. Because it already knows the password for Bob‘s account, it can create the TGT for Bob. The RODC uses its own krbtgt account when it creates the TGT.

3. The RODC sends the TGT back to BOB_WS, which stores the TGT in a ticket cache that is associated with Bob’s logon session.

4. To be able to work on BOB_WS, Bob needs a service ticket to gain access. The authentication package on BOB_WS creates the service ticket request and sends it to the RODC. The authentication package on BOB_WS prepares a TGT request and sends it to the RODC.

5. The RODC receives the service ticket request from BOB_WS and, because it already knows the password for the BOB_WS computer account, it can create the service ticket for Bob to access BOB_WS. The RODC uses its own krbtgt account when it creates the TGT.

6. The RODC sends the service ticket back to BOB_WS, which stores the service ticket in the ticket cache that is associated with Bob’s logon session.

7. Bob can begin working on BOB_WS.

Important:  
This scenario shows the importance of caching passwords for computer accounts in the branch office. If the password for a computer account is not cached and the WAN link to a writable domain controller is not available, a user in the branch office cannot log on to the computer because the user cannot retrieve the service ticket for that computer account.
[/quote]
那我就转过来好了……

Anders

恩，麻烦了:)

zflczx

好详细哦。真是谢谢楼主了。。

ourstory

写的好详细啊，谢谢LZ