This topic describes how Microsoft SQL Server Compact 3.5 relies on the following:

  • IIS Authentication

  • IIS Authorization

  • IIS Encryption

IIS Authentication

When you configure the SQL Server Compact 3.5 Server Agent, you specify whether clients must perform Microsoft Internet Information Services (IIS) authentication when they connect to the SQL Server Compact 3.5 Server Agent. There are three forms of IIS authentication:

  • Anonymous access

  • Basic authentication

  • Integrated Windows Authentication

It is expected that most Internet applications will use Basic authentication and Secure Sockets Layer (SSL) encryption.

Anonymous Access

With Anonymous access, IIS does not perform client authentication. All work that the SQL Server Compact 3.5 Server Agent performs on behalf of the client is performed under the identity of the Internet Guest Account. By default, the Internet Guest Account is IUSR_computername, but you can designate a different Windows user account as the Internet Guest Account.

Basic Authentication

With Basic authentication, the SQL Server Compact 3.5 client must supply a valid Windows account user name and password. IIS attempts to log in by using the client-supplied user name and password. If the logon attempt succeeds, all work that the SQL Server Compact 3.5 Server Agent performs is performed under the identity of the specified Windows user account. If the logon attempt fails, the request from the client is rejected. Basic authentication can be used for both Internet and intranet applications. Basic authentication requires that each client have a valid Windows account with a corresponding user name and password.

By default, Basic authentication passes the user name and password across the network in base64 encoding. This can pose a security risk if someone eavesdrops on the password exchange because the base64 encoding can easily be decoded. To safeguard the user password, Secure Sockets Layer (SSL) encryption should always be used whenever Basic authentication is used. For more information, see Configuring SSL Encryption.

Integrated Windows Authentication

Integrated Windows Authentication works much like Basic authentication. The SQL Server Compact 3.5 client must supply a valid Windows account user name and password. IIS attempts to log in using the user name and password. If the login attempt succeeds, all work that the SQL Server Compact 3.5 Server Agent performs is performed under the identity of the Windows user account. If the login attempt fails, the client synchronization request is rejected. Integrated Windows Authentication has one primary advantage over Basic authentication: Unlike Basic authentication, Integrated Windows Authentication does not transmit the client's user name and password over the network in unencrypted form. This avoids the risk of someone intercepting the password. Integrated Windows Authentication is best suited to intranet applications. Integrated Windows Authentication is seldom used for Internet applications because it cannot operate over a proxy server or firewall.

Because Microsoft Windows CE 4.2 does not support Digest Authentication, SQL Server Compact 3.5 connectivity solutions do not support this form of authentication.

IIS Authorization

After the IIS client is authenticated, IIS authorization determines whether the client can invoke the SQL Server Compact 3.5 Server Agent. You control who can perform SQL Server Compact 3.5 connectivity by controlling the clients that can access the SQL Server Compact 3.5 Server Agent.

IIS provides the following mechanisms for controlling access:

  • IIS first checks the address of the client against any IP address restrictions that are configured. You can configure the Web server to prevent specific computers, groups of computers, or entire networks from accessing the SQL Server Compact 3.5 Server Agent. When a client initially tries to access the SQL Server Compact 3.5 Server Agent, IIS checks the IP address of the client computer against the IP address restriction settings on the server. If the IP address is denied access, the synchronization request from the client is rejected with the message: "403 Access Forbidden."

  • If IIS is configured to require authentication, IIS checks whether the client has a valid Windows user account as described in the IIS Authentication section in this document. If the user account is not valid, the client's synchronization request is rejected with the message: "403 Access Forbidden."

  • IIS next checks the Web permissions. This IIS security check is not relevant for SQL Server Compact 3.5 connectivity solutions.

  • IIS then checks NTFS permissions for the SQL Server Compact 3.5 Server Agent to ensure the connecting user has appropriate permissions.

Although IIS can also be used with a File Allocation Table (FAT) file system, it is strongly recommended that you use NTFS. NTFS allows use of access control lists (ACLs) for granting or denying access to the SQL Server Compact 3.5 Server Agent and the input and output message files on the IIS system.

IIS Encryption

When you configure the SQL Server Compact 3.5 Server Agent, you can specify SSL encryption. When you specify SSL encryption, all communication between the SQL Server Compact 3.5 Client Agent and SQL Server Compact 3.5 Server Agent is encrypted. For more information, see Configuring SSL Encryption.

You should use SSL encryption in the following situations:

  • If you configure IIS to use Basic authentication.

    This is essential to safeguard the Internet password of the user. By default, Basic authentication transmits the user name and password across the network in base64 encoding. This can pose a security risk if anyone eavesdrops on the password exchange because the base64 encoding can easily be decoded. SSL encryption should always be used whenever Basic authentication is used to safeguard the user's Internet password.

  • For RDA only: If the application specifies an OLEDBConnectionString parameter that contains a password.

    The RDA Pull, Push, and SubmitSQL methods require an OLEDBConnectionString parameter. This connection string is passed across the network in clear text form. This can pose a security risk if anyone eavesdrops on the password exchange.

  • For replication only: If either the SQL Server Publisher or Distributor relies on SQL Server Authentication.

The Distributor is using SQL Server Authentication if the DistributorSecurityMode property specifies DB_AUTHENTICATION. The Publisher is using SQL Server Authentication if the PublisherSecurityMode property specifies DB_AUTHENTICATION. When SQL Server Authentication is used, the DistributorPassword and PublisherPassword are passed across the network in clear text form. This can pose a security risk if anyone eavesdrops on the password exchange. SSL encryption should always be used whenever SQL Server Authentication is used to safeguard DistributorPassword and PublisherPassword.

Concepts

SQL Server Security

Securing Databases (SQL Server Compact)