Many farms are moving from Windows Authentication(NTLM or Kerberos) to SAML. This migration and change requires a lot of planning
But how to start setting this up ? What are the configurations that will get impacted ? How are my third party applications going to behave ?
All this questions have been answered below .
Web Application configuration for Claims authentication :-
The first thing that comes to your mind is how am i going to start planning this .
Well the best way to do this is to extend your existing web application and configure it to Claims authentication .
The thinking behind this is that you cannot completely stop using the Windows authentication because Search Service Application is going to need Windows authentication in your “Default” zone to work properly.
So this is how you are going to design your authentication configuration :-
So this is what you do . Basically your web application is configured in the default zone with Windows authentication . You extend your web application to the intranet zone and then configure it to Claims authentication .
There is a nice blog written on how to configure for ADFS . We are not going to deep dive on that here . Please follow the blog below for this .
One of the next things that you need to think about is the User profiles . Well now you are going to have 2 user profiles for the same farm .
One with Windows and other with Claims . So how are you going to handle it .
Well the best way to do this is filter the user profile service application to only show claims user profiles . Because face it , your end users are going to get a hit at the sites hosted under the Web application with Intranet zone right . So there is no need for you to let users show Windows profiles.
Well we are using MIM to manage the synchronization between Active directory profiles and SharePoint user profile service application .
How we configured this is mentioned in the blog below , thanks to Adam Sorenson !!!
Third Party Applications
Well , we were using Nintex and certain actions like Web Request in Nintex need to authenticate to the site .
Now if you are planning to route your requests to the ADFS site , it is going to be development work like generating an authentication cookie and passing it with each and every request to authenticate successfully against an ADFS site.
We as an administrator found a bypass for this . Why not let the Nintex web Requests always and always authenticate to the default zone configured with Windows at the back end .
Here is what we did .
We created a Workflow Constant in Nintex with the name GlobalURL .
We configured the string for this workflow constant to the url of the web application in the default zone i.e “https://hostheader.example.com” .
Now what you have to do next is pretty simple. In the Nintex “web url” option , just choose from the workflow constant and insert this GlobalURL .
Done and dusted , all your requests will route to the Default zone with Windows authentication . No need for any custom development .
Above snips show how this is done .
Well this blog is increasing by the length , so i will be sharing the part 2 for this one .
Meanwhile guys , let me know if this helped you .
Always open to improvements, suggestions , thoughts on all my blogs. !!!