Chapter 3: Authentication and Resource Protection in Windows 2000

Transcription

1 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 1 of 23 Chapter 3: Authentication and Resource Protection in Windows 2000 Because this is a user administration book, not a security book, I m not going to go into a huge amount of detai about a the new security features in Windows There are security improvements in many parts of the product: Kerberos for authentication, an encrypting fie system, support for certificates, and in networking, IPSEC. Athough this is a chapter on security, we aren t going to discuss a of Windows 2000 s new security features. I am going to try and keep the discussion to the security features that impact your user or desktop administration duties. In this chapter, we discuss how Windows 2000 handes authentication, authorization, access contro and auditing. There are other security functions we wi discuss in ater chapters. For instance, we won t discuss how to contro visibiity and permissions on directory objects unti Chapter 4, "Understanding Organizationa Units: The Buiding Bocks of the Active Directory." Some of the security features in Windows 2000 are impemented as poicies IPSEC is an exampe. We wi discuss those security functions in Chapter 9, "InteiMirror Features for Cient Management," when we are taking about creating and depoying poicies. In the rea word, you reay shoud at east have a passing famiiarity with what Windows 2000 security can do for you as an administrator, so in this chapter, we wi have a high-eve discussion of some of the new security features, tak about some basic security concepts, and finay discuss how to secure your fie system resources and impement auditing on those resources. As I mentioned in Chapter 1, "Inside Windows 2000 Overview," the permission and inheritance mode has changed quite a bit in Windows 2000, so we wi spend a considerabe amount of time on that at the end of the chapter to make sure you fuy understand the security impications in administering the system. Let's start with some genera security terms and concepts, and see how Windows 2000 impements these functions. Security Perimeters When I was first earning about computer security, I was aways tod that there are four major security perimeters in any computer system: Physica security System security Appication security Data Security I was aso tod that these four ayers coud be thought of as being arranged in a bu's-eye pattern. As you move toward the center of the eye, each ring you pass through provides a higher eve of security for the resources contained in that ring. In Figure 3.1, you can see that the outer ring is the physica security ring. The fence around the instaation, ocked doors, and buetproof gass woud be considered physica security measures. Moving toward the center of the bu's-eye, the next ring is the system security perimeter. The idea of

2 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 2 of 23 a network ogon to an NT domain is an exampe of system security. After the system ring, there is the appication ring and finay the data ring. Often we use the system ogon to determine access to the innermost rings by using pass-through authentication to determine access eves for a particuar user. Figure 3.1 Security buõs-eye. Security Activities Any decent security system has to aow for the impementation of certain basic security functions. Naturay, every system impements these differenty. Five of the basic security activities are identification, authentication, authorization, access contro, and auditing. How strong a security system is depends on how strong and trustworthy each of these impementations is. Identification Identification is the concept of identifying yoursef to the system. Depending on the perimeter, the method of identification differs. In physica security systems, this may be a badge. In system, appication, and data security, you are typicay identified by your username: your ogon ID. Windows 2000 can use two methods of identification for oca and network ogons. One is the traditiona username and another is the Smart Card. Authentication When you authenticate to a system, you are proving that you are who you say you are. That picture on your badge is an exampe of authentication in the physica ayer. In the system security ring, your password is a typica authentication mechanism. The certificates on a Smart Card ogon are aso exampes of authentication. In order to achieve authentication, a network must know how to authenticate. What methods are foowed? What input is acceptabe as an authenticator? How do we securey pass those authenticators to a machine that can vaidate them? How do we et a cient know they have been authenticated? A these questions are answered by the choice of an authentication protoco. Windows 2000 supports three authentication protocos: NTLM, Kerberos, and SSL/TLS. We wi discuss these protocos in detai a itte ater in the chapter. Smart Cards There is a ot of tak in the Windows 2000 documentation about Smart Cards as an identification and authentication mechanism. Exacty what is a Smart Card? A smart card is a credit-card-sized device that is inserted into a smart card reader, which is either instaed internay in your computer or connected externay to your computer. The combination of the card (something you have) and a PIN that you enter (something you know) becomes the identification and authentication mechanism. To provide further security in a pubic key infrastructure environment, certificate information can aso be paced on the card. As you probaby aready know, a certificate is an encrypted set of

3 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 3 of 23 authentication credentias. These credentias are then passed to the system to be used as you access different servers. In order to use certificates in Windows 2000, you must use activate Certificate Services. Authorization When the system aows you to cross any given security perimeter, we refer to that as the process of authorization. You are being given the "authority" to cross the perimeter. When the door opens after you swipe that badge, the system has authorized you to enter a secure perimeter. When NT ogs you on after you enter your username and password correcty, you have been authenticated at the system security perimeter. Access Contro After you have been aowed to cross a given perimeter, there are usuay further contros on your activities within that perimeter. After a, just because you have gotten in the gate doesn t mean the house is unocked too. From a physica security standpoint, that is why you see mutipe security eves within a faciity, with more ocked doors protecting each area. In genera, how access contro is handed on a system eve depends on whether the particuar system invokes share-eve or user-eve security (see sidebar). Share-Leve or User-Leve Security? Share-eve security is the type usuay offered by ess secure peer-to-peer networking systems, such as Windows for Workgroups. Windows 9x can impement either share- or user-eve security. With a share-eve system, access restriction options are rather imited. Typicay, they are Read Ony, Fu Contro, or, at most, the access eve can be set depending on the password suppied. There woud be one password for Read Ony and another password for Fu Contro. A the Read Ony users share the same password to access the share. I ca this "secret knock" security. If you know the secret knock, you get in. Peope being what they are, when a password is out for a share, it typicay ends up being given to unauthorized users for one reason or another. Another aspect of this type of security is that there is ony one checkpoint the share. After you get into the sharepoint, a fies and foders that exist in the share are visibe to you and, if you have fu contro, aterabe by you. User-eve security, on the other hand, requires that each user of a system be uniquey identified. This concept of a unique identifier for users and groups is then used to impement discretionary access contro on resources in the system discretionary because your access depends on your identity and the permissions set on the resource using that identifier. Typicay, discretionary access contros are appied at each eve of a system's resources. For exampe, there woud be a ist governing access to the sharepoint, then to the foder, then to subfoders, and finay to individua fies. This aows an administrator to be very specific with permissions on resource eves. If a user wants to use a resource, he must have correct permission entries on a the ists eading to the resource he wants to access, based on either his persona identity or a group he is a

