SQL Server Magazine

Ever since Windows NT was called OS/2 3.0, we've heard about its C2 security design. Of course, security has many aspects, but most of us think of logons when we think about security: How do the computer and the network use my username and password? What's involved in the process of logging on to a domain and then accessing a network share? For the answers, I closely examined some Network Monitor logs.

So here's the scenario: A user (call her Amy) has an NT workstation (call it NTW) attached to an NT domain (call the Primary Domain Controller NTPDC). An NT server machine, S1, is in the domain, and Amy wants to access a share on S1. (I'll assume that she has a valid username and password for the domain and that she has permissions on S1's share.)

Logging the Workstation On to the Domain
First, Amy turns on NTW. Then she enters a username and password, right? Wrong. Before NT machines even pay attention to us meat-based computing devices, the NT workstation logs on to the domain. When an NT workstation joins a domain, the Primary Domain Controller (PDC) creates a machine account on the PDC similar to a user account. When the PDC creates an NT workstation machine account in the domain, it makes up a password for the NT machine and tells the password to the NT machine, which remembers it. The NT machine then uses that password to log on to the domain. The PDC creates the password, but any domain controller can log a machine on.

More specifically, suppose our three NT machines (NTW, NTPDC, and S1) are members of a domain named REALM. Workstation NTW wakes up and tries to find a domain controller, any domain controller, to log NTW on to the domain. (Domain controllers are sometimes called logon servers because that's largely what they do--logons.) To discover a domain controller, NTW takes the domain name, REALM, and adds the NetBIOS suffix <1C>, to designate a domain group name. All domain controllers in the domain, both backup and primary, share the domain group name REALM<1C>. The NTW machine broadcasts, "Hey! Is anybody here named REALM <1C>?" (If you're using Windows Internet Name Service--WINS--or have an LMHOSTS file, your system can directly look up the information at the WINS server or the LMHOSTS file and avoid the broadcasts.)

NTPDC hears the request and responds, "Here! I'm a domain controller. What do you want?" NTW responds, "I'm NT workstation NTW with password xyzzy. NTPDC, please convince yourself that I'm a member of REALM, and set up a secure channel between us." NTPDC then verifies NTW's password, and NTW and NTPDC have a secure channel. In other words, NTW is now logged on to REALM. The NetLogon service (you'll hear about NetLogon again) oversaw the machine-to-machine logon.

Logging a User On to a Domain
So Amy sits down at the machine and presses Ctrl+Alt+Del or, as it's known in NT techie parlance, the Secure Command Sequence (SCS). Amy is now communicating with a program called WINLOGON. Amy then logs on as "Amy" from domain REALM with password "swordfish."

The machine takes Amy's password and runs it through a one-way hash function, a mathematical operation that's easy to do but hard to undo. NT treats whatever string of characters you choose for a password as one very large binary number and performs the hash function on that number. Here's a simple example of a hash function: Take a number and divide it by 273. Keep the remainder; throw away the quotient. That operation is easy to do, but very hard to undo. Merely telling you that my original number had a remainder of 151 doesn't tell you much.

How do you store passwords in memory or on disk without compromising them? The answer is: You don't. Instead, when a user chooses a password, NT hashes it and saves the hashed result (the one-way function--OWF--password). A domain controller doesn't contain a list of passwords; it contains OWF passwords. With this system, a domain administrator cannot see a user's password, no matter how clever the domain administrator is--the passwords aren't there. (By the way, hash functions are a lot more complex than just division and remainder operations.)

So now WINLOGON at NTW, which Amy's sitting at, contains a copy of Amy's OWF password; NTW has already forgotten "swordfish." From this point on, WINLOGON doesn't perform the authentication; for that function, WINLOGON looks to the Local Security Authority (LSA). LSA notices that although Amy's sitting at NTW, she has asked to log on as Amy from REALM, her domain account, rather than from any local accounts on NTW. LSA on NTW doesn't contain a list of domain user account names and passwords, so LSA must go back out on the network and find an LSA on a machine to verify Amy. NetLogon handles this LSA-to-LSA conversation; therefore, the next order of business is for NTW to discover a domain controller. NTW looks for any machine responding to the name REALM<1C>. A domain controller (NTPDC in my example, because it's the only domain controller around) responds to the request to log on Amy, saying in effect, "What's Amy's password?"

Now we have a problem. We're not going to send Amy's password over the wire. Sure, we have a secure channel between NTW and NTPDC, but not between NTPDC and, say, a DOS machine. Besides, security folks like to be really sure that they're not handing passwords across a network cable. So how do we prove to NTPDC that Amy really knows the correct password? The answer is a challenge, similar to the Internet Challenge Handshake Authentication Protocol (CHAP) that you might know of (Remote Access Service--RAS--supports it). The logon server (NTPDC, in this case) says to NTW something like, "Okay, take the OWF version of Amy's password; again, treat it like a big number. Multiply it by 725, take the cosine of that value, square it, and take the logarithm of the result. What is the third digit to the right of the decimal point?" The workstation performs the operations, and sends the result--suppose it's 7--to the logon server, NTPDC. NTPDC then does the same set of operations to the OWF password for Amy and also derives 7. NTPDC then knows that Amy is sitting at NTW. The multiplier, 725, will vary from challenge to challenge to ensure anyone listening on the wire won't get useful information. The next challenge NTPDC issues will be based on a different number, so the results will be different. LSA on NTPDC then packages up what it knows about Amy--the Security IDs (SIDs) of her domain user account and any global groups that she's a member of--and passes them to LSA on NTW, Amy's workstation.

LSA on NTW then takes Amy's information and uses it to build a security access token for Amy that's good only on NTW. In addition to the domain account information that the logon server's LSA sent along, the local LSA figures out what Amy can do on the local system. For example, suppose NTW has a local group named Power Users, the local Power Users group contains the global group Domain Admins on REALM, and Amy is a member of the Domain Admins group on REALM. NTW's LSA has the SID proving that Amy is a member of REALM\Domain Admins. NTW's LSA will build Amy's security access token to include not only the SID of REALM\Domain Admins but also the SID of the local Power Users group.

At this point, Amy is logged on to the domain and her local workstation. She still doesn't have access to the file server, but that's all the space I have this month. I'll finish explaining logons next month.

End of Article