Active Directory integration changes within iXperion 1.2
Several changes have been implemented to provide a better integration with Active Directory and there's even a new LDAP Membership Provider, which allows you to integrate with other Active Directory-like security systems, such as Novell e-Directory.
This article will describe these changes in more detail.
Active Directory Group Membership mapping
Within iXperion 1.2, the Active Directory Group Membership mapping have been changed, to make it easier for an Domain Administrator to distribute the domain users across the domain groups, without the need to make everyone which should be provided access to Smartsite a member of a particular Smartsite access group. Notice that the group membership mapping described here also applies to the LDAP Membership Provider.
Recursive parent groups
First of all, as of iXperion 1.2, the parent groups of the groups the user is member of are taken into account (recursively). This means that the Smartsite Active Directory Membership Provider now follows the Active Directory group hierarchy.
So, when user "Pete" is a member of the Active Directory Group "Chief Editors", and the group "Chief Editors" is member of "iXperion Manager Access Group" (=ManagerAccessGroup in the example below), and that group is a member of "iXperion Access Group" (=SmartsiteAccessGroup in the example below), the user is considered to be a member of all of these groups.
(The example shown above displays the group hierarchy as it should be created within the Smartsite Usergroups, however the Active Directory group hierarchy doesn't and probably shouldn't be the same.)
This makes it also no longer necessary to have a corresponding group for the configured SmartsiteAccessGroup and ManagerAccessGroup with the same name within the Smartsite Usergroups, as was the case in prior releases. Only the groups which are actually used to distribute the domain users into role-specific groups (such as "Editors", "Chief Editors", "Content Managers" and "Webmasters") need to have a corresponding Smartsite Usergroup (with externallymanaged set to true).
When an user is member of multiple groups (as defined within Smartsite Usergroups), the primary group will automatically be set to the group highest in the hierarchy he/she is a member of. Hence, the Active Directory group hierarchy usually shouldn't equal the Smartsite Usergroups hierarchy (e.g. "Chief Editors" shouldn't be a member of "Webmasters", but must be a member of the group defined as ManagerAccessGroup).
When a primary group has been configured for a specific domain account, this group is not returned when querying the Active Directory for "memberOf". Therefore, prior to iXperion 1.2, you couldn't use the primary group (usually Domain Users) as member of the configured Smartsite Access Group. As of iXperion 1.2, the user's primary group is retrieved separately and added to the groups the user is a member of. Therefore, when every user within the Active Directory should have access to Smartsite, you can now just add e.g. the Domain Users group to the configured Smartsite Access Group.
ManagerAccessGroup replaces VisitorGroup
The VisitorGroup setting has been deprecated and replaced with the ManagerAccessGroup setting. The group defined as SmartsiteAccessGroup determines which domain users are given access to the Smartsite front-end. Then, if an domain user is (direct or indirect) member of the group defined as ManagerAccessGroup, the user is granted access to the Smartsite back-end (the cms manager) as well.
The deprecated VisitorGroup setting did use reversed logic, but shouldn't be used anymore.
When dealing with a large Active Directory implementation with lots of groups, it turned out that the performance of Smartsite iXperion was negatively impacted due to the fact that for each request the current user was checked against the Active Directory.
To improve the performance, as of iXperion 1.2 the Active Directory user object is retrieved only once and cached internally after the user has been successfully validated against the Active Directory. For each subsequent request, the cache is used and there's no need to query the Active Directory again. This has improved the performance a lot.
The Active Directory user objects are cached using the CacheManager, with a sliding time expiration of 10 minutes.
Cms manager vs. Active Directory / LDAP
When you wanted to use Active Directory security for the cms manager, you would need to configure an LogonHandler within the site's registry (Security key). Well, that's still the case, however, prior to iXperion 1.2 the LogonHandler you would need to specify was SixSecurity.Windows. And that LogonHandler had its own (COM) implementation to provide Active Directory integration. You'ld also needed to specify the SmartsiteAccessGroup and ManagerAccessGroup within the same registry key.
However, as of iXperion 1.2, there's a new LogonHandler available: SixSecurity.LDAP. This logonhandler uses COM-Interop to call the (almost the same) .NET implementation (Smartsite.Security.dll assembly) which is used on the front-end as well. So, there is only one code-base now and you only need to specify the Active Directory / LDAP configuration in one place, the web.config.
There's one main difference. As the name implies, the COM-Interop always uses the more generic LDAP implementation, regardless of the configured membership provider. It is therefore necessary to provide a SearchBase within the configuration section (which wouldn't be the case if you're just using Active Directory integration on the front-end).
The SearchBase parameter should specify the distinguishedName of the group/organizational unit of which the users are member of. All other configuration settings will be read from the web.config using the appropriate configuration section automatically (Smartsite.ActiveDirectoryConfiguration when the Active Directory membership provider has been configured as default provider and Smartsite.LDAPConfiguration when the LDAP membership provider is the default provider).
(Note: as of iXperion 1.2 build 2, it is recommended to specify the distinguishedName of the Active Directory root and use an user principal name (username@domainname) as connectionUsername on the membership provider element, so the membership provider is able to search the entire Active Directory. When all users which must be granted access to Smartsite are member of a specific organizational unit, then it is possible to specify the distinguishedName of this organizational unit.)
There's another small catch. Because COM-Interop is being used and the security implementation is called from the cms manager's process (which means Database.Current isn't available), you need to provide the DatabaseId within the Smartsite.ActiveDirectoryConfiguration/settings or Smartsite.LDAPConfiguration/settings element of the web.config. This id should refer to a database connectionstring with the same id as configured within Smartsite.Data.config. See the example below.
<Smartsite.ActiveDirectoryConfiguration> <settings> <add name="SmartsiteAccessGroup" value="Smartsite access group" /> <add name="ManagerAccessGroup" value="Manager access group" /> <add name="StoreFullyQualifiedLoginName" value="false" /> <add name="DatabaseId" value="e.g. DB_EmptySix" /> <add name="SearchBase" value="e.g. cn=Users,dc=...(,dc=...)" /> </settings> <membershipMappings> <add name="mm1" domain="your domain" providerName="ads" /> </membershipMappings> </Smartsite.ActiveDirectoryConfiguration>
Important: in case of Active Directory, the domain user specified as connectionUsername within the membership provider element must have a givenName which equals the sAMAccountName and which equals the first part of the distinguishedName, since the LDAP connection will be created using the distinguishedName.