4 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 4 of 23 member of. In Windows 2000, these permissions ists are caed Discretionary Access Contro Lists (DACLs). Like its NT predecessors, Windows 2000 impements access contros through the use of identifiers that uniquey identify users and groups. It then sets permissions using those identifiers to restrict or aow access using access contro ists attached to the resources. As aways, the system operates on the mode that if there is not an expicit entry on the ist for a user, that user gets no access. There is no such thing as an impied permission in the NT word. In addition, permissions setting is sti the responsibiity of a resource s owner or an administrator who has taken ownership of a resource on a user s behaf. There are a few differences in both the permissions avaiabe and the inheritance mode that Microsoft has impemented in Windows We wi discuss those differences in detai a itte ater in the chapter in the section on "Setting Object Permissions and the New Inheritance Mode." Auditing One requirement of a good security system is the capabiity to track what has happened on your system. Auditing is the security function that watches and then records security events of interest to the system administrator. Like a the other security activities, this may happen at any and a perimeters as needed. I remember one of our door entry systems was protected by a keypad system where we had to swipe our badges and then enter a PIN for entry. Each and every entry was then ogged to a system in the security manager s office for auditing purposes. Windows 2000 impements auditing of many system and access-reated events through the use of an overa security poicy that defines what type of security events to audit. In addition, each Active Directory and fie system object can be protected by a Security Access Contro List (SACL). Secure Authentication Services in Windows 2000 An authentication protoco determines the method a system uses to verify a user s identity and access eves. In Windows 2000, more authentication methods are avaiabe for use than in previous NT systems. Microsoft has accompished this by incuding additiona authentication protoco support to the security architecture. For backward compatibiity with previous Microsoft systems and standaone ogons, Windows 2000 sti supports the traditiona NTLM authentication protoco. As you have no doubt aready heard, Microsoft has aso opted to use the Kerberos security system as the defaut protoco for network authentication. The fina authentication protoco that is supported is Secure Sockets Layer/Transport Layer Security (SSL/TLS). Using this protoco and X.509 certificates, Windows 2000 can authenticate Smart Card users and provide protection for unsecured networks, such as the Internet. NTLM Authentication NTLM is Microsoft s egacy authentication protoco from NT 4. Prior to Windows NT 4.0 Service Pack 4 (SP4), Windows NT supported two kinds of chaenge/response authentication: LAN Manager (LM) chaenge/response and Windows NT chaenge/response (aso known as NTLM chaenge/response). In addition, Microsoft has deveoped a new version of NTLM known as NTLMv2.

5 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 5 of 23 A brief expanation of a three is in order so you can make informed decisions about aowing support for these protocos in your Windows 2000 environment. LM authentication is the weakest of the three protocos because, athough the passwords in LM can be onger than 7 characters, the agorithm aows onger passwords to be attacked in 7-character chunks. Password characters can be drawn from the set of uppercase aphabetic, numeric, and punctuation characters, pus 32 specia ALT characters. In contrast, NTLM uses a 14 characters in the password as a singe contiguous unit and aows owercase etters. Basicay, increasing the ength and character compexity in this manner means that athough an eavesdropping hacker can attack in the same way as with the LM authentication protoco, it wi take far onger for him to be successfu. Naturay, if your users are choosing shorter passwords, whoe words, or bank passwords, NTLM won t hep! NTLM on steroids is caed NTLMv2 by Microsoft. NTLMv2 improves both the authentication and session security mechanisms of NTLM. In addition, the NTLM Security Service Provider (SSP) now aows cients to contro which version of NTLM to use and aows servers to decide which aternatives to accept. Finay, NTLMv2 aows cients and servers to require the negotiation of message confidentiaity (encryption), message integrity, 128-bit encryption, and NTLMv2 session security. NTLMv2 is avaiabe on NT 4 systems with Service Pack 4 or higher. In Windows 2000, you have the capabiity to turn off NTLM support and go with a purey Kerberos mode that provides a higher eve of security for your network. However, you may find that you need to continue NTLM support on your Windows 2000 system for severa reasons. The first reason to continue NTML support is if you have downeve cients and servers that use one of the LM/NTLM authentication protocos isted above. Computers with Windows 3.11, Windows 95, Windows 98, or Windows NT 4.0 use the NTLM protoco for network authentication in Windows 2000 domains. Second, your Windows 2000 machines use NTLM when authenticating to servers with Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains. These first two reasons appy if you have a mixed Microsoft network environment. Other reasons to keep NTLM support have to do with, beieve it or not, UNIX compatibiity. Even though we think of Kerberos as a UNIX standard, you may aso have to consider keeping NTLM support if you have UNIX cients connecting to your Windows 2000 domains. If they are using an SMB cient to connect, whether the UNIX cients are configured for Kerberos or not, they need to use NTLM to connect because of the requirements set forth by the SMB cient. If the UNIX cients are using standard TCP/IP appication protocos, such as Tenet and FTP, excusivey, you can then eiminate NTLM support. Finay, if your Windows 2000 cients are connecting to a UNIX server using an SMB daemon and you want to keep that mode, you wi sti need NTLM. Another option in this situation woud be to turn off the SMB daemon and use an NFS cient for the Windows 2000 boxes. Microsoft provides that cient as part of their UNIX interoperabiity package, Services for UNIX. Kerberos Authentication In Windows 2000, Microsoft is impementing Kerberos version 5 with extensions to support pubic key authentication as the preferred network authentication protoco between Windows 2000

