locked
Identity Crisis RRS feed

  • Question

  • Hi Everyone

    I'm having a bit of an identity crisis, when it comes to connecting to the CRM Platform using various methods. I thought I had this worked out and now I'm a little confused and looking for a heads up to put this isssue to bed once-and-for-all.

    When working with Plug-Ins or C# DLL's I've always used the code block below to carry out actions on the CRM Platform using the logged in users credentials. Sometime when working in Plug-Ins I've also used the boolean flag to carry out tasks using the administrator because I knew the users credentials didn't have direct access to parts of the system I needed.

    CrmAuthenticationToken token = new CrmAuthenticationToken();
    token.AuthenticationType = AuthenticationType.AD;
    token.OrganizationName = "Adventure Works";
    CrmService crmService = new CrmService();
    crmService.Url = @"http://localhost:5555/MSCRMServices/2007/CrmService.asmx";
    crmService.CrmAuthenticationTokenValue = token;
    crmService.Credentials = System.Net.CredentialCache.DefaultCredentials; crmService.UseDefaultCredentials = true; WhoAmIRequest whoRequest = new WhoAmIRequest();
    WhoAmIResponse whoResponse = (WhoAmIResponse)crmService.Execute(whoRequest);


    I've now started experimenting with writing custom web-pages to carry out actions within CRM that cannot be entertained by the platform directly.

    One such action involves changing flags on a number of items highlighted on a crm grid display. For this process to work correctly I need to know who the user is that's kicked-off the process. But everytime I run the code block above I'm not getting the logged on users credentials, but that of the internal admin account (the one in the SQL table but not visible from CRM UI).

    Whilst typing this I suddenly realised that IIS may be the issue here, so please can anybody confirm the following behaviours.

    1. Does connecting to the CRM Platform with the above code block always use the current logged on users credentials, or does it depend on where the code is being executed.

    2. If one wants to use the internal administrator account what should one do.

    3. If you want to create or amend records as a particular individual what do you have to do (given that you won't know their login details e.g. password).

    4. Does IIS cause the true user to be hidden and how do I ensure I can always detect the AD user.

    Many thanks

    Steve
    • Edited by lemonje Saturday, July 18, 2009 4:37 PM
    Saturday, July 18, 2009 4:31 PM

Answers

  • Hi,

    For the authentication on a web page you should better use the same code as the example provided in the sdk for custom web pages http://msdn.microsoft.com/en-us/library/cc151050.aspx The issue here is that to impersonate a user on a web page you need to have impersonation enabled, normally you set that by disable anonymous access on IIS and enabling impersonation. However, with the integrated pages in Dynamics CRM you need to accoun for the IFD authentication as well, and that introduces some situations where you need the anonymous access enabled which invalidate the direct impersonation.

    More answers.

    1. It actually depends on where the code is executed. If you use that code on a separate web site configured for impersonation on ISS and ASP.Net web config it will impersonate the user properly. However, if the web site has enable the anonymous access (as the CRM has site for IFD) it might happen that the user's browser doesn't send the credentials on the first connection as it's not being challenged to send them. Hence you get an anonymous user and your code will use the credential of the IIS App Pool.

    2. Use the Network Service or Local System credentials to use the System account.

    3. You can set the Called Id to the GUID of the target used to be impersonated on the Web Service proxy. This will cause the actions to be recorded as that user http://msdn.microsoft.com/en-us/library/cc151052.aspx

    4. Same as 1. IIS will hide the real user if impersonation is not enabled, and if anonymous access is enabled.

    Hope it helps.


    Marco Amoedo - http://marcoamoedo.com
    • Marked as answer by lemonje Monday, July 20, 2009 12:49 AM
    Sunday, July 19, 2009 10:45 PM
    Moderator

All replies

  • Hi,

    For the authentication on a web page you should better use the same code as the example provided in the sdk for custom web pages http://msdn.microsoft.com/en-us/library/cc151050.aspx The issue here is that to impersonate a user on a web page you need to have impersonation enabled, normally you set that by disable anonymous access on IIS and enabling impersonation. However, with the integrated pages in Dynamics CRM you need to accoun for the IFD authentication as well, and that introduces some situations where you need the anonymous access enabled which invalidate the direct impersonation.

    More answers.

    1. It actually depends on where the code is executed. If you use that code on a separate web site configured for impersonation on ISS and ASP.Net web config it will impersonate the user properly. However, if the web site has enable the anonymous access (as the CRM has site for IFD) it might happen that the user's browser doesn't send the credentials on the first connection as it's not being challenged to send them. Hence you get an anonymous user and your code will use the credential of the IIS App Pool.

    2. Use the Network Service or Local System credentials to use the System account.

    3. You can set the Called Id to the GUID of the target used to be impersonated on the Web Service proxy. This will cause the actions to be recorded as that user http://msdn.microsoft.com/en-us/library/cc151052.aspx

    4. Same as 1. IIS will hide the real user if impersonation is not enabled, and if anonymous access is enabled.

    Hope it helps.


    Marco Amoedo - http://marcoamoedo.com
    • Marked as answer by lemonje Monday, July 20, 2009 12:49 AM
    Sunday, July 19, 2009 10:45 PM
    Moderator
  • Many thanks Marco

    I suspected I had half the reason for my web-page not working, but your detailed explanation puts everything into context now, and allows me to do some more research on IIS settings.

    Thanks again

    Steve
    Monday, July 20, 2009 12:48 AM