How to register labels against multiple domains

  • 24 February 2022
  • 0 replies

Badge +6


How to register labels against multiple domains


This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.



K2 blackpearl supports the use of multiple domains. However, there can be only one label for an AD (Active Directory) Provider with K2 blackpearl.

Important: The steps in this document refer to K2 blackpearl with Service Pack 1 or greater. Do not use these steps with pre-SP1 installations. K2 recommends upgrading to the latest service pack.

This document refers to older versions of K2 blackpearl, for information relevant to the the current version see the topic in the K2 blackpearl Installation and Configuration Guide: "Getting Started - Installation and Configuration > Installation > Post installation common tasks > K2 Environment > Adding Multiple Active Directory Domains". 



Implementation Discussion

Domain registration is performed by inserting the domain name and associated label into the SecurityLabels table in the HostServer database. The label has two components: Authentication Provider and Role Provider.

Note: This document assumes some programming knowledge and familiarity with SQL Server 2005

If you have subdomains or domains in a different forest, you will have to add those domains to the same security label by modifying the AuthInit and RoleInit fields in the SecurityLabels table in the HostServer database.

The following two placeholders are used in the examples below.


LDAP String
[parentnetbiosname] LDAP://DC=ParentDomain,DC=COM
[childnetbiosname] LDAP:// DC=ParentDomain,DC=ChildDomain1,DC=COM

Note: While the examples use a parent-child domain relationship, this is not required. If using domains in different forests, a one- or two-way trust relationship must be established. The type of relationship required depends on your environment.

The AuthInit field for the security label being modified should contain both domain NETBIOS names.


The RoleInit field for the same security label should be modified as follows:

  1. Set the "MultiDomain" property to "True"

  2. Edit the DataSources property by following the example below:

DataSources=<DataSources><DataSource Path="LDAP://DC= ParentDomain,DC=COM" NetBiosName="[parentnetbiosname]"/><DataSource Path="LDAP://DC=ParentDomain,DC=ChildDomain1,DC=com" NetBiosName="[childnetbiosname]"/>

Important: The escape characters "<" and ">" must be used as specified in the example above. Be careful to replace only the DataSources substring of the RoleInit string.

Important: The K2 Server needs to be restarted after the modifications have been made in order for the changes to be affected.

Implementation Script

The following query can be run to modify the security label to be updated. Note the placeholder values in the script are the same as those used above. Additionally, the [labelname] placeholder at the end of the script should be replaced with an actual value. This value is typically "K2" when using the security label for the default Active Directory provider.

Use K2HostServer
Update SecurityLabels
Set AuthInit = '<AuthInit><Domain>[parentdomain]</Domain><Domain>
Roleinit ='<roleprovider>
<DataSource Path="LDAP://DC=[parentdomain],DC=[parentdc]"
<DataSource Path="LDAP://DC=[childdomain],DC=[parentdomain],DC=
[parentdc]" NetBiosName="[childnetbiosname]"/>
<login />
<implementation assembly="ADUM, Version=, Culture=neutral,
PublicKeyToken=16a2c5aaaa1b130d" type="ADUM.K2UserManager2" />
<properties><user><property name="Name" type="System.String" /><property
name="Description" type="System.String" /><property name="Email"
type="System.String" /><property name="Manager" type="System.String" />
<property name="SipAccount" type="System.String" /><property
name="ObjectSID" type="System.String" /><property name="DisplayName"
type="System.String" /><property name="CommonName" type="System.String"
/><property name="UserPrinsipalName" type="System.String" /></user>
<group><property name="Name" type="System.String" /><property
name="Description" type="System.String" /><property name="Email"
type="System.String" /></group>
where SecurityLabelName='[labelname]'


Additional Details

The following details about the database structure may or may not be useful, depending on modifications made to your database. Do not update database values beyond what is specified in this article unless instructed to do so by a support representative.

  • SecurityLabelID is related to the SecurityLabelID field in the SecurityCredentialCache table. It is first generated in the SecurityLabels table so you can generate this manually if necessary.

  • SecurityLabelName is the name of the particular SecurityLabel. It should be unique.

  • AuthSecurityProviderID and RoleSec are the provider GUIDs found in SecurityProviders table.


Modifying the Workspace Web Site

When using multiple domains it is also important to modify the Workspace Web site to authenticate for each domain. To do this, follow these steps:

  1. Open web.config file corresponding to the Workspace Web site, typically located at C:Program FilesK2 blackpearlWorkspaceSite

  2. Add a new AD Connection String in the connectionString section. For example:

     <add name="ADConnectionString2" connectionString="LDAP://" />

  3. In the membership section add a new provider pointing to the newly added connection string. The name of the string needs to be unique and match the other example in Step 2. For example:

    <add connectionStringName="ADConnectionString2" connectionProtection="Secure"
        enablePasswordReset="false" enableSearchMethods="true" requiresQuestionAndAnswer="false"
        applicationName="/" description="Default AD connection" requiresUniqueEmail="false"
        clientSearchTimeout="30" serverSearchTimeout="30" attributeMapUsername="sAMAccountName"
        name="AspNetActiveDirectoryMembershipProvider_Domain2" type="System.Web.Security.ActiveDirectoryMembershipProvider,System.Web,
        Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>  

  4. Perform an IIS reset

Upgrading from K2 blackpearl 0807 (4.8210.3.0) Release

Note: The following applies to upgrading from K2 blackpearl SP1 to K2 blackpearl 0807 (4.8210.3.0) or K2 blackpearl 0803 (4.8075.1.0) to K2 blackpearl 0807 (4.8210.3.0).

Logic has been added to the K2 installer to preserve multi domain settings. This means that when upgrading from K2 blackpearl SP1 to K2 blackpearl 0807 (4.8210.3.0) or K2 blackpearl 0803 (4.8075.1.0) to K2 blackpearl 0807 (4.8210.3.0), the multi domain settings will be preserved.

The multi domain settings will be preserved only if the configuration Manager is completed right after the upgrade. If however the configuration is cancelled and later the configuration utility is executed, it will then assume full reconfiguration and overwrite/reset the multi domain settings. If the configuration was accidentally cancelled and the multi domain settings are to be preserved pass the flag –l to the executable on the command line when running the next configuration. This indicates limited UI mode for the configuration tool.

Important: If the Configuration Manager is run after the upgrade to K2 blackpearl 0807 (4.810.31.0) the domain settings will be reset and the steps in this article will need to be applied.


An update has been made with the installation of Update KB000575 and later the multi domain settings will always be preserved.


0 replies

Be the first to reply!