6 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 6 of 23 machines. In this section, we wi discuss the advantages of this decision as we as how Microsoft s impementation of Kerberos works in the simpest possibe terms. As I mentioned before, an in-depth discussion of Kerberos v5 is way beyond the scope of this book. But if you are a nuts and bots kind of person and want a the gory detais of Kerberos, there is good news. Because Kerberos has been around for more than a decade and is an estabished industry standard security protoco, there is ots of information out there on the system. To ook at Kerberos stricty from a Windows 2000 viewpoint, Microsoft has a white paper tited "Windows 2000 Kerberos Authentication." Windows NT magazine has aso pubished a coupe of good, understandabe artices on Kerberos. You can get those archived artices from their Web site at if you are a subscriber. Advantages of Using Kerberos Kerberos has a few advantages over NTLM as an authentication protoco. The number one advantage may very we be that it is an industry standard protoco. Kerberos v5 is outined in RFC 1510 from the IETF and is on standards track. In their whitepaper on Kerberos Authentication in Windows 2000, Microsoft says that their impementation of Kerberos "cosey foows the specification defined in Internet RFC 1510." That s Microsoftese for "we did it our way." To be fair to Microsoft, though, that s true of a standards impementations. From what we have seen of the product so far, it is generay agreed that cross-system authentication between Windows 2000 and existing Kerberosbased authentication systems shoud be possibe. Let s ook at some of the other advantages of Kerberos in the foowing section. Quicker Server Connection Time As we discussed in Chapter 2, with NTLM, an appication server connects to a domain controer to authenticate cients. This happens each time a cient estabishes a session with the appication server. If a cient connects to OFFAPPS1, disconnects and reconnects a few minutes ater, the machines go through the whoe authentication process again. With Kerberos, after the cient and the appications server are both authenticated, and the cient is approved for access, a set of credentias is issued for a session between the two machines. The cient can then reuse those credentias for subsequent conversations with that server. Because no further authentication is necessary, the use of Kerberos speeds up server connection time by eiminating the need to authenticate each time a connection to the same server is made. This can provide a noticeabe improvement for users who are coming in over sower WAN connections. For improved security, these credentias have an expiration time associated with them. You can set that expiration time to match the security eves required in your organization. By defaut, the time to ive on a session ticket in Windows 2000 is eight hours. Mutua Authentication NTLM is a one-way authentication protoco that aows cients to authenticate to a server. How does the cient know it is reay connecting to the server that it is supposed to be connected to and not some hacker s proxy? With NTLM, you don t know and can t be sure. NTLM was designed in an era where servers were assumed to be genuine. This is an invaid assumption in today s open Internet environments. Kerberos, in contrast, is based on mutua distrust. The Kerberos server makes a machines in the domain prove their identity before they are aowed to participate in the domain, even the servers. Through the use of shared private keys, Kerberos can guarantee that a the parties invoved in the

7 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 7 of 23 conversation are who they say they are. Deegated Authentication Windows services often have a need to impersonate cients when accessing resources. For exampe, this must be done when accessing a remote server. NTLM had no capacity to impersonate a cient and access a remote service. Kerberos has a proxy function that aows a service to impersonate its cient when connecting to other services on remote servers. For exampe, if a user is accessing an appication on the Personne server and that appication requires a resource from the Payro server, the Personne server pretends to be the user and passes the user s credentias when requesting authentication on the Payro server. Simpified Trust Management Because Kerberos empoys mutua authentication, it can impement a trust mode that aows for trust reationships that are two-way and transitive. Mutua authentication guarantees that any machine in a domain truy is a member. Kerberos forces servers to authenticate as we, so that a the domain controers are aso egitimate. In view of that assumption, the domain controers become trusted security principas in a mutidomain network and can be organized in a tree of transitive, mutua trust. Kerberos credentias issued in one domain can then be used and accepted anywhere in the tree or forest. Interoperabiity As mentioned earier, Microsoft s impementation of the Kerberos protoco is based on IETF standards-track specifications (RFCs 1510 and 1964) from the Internet Engineering Task Force (IETF). Therefore, the impementation of Kerberos in Windows 2000 gives you a basis for interoperabiity with other networks where Kerberos version 5 is used for authentication. In Windows 2000, Microsoft has impemented extensions to the Kerberos protoco that permit initia authentication using pubic key certificates rather than the conventiona Kerberos shared secret keys. This enhancement aows the protoco to support interactive ogon with a Smart Card. How Kerberos Works How does this paranoid security system work? Get yoursef a cup of coffee and open your mind this can be a itte hard to foow if you've never seen it before. Keep in mind two things as we go aong. First, remember that Kerberos operates on the concept of symmetric (or shared private key) encryption, meaning you must use the same key to decrypt a message as you used to encrypt the message in the first pace. I ca this the secret decoder ring method of encryption. If we both have the same secret decoder rings, with identica keys, we can encrypt and decrypt messages we send to each other. However, if you have the Batman decoder ring, and I have the Superman ring, we can't send secret messages to each other. Kerberos works on this same concept by issuing symmetric keys for authentication and work sessions. Another thing to remember is something I mentioned briefy earier. Kerberos works on the assumption of mutua distrust. It doesn't beieve that anyone is who he say he is unti his identity is proven by his abiity to decrypt messages encrypted in the private key he shares with the Kerberos server.

