When the internet browser sends the login and password of a user, the bcAuthenticate will need a way to translate these login names and passwords to their Windows NT counter parts which you have defined to protect your website. You describe this translation mechanism to the bcAuthenticate using a SQL statement which bcAuthenticate can use to retrieve Windows NT account userid and passwords using the credentials submitted from the browser.
There are two main strategies you may want to consider:
1. Mapping each user to a potentially different Windows NT account. You need this option if you have different types of users who should not see each others’ resources. For example, your organisation may have 5 projects going on. You have 20 customers (participants) for each project. You setup a server to share information with them. But the customers who pay for project 1 should not see project 2 etc. Then you can setup 5 different directories in your Windows NT Server and 5 different NT accounts where each account only has access to its relevant directory and do not have permission to access other directories. Then, for project 1, you can setup 20 different account names for each of your customers, and internally map them to the Windows NT account that has permissions for project 1 directories. You will NEVER tell your customers about your Windows NT account userid and password. They will only know their individual userid and passwords that you keep in your database. This way, when one of your customers leave the project, you can disable their account ONLY, without effecting others. Behind the scenes, you can keep changing your Windows NT account names and nobody will have to know.
2. Mapping all users to the same Windows NT Account. If you have an existing users database, or if you do not have permission to change database schema for one reason or the other, you can still map your users to NT accounts without the need to expose your Windows NT accounts.