This project has moved. For the latest updates, please go here.

Receive Location won't start using SSO

Coordinator
Jan 17, 2014 at 9:04 AM
Hi, we're using the SFTP adapter ver 1.4. It works fine using username+password in port config, but when we switched to using SSO the receive location refuses to start.

Here's the debug log:
Adapter.Adapter name: Sftp Receive Adapter
Adapter.Load
[SftpReceiveAdapter] Adapter Initializing...
Adapter.Initialize
[SftpReceiveAdapter] Adapter Initialized
The account name is not valid or does not exist. See the event log (on computer 'XXXXXBIZT01') for more details.
Here's the event log entry:
The Messaging Engine failed to add a receive location "XXXX_SFTP" with URL "SFTP://xxxx:22/XXXX/Output/*.txt" to the adapter "SFTP-Blogical". Reason: "Unable to read properties from SSO database. Make sure to use "UserName" and "Password" as fields".
Notice the discrepance of the error messages. I couldn't find the debug log message in the source code so I guess it's from Windows, or from the adapter base code.

We are using UserName and Password as fields. Here's the file with which we create the SSO application:
<SSO> 
  <application name="XXXX_SFTP"> 
    <description /> 
    <contact /> 
    <appUserAccount>DOMAIN\BizTalk Application Users T; DOMAIN\BizTalkHostUserRT; DOMAIN\BizTalkHostUserST; DOMAIN\BizTalkHostUserOT</appUserAccount> 
    <appAdminAccount>DOMAIN\SSO Affiliate Administrators T; DOMAIN\BizTalk Application Users T; DOMAIN\BizTalkHostUserRT; DOMAIN\BizTalkHostUserST; DOMAIN\BizTalkHostUserOT</appAdminAccount> 
    <field ordinal="0" label="UserName" masked="no" /> 
    <field ordinal="1" label="Password" masked="yes" /> 
    <flags groupApp="yes" configStoreApp="no" allowTickets="yes" validateTickets="yes" allowLocalAccounts="no" timeoutTickets="yes" adminAccountSame="no" enableApp="yes" /> 
  </application> 
</SSO> 
Any hints on where to look?
Coordinator
Jan 17, 2014 at 1:58 PM
RESOLVED: The account used wasn't really in the SSO Application Administrators group. What I mean with "really" is that the Windows domain has an alias name (don't ask me why and how, this is at a customer's site). Thus, you can enter an account name as X\user or X.PROD\user. The host instance was run under the account X.PROD\user but all the SSO Application accounts are entered as X\user.
I found out about the error when I debugged the code and found that the permissions exception was thrown from SSOConfigHelper at line 80:
((ISSOConfigStore)ssoStore).GetConfigInfo(appName, idenifierGUID, SSOFlag.SSO_FLAG_RUNTIME, (IPropertyBag)appMgmtBag);
The SSOConfigStore.GetConfigInfo appears to need SSO Application Administrator permissions. I changed the code to use SSO Lookup functions instead, and it worked.
WORKAROUND:
Add the exact account that the host instance runs as, to the SSO Application Administrators.
SOLUTION:
I will upload a patch that uses SSO Lookup functions instead, which does not need administrative priviledges.

Hope this helps other users!
Peter
Coordinator
May 8, 2014 at 8:19 AM
FYI: The patch I uploaded (15760) is in production at a customer's site since a couple of months, and it works fine.
Coordinator
May 8, 2014 at 9:35 PM
Would you like me to add you to the project, stop that you can merge your change and create a release?
Mikael

Sent from my Windows Phone

Coordinator
May 9, 2014 at 6:33 AM
Thanks, yes that was very kind of you! Suits me fine at the moment!
/Peter