8 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 8 of 23 Finay, in this shared private key system, there must be a pace that keeps track of and distributes these agorithms. In Kerberos, this function is caed the key distribution center (KDC). In the Windows 2000 impementation of Kerberos, the KDC is hosted in the Active Directory and is, therefore, resident on each and every domain controer. This gives the KDC a the advantages of the mutimaster domain controer repication and faut toerance. So in this discussion, whenever KDC is mentioned, think "domain controer." In theory, the functioning of Kerberos is rather simpe. A centraized security server (or repicated servers) issues each security principa in their domain a secure key to tak to the Kerberos server. This is often referred to as the ong-term key. Long-term keys are typicay derived from the user s password and other information through a one-way hashing agorithm and stored in the oca credentias cache. The credentias cache is an area of protected voatie memory that is destroyed when the user session is ended. Each security principa has a different key than its neighbor, and the security server is the ony other party that knows what each key is. This key is used to get another set of credentias, caed a ticket-granting ticket (TGT), that aows a user to request access to other servers. If one security principa wants to tak to another security principa Mary Jo wants to access that OFFAPPS1 server, for exampe Kerberos has to issue a session key (sometimes caed the shortterm key) to Mary Jo and the appications server so that those two can send secure messages to each other. Each session key is unique and has an expiration time on it to further enhance its security. Session tickets can be renewed if the administrator chooses to set this up as part of the domain's Kerberos poicy. See, simpe...in theory! Let's ook at the impementation of the detais. Logging On We' start with Mary Jo's ogon. When Mary Jo ogs on to her oca machine, the Kerberos cient software running on her workstation converts her password to an encryption key and saves the resuting key in its credentia cache. Then the cient sends an authentication request to the Kerberos server. The first part of the authentication request identifies Mary Jo and the name of the service for which she is requesting credentias. Because this is her ogon, she is requesting credentias for the ticket-granting service. As I mentioned, most peope don't og on to the domain to tak to the security system, they want to access appications and other resources. When she has ogged on successfuy to the domain, the KDC wi issue her a TGT that she wi use when taking to the Kerberos server (during this session) to request access to other servers. The second part of this authentication request message contains pre-authentication data that proves Mary Jo knows the password. This is usuay a timestamp encrypted with Mary Jo's ong-term key. Other forms of pre-authentication data can be accepted by the protoco. When the KDC receives this package, it checks its database for Mary Jo's ong-term key, decrypts the pre-authentication info, makes sure the timestamp is within aowed parameters, and then issues Mary Jo a TGT that she wi use to obtain future session tickets. To accompish this transaction, the KDC invents a session key for itsef and Mary Jo to use for their conversations. Then, it encrypts this ogon session key with Mary Jo's ong-term key. Next, it embeds another copy of the ogon session key and other authorization info about Mary Jo. It encrypts these two things in its own ong-term key. This portion that is encrypted in the KDC's ong-term key is the actua TGT. When Mary Jo's station receives this repy, it decrypts the session ticket using Mary Jo's ong-term

9 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 9 of 23 key and stores the session ticket in its credentias cache. It aso extracts the TGT, sti encrypted in the KDC s ong-term key, and stores it in the credentias cache. Accessing Other Servers Now that Mary Jo has been authenticated onto the domain and has a TGT to request access to other resources, she can ask for permission to tak to the OFFAPPS1 server. From the user standpoint, a this is invisibe. Mary Jo probaby goes to My Network Paces, searches the Active Directory, or cicks the Microsoft Word icon on her desktop. When she does, the Kerberos cient on her machine sends a Ticket Granting Service Request message to the KDC that incudes Mary Jo s name, an authenticator (again, usuay a timestamp) encrypted in the ogon session key, the TGT (sti encrypted in the KDC s ong-term key), and the name of the service for which Mary Jo is requesting a session key (OFFAPPS1, for exampe). When the domain controer receives this message, it decrypts the TGT with its ong-term key and extracts the ogon session key it embedded there. It uses that key to decrypt the authenticator portion of the request. If the authenticator is within bounds, the KDC creates a session key for Mary Jo to use when taking to the appications server. Now, at this point, the KDC coud send the session key to Mary Jo and a second message to the appications server with that same session key in it. This method of key distribution woud be inefficient because it requires the KDC to send two messages. Probems woud aso be caused if there was a network disturbance and Mary Jo tried to use her session key before the appications server had received its copy of the key. In order to overcome these potentia probems, the KDC s response to Mary Jo s request for access to the appications server ooks ike this: the response contains two parts. The first part is the session key for the Mary Jo- OFFAPPS1 session, encrypted in the Mary Jo-KDC ogon session key. In the second part of the response, the KDC embeds a second copy of the Mary Jo-OFFAPPS1 session key and Mary Jo s authorization data and encrypts this second portion in the OFFAPPS1 server s ong-term key. When Mary Jo s machine receives this response, it decrypts the first part of the message and stores the OFFAPPS1 session key in its credentias cache. It then extracts the second part of the message, the part encrypted in the OFFAPPS1 ong-term key, and stores that in its cache as we. When Mary Jo goes to access the appications server, a message is sent from the Kerberos cient on her machine to the Kerberos cient on the appications server. This message is caed a Kerberos Appication Request and contains an authenticator encrypted in the Mary Jo-OFFAPPS1 session key and the ticket that was sent back to Mary Jo s machine encrypted in the appications server s ongterm key. Upon receipt of the Appication Request, the appications server decrypts the session key and Mary Jo s authorization data using its own ong-term key and then uses the session key to test the authenticator that is encrypted in the session key. If the authenticator checks out, it sends a response to Mary Jo s machine, and the conversation between Mary Jo and the appications server can proceed. I warned you! Is that coffee cod yet? And that was the executive overview version of ogging on within a singe domain! When you are working within an Active Directory structure that has more than one domain, Kerberos accepts authentication credentias from other domains in the tree or forest. The way that those are forwarded from one domain to another is a itte more compicated than what we have discussed here. Again, if you want the fine detais, go to the Microsoft white paper on Kerberos authentication. I think this discussion was enough for you get the idea, though. I m sure you

10 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 10 of 23 can see why Kerberos is considered a good authentication protoco. Remember, Kerberos is just that, an authentication protoco. It does very itte to hep with impementing access contros after the initia ogon to a machine or service. A right, in our exampe, Mary Jo has been aowed to og on to the appications server, but can she run MS Exce? Kerberos pays a sma roe in determining the answer, but those kinds of permissions questions come under the mante of discretionary access contro. Secure Sockets Layer/Transport Layer Security The fina authentication protoco supported in Windows 2000 is SSL/TLS. This protoco is aready supported in other Microsoft products, such as Exchange and IIS. It is used primariy to authenticate Smart Card users using a combination of this protoco and X.509 certificates, and to protect connections on unsecured networks. It can be used to secure your emai and I net (Internet and intranet) appications. Security Access Tokens As mentioned earier, in order to impement discretionary access contro, each security principa must be uniquey identified to the system and there must be a mechanism to compare that identifier to a ist of approved users for each resource in the system. In Windows 2000, as it was in NT 4, security principas are uniquey identified by a SID (Security Identifier), a unique aphanumeric vaue consisting of two parts. The first part identifies the domain in which the SID was issued, and the second part uniquey identifies the account within that domain. Keep in mind that in Microsoftese, a domain can be the individua machine if it is a standaone box or a member of a workgroup. Regardess of the scope of the "domain," Microsoft guarantees that a SID wi aways be unique and never reused. SIDs are used to identify individua users as we as groups within the domain. These SIDs are used by the Loca Security Authority (LSA) on each oca machine to buid a Security Access Token (SAT) that foows a user s processes throughout the system. The SAT contains the user s individua account SID as we as a the SIDs for any groups he is a member of. Based on those SIDs, a ist of system rights is appended to the access token as we the right to og on interactivey to a domain controer, for exampe, or permitted ogon hours. In standaone machines, workgroups, and domains not using Kerberos for whatever reason, NTLM is used to buid SATs just as they were buit in previous versions of NT. In a native mode domain where Kerberos authentication is enabed, the KDC prepares authorization data in two steps to assist in the access contro process. Step one takes pace when the KDC prepares a TGT for a user. When the TGT is requested, the KDC queries the Active Directory for the user's account. In the attributes of the account there is a fied for the user's SID and another attribute fied for the SIDs of the security groups the user beongs to. Both of these attributes are returned and embedded into the authorization data fied of the TGT. In a mutidomain environment, the KDC aso queries the Goba Cataog for universa groups that incude the user's SID or the SIDs of any of the domain security groups of which the user is a member. If those are found, the SIDs for the universa groups are aso incuded in the authorization data fied. Step two happens when the KDC prepares a session ticket for conversations between two parties. When a user requests a session ticket for a particuar server, the domain controer (KDC) in the

11 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 11 of 23 server s domain copies the authorization fied data from the TGT and embeds it in the session ticket s authorization fied. If the server is in a different domain than the one where the user account was created, the KDC in the server s domain wi check its Active Directory for any domain oca groups that contain either the user SID or group SIDs that are aready in the authorization fied. If it finds any, it adds these to the session ticket s authorization fied before it is passed on to the target server. This authorization data is signed by the KDC. Wait a minute, what happened to the LSA and the access tokens? They are sti in existence. When this session ticket is received by the target server, the LSA process takes the information in the authorization fied and creates an access token for that user on the oca machine. At that point, the functioning of the system is essentiay the same as an NT 4 box. Discretionary Access Contro Lists (DACLs) Now that the user is authenticated onto the server, the user s SAT can be checked against the permissions ist for the objects she wants to use on that server. The header of every object in the system contains a security descriptor with a ist of permissions embedded in it. This ist is caed the Discretionary Access Contro List (DACL) and contains SIDs and permissions eves for each SID isted. If there isn t an expicit entry on the ist for a user or one of her groups, it is assumed by Windows 2000 that no access shoud be aowed. The permissions ist is maintained by the owner of the object. Ony the owner is aowed to grant and revoke permissions to the resource. Administrative Ownership of Resources In the event of an emergency, an administrator can take ownership of a resource and even reset permissions because he is the new owner. This abiity is usuay exercised when unexpected events happen (ike poor od Bob gets hit by a bus at unch) and it is necessary to transfer ownership to another user. To take ownership, the administrator woud go to the Properties screen of the resource and seect the Security tab. On the Security screen, seect the Advanced button and, finay, the Ownership tab shown in Figure 3.2, and seect the new administrative owner. An administrator can eect to set himsef as the owner, in which case the resource s size woud be counted against his persona disk quota space if disk quotas are being used. He can aso eect to set the ownership to the Administrators group. The Administrators group is exempt from disk quotas. Figure 3.2 Changing ownership of a resource. To pass ownership to another user, the administrator can go directy to the Access Contro Settings screen by using the Advanced button on the Security tab of the Properties screen. From there, cick on the Add button, and seect the desired user. Then, the Permission Entry screen wi pop up. Now, scro down to the Take Ownership permission on the Permission Entry screen and put a check in the Aow box to enabe the chosen user to take ownership of the resource. Now, when that user ogs on and accesses the Security Properties for that object, he wi

