As you might know, the latest KB001290 release was out last week and it includes a whole bunch of nice new features and fixes.  One of these fixes included in KB001290 was for resolution of foreign domain accounts in local AD groups (i.e. Active Directory groups in the same domain as the K2 servers).  Without this fix, basically any foreign principals in the AD group will be ignored when resolving K2 process permissions.  Process permissions still work fine if you are using a foreign AD group containing foreign user accounts.

WORKING WITH A TWO-WAY DOMAIN TRUST

Now as you may know working with a 2-way domain trust setup is somewhat easy as the service accounts and K2 servers/web servers can all reside in the same domain.  This is basically doing a standard single domain setup.  You then do the following 2 things:

1. Add the additional LDAP paths using the management console.  If this is blackpoint, you have to modify the RoleInit XML field for the K2 label record for the SecurityLabels table in the K2HostServer database.
2. For the blackpearl workspace site, you need to modify the web.config file to include the additional LDAP paths.

These are documented in the help file (Installation and Configuration > Installation > Install > Installing K2 blackpearl > Post installation common tasks > Adding Multiple Active Directory Domains) so you can refer to this article on the steps needed.  I will not be rehashing the documentation over here.

WORKING WITH A ONE-WAY DOMAIN TRUST

Now working with a one way trust is a bit more restrictive on permissions.  This has the unfortunate side effect of causing several components to not function properly.  This is also prevents the above mentioned group resolution hotfix in KB001290 to not work properly if this is not configured right.

I have spent some time getting this to work together with some help from the lab guys (thanks dudes!) and I wanted to document the entire process.  Hopefully this will help the next person who needs to get this working in their own one-way trust environment.

ENVIRONMENT SETUP

Now what I have here is two domains in two different forest.  The first domain is denallix.com (Netbios name is DENALLIX) and the second domain is k2train.local (Netbios name is K2TRAIN).  In this scenario, K2TRAIN is configured to have a selective one-way trust to DENALLIX where DENALLIX is the trusted domain.

Now one point of note is that the service account used to run the K2 server and IIS application pool (for the K2 workspace and custom web apps) needs to be from the trusted domain.  In this cause, I will be using the same account called denallix\bpservice.

As I am using the KB001290 release, I am also leveraging on the new K2 pass-through authentication feature.  This simplifies a distributed setup greatly and bypasses the Kerberos delegation configuration in general.  To configure this, just select Windows mode during your update.  For new K2 blackpearl installs, it only shows in the custom installation option (for K2 blackpoint, it defaults to Windows mode).

Now in a nutshell.  Here's the machine and domain setup in my environment.

Machines in Domain 1 (k2train.local)

• K2TRAINSQL - AD domain controller/SQL Server
• K2TRAINK2-01 - K2 server installed in farm mode (farm address is k2clust.k2train.local)
• K2TRAINWWW - K2 workspace and SharePoint (workspace address is ws.k2train.local)

Now to keep things easier for troubleshooting, I have used 1 node clusters so that I know where the traffic is moving.  However, this should also work fine with 2+ node clusters.

 Machine in Domain 2 (denallix.com)

• DLX - AD domain controller.

Domain Trust is a one-way selective trust.

GETTING THIS TO WORK

Now let's go through the key steps needed to get this setup working.

1) Given that it is a selective trust, you need to first give Allowed to Authenticate rights to the relevant foreign domain users.  In this case I am assigning DENALLIX\Domain Users this specific right for the 3 servers (K2TRAINSQL, K2TRAINK2-01 and K2TRAINWWW).  This is done from the Active Directory Users and Computers console (you also need to select ViewàAdvanced Features to see the security tab).

2) Configure the K2 workspace site and your custom web application site to run with an application pool that uses the foreign domain service account.  In my case, it is denallix\bpservice.  Also make sure to give this account rights to run as an app pool account.  This can be done from the command prompt.  You can use the aspnet_regiis.exe with the '-ga' option.  Note that if you are running IIS in 64-bit mode, use the aspnet_regiis.exe in the Framework64 folder instead.

