locked
Reporting Error when running report in CRM - rsAccessDenied RRS feed

  • Question

  • Hi all,

    We have several new users in our CRM.

    The old users -all of them have SysAdmin role- can access the Report without problem. However, when I access a report using 1 of the new users (let's call him Person1), there is a 'Reporting Error'.

    This happens when I access standard CRM report or custom (deployed) CRM Report. Eventhough the security role of Person1 is changed to SysAdmin, the error still occured.

    Below is the Reporting Error details:

    ReportServerException: The permissions granted to user 'DOMAIN\USERNAME' are insufficient for performing this operation.

    When I check in the AD, Person1 is member of:

    - Domain Users

    - Reporting Group

    - User Group

     

    Is there any other settings I need to do according to this error?

    Thanks for any help!


    Regards, Astri Kusumawardani
    Tuesday, September 28, 2010 10:23 AM

All replies

  • while creating the user wt type of licensing you have given to that user?

     

    Sudhanshu

    Tuesday, September 28, 2010 11:04 AM
  • thanks for your reply, sudhanshu.

    sorry if i don't understand, do you mean the licensing when creating user in AD, or in CRM?


    Regards, Astri Kusumawardani
    Wednesday, September 29, 2010 2:11 AM
  • its obvously in crm.

     

    Sudhanshu

    Wednesday, September 29, 2010 6:11 AM
  • the new users have the full licensing, same with the old users.
    Regards, Astri Kusumawardani
    Wednesday, September 29, 2010 12:07 PM
  • sorry to unmark the answer. but the problem is not resolved yet by the answer.

    the new users have the full licensing, same with the old users however the new users cannot access the report with following error message:

    "The permissions granted to user 'DOMAIN\USERNAME' are insufficient for performing this operation"

    is there any idea about this? thanks in advance.

     


    Regards, Astri Kusumawardani
    Friday, October 1, 2010 1:07 AM
  • Hi Astri,

    No issue at all.

    that was one catch related to that.

    just try to observe the following.

    go to settings -> addministrator -> Security roles -> and select the role the user is assigned to.

    and go to Core Records tab and see the privilege of the Reports.

    give the privilege as per required.

     

    hope this will help you out.

    Can you please share your gtalk-id so that we can share crm stuffs with each other?

    for more tips on crm click here http://bproud2banindian.blogspot.com/

     

    Sudhanshu

    Friday, October 1, 2010 4:58 AM
  • hi sudhanshu,

    actually even if the new user is given the System Administrator security role, i still couldn't view the Report when i log in as that user.

    that's why i'm confused.


    Regards, Astri Kusumawardani
    Friday, October 1, 2010 10:21 AM
  • Hi,

    Does the user also exist in SQL Reporting Group.

    Regards

    TGB


    Microsoft Certified Business Management Solutions Specialist
    Saturday, October 2, 2010 4:33 PM
  • Hi TGB, thanks for your reply.

    sorry if my question seems stupid since i don't know much about crm deployment:

    SQL Reporting Group that you mention, is it the ReportingGroup in Active Directory? If yes, this user is the member of ReportingGroup (the same ReportingGroup with the old user who can access the report)


    Regards, Astri Kusumawardani
    Monday, October 4, 2010 9:43 AM
  • Hi,

    It seems that your Reports virtual directory in IIS is set to allow anonymous access.  Try disabled anonymous access on this directory and see the reporting site working. 

    Hope it helps.


    Thanks, Ranjitsingh R | http://mscrm-developer.blogspot.com/ | MS CRM Consultant
    Monday, October 4, 2010 5:13 PM
  • Astri, I did see if this is SQL 2005 or SQL 2008.

    This error comes up on SQL 2008.

    If it's SQL 2008, look to see if there is a ROLE is SRS called Network service and give that the Browse Right.

    Restart the services and let us know what you come up with.

     

     


    Curtis J Spanburgh
    Monday, October 4, 2010 6:41 PM
    Moderator
  • hi, thanks for replying.

    unfortunately the anonymous access in IIS in Reports virtual directory is already disabled. do you have any other idea?


    Regards, Astri Kusumawardani
    Tuesday, October 5, 2010 3:19 AM
  • Yes , did you look at the roles in SRS and assign that right to he network Service?

     


    Curtis J Spanburgh
    Tuesday, October 5, 2010 3:59 AM
    Moderator
  • Hi Curt, thanks for replying. Sorry i thought i had replied to you also. Seems like i'm daydreaming..

    The SQL Server is SQL Server 2005, not 2008.

    However, using the old user, I can login to the Reports site, and from there I see the NETWORK SERVICE role already have all roles (Browser, Browser for MIcrosoft CRM, etc)


    Regards, Astri Kusumawardani
    Tuesday, October 5, 2010 5:46 AM
  • Have you compared user profile to user workstation?

    In other words , if the same user uses two or three different devices do the receive the same failure to SRS?

    Without attempting to run reports can they reach the srs server in their browsers?

     


    Curtis J Spanburgh
    Tuesday, October 5, 2010 7:55 AM
    Moderator
  • Hi Curt,

    In other words , if the same user uses two or three different devices do the receive the same failure to SRS?

    I've tried on other computers as well. I tried running reports from CRM with the same user (DOMAIN\person1) and the result is the same.

    Without attempting to run reports can they reach the srs server in their browsers?

    Yes 'DOMAIN\person1' can open the http://localhost/reports, but no report list is shown. However this user cannot enter http://localhost/ReportServer. There is the same error "The permission granted to user 'DOMAIN\person1' are insufficient for performing this operation. (rsAccessDenied)"

    Does this indicate something? Thanks in advance.


    Regards, Astri Kusumawardani
    Tuesday, October 5, 2010 8:42 AM
  • Yes, it could very well be a Kerberos error on the part of the User account in active directory.

    Serveral factors can cause this.  One common one in the past was excessive group membership in AD.

    When you realize that there is not much difference between a machine account and a user account and that both have extensive attributes you begin to percieve network authentication in a different light.

    IMHO the whole reason for the SQL Connector was to cut down on the support calls because of the double hop kerberos issue.

    But it does not end there.  Service records and Missing or duplicate SPNs can cause network havoc.

    Download the SPN tool SetSPN from the MSFT site.

    I had to use this tool one time to prove that users in one forest who could see the reports in a CRM instance of another forest but could not run them.   The forest were on different continents.

    The were linked by a forest trust. 

    One probem they did not understand.   There were two forest levels.   Because of that the forest trust did not allow kerberos traffic.  How did I know?   I ran an network monitor trace and studied it for about a day.

    In about 10 thousand packets I only saw NTLM traffic.

    I used the SetSPN tool to query accounts access to the Reports server.

    They all failed.

    This was the inspiration for an article I did a few years ago.

    http://www.windowsitpro.com/article/reporting-services/twelve-angry-techs.aspx

     In another recent situation CRM reports were working fine on a On Premise instance of CRM in a local segment.    There were several products working together.  Dynamics SL, Microsoft Business Portal and Dynamics CRM 4.0 were migrated to new Windows 2008 virtual servers in a hosted environment.  The hosted network segment was linked via trust to network segments in the US and EU.

    The result? Dynamics application authentication broke everywhere.

    I laughed when the "Network Engineer" at the hosting company said that authenticaton was ok because he could "Ping the servers".

    There were lots of details to the incidentg but we did get it sorted out.

    IPV6 was the issue.   Nothing wrong with IPV6 but it has to work "all the time" over the entire network layer of that old dusty thing called the OSI model.

    Since most of us have that in a closet somewhere we don't think of it much.

    It turned out that there was an issue with the virtual NICs in the VMs and another with the HBAs of the Fibre channels.

    That being applied authentication worked again.

    Nothing worse than that being able to login one day and the next day you can't.

    So in short, there experiences show us that it's time to go deeper.

    So at this point, IMHO I think you may want to stop blaming CRM and look underneath.

     


    Curtis J Spanburgh
    Tuesday, October 5, 2010 2:57 PM
    Moderator
  • A few more details to look at:

    Look at your security in SRS:

    Here's an example:

    NT AUTHORITY\NETWORK SERVICE Publisher for Microsoft CRM
    BUILTIN\Administrators Content Manager
    ATL\SQLAccessGroup {6a008455-7f75-4922-828a-1e53e4fab79c} Publisher for Microsoft CRM
    ATL\ReportingGroup {6a008455-7f75-4922-828a-1e53e4fab79c} Browser for Microsoft CRM

     

    As mentioned before, group membership is important.

     


    Curtis J Spanburgh
    Tuesday, October 5, 2010 3:42 PM
    Moderator
  • Hi Curt,

    Thanks for your information about what I need to look at. Please give me few days before I could confirm your above suggestions, as I was now deployed to other task. Thanks and I will reply asap after checking those you suggested.


    Regards, Astri Kusumawardani
    Wednesday, October 6, 2010 2:32 AM