Attaching to a File Server

Last month, I began to explain what goes on under the hood when a user logs on to a Windows NT workstation and accesses data on a server on the network. If you're just joining me, here's the short version: A user named Amy has logged on to her NT workstation, a machine named NTW. The domain controller that logged her on is named NTPDC, and the data that she wants to access is in a share called DATA on a server named S1. Her domain is named REALM, and she logged on to NTW as "Amy" from domain REALM with password "swordfish." NTW converted her password into a one-way, mathematical hash function (or a one-way function­OWF) password and discarded her plaintext password. Then NTPDC used a challenge process to verify the password that Amy gave NTW. A challenge eliminates the need to send passwords over the network cable; instead of sending the password, the domain controller sends a random number over the wire and tells the workstation to do something with the random number and the hashed password--multiply them, take the arctangent of their product, or whatever. Then the workstation sends the result of the computation. Because the challenge computation is based partly on a random number, the result of the challenge will always be different, so anyone trying to steal a password by listening on the network cable won't get any useful information.

Once NTPDC is convinced that Amy is indeed Amy, it sends Amy's security ID (SID) values to NTW; SIDs are shorthand ways of saying, "Amy has an account on REALM. Amy is a member of REALM's Domain Users group. Amy is a member of REALM's Domain Admins group," and so on. With that information, a program called the Local Security Authority (LSA) on Amy's workstation builds a security access token for Amy, which is good only on Amy's workstation NTW. The LSA also examines Amy's global groups to determine which NTW local groups Amy is a member of; for example, if Amy is a member of REALM\Domain Admins and that global group is a member of NTW's local Administrator's group, then Amy is indirectly a member of NTW\Administrators, and LSA adds that fact to Amy's local security access token.

Accessing the Share
Now suppose Amy tries to access a share on S1, a nondomain controller NT Server. The server S1 sees a user, REALM\Amy, attempting to access a local share named DATA. Suppose DATA's permissions allow Change access to anyone in the REALM\Domain Admins group. Because Amy is a member of REALM\Domain Admins, S1 will grant her access. Figure 1, page 64, illustrates this process.

A program called the Security Reference Monitor, part of the NT Executive, approves access to objects on an NT machine. Objects have security descriptors, a list of accounts and access levels. For example, if you add my name to a list of users approved for Full Control on a particular share, you've modified the security descriptor for that object.

People who have been using Microsoft network products since before NT will by now be saying, "Wait a minute. Isn't that list of users called the access control list (ACL)?" The notion of ACLs (pronounced ackels) has been around since the LAN Manager days, and the term ACLs is still appropriate. But security descriptor is the more complete and current term.

The Security Reference Monitor wakes up whenever a user (or a program a user initiates) tries to access an object. The object has a set of security descriptors (a list of approved users), and the user has a set of attributes (SIDs and group memberships). The Security Reference Monitor says, for example, "You are user X, and on this object, user X has Read permissions; you are therefore approved to access this object in read-only mode."

Let's get back to Amy's effort to access share DATA on server S1. The Security Reference Monitor wakes up and says, "Well, I've got the security descriptors for DATA, but I need to know who you are. After all, anyone can claim to be Amy. You need a security access token." So the Security Reference Monitor starts up the LSA on S1. (Believe me, I'm trying to minimize the acronyms, but NT security stuff is fraught with it. My apologies.) The LSA on S1 then asks the LSA on Amy's workstation NTW, "Who is this user?" The LSA on NTW responds, "This is user Amy of the domain REALM." S1's LSA responds with a challenge, such as, "All right then, take Amy's OWF password and multiply it by 47, take the cosine of that, then take the natural logarithm of that, and then give me the third digit to the right of the decimal point." So Amy's machine might respond, for example, "9." In a way, S1 is mimicking a domain controller, asking NTW to prove that Amy is indeed Amy in much the same way that the domain controller NTPDC did before.

However, NTPDC had the passwords and could verify Amy's logon. In contrast, S1, a plain-jane NT Server, doesn't have the passwords to the domain account. So what good did it do S1 to challenge NTW about Amy? The answer is simple: Now S1 contacts NTPDC and impersonates Amy. In effect, it says, "I've got someone who claims to be named Amy on the line with me. Can you verify a password for me? I told her to give me the third digit to the right of the decimal point of the logarithm of the cosine of her password times 47, and she told me 9. Is that right?"

NTPDC then repeats the challenge and says, "Yes, that's definitely Amy. Here are her SIDs." The LSA on the domain controller then sends those SIDs to server S1, and the LSA on S1 builds a security access token for Amy on S1, just as NTW's LSA module created a security access token for Amy on NTW. Again, that security access token includes not only the SIDs from the domain controller (think of them as the global SIDs), but also the SIDs that appear indirectly as a result of your domain account or global groups being members of some local group (consider them local SIDs). Now that a security access token for Amy exists, the Security Reference Monitor can match her SIDs against the SIDs in the security descriptor for the DATA share and choose to grant or deny access to DATA.

Are We Clear?
Let's follow the numbers in figure 1 to review the process. When Amy tries to access a share on server S1 (1), S1 finds that it lacks a security access token for Amy. So S1 initiates a logon between Amy and S1. S1 issues a challenge to Amy's workstation (2), which responds to the challenge (3). S1 then takes the challenge response to a nearby domain controller (4) and verifies that Amy is indeed on the other end of the line (5). Now S1 has a security access token for Amy, so the Security Reference Monitor can give the yea or nay to Amy's access request (6).

But what if Amy tries to access a second share on S1? Does S1 need to create another token? No. Amy's existing token will suffice to identify her. Accessing the second share will be a trifle faster than with the first because the second doesn't require chatter between S1 and a domain controller. In fact, as long as Amy maintains a connection to S1, S1 never rechecks with the domain controller to see whether her account is still valid. That situation leads to an interesting side effect: Suppose Amy logs on at 8:00 a.m. one day. She attaches to server S1 at 8:30 a.m. and is then called away to a brief meeting where she's fired. The network administrator deletes her account immediately. What's the effect of that action? It depends.

The security access token remains valid on S1 as long as Amy has active sessions on S1. As long as the session is active, S1 has no reason to reverify Amy's account. A session becomes inactive when Amy logs off, an administrator disconnects Amy from the server with Server Manager, or Amy's session times out.

By default, NT times out a session after 15 minutes of inactivity. Many people are skeptical about this feature--"I've never been timed out from a server!"--because NT doesn't give you a You have timed out message. You see, if you're away from your desk for 15 minutes or more, NT closes your connections to network resources. When you return and try to use the resources, NT invisibly re-establishes your connections, leading to an almost imperceptible delay as the resources' servers reconfirm the validity of your account with nearby domain controllers. In Amy's case, however, things might work out differently. If she'd walked away from her desk for more than 15 minutes, all her connections would have timed out. If the network administrator deleted her account, NT would have noticed this situation when she tried to use one of her network resources. The other way to force a server to re-examine a user's credentials is, again, to use the Server Manager to disconnect her from the resource. This method has the same effect as the timeout but doesn't take 15 minutes.

That's network logons simplified under NT 3.x and 4.0. But what about NT 5.0? That's a whole 'nother story, which I'll cover next month.

End of Article