12 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 12 of 23 have the abiity to go to the ownership tab and seect himsef as the new owner of the object. One interesting thing about the ownership interface: In the ist of users and groups that are dispayed to seect from, ony users and groups that have the permission to take ownership wi ever show up. As a further security precaution, ony the currenty ogged-on user and his authorized groups wi show up in the ist. For exampe, if I were ogged on and had been given the permission to take ownership of a resource, the ist woud show my "Lori" account as we as the "Administrators" group for my machine. Because ownership can ony be taken and never given, this makes sense. Otherwise, an unscrupuous administrator woud have the abiity to take ownership and then give it back without the resource s true owner ever knowing about it. Not a good thing, especiay if it s the payro fie or strategic, sensitive corporate information. Setting Object Permissions and the New Inheritance Mode One of the key things to remember about Windows 2000 and permissions is that there are different types of objects you can set permissions for. It can be a itte confusing at first, but if you are used to Nove or Banyan, or are famiiar with the idea of shares in the Microsoft word, I think you have no probems here. When we discuss permissions in Windows 2000, we tak about setting permissions on fie system objects or directory objects. In this section, we discuss setting permissions on fie system objects. Those woud be imited to fies, foders, and shared foders. We tak about directory object permissions in the next chapter. The interface for setting permissions on both types of objects, fie system and directory, is amost the same. Aso, the inheritance mode is very simiar, so when you get it for fie systems, the directory shoud be a breeze. Setting Fie System Permissions When setting permissions for fie system objects, we are actuay going to imit access to the object. As with NT 4, the defaut permissions mask on the Windows 2000 fie system is basicay everyone has compete access. If you are coming from the Nove or UNIX word, you are probaby breathess with shock right now. Instead of opening access up to an NT/Windows 2000 system ike you woud in other environments, you must do the opposite. You must shut it down. If you don t beieve me, just go have a ook at your system voume. By defaut, it wi say Everyone, Fu. There are exceptions to this mask in Windows The %systemroot% directory where Windows 2000 is instaed, as we as the Program Fies and Documents and Settings directories, has a different defaut mask that aows average users ess access and administrators fu access. But, trust me, amost everything ese is wide open. And remember, because the guest account is part of the Everyone group, that means whatever Everyone has, Guest has if the account is enabed. If it is enabed, anyone without a vaid account wi be ogged on as a guest. It s kind of ike putting out a big wecome sign for Hackers, Inc. That s why we re going to spend a itte time on setting permissions. Because Windows 2000 uses discretionary access contro, you can think of access to a resource as being simiar to passing through severa ocked doors in a buiding to get to your office. In order to access a fie, the user must have a the right "keys" to get through the fie system path that eads to the fie, as we as the correct key to open the fie. Having the right keys means having the necessary permission entries on the DACLs of the voume, foders, subfoders, and finay the fie. If the right permission eve is missing at any of these preiminary DACLs, access to the resource may be denied.

13 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 13 of 23 If it is a shared resource, and users are coming in over the network to access it, they must aso have correct permissions on the sharepoint to proceed with their entry into the fie system. Standard Permissions Sets As with NT 4, there is a set of standard permissions for fies and foders that you can use to make your ife as an administrator easier. You aso have the abiity to set very specific "specia" permissions on a fie system resource if necessary. We saw an exampe of this in the sidebar on taking ownership. Setting standard permissions can be accompished using the first screen of the Security Properties diaog box as shown in Figure 3.3. To get to this diaog box, right-cick on the desired object, seect Properties from the menu, and then seect the Security tab. Figure 3.3 Security Properties diaog box used for setting standard sets of permissions. This diaog box is just the first of three that you can use to set permissions on resources. The permissions set shown appies to the highighted user or group. In this case, our screen shot shows the permissions for the Administrators group. To see the other permissions eves, you woud need to move the highight bar to the appropriate group or user. Adding and removing users from the ist is very easy. Simpy choose Add or Remove. This part reay is intuitive! Tabe 3.1 shows the standard permissions sets for fies and foders and exacty what those sets mean in Windows Tabe 3.1 Standard Permissions Standard Permission Read Specific Permissions Granted as a Resut List Foder/Read Data Read Attributes Read Extended Attributes Read Permissions Read and Execute Synchronize List Foder/Read Data Read Attributes Read Extended Attributes Read Permissions Synchronize

14 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 14 of 23 Modify Traverse Foder/Execute Fie Create Fies/Write Data Create Foders/Append Data Deete List Foder/Read Data Read Attributes Read Extended Attributes Read Permissions Synchronize Write Attributes Write Write Extended Attributes Create Fies/Write Data Create Foders/Append Data Read Permissions Synchronize Write Attributes List Foder Contents Write Extended Attributes List Foder/Read Data Read Attributes Read Extended Attributes Read Permissions Synchronize Traverse Foder/Execute Fie

15 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 15 of 23 Fu Contro Change Permissions Create Fies/Write Data Create Foders/Append Data Deete Deete Subfoders and Fies List Foder/Read Data Read Attributes Read Extended Attributes Read Permissions Synchronize Take Ownership Write Attributes Write Extended Attributes You might have noticed the new coumn for "Deny" in Figure 3.3. In NT 4, you had the option to set a "No Access" fag, but you coudn t get specific about what permissions you wanted to deny someone. For exampe, if you wanted to deny someone the Write permission in NT 4, you had to set a the other permissions to aow access and eave the Write permission check box bank. As you can see from the interface, you can now expicity deny someone the right to write! Denying Fu Contro has the same effect as the NT 4 "No Access" fag. A the Deny permission entries in a DACL wi be at the top of the ist. This improves the efficiency of the permissions checks. If a person or group is denied any one of the requested set of permissions, they are thrown out at the top of the ist rather than having to read the whoe DACL to determine that they don t have that Write permission. When an access request comes into the system, the permissions that are requested are considered a set. This means that whether a person is aowed access is an "a or nothing" proposition. Let s say, for exampe, that I tried to open a document. This woud spawn severa requests. One request woud be to Read and Execute the program s.exe fie and its associated DLLs, pus there woud probaby be a second request for Modify access to the document fie. You can see from the standard permissions ist in Tabe 3.1 what Modify means. If I am denied any of those permissions on the document, I wi receive an "Access Denied" message. I wi not get a message that says, "You can Read and Add Data to this document, but you can t Deete the document." That s what I mean by "a or nothing." Permissions are cumuative in Windows 2000, as in NT 4. If a user is granted Read permission, but a

