When a user logs on to a Windows domain by typing in a username and password, a secure challenge and response protocol is invoked between the client computer and a domain controller to verify that the username and password are valid. Then the domain controller sends a SID back to the client, which uses it to create a Security Access Token (SAT) that is valid only for that system, to be used for further authentication. This access token has information about the user coded into it, including the username, the group, and the rights the user has within the domain. At this point, the user is logged on to the domain.

Subsequently, when the client attempts to access a shared resource within the domain, the client system enters into a secure challenge and response exchange with the server of the resource. The server then enters into another secure challenge and response conversation with a domain controller to check that the client is valid. (What actually happens is that the server uses information it gets from the client to pretend to be the client and authenticate itself with the domain controller. If the domain controller validates the credentials, it sends an SID back to the server, which uses the SID to create its own SAT for the client to enable access to its local resources on the client's behalf.) At this point, the client is authenticated for resources on the server and is allowed to access them. The server then uses the SID in the access token to determine what permissions the client has to use and modify the requested resource by comparing them to entries in the ACL of the resource.

Although this method of authentication might seem overly complicated, it allows clients to authenticate without having plain-text passwords travel through the network, and it is much more difficult to crack than the relatively weak workgroup security we described earlier.

Was this article helpful?

0 0

Post a comment