I need to get the Windows domain name from Internet Explorer using classic asp (I could try it in another way if with classic asp it's not possible).
I need to do this in order to insert the domain name into a database row.
So again, in summary, I need to retrieve the Windows computer domain name from the Internet Explorer that is accessing to a particular webpage.
Any idea where I could find and example in order to do that?, is it possible?
Web browsers by default use the web protocols (think Http, Html, Ssl, etc.). By your username I know that you are familiar with the RFCs that define these protocols.
Windows networks use a different protocols. The Domain is a logical security boundary in Windows networks. Yes, in modern versions of Windows Domain security uses standard protocols like Kerberos.
The problem you'll have is that a web browser doesn't normally send extra information to a web server about the client. That would be a huge security problem. So, by default a web browser (even IE) would not volunteer any network security information in an Http request.
When your web server requires client authentication, the web browser then must provide more security information to the server. Depending on the type of authentication your web server requires, your browser will send different information. For instance, in Http Basic authentication, the browser will send a username and password.
To my knowledge, the best way to get Windows Network Domain information from a web browser is to force the browser to authenticate using Windows Authentication. This is a special authentication mode that Microsoft built that pushes Microsoft network security information over the standard Http protocol. However, in order for this to work:
Users must be running IE on Windows
Web server must be IIS on Windows
The client and server must have a Windows security relationship
IIS must be enabled for Windows Auth
There are many restrictions about the network path between the client and the server. Proxies and firewalls will typically prevent the IE Client from using windows authentication with IIS.
If you can live with this checklist, I think you will find the domain info in the one of the http headers. You may have to parse it out of the username which will be domain\user. But I'm sorry I don't remember the specifics. This should work even in classic ASP. More info on Windows Authentication is available at http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication
http://msdn.microsoft.com/en-us/magazine/cc301387.aspx is about ASP.NET, but it says:
For a user authenticated using Windows
authentication, the name is of the
form domainname\username, where
domainname is the name of the domain
in which the user is registered (or
machine name if it's a local account
instead of a domain account), and
username is the user's name.
In Classic ASP, try Request.ServerVariables ("AUTH_USER") or Request.ServerVariables ("LOGON_USER")
One alternative to Windows Authentication is to use Basic Auth and force the user to login with their windows credentials as domain\user. This however presents other security issues and you should do this only over SSL. However, this technique will work over the Internet and doesn't require a security relationship between the client PC and the server. This would also work for non-IE browsers.
In case anyone happens to get the same problem, here is the solution I've implemented (pretty much what Michael Levy said).
You have to activate Integrated Windows Authentication in IIS: http://en.wikipedia.org/wiki/Integrated_Windows_Authentication.
You can read here how to do it: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5f8fe119-4095-4094-bba5-7dec361c7afe.mspx?mfr=true
After that you can use:
In Classic ASP Request.ServerVariables
("AUTH_USER") or
Request.ServerVariables ("LOGON_USER")
It seems to work also with other browsers, not only with IE.
Thanks again to Michael Levy to point me in the right direction.
Related
I am being driven slowly and inexorably mad by the setup of IIS to allow access to Exchange Web Services from ASP.NET website that uses Windows Authentication. I have found literally dozens of articles on how to set this up, each of which seems to say something different, or else describes a process to me that fails when I duplicate it, presumably by there being some assumed knowledge on my part.
Application uses windows authentication to identify the user.
Application sends emails using EWS such that the email ends up in the users "sent items"
Exchange is hosted on a separate server than the web server, so I am assuming the "double-hop" I have read about issue is occurring. I am not a sysadmin, so I do not really understand this.
Is there some clear way for me to setup this up to work, and then potentially troubleshoot the problem?
Yes, from your description it certainly looks like a double-hop problem. It's non-trivial to fix, basically you need to setup delegation between the web server and the exchange server to for the web server to be able to use the kerberos ticket issued when the user logs in to the web server.
I have yet to deploy a single solution that actually does that. We have always ended up either using a service account (with appropriate access rights to exchange, mailboxes etc.) or place the web application on the exchange server. Neither option is particularly elegant, but in most cases operations teams have been unwilling to set up delegation or known how to do it properly.
I've gone too long just telling myself, well this just works so I'll treat it as a black box.
I can enable anonymous, forms, windows security, etc... But if I enable multiple of them on the same path/app, what does that mean? Do they all run? Does the most secure take the role of verification?
Is there a point to enabling anonymous and windows authentication?
Is there a way to step through the authentication process?
This article is for older versions for Windows Server, but the logic is the same
http://support.microsoft.com/kb/264921
When the browser makes a request, it always considers the first request to be Anonymous. Therefore, it does not send any credentials. If the server does not accept Anonymous or if the Anonymous user account set on the server does not have permissions to the file being requested, the IIS server responds with an "Access Denied" error message and sends a list of the authentication types that are supported by using one of the following scenarios:
If Windows Integrated is the only supported method (or if Anonymous fails), then the browser must support this method to communicate with the server. If this fails, the server does not try any of the other methods.
If Basic is the only supported method (or if Anonymous fails), then a dialog box appears in the to get the credentials, and then passes these to the server. It attempts to send the credentials up to three times. If these all fail, the browser does not connect to the server.
If both Basic and Windows Integrated are supported, the browser determines which method is used. If the browser supports Kerberos or Windows NT Challenge/Response, it uses this method. It does not fall back to Basic. If Windows NT Challenge/Response and Kerberos are not supported, the browser uses Basic, Digest. The order of precedence here is Basic, Digest.
Is it possible for the browser to know the currently logged in AD user without explicitly logging in? I want the code in the server to execute with the same permissions as the user in the browser. Is that possible or do I have to require the user to explicitly log on?
Context: ASP.NET, mostly IE 7, IIS 7.
Thanks.
If you...
use Integrated Windows Authentication in IIS
in web.config where relevant
and your users and IIS server are on the same domain
...then it is possible to pass credentials through the browser. IE (being Microsoft's creation) can do this without prompting, other browsers may still insist on users inputting their credentials at the start of a new session.
OK there are a couple parts to this question so I'll take them one at a time:
First, you would like to authenticate "without explicitly logging in". This is definitely possible with Internet Explorer using Windows Integrated authentication. Please see this article (Internet Explorer May Prompt You for a Password) for more details on requirements for your environment. You will want to enable this with ASP.NET Windows Authentication mode.
Second, you want server side code to run as the client's locally logged in user. This is called Identity Impersonation, and you should read this MSDN article to show how to configure it: Using IIS Authentication with ASP.NET Impersonation
Also See: MSDN Windows Authentication Provider
I have a website with a large user base configured with asp.net 2.0 forms authentication. Before the user logs in via forms authentication is it possible to retrieve the windows login name/user account name on the machine they are using?
Many thanks
It certainly is possible--by adding another web application to your system. Here's roughly how I have done it:
Your primary web app uses Forms authentication. On the forms login page, any user that is determined to be on the local LAN (check IP address), redirect them to another app that uses Windows authentication. In this second app, you can determine the user (assuming the browser is configured to send credentials automatically to the zone in which your app resides), then set a cookie which your first app can read, and redirect the user back to the original app.
This does work.
This would only be possible if you were using Windows Authentication in your web application and then only if the user had logged in.
The kind of information you are after is not sent as part of the web request (quite rightly) and is therefore unknown to the web server.
Unfortunately no - if the user has not logged on, they are browsing anonymously, and are therefore unknown to the server. There is no way to identify them.
Once they're logged on, if you're using impersonation use WindowsIdentity.GetCurrent().Name. However, for forms authentication there's no direct way to ask the browser for their Windows credentials as they may not even be running Windows!
Not BEFORE no (not from the server).
Depending on the type of Auth you use, though, and the way the site is configured, you CAN get them to log in with their windows details.
See Mixing Forms and Windows Security in ASP.NET on Microsoft's MSDN.
The main difference with #TheObjectGuy answer is that instead of using 2 websites, this does all in a single website by configuring IIS to use the Integrated Windows authentication just in a "single" page (WinLogin.aspx).
I am trying to implement NTLM authentication on one of our internal sites and everything is working. The one piece of the puzzle I do not have is how to take the information from NTLM and authenticate with Active Directory.
There is a good description of NTLM and the encryption used for the passwords, which I used to implement this, but I am not sure of how to verify if the user's password is valid.
I am using ColdFusion but a solution to this problem can be in any language (Java, Python, PHP, etc).
Edit:
I am using ColdFusion on Redhat Enterprise Linux. Unfortunately we cannot use IIS to manage this and instead have to write or use a 3rd party tool for this.
Update - I got this working and here is what I did
I went with the JCIFS library from samba.org.
Note that the method below will only work with NTLMv1 and DOES NOT work with NTLMv2. If you are unable to use NTLMv1 you can try Jespa, which supports NTLMv2 but is not open source, or you can use Kerberos/SPNEGO.
Here is my web.xml:
<web-app>
<display-name>Ntlm</display-name>
<filter>
<filter-name>NtlmHttpFilter</filter-name>
<filter-class>jcifs.http.NtlmHttpFilter</filter-class>
<init-param>
<param-name>jcifs.http.domainController</param-name>
<param-value>dc01.corp.example.com</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>CORP.EXAMPLE.COM</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>NtlmHttpFilter</filter-name>
<url-pattern>/admin/*</url-pattern>
</filter-mapping>
</web-app>
Now all URLs matching /admin/* will require NTLM authentication.
What you're really asking is: Is there any way to validate the "WWW-Authenticate: NTLM" tokens submitted by IE and other HTTP clients when doing Single Sign-On (SSO). SSO is when the user enters their password a "single" time when they do Ctrl-Alt-Del and the workstation remembers and uses it as necessary to transparently access other resources without prompting the user for a password again.
Note that Kerberos, like NTLM, can also be used to implement SSO authentication. When presented with a "WWW-Authenticate: Negotiate" header, IE and other browsers will send SPNEGO wrapped Kerberos and / or NTLM tokens. More on this later but first I will answer the question as asked.
The only way to validate an NTLMSSP password "response" (like the ones encoded in "WWW-Authenticate: NTLM" headers submitted by IE and other browsers) is with a NetrLogonSamLogon(Ex) DCERPC call with the NETLOGON service of an Active Directory domain controller that is an authority for, or has a "trust" with an authority for, the target account. Additionally, to properly secure the NETLOGON communication, Secure Channel encryption should be used and is required as of Windows Server 2008.
Needless to say, there are very few packages that implement the necessary NETLOGON service calls. The only ones I'm aware of are:
Windows (of course)
Samba - Samba is a set of software programs for UNIX that implements a number of Windows protocols including the necessary NETLOGON service calls. In fact, Samba 3 has a special daemon for this called "winbind" that other programs like PAM and Apache modules can (and do) interface with. On a Red Hat system you can do a yum install samba-winbind and yum install mod_auth_ntlm_winbind. But that's the easy part - setting these things up is another story.
Jespa - Jespa (http://www.ioplex.com/jespa.html) is a 100% Java library that implements all of the necessary NETLOGON service calls. It also provides implementations of standard Java interfaces for authenticating clients in various ways such as with an HTTP Servlet Filter, SASL server, JAAS LoginModule, etc.
Beware that there are a number of NTLM authentication acceptors that do not implement the necessary NETLOGON service calls but instead do something else that ultimately leads to failure in one scenario or another. For example, for years, the way to do this in Java was with the NTLM HTTP authentication Servlet Filter from a project called JCIFS. But that Filter uses a man-in-the-middle technique that has been responsible for a long-standing "hiccup bug" and, more important, it does not support NTLMv2. For these reasons and others it is scheduled to be removed from JCIFS. There are several projects that have been unintentionally inspired by that package that are now also equally doomed. There are also a lot of code fragments posted in Java forums that decode the header token and pluck out the domain and username but do absolutely nothing to actually validate the password responses. Suffice it to say, if you use one of those code fragments, you might as well walk around with your pants down.
As I eluded to earlier, NTLM is only one of several Windows Security Support Providers (SSP). There's also a Digest SSP, Kerberos SSP, etc. But the Negotiate SSP, which is also known as SPNEGO, is usually the provider that MS uses in their own protocol clients. The Negotiate SSP actually just negotiates either the NTLM SSP or Kerberos SSP. Note that Kerberos can only be used if both the server and client have accounts in the target domain and the client can communicate with the domain controller sufficiently to acquire a Kerberos ticket. If these conditions are not satisfied, the NTLM SSP is used directly. So NTLM is by no means obsolete.
Finally, some people have mentioned using an LDAP "simple bind" as a make-shift password validation service. LDAP is not really designed as an authentication service and for this reason it is not efficient. It is also not possible to implement SSO using LDAP. SSO requires NTLM or SPNEGO. If you can find a NETLOGON or SPNEGO acceptor, you should use that instead.
Mike
As I understand it.
NTLM is one of IIS built in authentication methods. If the the Host is registered on the domain of said active directory, it should be automatic. One thing to watch out for is the username should be in one of two formats.
domain\username
username#domain.tld
If you are trying to go against a different active directory you should be using a forms style authentication and some LDAP code.
If you are trying to do the Intranet No Zero Login thing with IIS Integrated authentication
the domain needs to be listed as a trusted site in IEx browser
or use a url the uses the netbios name instead of the DNS name.
for it to work in firefox read here
The ModNTLM source for Apache may provide you with the right pointers.
If possible, you should consider using Kerberos instead. It lets you authenticate Apache against AD, and it's a more active project space than NTLM.
Check out Waffle. It implements SSO for Java servers using Win32 API. There're servlet, tomcat valve, spring-security and other filters.
You can resolve the Firefox authentication popup by performing the following steps in Firefox:
Open Mozilla Firefox
Type about:config in address bar
Enter network.automatic-ntlm-auth.trusted-uris in Search texfield
Double click preference name and key in your server name as String value
Close the tab
Restart Firefox.
Hm, I'm not sure what you're trying to accomplish.
Usually implementing NTLM on an internal site is as simple as unchecking "Enable Anonymous Access" in "Authentication and Access Control" in the "Directory Security" tab of website properties in IIS. If that is cleared, then your web application users will see a pop-up NTLM dialog.
There's no need for you to write any code that interfaces with Active Directory. IIS takes care of the authentication for you.
Can you be more specific about what you're trying to do?
i assume that you are wanting get to some of the attributes that are set against the LDAP account - role - department etc.
for coldfusion check this out http://www.adobe.com/devnet/server_archive/articles/integrating_cf_apps_w_ms_active_directory.html
and the cfldap tag http://livedocs.adobe.com/coldfusion/6.1/htmldocs/tags-p69.htm#wp1100581
As to other languages - others will do it with there respective APIs