Managing integrated security with Windows Authentication Mode
When your connection string contains the keyword Integrated Security=SSPI, ADO.NET (or the data access interface you're using) uses Windows Authentication Mode. Behind the scenes this mode uses the NTLM (NT LAN Man) Windows NT Challenge/Response authentication protocol to validate the account credentials which uses encryption for secure transmission of passwords to prevent "snoopers" from picking your credentials off the wire. Each time a connection is opened (or reopened), the user credentials are re-verified against the domain controller (Active Directory) database. Microsoft recommends Windows Authentication Mode for most applications.
Note For more information on Security Support Provider (SSP) packages (like NTLM and Kerberos), see the SSP Packages Provided by Microsoft in the Platform SDK.
The test application I wrote to validate this code works fine (the bulk of the code is shown in Code Listing 1). That's because I'm logged in as an administrator, and as such my Windows account is granted system administrator rights on SQL Server. This is why you don't need to use the SA account or know what the SA password is when working with SQL Server Express. However, I certainly hope your end users won't be given admin accounts. When anyone logs into a Windows domain, they are granted rights determined by the domain's administrator. This information is stored in the Active Directory. These rights are not passed on to SQL Server unless you specifically grant them. This means non-administrators are (by default) not granted rights to the server or its contents and you'll need to set up users, groups, and roles to manage the database and its contents. The mechanisms for doing this have not changed in some time, and they are well documented in SQL Server Books Online. (More details are found in SQL Server 2000 SP3 Security Features and Best Practices on TechNet.)
Basically, there are four layers of security you'll need to establish and configure.
The Windows domain account: Your system administrator needs to establish a domain account that includes a Login name and (strong) password—the user "credentials". This account is (by default) a member of the "Domain Users" group. Your administrator can set up other groups and assign users to these groups as needed. I usually set up "classes" of users that categorize them by the type of work role within the office they are assigned to. For example, I'll setup "Accounting Admin1" and "Accounting Admin Lead" groups and add specific Windows domain accounts to these groups. A single Windows user can be assigned to several roles.
Physical security of the workstation and the user. If the workstation is left logged in while the user is away, or the user permits others to use their Windows account credentials, your security has already been penetrated. This layer is often overlooked. This is why Microsoft uses a key-access system to prevent access to systems when the user is not physically present.
SQL Server Login: This is an account setup on SQL Server that's used to screen attempts to connect to SQL Server. Each account you add to this list dilutes the server's ability to protect the data as it permits additional Windows users to gain access to the server. When using Integrated Security (as we suggest), you'll still need to setup a Login account on SQL Server to permit access to the targeted database by a specific user or to a Windows Domain group (such as Domain Users). Each Login account is granted rights to one or more databases and is assigned a default database that is referenced if the initial catalog (Database) keyword is not used in the connection string.
Database Users: The final layer of protection is managed in the database itself. In this case, you need to set up one or more database users that are granted rights to specific tables, views, functions, and stored procedures. You can even grant rights to specific columns if the need arises.
One approach to managing security accounts on any SQL Server database is to use SQLCMD. However, unless you're a database administrator (DBA) and are experienced with T-SQL, this can seem a bit daunting. Fortunately, you can use the SQL Server 2005 Management Studio that is equivalent to SQL Enterprise Manager to create database users, groups or roles. This tool is not included with SQL Server Express, so you'll need to use the Standard or Developer Editions for Microsoft-provided tools, or use one of the third-party tools. Once these roles are created, you can get the SQL tools to export these T-SQL commands to a script file.
Using mixed-mode security
Mixed Mode Authentication is an alterative to using Windows Integrated Security. In this case, the connection string UID and PWD keywords are validated against a SQL Server Login name and password. Since this technique bypasses Windows Authentication, it's seen as less secure. To use this security mode (and ignore our advice), you'll need to enable this Mixed Mode security during setup. To do so, when using setup batch files, you can set the SECURITYMODE command parameter to "SQL". This option is also available with the SQL Server Express interactive setup program and the SQL Server Express Manager (XM), of which a preview version should be available soon.
source : http://msdn2.microsoft.com/en-us/sqlserver/aa336270.aspx
------------------------------------------
Related:
single-record
Trik Cara Melacak IP
Trik Choose Phone
Trik woodwork-stores
Trik woodwork supplies
Trik wood work tool
Using radio button vb2008
Valentineday
vb2008 with control
vb2008 with control properties
vb2008 with oriented programming
VB.NET Solution files
VB.NET Code myclass
