locked
Delegation issue...or is it? RRS feed

  • Question

  • Good afternoon,
    I'm new to CRM, so I may use the wrong terminology from time to time. 

    My organization uses several custom ASP.net pages that are called from iframes within CRM. These pages live along size the native CRM website. 

    One of these custom ASP.net pages is a custom search page.  This page makes its own call to SQL Server using a standard connection string: 
    cn.ConnectionString = @"Data Source=sqlserver_name;Initial Catalog=MyCompany_MSCRM;Integrated Security=True";

    My web.config file (the one all of CRM uses) has the following parameters set:
    <authentication mode="Windows" />
    <identity impersonate="true" />

    And, in ADUC, the CRM web server's Delegation property is set to forward to any, using Kerberos. 

    When I test my code from my development machine, it runs fine.  When I execute it from within CRM, I receive the error: 
    Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

    For whatever reason, my user account information isn't making it to SQL Server like it does in my local build, even though all of the applicable settings seem to be correct. (and delegation is clearly working for the rest of CRM) We are using the OnPremise authentication scheme as this is an intranet deployment.

    Any ideas on why this might be happening?

    P.S.  We are intentionally not using web services to interface with the database for this purpose because we prefer the flexibility of writing our own queries in SQL (and avoiding writing XML or building a query object programmatically)
    Thursday, February 25, 2010 6:09 PM

Answers

  • Following step 5 from the previously mentioned article did produce a change. (It is worth noting that the MSDN article he references has incorrect syntax that will break authentication in IIS.)

    After we figured out that the MSDN article was wrong, we noticed an immediate change: our lead developer suddenly was able to use the custom search in our development environment. Excitement quickly faded when we found that only his username was able to access it.  Strangely, he started receiving the same error message 5 minutes later. 

    We restarted IIS but it did not help. 

    This all happened around 5PM EST so we have postponed further testing till Monday.

    Any additional ideas would be welcome...it seems we have done everything prescribed, there just is something not quite working. 
    • Marked as answer by Jim Glass Jr Tuesday, March 2, 2010 5:38 PM
    Saturday, February 27, 2010 6:03 PM

All replies

  • Hi
    Generally, MS CRM Applictations run under the user  of "Network service" which impersonate enabled, the user who is using the application is actually the one whose context is being used to perform the operations.
    so in your case instead of using windows authention like this.
    cn.ConnectionString = @"Data Source=sqlserver_name;Initial Catalog=MyCompany_MSCRM;Integrated Security=True";
    create a "sql server authentication user in MS CRM database and then change teh configuration to work like this.
    cn.ConnectionString = @"Data Source=sqlserver_name;Initial Catalog=MyCompany_MSCRM;userid=sa;password=sa";

    But i still believe using the webservice is better. beacause Microsoft may change teh database structure in future version of CRM or any roolup update may break up your existing code against sql server.

    Muhammad Ali Khan
    My MS CRM blog
    Thursday, February 25, 2010 6:22 PM
  • Thanks for the reply, Muhammad. 

    The reason using Integrated Security is important to us is the ability to limit the results to only what the user has access to.  Using a specific account would return all results. 

    Does that make sense?
    Thursday, February 25, 2010 6:32 PM
  • Yes i know, in this case you have to add all the users to the sql server database, means create the sql server windows account for all the users., offcourse not a goot option. but i think in your case this is the only option.
    This is the exact reason i would prefer using webservice, because it will return you the records only the user has the access to.
    Regarding the "FilteredViews" which you are using ( i think), these filtered views are there for MS CRM custom reports.

    Muhammad Ali Khan
    My MS CRM blog
    Thursday, February 25, 2010 6:37 PM
  • Thanks for the quick response. We are indeed using FilterViews. I mispoke before. (I am not the primary developer on this project, I'm just trying to research the issue.)

    The thing that is not making sense for me is that my account has full access to the SQL server in question, so even if what you say is true (about needing to use a sql account or create accounts for everyone), it still makes no sense that my account would return an error about an anonymous login, right? At a minimum it should say my account is unable to authenticate.

    There's just something not quite adding up here. 
    Thursday, February 25, 2010 7:11 PM
  • Your account has teh rights on the MS CRM database as well? you have to give the rights on the MSCRM_Config and MSCRM_organization database, at least dbo.reader.

    Muhammad Ali Khan
    My MS CRM blog
    Thursday, February 25, 2010 7:15 PM
  • I have full rights to both databases. 
    Thursday, February 25, 2010 7:26 PM
  • When I test my code from my development machine, it runs fine.  When I execute it from within CRM, I receive the error: 
    Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

    In IIS, can you remove "Anyonmous" from your Virtual Directory, i think in IIS you still have enabled anonymous in addition to windows authetnication and thats why it is using anymonus.

    Muhammad Ali Khan
    My MS CRM blog
    Thursday, February 25, 2010 7:29 PM
  • I actually have that unchecked as well. 

    I should have mentioned that in my original post.  "Enable Anonymous access" is not checked...only "Integrated Windows authentication" is checked. 
    Thursday, February 25, 2010 7:32 PM
  • hmmm, can u check the "Identity of the the application pool" your website is running under? is it NetworkService, if not then change it to "Network Service"
    Muhammad Ali Khan
    My MS CRM blog
    Thursday, February 25, 2010 7:39 PM
  • I believe the issue may be related to step 5 in this article:

    I have made the change and am currently testing. I'll update as soon as I have a result. 
    Thursday, February 25, 2010 7:54 PM
  • It does sound like a delegation issue (based on the fact that the error is about 'Anonymous'). What account is used for the identity of the application pool that your code runs under ? If it's a built-in account (e.g. Network Service), then the delegation properties in AD need setting on the computer object (as you stated earlier, and in the article you linked to), but if it runs under a specific service account, then you need to set the delegation properties for that account.

    I'd also use the setspn tool to check the SPNs that Kerberos needs.
    Microsoft CRM MVP - http://mscrmuk.blogspot.com  http://www.excitation.co.uk
    Thursday, February 25, 2010 8:34 PM
    Moderator
  • Following step 5 from the previously mentioned article did produce a change. (It is worth noting that the MSDN article he references has incorrect syntax that will break authentication in IIS.)

    After we figured out that the MSDN article was wrong, we noticed an immediate change: our lead developer suddenly was able to use the custom search in our development environment. Excitement quickly faded when we found that only his username was able to access it.  Strangely, he started receiving the same error message 5 minutes later. 

    We restarted IIS but it did not help. 

    This all happened around 5PM EST so we have postponed further testing till Monday.

    Any additional ideas would be welcome...it seems we have done everything prescribed, there just is something not quite working. 
    • Marked as answer by Jim Glass Jr Tuesday, March 2, 2010 5:38 PM
    Saturday, February 27, 2010 6:03 PM
  • It was SPNs.

    The service account being used for our development SQL server environment wasn't able to setup the SPNs for our instance.  We fixed that and it started working.

    Thanks to all for your help on this. I couldn't have done it without you.
    Monday, March 1, 2010 9:16 PM
  • Glad you got it sorted. SPNs do tend to cause an inordinate amount of trouble, especially when using service accounts. I much prefer to use built-in accounts, but unfortunately that's not always my decision.

    An additional headache with SPNs is that the information is written to AD. As you may need to wait for AD replication to complete for changes to take effect, you can often see apparently inconsistent behaviour
    Microsoft CRM MVP - http://mscrmuk.blogspot.com  http://www.excitation.co.uk
    Tuesday, March 2, 2010 12:18 PM
    Moderator