1. SQLOS: which implements the basic services required by MS SQL Server, including thread scheduling, I/O stat management and memory management.

2. Relational Engine: which implements the relational database components including support for databases, tables, queries and stored procedures as well as implementing the type system.

3. Protocol Layer: which exposes the MS SQL Server functionality.

SQLOS

SQLOS is the base component in the Windows SQL Server architecture. It implements functions normally associated with the Operating System, thread scheduling, memory management, I/O management, buffer pool management, resource management, synchronization primitives and locking, and deadlock detection. Because the requirements of Windows SQL Server are highly specialized, it implements its own memory and thread management system, rather than using the generic one implemented in the OS. SQLOS also includes synchronization primitives for locking as well as monitoring for the worker threads to detect and recover from deadlocks.

SQLOS handles the memory requirements of MS SQL Server as well. Reducing disc I/O is one of the primary goals of specialized memory management in SQL Server. It maintains a buffer pool, which is used to cache data pages from the disc, and to satisfy the memory requirements for the query processor, and for other internal data structures. SQLOS monitors all the memory allocated from the buffer pool, ensuring that the components return unused memory to the pool, and shuffles data out of the cache to make room for newer data. For changes that are made to the data in buffer, SQLOS writes the data back to the disc lazily, that is when the disc subsystem is either free, or there have been significant numbers of changes made to the cache, while still serving requests from the cache. For this, it implements a Lazy Writer, which handles the task of writing the data back to persistent storage.

WIndows SQL Server normally supports up to 2 GB memory on x86 hardware, though it can be configured to use up to 64 GB if the Address Windowing Extension is used in the supporting operating system. For x64 hardware, it supports 8 TB of memory, and 7 TB for IA-64 systems (currently it is limited by Windows Server 2003 SP1 to 1TB). However, when running x86 versions of SQL Server on x64 hardware, it can access 4 GB of memory without any special configuration.

Relational Engine:

The Relational engine implements the relational data store using the capabilities provided by SQLOS, which is exposed to this layer via the private SQLOS API. It implements the type system, to define the types of the data that can be stored in the tables, as well as the different types of data items (such as tables, indexes, logs etc) that can be stored. It includes the Storage Engine, which handles the way data is stored on persistent storage devices and provides methods for fast access to the data. The storage engine implements log-based transaction to ensure that any changes to the data are ACID compliant. It also includes the query processor, which is the component that retrieves data. MSSQL queries specify what data to retrieve, and the query processor optimizes and translates the query into the sequence of operations needed to retrieve the data. The operations are then performed by worker threads, which are scheduled for execution by SQLOS.

Protocol Layer:

Protocol layer implements the external interface to MS SQL Server. All operations that can be invoked on MSSQL Server are communicated to it via a Microsoft-defined format, called Tabular Data Stream (TDS). TDS is an application layer protocol, used to transfer data between a database server and a client. Initially designed and developed by Sybase Inc. for their Sybase MS SQL Server relational database engine in 1984, and later by Microsoft in Microsoft MS SQL Server, TDS packets can be encased in other physical transport dependent protocols, including TCP/IP, Named pipes, and Shared memory. Consequently, access to MSSQL Server is available over these protocols. In addition, the MSSQL Server API is also exposed over web services.

Local Group Policy:
Using local Group Policy involves setting up Group Policy on the local machine.This is not very useful for managing computers on a network. Local Group Policy is configured on the local computer.

Site Group Policy:

Site Group Policy is when the Group Policy object is linked to the site. Site Group Policies can generate unwanted network traffic, so use these only when absolutely necessary.

Domain Group Policy:
Domain Group Policy is when the Group Policy object is linked to the domain.This will apply the Group Policy object to all computers and users within a domain.This is especially useful for enforcing company-wide settings.This is one of the two most commonly used applications of Group Policy.

Organizational Unit:
Group Policy When the Group Policy object is linked to the organizational unit (OU). Organizational unit Group Policy is especially useful for applying a Group Policy object to a logical grouping (organizational unit) of users or computers.

When a Windows Server machine logs on to a Windows AD, any legacy Windows 2000 Group Policies will be applied to and work on Windows Server. The new Windows Group Policy snap-in will work on a Windows 2000 AD as well as Windows 2003.You can use the Windows Group Policy snap-in to connect to any Group Policy object in the Active Directory.You can also create a new Group Policy object using this snap-in. When you connect to a GPO using this snap-in, the ADM files are automatically updated using the newer versions of these files found on Windows XP.

Windows has over 200 policies.These policies are reflected in the new ADM files that are updated on the domain.The Windows admin snap-in shows what policies work on which clients. Best practice in a mixed environment: Use the Latest Windows Group Policy snap-in to administer Group Policy because it will display what policies are supported on what clients.

Group Policy Order

When Group Policies are applied in Windows Server, they are applied in a specific order.This is important to note because the order applied can affect the resulting policy. Group Policy is applied in the following order:

■ Windows NT 4 Policies (if any exist)
■ Windows 2000 Policies
■ Local Group Policies
■ Site Group Policies
■ Domain Group Policies
■ Organizational Group Policy Objects (going from Highest Parent in the chain to lowest)

Additionally, the result of all of the applied policies can be determined by using the Resultant Set of Policy (RSOP) snap-in. More information on this topic is covered later in the “Resultant Set of Policy (RSOP)” section. Figure A.1 shows how Group Policy is applied by different organizational units along with the domain Group Policy.

