From the operating system point of view, everything creatable on Windows NT is securable. By 'creatable' we mean any object (excuse our overloaded usage of the word object here again) that either the system can create or the programmer may create using programmatic means. This includes the standard files and devices, but also applies to processes, threads, and even more mundane things like a semaphore, a piece of shared memory, or a registry key. By 'securable' we mean that specific access rights can be associated with it, and those rights can be verified by the OS when the object is accessed.
The implementation for such security handling is buried deep, deep in the kernel space. Essentially, every new object created gets a handle which can have a security descriptor associated with it. We'll talk about the composition of this security descriptor in a section coming up soon.
A domain is an administrative grouping of networked machines (and all the users plus resources associated with these machines). The domain controller machine in a domain stores and authenticates all users in the domain for network resource access. This means that the user and password database is stored and managed by the domain controller machine. Windows NT domain implementation allows for a Primary Domain Controller and a Backup Domain Controller. The Backup Domain Controller sits on the network and gets a replication of all modifications and changes to the Primary Domain Controller. If and when the Primary Domain Controller should go out of commission, the Backup Domain Controller can take over as the Primary Domain Controller, ensuring continued network operation. Note that it isn't currently possible to perform any administrative operations on the Backup Domain Controller while the Primary Domain Controller is still alive and operating.
For proper secured operations, every machine within a domain should authenticate user IDs and passwords against its domain controller.
For every large installation, it's possible to organize multiple domains in one or more 'trusted relationship'. This basically allows all users in one domain to access resources on another (access rights are still checked, of course). Operationally, a domain controller will authenticate a user against a trusted domain should it fail to authenticate the user locally. This allows for a degree of separation between the functions of user-account administration and shared resource management.
Each and every time a user on a secured Windows network is authenticated, three pieces of information are required. The authentication authority (i.e. the domain which the user belongs to), the user ID, and the password. For example:
UserID: WRXDOMAIN\JULIAN
Password: xyzzy
indicates that the authentication authority is the domain controller of WRXDOMAIN, the user ID is JULIAN, and the password is xyzzy.
If the authentication authority isn't explicitly named, it will always default to the local authentication authority. This means the local registration database on a non-domain controller Windows machine, and the domain registration database on a domain controller machine.
To make administration and assignments of access rights somewhat easier, Windows NT Server-based networking allows the assignment of users to groups. A user is considered a 'member' of a group if the group is defined to be containing the user. Access rights can then be assigned to the object, allowing or denying access to a group instead of spelling out all its members.
Groups which contain purely users from a single domain are called global groups; these groups are assigned and tracked on the Domain Controller. Groups which are administered local to a machine are called local groups and can contain users on the local machine, users from trusted domains, or global groups.
Each user on a secured Windows network has an account, the account contains information such as password, groups that the user belongs to, profile-specific items, hours allowed to logon, etc. It also contains something called a Security ID (or SID). An SID uniquely identifies the user in both 'space and time'. What this means is that no two SIDs generated will ever be the same due to the generation algorithm. It contains information which can be used to uniquely locate the user's account information on a registration database. Notice that a group can also have its own SID.
As mentioned earlier, every elementary operating system object created by the operating system can be associated with a Security Descriptor. This descriptor contains the following important pieces:
| Information Contained | Meaning |
| Owner | Owner of the object, qualified by authentication authority. |
| Group | Group that the owner belongs to, qualified by authentication authority. |
| Discretionary Access Control List (DACL) | A set of access rights set by owner or administrator. |
| System Access Control List | A set of access rights set by the system for system operations. |
The discretionary ACL can be used to specifically allow or deny access to the object by certain user and/or groups. The OS provides set and query operations to this descriptor. It also provides APIs to assist in manipulation of access lists, perform access checking, or assist in generating operating system based audits.
Let's now take a look at what Access Control Lists (ACLs) are.
An access control list consists of zero or more Access Control Entries (ACEs). Each ACE will contain:
ACCESS_ALLOWED_ACE_TYPEACCESS_DENY_ACE_TYPEThe access control list within a security descriptor that can be changed by applications or users programmatically is called the discretionary access control list (DACL). All SDs and the associated ACLs are stored in compact binary form.
It's interesting to note that an object which has an SD with a DACL containing no ACE entry is deemed to be explicitly inaccessible to everyone, while an object that has an SD with no DACL (i.e. set to
) is accessible by everyone.NULL
Historically, programmatic modification of ACLs has been a very complex procedure requiring painstakingly careful coding (and testing since you can easily lock up a machine or a domain with faulty ACL modification code). The recent release of Windows NT 4.0 Service Pack 2 has fixed this problem through the implementation of a well-tested body of code in the form of a reusable COM based software component! This provides an interface called
which ActiveX/COM programmers can readily reuse in situations requiring modifications to ACLs.IAccessControl
ACLs are associated with static objects such as files, devices, and users. For dynamic objects in the operating system (things that come and go relatively quickly), such as processes and threads, they have associated with them something called a security access token. It's this security access token which enables a server to impersonate a client after authentication. Among other information, the security access token contains the following very important information:
Since it's always servers (or threads) which actually access protected resources, it's important that threads can carry with them a context for security. The security access token is such a context.
A thread of execution assumes an alternative personality (i.e. impersonates others) by switching security access tokens. The same thread can later revert back to itself by switching back to the base process's security access token.
Client credential refers to the set of user ID and password information maintained by a server on behalf of a calling client. This is often required, in addition to an impersonation token, to access networked resources on other networked nodes.
We've been talking about authentication thus far as if it just magically happens between the client seeking authentication and the server performing the authentication. If the client simply sends the textual user ID and password over the network to the server, the system can't be totally secure because other nodes on the network can easily capture the user ID and password, and wreak havoc on the server with this information.
Since so much of the Windows security implementation rests on dependably robust and secure authentication, the above simple scenario can't be depended upon for proper authentication.
Instead, Microsoft has designed an elaborate architecture for handling authentication. This architecture allows the actual method of authentication to be abstracted away from the user using the authentication service. As a side benefit, it allows arbitrary extensibility through the 'plug-in' of new authentication providers. This architecture is frequently referred to as the Security Service Provider Interface (SSPI).
The following diagram shows how the SSPI fits in with the rest of the security implementation.
The architecture clearly separates the user of the security services from the provider of the services, and allows newer service providers to 'plug-in' and function with existing application using the SSPI services.
While the architecture is indeed elegant, the only easily usable default security provider for Windows NT 4.0 is the NTLM security provider (or NTLMSP). As a bonus, the client portion of the NTLM security provider is also implemented on Windows 95 so that Windows 95 client workstation can participate in the network.
Since this is all we've got today, it may be worthwhile to understand how NTLM works. The key element here is that the user's password is never transmitted across the wire during authentication. This is both NTLM's strong point (for security) and its weakness. We'll cover the weakness part later, but first let's see how authentication can be performed without sending the password over the wire. When a client application supplies the authentication authority, user ID, and password triplet to the client portion of the NTLMSP, the following happens:
So far so good: only an encrypted response is sent across the wire, but not the actual password. However, since the server actually never receives the password, the server will have no way of using the password to access other resources that user would have access to. Specifically, these may be network resources (i.e. files, databases, etc.) that the user would normally be able to access. This is one weakness of NTLMSP, significantly reducing the possible tasks which the server can perform on behalf of the client.
It's anticipated that the Kerberos security provider will be available with Windows NT 5.0 in the future. It's based on a mature public standard originated from MIT called MIT Kerberos V5 and endorsed by the Internet Engineering Task Force for interoperability. This new security provider is expected to provide improved performance, scalability and flexibility over the NTLM implementation. Most important of all, it will eliminate the problem we've cited with the NTLM provider.
The NT File System format (called NTFS), although not new, is an essential piece of the Windows NT security puzzle. While NT supports alternative file format for hard disk, such as FAT and HPFS, one must make use of NTFS to enable a fully secured system. Besides offering higher performance and less fragmentation with large disks, it is the only NT-supported disk format which allows ACLs to be associated and stored with files and folders. This capability is vital to the proper operation of a secured Windows network.
As a bonus, NTFS also supports optional journalizing of all disk transactions, allowing the file system to be totally recoverable against disk failures.
Take a careful look at the diagram in the previous section, and you'll notice a box called 'Authenticated RPC' under the 'DCOM Security' box. This implies that authenticated RPC, whatever it is, is the foundation upon which DCOM security is built on. It would be wise, then, for us to take a look at what authenticated RPC is about.
You'll frequently see the mention of Secure RPC as well. They actually refer to the same thing. Secure RPC can be viewed as where authenticated RPC is heading in the near future.
We've learned that DCOM (or COM for that matter) is based on RPC (or LRPC) as the interprocess communications mechanism. We also learnt that RPC can operate over a variety of network transports, including TCP/IP, IPX and named pipes. The named pipe protocol has provided authenticated connections across networks long before the arrival of RPC. Unfortunately, other TCP/IP or IPX based protocols don't offer such features.
By building in code which will call the SSPI service, and bundle additional security information 'on-the-wire' in the runtime implementation of RPC, Microsoft has created authenticated RPC which can operate over all transports supported by the raw RPC implementation.
This can be viewed as a layer of software on top of RPC (but since it's implemented in the RPC runtime code, it can be treated just as a variant of RPC) which provides a secured channel for intermachine procedure calls. The specification for Secure RPC has five levels of security:
| Security Level | Meaning |
| NONE (1) | This is regular RPC with no security ramification. |
| CONNECT (2) | Authenticate the client connection during the connection phase (i.e. when the initial TCP/IP socket is established under TCP/IP). |
| CALL (3) | Authenticate the request for each and every interface call. |
| INTEGRITY (4) | Authenticate and verify that the request packets received have not been modified. |
| PRIVACY (5) | Perform all of the above and encrypt the data packets for transmission of the wire. |
Obviously, level 5 security would be very CPU-intensive when performed on a packet level. For performance reasons only the CONNECT level of security is implemented on Windows 95 clients. The symmetric connection nature of RPC requires both ends of an RPC connection to be at the same security level. This means that most applications or software components must work on the CONNECT level of security, or below, if it is ever to accommodate Windows 95 clients.
So far, Windows NT appears to be more secure than Windows 95. We have always been saying '...but Windows 95 cannot do this...' or '...except for Windows 95 because...'. Is Windows 95 really a security 'wimp'? You bet your CDROMs! Let's take a good look at what's missing.