16 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 16 of 23 group he beongs to is granted Write and Deete, the user s access is Read, Write, and Deete. When trying to determine a user s access eve to a resource, there are three ways a permissions check can be terminated. The DACL entries wi be checked unti one of the foowing three conditions is met: The fu set of requested permissions has been satisfied by SID entries for the user or the groups of which the user is a member One or more of the requested permissions has been denied for the user or one of the groups of which the user is a member The entire DACL has been checked and there was no entry for one or more of the requested permissions; therefore, access is assumed to be denied If you are troubeshooting a permissions probem and need to know the actua ordering of the DACL, you can view the DACL by using the Advanced button on the Permissions tab. This wi bring up the screen in Figure 3.4, which shows the ordering of the entries. From an administrative standpoint, you might find this screen easier to use because it gives you the whoe ist and the permissions eves without having to move the highight bar. If you want to know specificay which specia permissions have been set, simpy highight the entry in question and cick on the View/Edit button. This wi take you to the Specia Permissions diaog box. Figure 3.4 Access Contro Settings screen used to view the ordering of the DACL on objects. Setting Specia Permissions As was mentioned earier, an administrator or owner of a resource can be very granuar about what permissions they want individuas to have. Besides being abe to expicity Aow or Deny a permission, the screen shot in Figure 3.5 shows the specia permissions that can be set on foders or fies. The interface is a itte more sef-expanatory than it was in NT 4. Figure 3.5 Permission Entry screen used to view the detais of a particuar DACL entry. Naturay, whenever possibe, you shoud use the standard permissions and set permissions using groups instead of individuas. Doing these two things and using the capabiities of the new inheritance mode shoud make this part of your job as an administrator much easier. Permission inheritance wi be discussed in the next section. Shared Foder Permissions There are a few things to remember about shared fie system resources and permissions. First, a share is nothing more than a foder that has been designated for network access. If you have a foder caed DOCS that you share out, a user who ogs on ocay to your machine wi be governed by the DACL on the oca fie system foder. When you share the foder out, you have the option to set an additiona DACL for the share that woud govern users coming into the resource over the network. Oh, and by the way, guess what the defaut permissions mask is on a shares...that s right: Everyone, Fu. If there is a

17 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 17 of 23 confict between the share DACL and the foder DACL, the most restrictive permissions set is used. For exampe, if you have an entry for Bob on the share DACL with Fu Access set, and the foder DACL aso has an entry for Bob, but with ony Read access, Bob wi ony get Read privieges. There are fewer choices for standard permissions settings on a share. Basicay, you have Read, Change, and Fu Contro. The capabiity to set specia permissions is not avaiabe at a on the share eve. You can sti set those specia permissions at the foder eve if you need them, and they wi appy for your network users as we. The standard permissions that can be set on a share are shown in Tabe 3.2. Tabe 3.2 Standard Share Permissions Standard Permission Read Specific Permissions Granted as a Resut Traversing subfoders Viewing data in fies and running programs Change Viewing fienames and subfoder names Adding fies and foders to the shared foder Changing data in fies Deeting subfoders and fies Traversing subfoder Viewing data in fies and running programs Fu Contro Viewing fienames and subfoder names Adding fies and foders to the shared foder Changing data in fies Changing permissions (NTFS ony) Deeting subfoders and fies Taking ownership (NTFS ony)

18 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 18 of 23 Traversing subfoders Viewing data in fies and running programs Viewing fienames and subfoder names Permission Propagation and Inheritance In NT 4, you coud set permissions at the top eves of a fie structure and then push that permissions mask down through the structure to subfoders and fies, as ong as you were the owner of the resources. You had some contro over how far you wanted to push the mask, but there weren t a ot of options in the interface. After you set a new mask and chose to push it down, NT 4 had the rather annoying habit of repacing a permissions. So, if you had set specia permissions somewhere down in the bowes of the fie structure, these were erased and repaced with the new mask. There was no way to preserve those expicity set permissions. Pretty aggravating after you had gone to a the troube to set them in the first pace! Windows 2000 has improved on that mode by recognizing two sets of DACLs on a resource: the inherited DACL and the expicit DACL. Now, it is possibe to set a defaut mask at the top eve, push it down, and sti keep those specia permissions you had to set for Bob ast week. Naturay, there are some new rues to know with this new capabiity. I mentioned previousy that Deny permissions woud be isted at the front of the DACL to improve access request response times. It s simpy more efficient that way. We, et s compicate that picture just a itte. If you have both types of permissions set on a resource, expicit and inherited, the expicit permissions are aways checked first. So, the rea search order on that resource woud be Expicit Denies, Expicit Aows, Inherited Denies, and finay Inherited Aows. Figure 3.6 shows the Access Contro Settings screen. I tod you earier that this screen was the easiest one to use to troubeshoot permissions, and you can see why if you ook at it cosey. I have created a DACL with both inherited and expicit permissions, as we as an Aow and a Deny for each type. They are isted on the interface in exacty the same order they are searched by Windows If you ook cosey at the first two entries, you wi see that the icons to the eft of the entries are nice and cear. These are expicit entries. The icons for the next two entries ook a itte fuzzy and faded. It s not your eyes; reax. These are the inherited entries. The icons are designed that way to give you a graphica cue to et you know which ones are expicit and which are inherited. As you can see in that same figure, the expicit deny is isted first, foowed by the expicit aow, then the inherited deny, and finay the inherited aow. The DACL wi be searched in that order, and the three conditions isted earier in the chapter wi be used to terminate the request. That means expicit permissions wi override inherited permissions. In our ist, Lori wi be denied Read access even though she inherits a Fu Contro permission from the parent foder. This happens because when the request comes in for access, the system wi see the expicit deny isted first, terminate the request with an Access Denied message, and never search the ist any farther, so it woud never even see that Fu Contro entry. The ogic here is that if the owner of the resource went to a the troube to expicity set a permission for Lori that is different from the inherited mask, there must be a reason

