Is it possible to use both Basic and NTLM Authentications on EWS?
I have read here
https://msdn.microsoft.com/en-us/library/office/dn626019(v=exchg.150).aspx#sectionSection2
that it is not possible. Not that I am questioning msdn, but does not looks so, because I have option in exchange configuration to check both windows authentication and basic along each other. From that point it does not look that basic excludes NTLM.
You can at the IIS level configure it that way eg the defaults are all listed on https://technet.microsoft.com/en-us/library/gg247612(v=exchg.150).aspx. However the supported way which the documentation is outlining is that all configuration of virtual directories should be done via the Exchange Management tools (EMS etc). Autodiscover tells Outlook which authentication to use which is configurable via Set-WebServicesVirtualDirectory https://technet.microsoft.com/en-us/library/aa997233(v=exchg.160).aspx and this only allows you have one of the other which will then in turn configure the backend directories. So best practice is to choose one or the other.
Related
I have a requirement to integrate an ASP.NET web application with active directory - basically they want to be able authenticate and authorize with AD.
I realise this is relatively simple, but what I want to know is how I can simulate the AD for developing and testing against. I don't have AD available to me (right now) and don't cherish the thought of setting it up even if I had hardware available to run it on.
What other options are available to me? I've seen ADAM mentioned in a couple of places but this doesn't seem to provide the federation services I need (and seems a little out dated). Would it be possible to use Azure for this? I want to keep costs (time-wise as well as money) to a minimum.
I have managed to set up an active directory environment suitable for development using a Microsoft Azure VM.
A brief summary of the steps I went through to get this working are below. Although it sounds scary setting up AD and ADFS, the windows server 2012 interface makes it incredibly easier, barring a few gotcha's I mention below - it takes a while for them to install as well.
Create a new azure windows server 2012 VM and add endpoints for http and https.
Install the AD role on the VM
Install the ADFS role on the VM
Create an ASP.NET MVC 4 app (on your dev machine) and verify it is working correctly.
Run the app through IIS (not IIS express - this just makes SSL etc easier).
Ensure the site has a https binding set up
Install the Identity and Access tool for VS2012
Right click your project to select the identity and access tool.
The path to the STS meta document will be https://<your VM url>/FederationMetadata/2007-06/FederationMetadata.xml (you may need to download this file manually if your certificates are self signed).
Back on your VM, in ADFS create a relying party trust for your application.
Run your MVC app again and you should be redirected to your VM for authentication and then back to your app again (but this time using https).
If you are using the default MVC template, in the top right corner assuming you have set up the claims correctly, you should see Hi, <user>#<domain>
The main articles that I followed to achieve this are as follows:
http://blogs.rondewit.com/post/MVC-2b-ADFS-20-Federated-Authentication.aspx
http://garymcallisteronline.blogspot.co.uk/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
Below is a list of gotcha's that I hit (in no particular order).
When setting up the relying party trust enter the data manually and ensure you set the Relying part WS-Federation Passive protocol URL and the relying party trust identifiers correctly. The first is simply the https url that ADFS will redirect back to after authentication has completed - https://localhost for example. The second is an identifier used to identify the application that is trying to authenticate. One of the identifiers entered must match the realm attribute of the wsFederation node in your MVC 4 apps web.config.
When logging in the username should be of the form <domain>\<username>
I couldn't get Windows Authentication to work with any browser other than IE. For this set up to work with Chrome I had to change the order of the local authentication types in the web.config of the adfs/ls application so that forms authentication appeared first. To get to this, open up IIS manager on your VM, expand default web site/adfs/ls, right click ls and select explore.
At the time of writing I haven't been able to login with an AD user I created myself - I've probably just not set it up correctly. When setting this up initially, I'd suggest trying to connect with the admin user you created through the azure portal when you created the VM.
Once I finally managed to authenticate correctly AntiForgeryToken html helper started throwing an exception, talking about missing claims. Ensure that you have added a claim rule to your relying party trust, that sets either the name or name id claim. Then in Application_Start do the following: AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name; as explained here.
It is also worth noting that the Identity and Access tool allows you to setup authentication with Azure ACS and more noteworthy, a development STS. For my requirements, I need to be able to integrate with ADFS, but if you're just experimenting with claims based authentication, one of these may be a better option than the process that I have gone through above.
Consider ADFS and ws-federation.
Ws-federation is an enterprise sso protocol that gives you cross domain authentication/authorization in a sso manner. Adfs is a free implementation of the protocol that sits on top of the active directory. It is relatively easy to set up.
But having a client application that expects a ws-federation identity provider, you can substitute the provider with any compliant provider, your own or the identityserver which is another free implementation but can use a membership provider. The completely custom implementation on the other hand would give you a chance to set up and serve an
arbitrary identities.
The is a small learning curve for this approach but benetifs are:
cross domain sso
support for multiple browsers for free (kerberos/ntlm based ad authentication could be unsupported on some browsers)
works in an intranet and the internet
support for advanced scenarios like for example you can set up your cloud Office365 to authenticate against your local adfs
adfs 2.0 is free component dowloadable from msdn
We've recently released the latest version of our intranet application, which now uses windows authentication as standard, and needs to be able to connect to a configured SQL server with the end-user's domain credentials.
Lately we've found that on a couple of customer deployments, although IIS can see the user's domain credentials, it will not pass these on to SQL server. Instead, it seems to use the anonymous account. This is in spite of following all the correct steps (changing the directory security to Win Auth, updating Web.Config to use Win Auth and denying anonymous users).
I've been doing a lot of reading that suggests we need to make sure that Kerberos is in place, but I'm not sure (a) how valid this is (i.e. is it really a requirement?) or (b) how to go about investigating if it's set up or how to go about setting it up.
We're in a situation where we need to be able to either configure IIS or the application to work for the customer, or explain to the customer exactly what they need to do to get it working.
We've managed to reproduce this on our internal network with a test SQL server and a developer's IIS box, so we're going to mess around with this set up and see if we can come up with a solution, but if anyone has any bright ideas, I'd be most happy to hear them!
I'd especially like to hear people's thoughts or advice in terms of Kerberos. Is this a requirement, and if it is, how do I outline to customers how it should be configured?
Oh, and I've also seen a couple of people mention the 'classic one-hop rule' for domains and passing windows credentials around, but I don't know how much weight this actually holds?
Thanks!
Matt
This is called the Double-Hop Problem and prohibits the forwarding of user's credentials to third parties. This occurs when they browse from one machine, against a site on another (first hop), and forwarding the credentials to a third machine (second hop).
The problem will not appear if you host IIS and SQL Server on the same machine.
There's alot more technical details published on this at How to use the System.DirectoryServices namespace in ASP.NET, which explains the double-hop issue, and primary and secondary tokens.
To run your application under the user's Active Directory or Windows credentials, ensure these:
the IIS application is set to NOT allow anonymous access
the IIS application uses Integrated Windows authentication
your connection string should have Integrated Security=SSPI to ensure the user's Windows/AD credentials are passed to SQL Server.
i.e. Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
You state you're not sure "how to go about investigating if it's set up or how to go about setting it up".
For this I'd heartily recommend a tool called DelegConfig. It's a very handy app that you can tell you if kerberos is setup properly.
Unzip it into a directory, configure a virtual directory in IIS to point to it. Browse to the main page and you tell it which backend server you want to allow access to (e.g. UNC, SQL, HTTP etc..) and it tell you its setup correctly or not and explain why.
It even has the abilty to recongiure the kerberos to fix the issue if you so desire (although I've not used this - I'd rather reconfiguire it myself to understand what I've done in future)
I realise this comes too late for your particular problem but thought it worth sharing for others that follow - especially the tools ability to explain why delegation is or is not working. I've found it invaluble.
We have multiple web-applications running Windows authentication.Users log on to the websites using Domain\Username which is different from the DomainOther\UsernameOther that they use on their local computers.
Considering we have 2 sites One.xyz.com and Two.xyz.com both running Windows Authentication (and user logs in to both using Domain\Username), is it possible to have theuser redirect from a page on One.xyz.com to the homepage of Two.xyz.com without entering his credentials again once he has already entered them on One.xyz.com?
Is it possible to do this using ASP.Net?
Kind regards,
What you are looking for is called Single Sign-On and there are a broad variety of commercial products capable of supporting your needs. Many of them pass credentials via server variables over HTTPS so that the users doesn't see the credentials in the URL. I've worked with companies that wanted to "roll their own" and who went for other approaches (session keys that reference a third server, encrypted and time-sensitive URL strings, etc.).
To get started, you'll want to read the Wikipedia entry on single sign-on (it links with SAML as well). You may want to visit some of the more popular commercial vendors' websites such as Passlogix and Imprivata as well (there are dozens, though, so don't take this list as exhaustive or even particularly recommended - just popular).
SharePoint supports SPNEGO authentication, a form of single sign-on. MSDN has documentation for using SPNEGO for single-sign on .net. Look at the Microsoft Security SSPI. I found this sample with a quick search.
SPNEGO is a Microsoft variation of Kerberos and it will interoperate with IBM products and Oracle WebLogic, as well.
If you want single-sign using an international standard that has wider interoperability than Kerberos, you should use SAML. See Active Directory Fedration for a Microsoft discussion of SAML. However, SAML is much more complicated to implement and configure.
I have a Web Service (ASMX) with a few Web methods on our production Web server. On a separate internal Web server (which isn't publicly exposed) I have another Web site that will use the ASMX's public web methods. What are some of the best ways to secure the Web service such that only the internal Web server can access the Web Services running on the publicly exposed Web server?
One of the easiest ways is to pass credentials in the soap header of the message. So each call passes along the info needed to determine if the user is authorized. WSE makes some of that easier but one of the most succinct descriptions of this process can be found in Rocky Lhotka's book on Business Objects. I get a lot of books to review by publishers and this one had the best explanation
Assuming you don't have the option of using WCF, I'd advocate using WSE 3 (Web Service Enhancements). You can get the toolkit / SDK thingummy at MS's site
To limit the access to only internal machines (as I think your question asked), I'd set up a separate web site in IIS and set it to only respond to the internal IP address of your server.
I would set a firewall rule to restrict access to a whitelist of IP addresses.
Use IIS's directory security IP address restrictions, and limit access to just that internal web server IP address.
If you can't do that then, and you can't setup a username/password on the directory, then use WSE and add a username/password into the service, or look at certificates if you want some fun grin
Maybe I did not understand correctly, but why expose the web methods publicly at all if they're only going to be consumed by the internal server?
A simple HTTP module will work. Just hardcode (or from config) the allowed IP/host and reject all others.
If it is only the internal server that will be accessing the asmx files? You could set them up in IIS under a separate web site or virtual directory, then place some IP restrictions on the site. In properties, go under Directory Security, then "IP Address and Domain Name Restrictions."
Also, for passwords, WSE 3 is the new go-to, but I did find a simple method in a book from Apress called "Pro ASP.NET 2.0 in C# 2005" Chapter 34. (Note, the newer version of this book omits this chapter.) The section is custom Ticket-based authentication.
In this moment what comes to my mind is IP filtering on IIS. Fast to apply, should work in your scenario.
TLS with client certs. See Wikipedia entry to get started.
Be aware that there are ways around whitelisting IPs. Don't get me wrong, it's a great idea, and you should definetly do it, but if your budget/resources allow it, you can expand your threat model.
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