WIA authentication (deployed only)

For deployed systems using Window integrated authentication (WIA or IWA) it's possible to hook up the CMS with the local Active directory in order to provide seamless unchallenged authentication.  These users will not be anonymous however in some cases they can belong to multiple groups. The Active directory setting allows you to set the master group they'll belong to. Note that the section below is only visible for deployed servers.

Getting WIA set up is complex. The API PDF in the downloads section on the right provides fuller details on its configuration and testing for both approaches

Windows integrated authentication options

WIA is implemented in two different ways in the CMS, the logic is described in a later section

1. TryUnchallengedWindowsAuthentication – this provides unchallenged WIA access in conjunction with a looks up of the relevant users directory entry via LDAP it then maps the windows user to a local sitekit user
2. TryWindowsAuthentication– this provides unchallenged WIA in conjunction with a single associated group association

Approach 1 is richer approach with more information available on the relevant intranet about the end user. However it depends on reliable local access to the relevant AD OU via an LDAP query.  The first approach performs exactly as the authentication by web service does in that it creates the Sitekit user, maps all their fields over and adds them to all of the Sitekit groups whose names correspond to active directory group names. The AD and Sitekit users will be created/synched at the start of every session. Synching is one-way, AD to Sitekit. Often it’s possible to authenticate via remote domain by mapping users into universal AD groups and setting up one way or two way trust relationships. Such complications will prevent the mapping of fields via LDAP but may still support the simple second option. 

Configuration option 1 takes the following form

1. Set the Sitekit user master group setting to the relevant group in site settings.
2. Set the field mapping from used to map the AD user fields to the local Sitekit user in site settings.
3. Set the LDAPServers key in the CMS web.config to the correct value for the LDAP domain(s) your using, entries should be prefixed by the protocol and separated by commas.
4. Change the web.config with the following
   

   <system.web> <identity impersonate="true"/> <authorization> <deny users="?" /> </authorization> </system.web>

5. In IIS, for the relevant deployed server, anonymous authentication must be 'disabled' and windows authentication must be 'enabled'.

Again see the PDF for more details

Notes on WIA

Because authentication via WIA is server wide this can cause some challenges on implementation

1. The fields are not re-refreshed over again until the session time elapses. So there's no real-time update from changes to the AD
2. The Channel emailer requests newsletter pages via http and thus needs authentication. This means that the channel emailer need run as a scheduled task under a user that has access to the relevant pages (ie not a local server admin user).
3. Pages don’t index easily for search – getting pages to be indexed is more difficult. Pages need created then visited by an authenticated user with read access for that page to be added to indexable content. In addition the visibility needs to be correct and the pages asset class needs to not have a universal read and it needs to be an extranet (all other users barred). Generally its harder to get pages to index in this environment which cause issues in initial population before there's any 'natural visitors'.
4. Multiple AD domains -  it's relatively common in AD system to have the same user in more than one domain. This will produce duplicate Sitekit users in the CMS
5. Edit profile and Logout as nav menu item will not be shown to users logged in this way.