EFS can be used to encrypt SQL Server 2005 data files and folders. EFS is supported on Windows 2000 and later operating systems with New Technology File Systems (NTFS) formatted drives. EFS uses a combination of symmetric and asymmetric methods to provide transparent SQL Server 2005 data encryption. On Windows 2003 Server and newer operating systems, EFS by default creates a random File Encryption Key, which is a 256-bit AES key to perform data encryption.The File Encryption Key is then itself encrypted with the user’s public key and stored within the encrypted file or folder.

To encrypt SQL Server 2005 data files and folders using EFS, follow these steps:

1. Stop the SQL Server service.
2. Log out and log in using the SQL Server service account credentials.
3. Right-click on the file or folder to be encrypted and select Properties | General Tab | Advanced.

4. Within the Advanced attributes window, select Encrypt contents to secure data.
5. Within the Advanced attributes window, press OK.
6. Within the Properties tab, press OK.
7. If you are encrypting a folder containing subfolders, you will be presented with another window asking if you would like to  encrypt them as well. Press OK.
8. EFS encrypted files and folder names should now appear in green within any Windows file explorer window.
9. Restart the SQL Server services.

If errors are generated, you may have encrypted the SQL Server data files using an account that is not linked to the SQL Server service account.You can decrypt the data folders by reversing the steps above and trying again. When encrypting individual database files, EFS first creates a plain text copy of the file to be encrypted, encrypts the target file, and then deletes the temporary file.This temporary file is not securely deleted and can be recovered using common data recovery tools. To prevent local file disclosure, you should use a secure data deletion tool to overwrite the areas of disk containing the temporary file. Alternatively, you can simply encrypt the parent folder that contains the database files to ensure any temporary files are also encrypted.

EFS encryption is beneficial if the database media is stolen or misplaced. When transferring EFS encrypted files over the network, Windows first decrypts the file and then transfers the plain text equivalent. Some administrators perform manual backups of database files prior to implementing changes on the database server. If this backup involves copying data files from one server to another, you will effectively be storing an unencrypted copy of your database on the destination server.

Encryption File System Contains Inherit Flaws

On Windows Server 2003, EFS uses a strong 256-bit AES key to encrypt data. Under most circumstances, this would be an effective method of encryption; however, this AES key is protected by the user’s public key, which is based on the user’s Windows login password. This ultimately reduces EFS protection to the strength of the user’s Windows password. There are publicly available tools that can successfully decrypt EFS encrypted data by exploiting this flaw. Because of this, EFS should not be used to encrypt sensitive database data.

Working with EFS Encrypted Data

EFS encryption is managed by the operating system, and seamlessly provides file and folder encryption to SQL Server 2005. All SQL Server functions and operations remain unchanged when using this encryption method. Because EFS is handled outside of SQL Server 2005, encryption keys must be backed up separately in addition to your database backups.

A password that allows for spaces can be referred to as a pass phrase. The benefit of pass phrases is that you can make them meaningful and easy to remember. Instead of creating and managing encryption keys or certificates in your database server, you can encrypt data using only a pass phrase.The ENCRYPTBYPASSPHRASE statement uses the supplied pass phrase to generate a symmetric key, which is used to perform the actual data encryption. No key management is required, as the key will be recreated each time the same pass phrase is supplied.The common syntax of the ENCRYPTBYPASSPHRASE statement is as follows:

ENCRYPTBYPASSPHRASE ('PASSPHRASE', 'PLAINTEXT')

In this statement, PASSPHRASE specifies the data string to be used to derive an encryption key. PLAINTEXT specifies the data to be encrypted. No permissions are required to run the ENCRYPTBYPASSPHRASE statement.

The following syntax encrypts the string using the supplied pass phrase:

SELECT ENCRYPTBYPASSPHRASE('SQL Server 2005 Pass Phrase Encryption', 'pass phrase encryption test')

Here are the results:

0x01000000B0FA66E0152FB0B655B23439904E36F3ED5B758618BEED0F2A2BF918C6CF9DF685BC2A60A
AD5E81D660BA5A396D1CA89

As mentioned earlier, the preceding results will differ from what you receive on your SQL Server.To decrypt data, you can use the DECRYPTBYPASSPHRASE statement.The general syntax of this statement is as follows:

DECRYPTBYPASSPHRASE ('PASSPHRASE', 'CIPHERTEXT')

In this statement, PASSPHRASE specifies the data string to be used to derive a decryption key. CIPHERTEXT specifies the data to be decrypted. Similar to the ENCRYPTBYPASSPHRASE statement, no permissions are required to execute the DECRYPTBYPASSPHRASE statement.The following syntax uses the DECRYPTBYPASSPHRASE statement to decrypt the previously encrypted data, and converts it into the human readable varchar format:

SELECT CAST (DECRYPTBYPASSPHRASE('SQL Server 2005 Pass Phrase Encryption',
0x01000000B0FA66E0152FB0B655B23439904E36F3ED5B758618BEED0F2A2BF918C6CF9DF685BC2A60A
AD5E81D660BA5A396D1CA89) AS varchar)

Note that you should substitute the cipher text in the preceding statement with the cipher text that you obtained from the earlier ENCRYPTBYPASSPHRASE statement. Here is what the results of running the preceding statement will look like:

pass phrase encryption test

The encryption algorithm and key length used by pass phrase encryption have not been formally documented by Microsoft. Because of this, it is recommended that you do not use this encryption mechanism to encrypt sensitive data.

Flaws within Microsoft Object Encryption

The object encryption used by Microsoft is weak, and there are publicly available scripts that can successfully decrypt the objects. Further, at run-time, SQL Server internally decrypts the object and SQL Profiler can be used to capture object logic in plain text form. Due to this, object encryption should not be used to encrypt sensitive information, and you should not embed key or certificate passwords or pass phrases in SQL Server objects encrypted using objectbased encryption.