Authentication is required for session xxxxxxxxxxxx

  • 23 August 2011
  • 4 replies
  • 234 views

Badge +3

 


I upgrade my environment from version 0807 to k2 4.5  with Update KB001370 in new hardware. My environment after upgrading is like below:



  1. K2 Server with K2 workspace and K2 Host components
  2. Database Server.
  3. SharePoint 2010 Server with k2 for sharepoint components.

All Servers are running Window 2008 R2 Server SP1. I installed and configured the k2 components on all machine using K2Service Account.In addition to that, I setup the SPN on active directory for K2 Host server, K2 Server and K2 workspace for K2Service Account. When I try to access K2 workspace i got the following error:



  1. Authentication is required for session xxxxxxxxxxxx

I run the K2 blackpearl in the console mode and i found the following entries:



  1. Info 7003 SourceCode.SmartObjects.Runtime.SmartObjectClientServer not yet Loaded
  2. "10889","2011-08-23 02:49:16","Error","Unknown","8060","ProcessPacketError","SourceCode.Hosting.Server.Services.TCPClientSocket.ProcessPacket","8060 ProcessPacket Error, Authentication required for session ACF1AC9588DD682ADBE8D7D5FEF01199","system","::1","K2:C:Program Files (x86)K2 BlackPearlHost ServerBin","10889","b1e1ef67d2ad4531a33b99a24a6a832f",""

Added to that, I found new file under C:Program Files (x86)K2 blackpearlHost ServerBin named AdumError1 and it contain the following entry:



  1. The Domain Path("[NETLDAP]") is not in the Correct Format: "LDAP://DC=DOMAIN1,DC=COM", please contact your System Administrator.
       at ADUM.K2UserManager2.GetDomainNamePath(String& Path, String& Name)

Does any body have any ideas about this?


 


 


The Domain Path("[NETLDAP]") is not in the Correct Format: "LDAP://DC=DOMAIN1,DC=COM", please contact your System Administrator.
   at ADUM.K2UserManager2.GetDomainNamePath(String& Path, String& Name)


4 replies

Badge +10

Hi,


It looks like your K2 installation did not properly update the K2HostServer database. The [NETLDAP] string is a placeholder which should have been replaced with the correct LDAP string during Setup. I would suggest that you check your setup logs to determine what went wrong and then run through the Setup Manager again. It is probably due to some SQL permission. Ensure the installation account is a dbowner on all the K2 Databases.


Hope this helps!

Badge +10

Strangely enough I had exactly the same issue when trying to upgrade a Virtual Machine from KB1170 to KB1370.


A reconfigure did not resolve the problem.


Here is what I did to resolve it:


Run the following query on the K2HostServer database:


SELECT * FROM [K2HostServer].[dbo].[SecurityLabels] WHERE SecurityLabelName = 'K2'


On the resulst investigate the AuthInit and RoleInit column values. These will most probably still contain the placeholder values. Make a backup of the K2HostServer DB and then write an update query to update this value. The placeholder values you can get from the K2HostServer..Configuration table or by running the following query:


SELECT * FROM [K2HostServer].[dbo].[Configuration]
WHERE VariableToken = '[NETBIOSNAME]' OR VariableToken = '[NETLDAP]'


In your update query replace the placeholders with the values you retrieve from the Configuration table under the "VariableValue" column. The updated script should look something like this (My [NETBIOSNAME] = DENALLIX and [NETLDAP] = LDAP://DC=DENALLIX,DC=COM)


UPDATE [K2HostServer].[dbo].[SecurityLabels]
   SET [AuthInit] = '<AuthInit>
  <Domain>DENALLIX</Domain>
</AuthInit>'
      ,[RoleInit] = '<roleprovider>
  <init>ADCache=0;LDAPPath=LDAP://DC=DENALLIX,DC=COM;ResolveNestedGroups=False;IgnoreForeignPrincipals=False;IgnoreUserGroups=False;MultiDomain=False;OnlyUseSecurityGroups=False;DataSources=&lt;DataSources&gt;&lt;DataSource Path="LDAP://DC=DENALLIX,DC=COM" NetBiosName="DENALLIX" /&gt;&lt;/DataSources&gt;;;</init>
  <login />
  <implementation assembly="ADUM, Version=4.0.0.0, 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="UserPrincipalName" type="System.String" />
    </user>
    <group>
      <property name="Name" type="System.String" />
      <property name="Description" type="System.String" />
      <property name="Email" type="System.String" />
    </group>
  </properties>
</roleprovider>'
 WHERE [SecurityLabelName] = 'K2'


Please use the above script at own risk and ensure that you take a backup of the K2HostServer database before running this script so that you can restore it if it does not work.


I hope this resolves your problem.

Badge +3

Thanks JohanL 


It is working fine now, But I have another question:



  1. Why K2 Setup Manager does not update K2 Security label on K2_HostServer Database? I think this database is configured only on the installation step only.

Regards,
 

Badge +10

Hi Maki,


I think the cause for this problem was the suggestion Vernon made in the following thread: http://www.k2underground.com/forums/p/13749/40509.aspx#40509


There he instructed to run the default HostServerAlter script and not the populated one.


These scripts are only executed on the first installation so therefore the when this script was executed it basically reset the security labels. If the correct HostServerAlter script was used this problem could have been avoided.


To be clear, I also had the same problem explained in the other post about the GroupProviders and also ran the incorrect HostServerAlter script as Vernon suggested. I then manually fixed it using the steps above after trying a reconfigure but seeing that it did not work.


I don't think the Setup Manager checks the labels each time it is ran, so that might be the reason why it did not update the placeholders.


Regards,

Reply