This issue is simple to solve. Follow this and then you can deploy any application, certificate or VPN software to the PDA.
Next major release of Microsoft CRM, Titan, will be facing new possibilities:
The main design themes of the Microsoft CRM Titan release will be:
Deployment will be ready around April 2007. If you haven't bought your Hosted CRM solution by then, check www.netdanmark.com or do it now 😉
Dealing with integrated Windows Security (IWS) on IIS 6.0 and especially with .NET applications (such as Microsoft Sharepoint Services or Portal Server) can be a hard pain to deal with. I wrote this article to clarify a few thinks and to share my knowledge on the subject.
First of all – if your IIS is installed on the global catalog server, don’t read on. It is a bad solution, and all the problems listed in this article will disappear, due to the fact, that security is not delegated, but stays within the same server/application domain. From a hosted perspective I would really disapprove the solution, of having an IIS on the global catalog server.
To understand integrated security, and how things are accessed, we need to look at delegation, and understand why this is the problem as well as the solution, while operating IWS on IIS with your .NET application.
A user connects to the website, and supplies his/her credentials. The webserver then authenticates with user against the Active Directory. This will happen in a transparent process, and will be handled by IIS and the Active Directory without any custom involvement.
So far so good.
While the above solution will support 70-80% of all given solutions, there are a few of us who like to trouble ourselves by going feather. The pain starts, when the application (such a Sharepoint) need to access resources on another server without re-authenticating the user, nor saving the supplied credentials on the actual webserver (some use a fairly unsecure solution, by saving the credentials in session or somewhere else…).
A good example is to use the System.Directoryservices namespace within the .NET framework, and let’s say, get a list of known users on the Active Directory. This operation can only be a achieved from an authenticated user, and therefore we use impersonation.
Impersonation is when a given process (.NET code, IIS or service) gets a new set of identity credentials attached, which causes this process to use the supplied credentials to re-authenticate – seamless of cause – the process or user on other resources or processes. Impersonation is a useful but often painful tool to gain access.
If we go back to our example, we wish our code to access the Active Directory with the user we just authenticated with. This is where our understanding of the authentication protocols and our base setup often is the issue to errors and pains.
Kerberos or NTLM
Only a narrow sets of the authentication mechanisms in IIS supports delegation of an impersonated process. Because delegation is so vital to the solution, please do not try to extend this table. It cannot be done! The following supports delegation:
• Basic Authentication
• Integrated Authentication (with Kerberos)
The following will NOT support delegation:
• Integrated Authentication (NTML)
• Forms, Passport, Database or other "custom" build
While the last list is not totally true, I will get back to this in a later article (writing custom Windows Authentication for Delegated environments).
As the list describes you will have to configure your IIS website to use ONLY integrated security or Basic Authentication. Because basic authentication is credentials supplied in clear-text, this is often the most used method. It also is supported by almost all web browsers today – but it is an unsecure solution (due to the clear text), and if you decide to use this, remember to implement a SSL certificate to encrypt the data between the client and the webserver.
Integrated security on the other hand, is not supported from a range of vendors. Internet Explorer 5.0 and never is almost the only browser that support integrated authentication with the Kerberos.
The differences between Kerberos and NTLM, is that while both support authentication in a secure matter, only Kerberos is supported for delegation. Delegating being vital to our solution, we need to go with this protocol.
A simple test with a few lined of code, will prove to us that the System.Directoryservices will work with the solution above, if we access the website by the FQDN of the webserver (being i.e. webserver1.mydomain.com). Adding an alias for the solution (i.e. intranet.mydomain.com) breaks this.
Why is that?
Setspn – "I know you"
Directory Services is by default configured to supply NTLM credentials and not the only delegated-supported protocol – Kerberos. Because NTLM can get the credentials from within a Kerberos package, and not the other way around, you website will allow access to your user (successful authentication), but not to the Directory Services process. The reason to the fallback event, is due to the issue that Kerberos relays on known service principal names (SPN, as you FQDN is).
To solve this matter Microsoft nicely provided us with the SetSpn.exe tool. SetSpn can add aliases to known AD object to provide the necessary alias. Now the Active Directory will know who intranet.mydomain.com is, can provide a seamless Kerberos authentication to the System.Directoryservices process.
Integrated Windows Authentication is a narrow and secure protocol, but yet painful and not always understandable. Because of the many aspects to understand (impersonation and delegation), the easy way is to go with basic authentication.
But there is another solution, by hard coding your own authentication mechanism. The Windows 32 API fully supports authenticating a user with Kerberos, which allows us to code a neat and great solution for authentication again the Active Directory.
My next article will be on this matter, where I will combine both FORMS authentication and Kerberos Windows authentication in on solution, which is supported on all browsers