19 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 19 of 23 and therefore the expicit must be the more important permission. Figure 3.6 Using the Access Contro Settings screen to view and troubeshoot fie access probems. If you don t need that much detai, you can get some of the same information on the first Security tab of the resource. Notice that inherited standard permissions are indicated by gray backgrounds in the check boxes, ike those in Figure 3.7, whie expicity set permissions have cear backgrounds, as you can see in Figure 3.8. As aways, you wi have to move the highight bar around to determine who has what. Figure 3.7 Using the Security Properties screen to view the inherited permissions set. Figure 3.8 Viewing expicit permissions using the Security Properties tab. There is one sma gitch in this first interface that I want to make sure you are aware of. Look at Figures 3.7 and 3.8 again. Notice that there is ony one entry for "Lori" on the first properties page, even though you can ceary see both entries isted on the Access Contro Settings screen back in Figure 3.6. Be aware that mutipe entries for the same account might not show up. Even worse, the genera page shows ony that Lori has inherited Fu Contro permissions. It says nothing about that Expicit Deny for Read access. This coud be very deceiving (and aggravating) if you are trying to troubeshoot a probem. This is another argument for just going to the Access Contro Settings screen in the first pace. So, if these expicit entries are going to be preserved, what do you do if you mess up the mask and need to reset the permissions to the inherited defaut? It takes a itte work and forethought, but you can sti recover from this type of mistake. One option is to simpy go in and remove the offending expicit entries and then propagate that mask down to the fies and subfoders (I te you how to do that in the next section). If the mask is so messed up that you can t determine for sure which entries are good and which are bad, but you know they are correct above that point in the tree, you can simpy move up in the fie tree to the eve where they are correct and choose to propagate the correct mask from there. If you are at the top eve and moving up is not an option, you can do it the odfashioned way. If there is a correct mask anywhere on the partition, copy the tree structure so that it becomes a chid of the resource with the correct mask. Then, check that the permissions are correct and move the structure back to its origina spot. Remember the mantra: move retains, copy inherits. It works for permissions and compression states. This method ony works within a singe partition, however, because moves across partitions behave ike copies, and in that case, a permissions wi be inherited from the target parent foder. You can think of propagation of permissions as pushing permissions down the fie system tree. Inheritance, on the other hand, has to do with receiving a permissions mask that has been propagated. On the interfaces I have shown you, there are actuay a coupe of entries that dea with permission propagation and inheritance. Let s ook at those two functions and their associated interface entries separatey so you get a better understanding of each. Propagation Contros

20 Chapter 3: Authentication and Resource Protection in Windows 2000 Page 20 of 23 There are basicay three screens we have discussed that are part of the permissions modue in Windows 2000: The Security Properties screen, where you see the standard permissions The Access Contro Settings screen, reached by using the Advanced button on the Security Properties screen The Permission Entry screen, which gives the detais for each entry on the DACL The ast two screens have entries that contro propagation. Earier we discussed the probem of needing to repace an incorrect permissions mask that contained expicit entries. I mentioned that this is a probem because those expicit settings are preserved by defaut and checked before the inherited entries in the DACL. If that s the case and you want to repace the whoe set of permissions on a subfoders and fies, simpy go to the Access Contro Settings screen and check the box shown with the arrow in Figure 3.9. Figure 3.9 Using the Access Contro Settings screen to repace expicit permissions and propagate the desired mask down through the fie tree. Because this is such a drastic action, you get a warning message teing you that this wi remove a expicity set permissions and turn for inheritance for a subfoders and fies. If you are famiiar with NT 4, you shoud know that turning on this check box makes the system act ike the NT 4 fie system did when you eected to repace permissions on subfoders and fies. As you might imagine, the system defaut is for this check box to be bank. If, on the other hand, you ony want to propagate seected DACL entries or have a need to finey contro how far a particuar entry shoud go, use the Permission Entry diaog box. As you can see in Figure 3.10, by using this interface, you can be very seective about just where you want this particuar entry to be appied. I think this is pretty intuitive. Just be aware of the granuarity you have in this interface. By the way, the defaut is for the entry to be appied to "This foder, subfoders and fies." Figure 3.10 Using the Permission Entry diaog box to precisey contro the appication of permissions and imit propagation to the desired eve. At the bottom of that diaog box you wi notice another check box. This one says "Appy these permissions to objects and/or containers within this container ony." If you turn this feature on, propagation wi be imited to the foder and its immediate chidren. Its chidren are defined as the subfoders and fies that exist within that foder. The grandchidren objects the fies that exist in a subfoder, for exampe wi not have the mask appied to them. These two boxes work together. If you do not imit the propagation by checking the box at the bottom of the screen and seect to have these permissions appied to "Subfoders ony," a the subfoders at a eves beow this one wi have the permissions reset. So, if you have five eves of subfoders, a wi be affected. On the other hand, if you choose to imit the propagation, ony this foder and one