The techniques for setting up security and handling logins on each kind of data stores will differ, but the overall principles are the same. In particular, providing declarative security is in use in MTS, the account used to access the data store driver (such as ODBC or OLEDB) will be the same—irrespective of the data store in use.
In SQL Server 6.5 we can choose between Integrated security (SQL Server uses the security information stored in Windows NT, and you manipulate it with User Manager just like any other Windows NT Service), Standard security (SQL Server maintains it's own set of security information), and Mixed (a combination of both). In other database systems you may have only the manufacturers own security implementation, or it may interface with Windows NT.
While Integrated security is usually the best choice, as it allows user permissions to be controlled from User Manager along with all other security information, Standard security can be used successfully in a DNA-based application. In fact, because MTS provides impersonation of users by mapping them to a limited number of user accounts, it is usually simple enough to keep the total number of logins and their security permissions under control.
In SQL Server, the Enterprise Manager tool allows you to create new Logins (accounts) and assign permissions to them for each object in your database:
Setting appropriate permissions to the separate objects in your database is vital. However, in SQL Server and most other data sources, you can generally set individual permissions right down to field level if required:
The network protocol that SQL Server is configured to use also has a big impact on how it integrates with IIS. The two most likely protocols to be used are Named Pipes and TCP/IP Sockets. Named Pipes is an authenticated protocol, while TCP/IP is not.