none
IAG+Sharepoint 2007+Coqnos Web Part with Kerberos Constrained Delegation issue RRS feed

  • Question

  • Hello Experts,

    I want to get clarification from you with following design. I'm not so familiar with Coqnos so hopefully someone has published Coqnos before.

    Our customer has published Sharepoint 2007 via IAG and  Kerberos Constrained Delegation is used and KCD works with Sharepoint but not when end user is clicking Coqnos Web part on Sharepoint.

    Coqnos database is on SQL Server and front end Web Server is IIS 6,  Coqnos team states Coqnos side should be configured correctly.

    From IAG point of view Coqnos is published as Generic Web Application and KCD is selected on Web Settings-tab and Application SPN is defined. Maybe application type needs to be changed?

    SPN's has been registered for SQL server (MSSQLsvc) and for the hostname which has been defined is Application SPN-box and also for Coqnos Service Account.

    In Web Monitor, they'll see following error:

    "The request from user domain\user at source IP address xx.xx.xx.xx to trunk MyTrunk; Secure=1 failed because the request was unable to reply to an HTTP 401 request from application" so it seems to be delegation issue (?).

    In ADUC, when defining Application SPN to Delegation-box, it states that "value already exists", I think this could be because some other application is using same SQL server, or what do you think?

    Maybe the main question is, how would you start to troubleshoot this issue or do you see whole scenario is designed incorrectly?

    Please ask if you need more information, I will be more than glad to provide it.

    BR,

    -Snendis

    Monday, November 8, 2010 11:46 AM

Answers

  • Hello,

    The problem was solved by parsing the credential input which are sent into the Cognos login form.

    This case was tricky one :)

    BR,

    -Snendis

    • Marked as answer by Snendis Wednesday, December 1, 2010 6:46 AM
    Monday, November 29, 2010 8:10 PM

All replies

  • No ideas? Anyone?

    BR,

    -Snendis

    Friday, November 12, 2010 8:47 AM
  • Hi, Got this bit further. Turned out Cognos wasn't configured correctly to use Kerberos authentication mode. I think there could be something wrong with Delegation. Now when user click Cognos report on Sharepoint, IAG does not complain "You do not permission to access this application..." but prompts user to login again. It can be seen that username is in incorrect format in the form. Like this: "domain\username@domain.local" and not "domain\username". After user types credentials again user is redirected to the application. In Web Monitor error 24: "The request from user domain\user@domain.local at source IP address xx.xx.xx.xx to trunk MyTrunk; Secure=1 failed because the request was unable to reply to an HTTP 401 request from application" Kerberos itself seems to work since "Kerberos Protocol Transition Succeeded"-messages appears on Web Monitor. In Application->Web Settings -tab Application is following: "http/*" (http/FQDN have been tried also). Delegation for Coqnos application has been defined in ADUC like following (on IAG server Machine account): http/FQDN (This is coqnos server FQDN, no service account defined in SPN creation since IIS is using "local system" service account.) What am I missing? BR, -Snendis
    Monday, November 15, 2010 1:33 PM
  • Hi,

    Seems delegation part is now OK (I guess), I noticed following:

    When logging into Sharepoint application through IAG, I can see from Web Monitor that Kerberos ticket is actually created with in user's UPN attribute, not sAMAccountName as we would like to have.

    I tried to set these two registry keys into registry editor (found from http://support.microsoft.com/kb/975491):

    Subkey: HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\eGap\von\UrlFilter
    Entry: KCDUseKerberosSSN
    Type: REG_DWORD
    Value: 1
    and
    Subkey: HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\eGap\von\UrlFilter
    Entry: KCDUseSAMAccount
    Type: REG_DWORD
    Value: 1
    and restarted UserMgr-service and activated the configuration. Kerberos ticket is still created in UPN format. Why's that? I would expect this registry modification working since it's published by Microsoft. Cognos seems to expect sAMAccountName -formatted Kerberos ticket, since it's working from intranet perfectly.
    using NETMON Kerberos tickets are exact same when navigating to Cognos through IAG and directly to the application except:
    "KerberosV5:TGS Response Cname: user"  (when navigating directly), nametype NT-PRINCIPAL
    "KerberosV5:TGS Response Cname: user@domain.com"  (when navigating through IAG), nametype NT-ENTERPRISE.
    I think we are close but something's missing....... :(
    BR,
    -Snendis
    Wednesday, November 24, 2010 2:11 PM
  • In UAG, this is now:

    HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\URLFilter\KCDUseUPN

    Source: http://technet.microsoft.com/en-us/library/ee809087.aspx

    Maybe the same for later versions of IAG?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Erez Benari Wednesday, November 24, 2010 6:09 PM
    • Unmarked as answer by Snendis Wednesday, November 24, 2010 7:46 PM
    Wednesday, November 24, 2010 3:20 PM
    Moderator
  • Hi Jason,

     

    I Tried that registry value, no bonus. I think I didn't remove older registry entry "KCDUseSAMAccount" in registry also, I can try to remove that one. It seemed what ever I configured to the registry, UPN was used for KCD.

    Can Ben Ari confirm, this "KCDUseUPN" works in IAG sp2 version? if so, Jason's response can be marked as answer :)

     

    I also got update from System admin that there were some funny error on IAG server's event viewer.

    "kdc_err_s_principal_unknown" and target was pointing to the domain controller.

    Reason why it was funny, value in the target was domain controller's IP address, not hostname, i.e. "ldap/10.0.0.1".

    Even when Domain controller was also set as trusted for delegation.

     

    Anyway thank you Jason for your answer so far, I'll let you know how things are going.

     

    BR,

     

    -Snendis

    Wednesday, November 24, 2010 8:09 PM
  • Hello,

    The problem was solved by parsing the credential input which are sent into the Cognos login form.

    This case was tricky one :)

    BR,

    -Snendis

    • Marked as answer by Snendis Wednesday, December 1, 2010 6:46 AM
    Monday, November 29, 2010 8:10 PM