There's an HTTP header called "LOGON_USER". In ASP (not .Net) you could get this with the code:
sUser = Request.ServerVariables("LOGON_USER")
I'm not sure what the equivalent is in .NET
With that said, I don't believe it's available all the time. For example, when I launch some code that displays all my header variables, I don't see my ID in the LOGON_USER header. It may be due to the Novell client that is installed, but I'm not sure.
An alternative is to have a login form that authenticates against your NT domain. I can try to provide some samples (all my code authenticates against LDAP, but the process should be very similar) if necessary.
There are several software vendors that provide site security. Many can tie into NT or LDAP (and other apps) to authenticate. One we use at our company is called Siteminder, and it is a security interface between the user and our application. You install the software on your web servers, and have separate software that manages secured resources on your web servers, and when a user attempts to access the page, the security interface intercepts the request and prompts for a username and password. In our case, that username and password is validated against Active Directory. One of the greater benefits of a system like this is that they can provide single-signon for a multitude of applications by storing an authentication token in a cookie. This way you login once, and any other application tied into the same security interface can automatically authenticate you. In some versions, you can extend this to 3rd party systems through APIs that will autheticate the token as well.
A final alternative would be to manage your own security (logins and passwords) within the database. With this you have to write code on every page to verify that they have been logged in, and you'll need to encrypt the password in the database. If you go this route, look up MD5. I'm sure you can find some freeware code to convert a string into MD5. Then when you create an account, you MD5 the password and store the encrypted version in the DB. When the user logs in, you MD5 the entered password, and check to see if the two encrypted values match.
That which does not kill me postpones the inevitable.