Results 1 to 3 of 3
  1. #1
    Join Date
    Apr 2004
    Location
    LA, CA
    Posts
    125

    Unanswered: How to get User's NT Account?

    Hi Guys!

    I am trying to put together a small web application to be used in our company's intranet. Using ASP.Net (to which I am a newbie) I am trying to to build a public start page accessible by everybody and a permission controlled area for managers. My intial idea is to use Windows NT account info to determine who has permission to access what areas.

    My first question is: Is it possible to read the user's NT account name (the account they use to login to their workstation) when they try to open a particular asp page? If yes, how to do that?

    My second question is: Am I taking the right approch or should I consider another way to do this?

    Thanks,

  2. #2
    Join Date
    Apr 2004
    Location
    LA, CA
    Posts
    125
    Request.ServerVariables("LOGON_USER")

  3. #3
    Join Date
    Jul 2003
    Location
    SoCal
    Posts
    721
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •