Smartsite has built-in support for Active Directory (AD). Speciliazed Role- and Membership Providers can be configured using the web.config.

Using the AD role- and membership providers, users in AD domains can log on to Smartsite iXperion automatically (when IIS has been configured to support this as well). Authentication takes place in the realm of AD. Then, the AD group membership is mapped to the Usergroups in Smartsite marked as 'Externally Managed'. User management in Smartsite is automated: when an AD user logs on for the first time and group membership checks are passed, account information is copied to the Users or Visitors table (AllUsers as of iXperion 1.2). This is necessary to allow for Smartsite database relations, for instance for content creation.

Configuration

Connection string

The configuration/ConnectionStrings section in the web.config must contain the Active Directory path.

XML	Copy Code
<connectionStrings>     <add name="ActiveDirectoryConnection" connectionString="LDAP://YOURDOMAIN" />   </connectionStrings>

Membership provider

Register the membership provider in configuration/system.web/membership and set it as defaultProvider:

XML

Copy Code

<membership defaultProvider="ads">       (...)       <providers>         <add name="ads" applicationName="Smartsite"             type="Smartsite.Security.Authentication.ActiveDirectoryMembershipProvider, Smartsite.Security"             attributeMapUsername="SAMAccountName"             connectionStringName="ActiveDirectoryConnection"             connectionUsername="ixperionadsuser@yourdomain.com"             connectionPassword="yourpassword" searchUserQuery="ou=some-organizational-unit"        />       </providers> </membership>

connectionStringName

ConnectionString name which must refer to a connection string within the connectionStrings section of the web.config.

connectionUsername, connectionPassword

An account with sufficient rights to query the Active Directory.

Note: as of iXperion 1.2 build 2, when you use Active Directory security for the cms manager as well (LogonHandler within Security registry key set to SixSecurity.LDAP), which will be using the LDAP membership provider through COM-Interop, you should specify an user principal name (username@domainname) as connectionUsername. This will cause the LDAP membership provider to switch to negotiate authentication method, which is needed to be able to search the entire Active Directory and not just the specified organizational unit. You should also specify the SearchBase setting within the Smartsite.ActiveDirectoryConfiguration section, since that setting is required by the LDAP membership provider. Usually you need to specify the distinguishedName of the top-level of the Active Directory as it's value.

searchUserQuery (optional but strongly recommended)

Specifies the query which should be used to search for an user. Defaults to "cn=Users". If you want to filter users to be a member of a specific organizational unit from your Active Directory, change the attribute searchUserQuery of the membership provider element to e.g. "ou=SmartsiteGroup".

Note: as of iXperion 1.2 build 2, the default cn=Users has been removed. The default, although overridable with your own organizational unit as base searchUserQuery, was a too strict criterium to search for an user on the domain. In practice this meant that all users had to be a member of cn=Users or the specified organizational unit, since the searchUserQuery was used as starting point to search for an domain user. As of iXperion 1.2 build 2, when no searchUserQuery has been specified, the "root" directory entry is used as starting point, which in practice means that domain users on any level within the domain hierarchy can be found.

Additional note: it turns out that not specifying an Organizational Unit (OU) as searchUserQuery seriously increases the time it takes to query the Active Directory for an user and/or group membership (of an user and/or group). For an individual group membership query for a particular group, a directory search request usually is about 15 to 30 times faster if an appropriate OU has been specified as searchUserQuery (2 to 3 ms. versus 50 to 60). And when users are member of a lot of (recursively nested) groups, you can imagine it will have a serious impact on performance if you haven't specified an OU.

settingsSectionName (1.4 build 3+)

As of iXperion 1.4 build 3, when using multiple membership providers (each connected to a different domain), it is recommended to give each membership provider its own settings configuration section (as described below). With the settingsSectionName attribute, the name of the section for a particular membership provider is specified. See also the article Multi-domaining support revisited for more information.

Role provider

Register the ActiveDirectoryRoleProvider in configuration/system.web/roleManager and set it as defaultProvider:

XML

Copy Code

<roleManager defaultProvider="adsrp" enabled="true"            cacheRolesInCookie="true" cookieName=".ASPROLES"            cookieTimeout="30" cookiePath="/" cookieRequireSSL="false"            cookieSlidingExpiration="true" cookieProtection="All">       <providers>          (...)         <add applicationName="Smartsite" name="adsrp"              type="Smartsite.Security.Authorization.ActiveDirectoryRoleProvider, Smartsite.Security"              connectionStringName="ActiveDirectoryConnection"              writeExceptionsToEventLog="true" />       </providers> </roleManager>

Settings

The Smartsite Active Directory provider has its own config section in the configuration/configSections for further configuration settings:

XML	Copy Code
<configSections>      (...)     <section name="Smartsite.ActiveDirectoryConfiguration" type="Smartsite.Security.ActiveDirectoryConfigurationSection, Smartsite.Security" /> </configSections>

Then, add the configuration/Smartsite.ActiveDirectoryConfiguration section. At this time, the section contains settings for controlling access to Smartsite:

XML

Copy Code

<Smartsite.ActiveDirectoryConfiguration>     <settings>       <add name="SmartsiteAccessGroup" value="Smartsite Access Group" />       <add name="VisitorGroup" value="SiteVisitors" /><!-- deprecated --> <add name="ManagerAccessGroup" value="Manager Access Group" /> <add name="StoreFullyQualifiedLoginName" value="false" /> <!-- settings below as of iXperion 1.4+ ; built-in default values shown as example --> <add name="ObtainPrimaryGroup" value="true" /> <add name="ObtainParentGroupsForPrimaryGroup" value="true" /> <add name="MaxParentGroupRecursionDepth" value="0" /> <add name="UpdatePrimaryGroup" value="true" /> <!-- settings below as of iXperion 1.4 build 13+ --> <add name="GroupSearchBase" value="OU=Smartsite Groups,DC=your,DC=domain,DC=example" /> <add name="ReferralChasing" value="None" /><!-- None, Subordinate, External, All -->     </settings> </Smartsite.ActiveDirectoryConfiguration>

SmartsiteAccessGroup

Group that defines access to Smartsite. Active Directory group membership must at least include this group to get access to smartsite.

VisitorGroup

When Active Directory user membership includes this group, mapping will be forced to the Visitors table instead of the Users table.

Notice that as of iXperion 1.2, VisitorGroup has been deprecated and you should use ManagerAccessGroup. For more information: Active Directory integration changes within iXperion 1.2.

ManagerAccessGroup (1.2+)

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.

StoreFullyQualifiedLoginName

Specifies whether to store the fully qualified user name (user@domain) in the users/visitors tables when updating Smartsite user accounts with the AD information for a user.

ObtainPrimaryGroup (1.4+)

Since 1.2 the primary group of an user is also obtained. This way you can easily give access to your Smartsite site for every domain user by simply adding e.g. Domain Users to the configured Smartsite Access Group (if every user's primary group equals Domain Users).

However, if the primary group of most users is not set to the same group and the parent groups (recursively) of the primary group are of no concern to Smartsite, set this option to false. Then, the primary group and its parent groups will not be obtained, which limits the number of groups which must be queried and thereby increases the performance.

ObtainParentGroupsForPrimaryGroup (1.4+)

If the primary group itself is of concern for Smartsite but its parent groups are not, you can use this option to switch off obtaining the parent groups (recursively) of the primary group. Just include this configuration setting and set its value to false.

MaxParentGroupRecursionDepth (1.4+)

If your Active Directory contains tens or hundreds of groups and each user is a direct or indirect member of tens or even hundreds of groups, determining group membership for an individual user can take quite a lot of time (when an appropriate OU has been specified 2 to 3 ms. for each group, otherwise 50 to 60 ms.; notice however that this only takes place once during an user's session).

If the Active Directory groups used for Smartsite (and which must exists within Smartsite as well, marked as externally managed) are limited and each of these groups can be obtained for every user just by examining the group membership a few levels up, you should configure this option and set it to an appropriate value (e.g. 3 or 4). This can significantly decrease the number of Active Directory search requests being executed, which is a good thing on itself.

Built-in default value for this setting equals 0, which means no checks on recursion depth will be applied.

UpdatePrimaryGroup (1.4+)

This setting has been introduced to support "mixed mode" security, and can be used to switch off updating the primary group of users when logging in (the setting defaults to true when it hasn't been specified). "Mixed mode" security is the concept of using Active Directory for maintaining and validating the users, but maintain group membership of each user within Smartsite only (whereas normally the group membership on the domain is leading).

GroupSearchBase (1.4 build 13+)

The new setting GroupSearchBase can be used to limit the groups on which recursion takes place. When an Organizational Unit has been specified as GroupSearchBase, a specific group an user is member of will only be recursed for parent groups if the group is member of this specified GroupSearchBase.

ReferralChasing (1.4 build 13+)

Sets the referral chasing option when performing Active Directory searches. When the search results cross a naming context (for example, when you have child domains and search in the parent domain), the server sends a referral message to the client that the client can either ignore or chase. With this optional setting, you can override the default value All.

Legal values are: None, Subordinate, External and All.
The value None can give a better performance.

Examples

Your (externally managed) Smartsite Group is 'SmartsiteAccess', and you have configured a 'SmartsiteVisitiorGroup' for AD users who should be mapped to the Visitors table.

JohnG is a member of 'SmartsiteAccess' in Active Directory, so he will be mapped to the Users table on first login.

SandraB is a member of 'SmartsiteAccess' and the 'SmartsiteVisitorGroup' in Active Directory, so she will be mapped to the Visitors table on first login.

For further information on how to configure Smartsite with Active Directory, see http://support5.smartsite.nl/smartsite.dws?goto=118

Notes

When using AD for security, all users on the configured AD domains can log on to Smartsite iXperion if they are a member of the configured 'SmartsiteAccessGroup'.

XML	Copy Code
<add name="SmartsiteAccessGroup" value="Smartsite iXperion"/>

In this case, all configured AD domains must have a group named 'Smartsite iXperion', and the group must exist in Smartsite and have 'Externally Managed' set.

(Note: As of 1.2, the configured SmartsiteAccessGroup and ManagerAccessGroup doesn't need to exist within Smartsite anymore. They are just used to determine if an user has access to Smartsite. Membership of the SmartsiteAccessGroup makes sure the user will be granted access to the front-end of the site. Membership of the ManagerAccessGroup will give the user access to the cms manager.)

Now, all AD users being members of the 'Smartsite iXperion' group can log on with their AD credentials.

Smartsite queries the Active Directory with the following string:

	Copy Code
(SAMAccountName=<userName>)

When a user is found, the ADS properties Smartsite will retrieve are:

	Copy Code
"objectSid"    // Security Identifier "cn"           // User's common name "displayName"  // Display name "mail"         // Email