Customising the experience for Sitecore AD users

-
In the overwhelming majority of Sitecore installations that we deliver for clients, content authors want to use the Active Directory integration module to login to Sitecore -- understandable, who wants to have another login!  As outlined in my previous post about recursive AD synchronisation, it is actually quite simple to set up the Sitecore AD module to use your AD roles and user accounts to enable Sitecore login.

One of Sitecore's little idiosyncrasies is that by default it will log you in to the content editor application, which I find is the least useful thing for most content authors.  Generally we want to log content authors into the Sitecore Desktop.  This is not a setting that you can set on a role, instead it is a setting of the user's profile.


You can definitely go an individually update each of the users that have been created by the  AD module to by default log the user into the desktop, but we don't want to have to do that every time we create a new user.  Sitecore does support a better way...

Default domain profiles

In order to have all AD users created with a particular start URL (or any profile settings such as a particular wallpaper) we have to create a new default user profile.
The first step for this is to create a profile template with fields the we required.  To do this we need to switch to the core database and create a new template at the location /sitecore/templates/System/Security inheriting from the existing "User" template at that location.  In this example I've called the template "ADUser"


Then add a new field "StartUrl" (single-line text) to the new ADUser template


Finally create an instance of this new ADUser template under /sitecore/system/Settings/Security/Profiles, name the item "AD Desktop User", and set following values for the profile: 
  • StartUrl = /sitecore/shell/default.aspx


Finally update the domains.config file in /App_Config/Security to use the new profile for the "ad" domain (or whatever you have named the domain that AD users have been synchronised into:
  • <domain name="ad" ensureAnonymousUser="false" defaultProfileItemID="{[GUID of AD Desktop User item]}"/>

When you log AD users log in using the LDAPLogin.aspx, they should now be logged into the Sitecore desktop.  You can also use this approach to set any other default profile values (e.g. wallpaper) that you want for users based on their domain.


Comments

Post a Comment

Popular posts from this blog

Cloud hosting Sitecore - High Availability

-
Image
The approach to hosting web facing systems has changed significantly over the last few years, with virtual machines almost completely replacing physical infrastructure.  These private cloud virtual server farms allowed server instances to be built and run on consolidated hardware, simplifying purchasing for IT departments.  This cloud computing pattern is generally known as Infrastructure as a Service (IaaS), and it simplified the way that physical hardware was purchased, whilst supporting the same approach to building and deploying applications that had been used before.  Public cloud hosted IaaS platforms remove the purchasing requirements, whilst providing a high degree of flexibility in how services are hosted, however IT teams still had to install and configure operating systems and other system software like content management and database systems the same way as with traditional environments.   Amazon Web Services and Microsoft Azure are currently the two leading IaaS cloud
Read more

Sitecore - multi-site or multi-instance?

-
Image
I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec
Read more

Setting up TDS to work with Azure DevOps

-
Image
We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items. Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys. Setting up the TDS license The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime. Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables - task: PowerShell@2 displayName:
Read more