3) Give the foreign service account denallix\bpservice local administrator rights on the K2 server machine(s).

4) Re-run the K2 setup manager on the K2 server(s) to re-configure the K2 server service account.  You should do this from the setup manager instead of manually changing it in the services console as the setup manager does some changes to the config files to allow this new service account to read the encrypted sections.  Do this for all K2 server nodes in your farm.

5) Now if you are running in farm mode instead of standalone mode (skip this step if you installed in standalone mode).  If you run the K2 server in console mode using the new foreign service account, you will notice an authentication error being shown in the trace and this prevents the K2 server from initializing correctly.  This is due to a missing K2 server SPN (even when in K2 pass-through authentication mode).  This can be fixed in 2 ways.  Firstly, you can configure the disableloopbackcheck setting (server needs to be rebooted after setting it).  Alternatively, if you still want to use Kerberos, you can create the relevant K2 SPNs on the new foreign service account.  Using a domain admin account in the foreign domain (DENALLIX), I ran the following commands to set the SPNs (modify the farm name and service account name according to your own setup):

• setspn -A K2HostServer/k2clust.k2train.local:5555 denallix\bpservice
• setspn -A K2HostServer/k2clust:5555 denallix\bpservice
• setspn -A K2Server/k2clust.k2train.local:5252 denallix\bpservice
• setspn -A K2HostServer/k2clust:5252 denallix\bpservice

If you have done either of these options, you will notice that the authentication error will disappear when you start the K2 server console again in console mode using the denallix\bpservice account.

6) You will also see another error in the K2 server console at the end when it tries to initialize the event bus component.  There will be an MSMQ resolving a path name.  I spent some time looking at this and it seems to be some issue trying to talk to a AD-integrated MSMQ using foreign domain credentials.  To work around this, I used this trick to point the MSMQ queue configuration to a private queue.  Modify the following bold portions in these two configuration files in C:\Program Files\K2 blackpearl\Host Server\Bin folder.

SourceCode.EventBus.ClientRecorder.dll.config

<msmqpath>K2TRAINK2-01\Private$\EventBus</msmqpath>

SourceCode.EventBus.Server.config

<msmqpath>K2TRAINK2-01\Private$\EventBus</msmqpath>

<msmqerrorpath>K2TRAINK2-01\Private$\EventBus Error</msmqerrorpath>

After making and saving the changes, you will notice the K2 server now starts fully without issues.

7) Now the only other thing here is that if I wanted to resolve multiple AD groups in the group permissions, I had to set the OnlyUseSecurityGroups setting to true. If you are interested in finding out more, read this other article.

8) Now at this point, the environment is functioning somewhat and I can already assign AD groups from both domains and user from both domains can start processes correctly.  However, if you assign process permission start rights to a domain local security group in the K2TRAIN domain with users from both K2TRAIN and DENALLIX. You will notice that only users from from the K2TRAIN domain work.  This is because the denallix\bpservice account lacks certain rights to resolve the foreign users properly.  To get this fixed, go to the Active Directory Users and Computer console in the K2TRAIN domain.  Go to the ForeignSecurityPrincipals folder.  You will notice that any foreign users nested in your local AD groups will have a reference here.  Modify the properties of the denallix\bpservice account and make it a member of the account BUILTIN\Account Operators built-in group.  Now so far, there are only built-in groups that will make this work (BUILTIN\Account Operators and BUILTIN\Administrators), so I am choosing the one which has lesser permissions.  Test your process rights again after making this change and you should discover that the foreign domain users should now work as expected.

Ok, I hope this will be useful to people who need to work with a restrictive one-way trust setup.  This article has mostly been focused on the core K2 components and I have left the SharePoint portions out.  However, I don't expect the SharePoint portions to be impacted too much as workflow permissions for SharePoint integrated processes and InfoPath processes still rely on the same K2 group resolution mechanism.

If you have any feedback or comments, feel free to send them to me.  Cheers.