Cannot launch SSRS Report Manager
SSRS v2012, I am the admin. I installed and configured SSRS in native mode successfully. I had enabled several third party report sets (ie., BizNet, Great Plains, etc.), and even enabled a couple of users. No problems anywhere, things were fine. Last week we made a change to implement Kerberos Authentication. This is because the reporting layer is 3 tiers; clients, SSRS, relational database data sources -- and I needed to get around the double-hop. I used this reference to set up the Kerberos Authentication: http://technet.microsoft.com/en-us/library/ff679930(v=sql.100).aspx
No errors anywhere, no reason to think it wasn't done properly... I even loaded the Report Mgr URL several times after I had edited rsreportserver.config, and had restarted the SSRS svc. No problems, Report Mgr loaded up fine.
However right now, nobody can access Report Manager. Prior to making the Kerberos change I had been in there and established some security. My domain login was content manager and everything else, and I had several users set up with a little less privilege. Again, all of the security was defined prior to the Kerberos change, and everyone was able to get into the Report Manager successfully. We hadn't gone any farther than that yet, but the tool was usable.
Now, when I attempt to load the Report Mgr URL, I receive a Windows Security dialog box, which says 'Connecting to SERVERNAME.domainname.com'
This happens if I launch IE as administrator or non-admin. If I attempt to use Chrome to load the URL, I receive a message saying authentication is required. I input my credentials and receive this:
This webpage is not available
When I hit 'details', I receive this:
The webpage at http://servername/reports might be temporarily down or it may have moved permanently to a new web address.
Error code: ERR_INVALID_AUTH_CREDENTIA
This is the <authentication> within my rsreportserver.config - I only replaced RSWindowsNTLM with RSWindowsNegotiate, as instructed in the reference I noted above.
<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
</AuthenticationTypes&g
<RSWindowsExtendedProte
<RSWindowsExtendedProte
<EnableAuthPersistence&
</Authentication>
Is anyone able to advise?
No errors anywhere, no reason to think it wasn't done properly... I even loaded the Report Mgr URL several times after I had edited rsreportserver.config, and had restarted the SSRS svc. No problems, Report Mgr loaded up fine.
However right now, nobody can access Report Manager. Prior to making the Kerberos change I had been in there and established some security. My domain login was content manager and everything else, and I had several users set up with a little less privilege. Again, all of the security was defined prior to the Kerberos change, and everyone was able to get into the Report Manager successfully. We hadn't gone any farther than that yet, but the tool was usable.
Now, when I attempt to load the Report Mgr URL, I receive a Windows Security dialog box, which says 'Connecting to SERVERNAME.domainname.com'
This happens if I launch IE as administrator or non-admin. If I attempt to use Chrome to load the URL, I receive a message saying authentication is required. I input my credentials and receive this:
This webpage is not available
When I hit 'details', I receive this:
The webpage at http://servername/reports might be temporarily down or it may have moved permanently to a new web address.
Error code: ERR_INVALID_AUTH_CREDENTIA
This is the <authentication> within my rsreportserver.config - I only replaced RSWindowsNTLM with RSWindowsNegotiate, as instructed in the reference I noted above.
<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
</AuthenticationTypes&g
<RSWindowsExtendedProte
<RSWindowsExtendedProte
<EnableAuthPersistence&
</Authentication>
Is anyone able to advise?
Hi,
Firstly, SSRS in SQL Server 2012 uses role based authentication, you must ensure that each group has access to the Report Manager / Web Service, also note that the Report Server Web service and Report Manager use the same authentication type.
To confirm that this is a Kerberos issue, replace RSWindowsNegotiate with RSWindowsNTLM and retry, if this works, then Kerberos is misconfigured, else you have another underlying issue.
Are you running the Report Server under a local account, or a domain account?
If this is under a domain account, you must use an SPN for that account, try changing the service account to run under a built-in account such as Network Service.
Cheers
Leon
Firstly, SSRS in SQL Server 2012 uses role based authentication, you must ensure that each group has access to the Report Manager / Web Service, also note that the Report Server Web service and Report Manager use the same authentication type.
To confirm that this is a Kerberos issue, replace RSWindowsNegotiate with RSWindowsNTLM and retry, if this works, then Kerberos is misconfigured, else you have another underlying issue.
Are you running the Report Server under a local account, or a domain account?
If this is under a domain account, you must use an SPN for that account, try changing the service account to run under a built-in account such as Network Service.
Cheers
Leon
ASKER
I have confirmed it is a problem w/our Kerberos setup. I did this by removing RSWindowsNegotiate from the rsreportserver.config, and replacing it with RSWindowsNTLM. I made this change and restarted the SSRS service. Now I can launch the Report Manager just fine.
Then, I stopped SSRS again, put RSWindowsNegotiate back into the config file, and changed the svc account to Network Service. Restarted the SSRS service, and again, I can launch the Report Mgr just fine.
But -- I don't want to leave it this way. We'll need the service account to be a domain account.
I have attached the SSRS log from before making the above changes that allowed me to get into the Report Mgr URL successfully. It has been slightly genericized, but only the names of the server, domain and service account. Otherwise, it is unchanged.
Is anyone able to see a problem?
ReportServerService--12-19-2014-02-32-08
Then, I stopped SSRS again, put RSWindowsNegotiate back into the config file, and changed the svc account to Network Service. Restarted the SSRS service, and again, I can launch the Report Mgr just fine.
But -- I don't want to leave it this way. We'll need the service account to be a domain account.
I have attached the SSRS log from before making the above changes that allowed me to get into the Report Mgr URL successfully. It has been slightly genericized, but only the names of the server, domain and service account. Otherwise, it is unchanged.
Is anyone able to see a problem?
ReportServerService--12-19-2014-02-32-08
ASKER
Hi Leon. Looks like we crossed paths... I did exactly what you suggested to confirm that yes, it is a problem with Kerberos. The svc account was a domain account, but it is network service right now, and the Report Mgr URL is available. I do not want to leave it this way, though, and it is still unclear to me where exactly the Kerberos problem is.
ASKER
also the spn is setup. as I mentioned in the first post, this is the reference we used to define the Kerberos:
http://technet.microsoft.com/en-us/library/ff679930(v=sql.100).aspx
the dc, the spns, the trust delegation, the Kerberos full delegation and the ssrs authentication types. these things were all defined as outlined in the document downloadable from the above link.
looks like there is an error somewhere, but it is not clear -- and it is not being logged anywhere that I have found yet.
http://technet.microsoft.com/en-us/library/ff679930(v=sql.100).aspx
the dc, the spns, the trust delegation, the Kerberos full delegation and the ssrs authentication types. these things were all defined as outlined in the document downloadable from the above link.
looks like there is an error somewhere, but it is not clear -- and it is not being logged anywhere that I have found yet.
Hi,
Seems you have everything set correctly.
Have a look at the web config file for the report server, check that the authentication is set to windows and not forms.
Cheers
Leon
Seems you have everything set correctly.
Have a look at the web config file for the report server, check that the authentication is set to windows and not forms.
Cheers
Leon
ASKER
From the web.config file within the \ReportingServices\ReportS
<authentication mode="Windows" />
Do you have any suggestions for how to move forward, Leon? Per this reference, I have a Kerberos problem, yet I am not sure what it is, or how to correct it. http://msdn.microsoft.com/en-us/library/cc281253(v=sql.110).aspx
<authentication mode="Windows" />
Do you have any suggestions for how to move forward, Leon? Per this reference, I have a Kerberos problem, yet I am not sure what it is, or how to correct it. http://msdn.microsoft.com/en-us/library/cc281253(v=sql.110).aspx
ASKER
>>Firstly, SSRS in SQL Server 2012 uses role based authentication, you must ensure that each group has access to the Report Manager / Web Service, also note that the Report Server Web service and Report Manager use the same authentication type.
Leon, please tell me how to confirm that the RS Web Service and Report Mgr use the same authentication type.
Leon, please tell me how to confirm that the RS Web Service and Report Mgr use the same authentication type.
ASKER
I've worked with the domain admin today, verified the SPNs are all in place for the service account, for the fqdn and the NetBIOS. Yet I still cannot launch report mgr unless the SSRS service is running under Network Service, rather than the domain account.
Any Expert suggestions?
Any Expert suggestions?
Hi,
Sorry for he late reply, got dragged to the company Christmas do.
Everything points to a Kerberos issue, but everything seems to be setup correctly from what I can see.
Are you using the Network Name in the URL rather than the FQDN?
If the URL includes a FQDN, Internet Explorer selects NTLM.
If the URL specifies localhost, Internet Explorer selects NTLM.
If the URL specifies the network name of the computer, Internet Explorer selects Negotiate, which will succeed or fail depending on whether an SPN exists for the Report Server service account.
Are you certain you are in the same Forest?
Are there versions / editions of Windows Server on the Network which do not support Kerberos Authentication?
Apart from that I am the limits of my expertise, I think someone with more Windows Admin and Authentication will have to step in, sorry I could not be of more assistance.
Cheers
Leon
Sorry for he late reply, got dragged to the company Christmas do.
Everything points to a Kerberos issue, but everything seems to be setup correctly from what I can see.
Are you using the Network Name in the URL rather than the FQDN?
If the URL includes a FQDN, Internet Explorer selects NTLM.
If the URL specifies localhost, Internet Explorer selects NTLM.
If the URL specifies the network name of the computer, Internet Explorer selects Negotiate, which will succeed or fail depending on whether an SPN exists for the Report Server service account.
Are you certain you are in the same Forest?
Are there versions / editions of Windows Server on the Network which do not support Kerberos Authentication?
Apart from that I am the limits of my expertise, I think someone with more Windows Admin and Authentication will have to step in, sorry I could not be of more assistance.
Cheers
Leon
ASKER
>>Are you using the Network Name in the URL rather than the FQDN?
I am just using the default URL setup within SSRS config. Like this: http://servername/Reports
>>If the URL specifies the network name of the computer, Internet Explorer selects Negotiate, which will succeed or fail depending on whether an SPN exists for the Report Server service account.
This is what I would expect, as I have edited the rsreportserver.config to use RSWindowsNegotiate rather than RSWindowsNTLM. And yes, an SPN was created NetBIOS and fqdn for the ssrs service account.
No apologies necessary, Leon. I really do appreciate your input. Hopefully another expert will see this, and be able to advise.
I am just using the default URL setup within SSRS config. Like this: http://servername/Reports
>>If the URL specifies the network name of the computer, Internet Explorer selects Negotiate, which will succeed or fail depending on whether an SPN exists for the Report Server service account.
This is what I would expect, as I have edited the rsreportserver.config to use RSWindowsNegotiate rather than RSWindowsNTLM. And yes, an SPN was created NetBIOS and fqdn for the ssrs service account.
No apologies necessary, Leon. I really do appreciate your input. Hopefully another expert will see this, and be able to advise.
ASKER
Again, I have confirmed the problem is Kerberos, but I cannot identify exactly what is the source of the conflict. Is anyone able to advise?
Hi, was just thinking.
On the local machine Report Manager URL (http://localhost/ReportManager/Pages/Folder.aspx), look in Folder Settings, are the users in the domain group(s) given the rights to open the report manager?
Cheers
Leon
On the local machine Report Manager URL (http://localhost/ReportManager/Pages/Folder.aspx), look in Folder Settings, are the users in the domain group(s) given the rights to open the report manager?
Cheers
Leon
ASKER
Will check first thing in the am and get back to you, Leon.
ASKER
>>Firstly, SSRS in SQL Server 2012 uses role based authentication, you must ensure that each group has access to the Report Manager / Web Service, also note that the Report Server Web service and Report Manager use the same authentication type.
Leon, is it correct to say that IF Kerberos is setup correctly, the way to provide each AD group the correct access, is to add them within Report Manager. Open it up, Folder Settings, New Role Assignment... and then input the AD group here, with the correct role, such as Browser.
Leon, is it correct to say that IF Kerberos is setup correctly, the way to provide each AD group the correct access, is to add them within Report Manager. Open it up, Folder Settings, New Role Assignment... and then input the AD group here, with the correct role, such as Browser.
ASKER
My Report Manager URL is the default, http://servername:80/Reports.
Since the attempt to enable Kerberos, the ONLY way I could even launch Report Manager was by changing the SSRS service account from the domain account to Network Service.
Today, after re-reading all of your input, Leon, I realized that I had not properly defined the different user accounts (AD Groups) within the Report Manager -- using item and server level role assignments. Presumably, that was the reason they cannot even open Report Manager since the Kerberos was enabled.
I then used this reference to create my item and server level roles for just two AD groups, several role assignments, but primarily Browser -- assuming that is the requirement for just opening the Report Manager.
http://technet.microsoft.com/en-us/library/ms156034(v=sql.110).aspx
Then, I stopped the SSRS service, changed the service account, deleted/recreated the encryption key, and re-started the service.
Now, even after that, I still could not launch Report Manager. I stopped the SSRS svc again, changed it back to Network Service, and restarted the service. I can get into the Report Manager now.
My account, mind you, is a System Administrator and System User in the Site Settings.
The ONLY thing that I can see that MAY be a problem, is that the local security policies are not setup properly for the SSRS service account. Specifically, it cannot logon as a service. It is, however, set up to impersonate. Unfortunately, I cannot change the local policy. I have to wait for my domain admin.
I want to say that this further confirms the problem is with Kerberos, but maybe goes a bit further and suggests the service account is not setup correctly for delegation. Leon, do you think that is it? Only today as I was checking all of the configs, did I realize it was not defined to logon as a service.
What do you think?
Since the attempt to enable Kerberos, the ONLY way I could even launch Report Manager was by changing the SSRS service account from the domain account to Network Service.
Today, after re-reading all of your input, Leon, I realized that I had not properly defined the different user accounts (AD Groups) within the Report Manager -- using item and server level role assignments. Presumably, that was the reason they cannot even open Report Manager since the Kerberos was enabled.
I then used this reference to create my item and server level roles for just two AD groups, several role assignments, but primarily Browser -- assuming that is the requirement for just opening the Report Manager.
http://technet.microsoft.com/en-us/library/ms156034(v=sql.110).aspx
Then, I stopped the SSRS service, changed the service account, deleted/recreated the encryption key, and re-started the service.
Now, even after that, I still could not launch Report Manager. I stopped the SSRS svc again, changed it back to Network Service, and restarted the service. I can get into the Report Manager now.
My account, mind you, is a System Administrator and System User in the Site Settings.
The ONLY thing that I can see that MAY be a problem, is that the local security policies are not setup properly for the SSRS service account. Specifically, it cannot logon as a service. It is, however, set up to impersonate. Unfortunately, I cannot change the local policy. I have to wait for my domain admin.
I want to say that this further confirms the problem is with Kerberos, but maybe goes a bit further and suggests the service account is not setup correctly for delegation. Leon, do you think that is it? Only today as I was checking all of the configs, did I realize it was not defined to logon as a service.
What do you think?
ASKER
Just want to reiterate; With the ssrs service account as Network Service, I can launch the Report Manager locally, or remotely. With the service running under the domain account, I cannot launch the Report Manager anywhere. Locally, or otherwise.
Hi,
Sorry I have not been around today.
I am pretty certain If it is setup to impersonate, it switches to NTLM as there is no Kerberos Key, but I am not a network admin, so I could be wrong :)
With the Network Account running under the Network Service Local Account for the OS, NTLM will be used, so that explains why you can access the service in the local account since the OS is aware of the LDAP user accounts.
Under the Domain Account, if SSRS has no rights, it will not run.
Cheers
Leon
Sorry I have not been around today.
I am pretty certain If it is setup to impersonate, it switches to NTLM as there is no Kerberos Key, but I am not a network admin, so I could be wrong :)
With the Network Account running under the Network Service Local Account for the OS, NTLM will be used, so that explains why you can access the service in the local account since the OS is aware of the LDAP user accounts.
Under the Domain Account, if SSRS has no rights, it will not run.
Cheers
Leon
ASKER
>>Under the Domain Account, if SSRS has no rights, it will not run
Sure, sure, but where are the rights missing? What privilege or configuration is missing for the SSRS service domain account?
Sure, sure, but where are the rights missing? What privilege or configuration is missing for the SSRS service domain account?
Hi,
The SPNs define the services which User Accounts can run which Services in Kerberos Authentication.
I have had a chat with a friend who is a Network Admin for a large organization, he has stated the following:
The Domain User Account running Reporting Services needs 2 of 3 separate SPNs to function depending on the setup, these are NetBIOS / FQDN and HTTP. (IIRC you are using the NetBIOS name to contact the server.)
The same is true if NETWORK SERVICE is used to host SSRS.
if there is no SPN, it will fall back to NTLM
So you need 2 SPNs, one for http and one for NetBIOS
Cheers
Leon
The SPNs define the services which User Accounts can run which Services in Kerberos Authentication.
I have had a chat with a friend who is a Network Admin for a large organization, he has stated the following:
The Domain User Account running Reporting Services needs 2 of 3 separate SPNs to function depending on the setup, these are NetBIOS / FQDN and HTTP. (IIRC you are using the NetBIOS name to contact the server.)
The same is true if NETWORK SERVICE is used to host SSRS.
if there is no SPN, it will fall back to NTLM
So you need 2 SPNs, one for http and one for NetBIOS
Cheers
Leon
ASKER
Hi Leon. Yes, I did ask for that, and we do have 2 SPNs. See here:
C:\>setspn -L accountname
Registered ServicePrincipalNames for CN=accountname,OU=Service Accounts,DC=domainname,DC=
http/servername:1433
http/servername.domainname
There is one more spn on the box, for the old service account. I wonder if that should be removed.
You said before that 'Under the Domain Account, if SSRS has no rights, it will not run.'
What rights are missing? The service runs just fine under the domain account until we attempted to enable the Kerberos.
C:\>setspn -L accountname
Registered ServicePrincipalNames for CN=accountname,OU=Service Accounts,DC=domainname,DC=
http/servername:1433
http/servername.domainname
There is one more spn on the box, for the old service account. I wonder if that should be removed.
You said before that 'Under the Domain Account, if SSRS has no rights, it will not run.'
What rights are missing? The service runs just fine under the domain account until we attempted to enable the Kerberos.
ASKER
This has really become critical. I have attempted to enable Kerberos Authentication, and now I cannot launch Report Manager unless the SSRS service is running under NETWORK Service.
recap -
SSRS was installed, completely built out, everything fine. Service running just fine under a windows domain account.
Then, an attempt was made to enable Kerberos -
DC configured and SPNs created
Service account trusted for delegation
Authentication type changed to RSWindowsNegotiate in rsreportserver.config
Local security policies set for service account
Now, the Report Manager cannot be opened by anyone, UNLESS the SSRS service is running under NETWORK SERVICE, rather than the domain account.
NOTE: Only impersonate client after authentication is enabled. I have just confirmed (again) that Log On as a Service is not enabled for the service account.
Is that enough to prevent anyone (even myself who is admin) from launching Report Manager?
The SSRS service runs just fine under both NETWORK SERVICE and a specified domain account.
recap -
SSRS was installed, completely built out, everything fine. Service running just fine under a windows domain account.
Then, an attempt was made to enable Kerberos -
DC configured and SPNs created
Service account trusted for delegation
Authentication type changed to RSWindowsNegotiate in rsreportserver.config
Local security policies set for service account
Now, the Report Manager cannot be opened by anyone, UNLESS the SSRS service is running under NETWORK SERVICE, rather than the domain account.
NOTE: Only impersonate client after authentication is enabled. I have just confirmed (again) that Log On as a Service is not enabled for the service account.
Is that enough to prevent anyone (even myself who is admin) from launching Report Manager?
The SSRS service runs just fine under both NETWORK SERVICE and a specified domain account.
ASKER
ok. I have finally gotten them to get the correct security policies into place. the service account can not log on as a service and it will impersonate a client after authentication.
stop SSRS service, change it from NETWORK SERVICE to the domain account, restart SSRS service successfully.
I still CANNOT launch Report Manager. What is it? Is anyone able to advise? This is now business critical. I have been working with SQL and SSRS more years than I can count. I have never had this problem, and I need an assist.
stop SSRS service, change it from NETWORK SERVICE to the domain account, restart SSRS service successfully.
I still CANNOT launch Report Manager. What is it? Is anyone able to advise? This is now business critical. I have been working with SQL and SSRS more years than I can count. I have never had this problem, and I need an assist.
Hi,
Since you are using impersonation, check with the Admin that the impersonated user account In AD has the option "Account is sensitive and cannot be delegated" enabled.
I know that this is a longshot, but have you tried using wireshark to see what is coming into the server, and the packet content coming back out?
Could give you an idea as to what's happening inside the application layer.
Cheers
Leon
Since you are using impersonation, check with the Admin that the impersonated user account In AD has the option "Account is sensitive and cannot be delegated" enabled.
I know that this is a longshot, but have you tried using wireshark to see what is coming into the server, and the packet content coming back out?
Could give you an idea as to what's happening inside the application layer.
Cheers
Leon
ASKER
I'm not sure why you say that, Leon. All of the docs say that option should NOT be selected. See pg 14 and 15 of the attached.
" 4. On the Account tab, under Account options, verify that the following option is not selected: Account is sensitive and cannot be delegated. "
Also in step 4 of this link:
http://sqlmag.com/sql-server-reporting-services/implement-kerberos-delegation-ssrs
"...In AD, go to the Account Options list on the Account tab of the user and verify that the Account is sensitive and cannot be delegated option is not selected, as shown in Figure 5."
" 4. On the Account tab, under Account options, verify that the following option is not selected: Account is sensitive and cannot be delegated. "
Also in step 4 of this link:
http://sqlmag.com/sql-server-reporting-services/implement-kerberos-delegation-ssrs
"...In AD, go to the Account Options list on the Account tab of the user and verify that the Account is sensitive and cannot be delegated option is not selected, as shown in Figure 5."
ASKER
and now for the attachment. :-)
SSRSKerberos.docx
SSRSKerberos.docx
Hi,
I have just had a read through of the document you linked.
Everything has been done to the letter as far as I can see.
The only thing I can suggest is to create a new thread specifically targeted at Kerberos as this thread is quite old and there have been no other user interactions.
From Windows Server 2003 Internals:
"It is recommended that you deny the right to participate in delegated authentication to the computer accounts in Active Directory for computers that are not physically secure, to domain administrator accounts, and dedicated administrator accounts for service impersonation."
Sorry I could not be of more assistance
Cheers
Leon
I have just had a read through of the document you linked.
Everything has been done to the letter as far as I can see.
The only thing I can suggest is to create a new thread specifically targeted at Kerberos as this thread is quite old and there have been no other user interactions.
From Windows Server 2003 Internals:
"It is recommended that you deny the right to participate in delegated authentication to the computer accounts in Active Directory for computers that are not physically secure, to domain administrator accounts, and dedicated administrator accounts for service impersonation."
Sorry I could not be of more assistance
Cheers
Leon
Dear dbaSQL,
Please correct me if I misunderstood something from your wide conversation.
You pointed that your domain account has no logon as a service privilege, actually it is a prerequisite for that account - see following article.
http://msdn.microsoft.com/en-us/library/ms143504(v=sql.110).aspx
Additionally you can't have doubled SPNs registered for different accounts. So if you're using domain account as svc account for SSRS you just need to register SPN's for this account and delete old ones for particular service class.
I would also register SPN's for SQL Server.
Regards,
Daniel
Please correct me if I misunderstood something from your wide conversation.
You pointed that your domain account has no logon as a service privilege, actually it is a prerequisite for that account - see following article.
http://msdn.microsoft.com/en-us/library/ms143504(v=sql.110).aspx
Additionally you can't have doubled SPNs registered for different accounts. So if you're using domain account as svc account for SSRS you just need to register SPN's for this account and delete old ones for particular service class.
I would also register SPN's for SQL Server.
Regards,
Daniel
ASKER
Hi Daniel. Thank you very much for taking a look. That was the case initially, but I finally had it corrected, as noted in post ID: 40536355 The service account has both of these security policies enabled:
* Log on as a service
* Impersonate a client after authentication
>>>Additionally you can't have doubled SPNs registered for different accounts. So if you're using domain account as svc account for SSRS you just need to register SPN's for this account and delete old ones for particular service class.
I would also register SPN's for SQL Server.
I am not sure I follow you here. These are the SPNs that I have in place now for the intended service account:
http/servername:1433
http/servername.domainname
There is another one also on the same server, that was used for an older service account. I had asked the AD admin to remove it, thinking that it may conflict, but that has not been done yet. Is that what you mean by 'doubled SPNs registered for different accounts' ? Please clarify.
>>I would also register SPN's for SQL Server.
Lastly, what does this mean? From all of the documentation I read, I was under the assumption that I needed two SPNs for the intended service account, which is a domain account. One for http an done for netbios. Please clarify what you mean by also registering SPNs for SQL Server.
* Log on as a service
* Impersonate a client after authentication
>>>Additionally you can't have doubled SPNs registered for different accounts. So if you're using domain account as svc account for SSRS you just need to register SPN's for this account and delete old ones for particular service class.
I would also register SPN's for SQL Server.
I am not sure I follow you here. These are the SPNs that I have in place now for the intended service account:
http/servername:1433
http/servername.domainname
There is another one also on the same server, that was used for an older service account. I had asked the AD admin to remove it, thinking that it may conflict, but that has not been done yet. Is that what you mean by 'doubled SPNs registered for different accounts' ? Please clarify.
>>I would also register SPN's for SQL Server.
Lastly, what does this mean? From all of the documentation I read, I was under the assumption that I needed two SPNs for the intended service account, which is a domain account. One for http an done for netbios. Please clarify what you mean by also registering SPNs for SQL Server.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Daniel, I will have them remove the SPN from the old service account. I will also have them remove/recreate the SPNs that are using 1433 right now. Port will not be specified, so we should default to 80.
That gives me two SPNs for the correct service account, http and NetBIOS.
Now, you are saying that we need two additional SPNs for the SQL Server service. Created exactly as you have specified, only listing the correct service account name.
Totaling 4 SPNs. Is that correct?
That gives me two SPNs for the correct service account, http and NetBIOS.
Now, you are saying that we need two additional SPNs for the SQL Server service. Created exactly as you have specified, only listing the correct service account name.
Totaling 4 SPNs. Is that correct?
Hi,
That's correct. You can stay with SPNs for HTTP only and when it still won't work then consider adding SPNs for SQL Server.
Regards,
Daniel
That's correct. You can stay with SPNs for HTTP only and when it still won't work then consider adding SPNs for SQL Server.
Regards,
Daniel
ASKER
No need to specify the port, correct? he's doing it through the gui, basically like this:
http/servername
http/servername@domainname
http/servername
http/servername@domainname
Yupp,
For HTTP service class port 80 is default.
For HTTP service class port 80 is default.
ASKER
Daniel, if I could pay you right now...
We're good. I had him remove ALL SPNs. Then he recreated only two of them for the correct service account. It was done through the gui, as I showed one post up. One for http, one for NetBIOS. I did not make any changes anywhere on the SQL or SSRS side of things. Tried to hit the Report Manager URL, it failed due to the encrypted key. I dropped/recreated the key, and tried again. It opened up just fine. The SSRS service is running under the domain account, not the NETWORK SERVICE.
very big thank you to you both, Daniel and Leon. As I said, I've been working with SSRS and SQL for a very long time, but I hadn't run into this problem before. I should have looked closer. I truly should have caught the use of 1433 rather than 80.
We're good. I had him remove ALL SPNs. Then he recreated only two of them for the correct service account. It was done through the gui, as I showed one post up. One for http, one for NetBIOS. I did not make any changes anywhere on the SQL or SSRS side of things. Tried to hit the Report Manager URL, it failed due to the encrypted key. I dropped/recreated the key, and tried again. It opened up just fine. The SSRS service is running under the domain account, not the NETWORK SERVICE.
very big thank you to you both, Daniel and Leon. As I said, I've been working with SSRS and SQL for a very long time, but I hadn't run into this problem before. I should have looked closer. I truly should have caught the use of 1433 rather than 80.
Great, good to know everything is working fine.
Cheers,
Daniel
Cheers,
Daniel
ASKER
Not totally fine yet.. but I can open the darned Report Manager. Shouldn't take too long to clean the rest of it up. Thank you again, Daniel. Truly.
>>>The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
>>>The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Hi,
Please verify what setting do you have at authentication mode setting on the Database page of Reporting Services Configuration Manager. Next go to the SQL Server and check error log for failed login messages. Get back with results.
Ps. sorry for late responce - I had some incidents in my environments :/
Regards,
Daniel
Please verify what setting do you have at authentication mode setting on the Database page of Reporting Services Configuration Manager. Next go to the SQL Server and check error log for failed login messages. Get back with results.
Ps. sorry for late responce - I had some incidents in my environments :/
Regards,
Daniel
ASKER
No failed logins reported. I'm in the Database page of SSRS config mgr, but I don't see an actual 'authentication mode' reference.
My 'Current Report Server Database' includes servername, dbname and native mode. My 'Current Report Server Credential' includes a SQL account w/the name and ****** for a SQL account I had created for this.
If I go into change the credentials, it says 'Current User - Integrated Security', and my domainname\login is listed in the username box. If I Test the connection, it succeeds.
Should the credential be the service account? How can I change this, if necessary? I ask, because the dialog is grey/unchangeable.
My 'Current Report Server Database' includes servername, dbname and native mode. My 'Current Report Server Credential' includes a SQL account w/the name and ****** for a SQL account I had created for this.
If I go into change the credentials, it says 'Current User - Integrated Security', and my domainname\login is listed in the username box. If I Test the connection, it succeeds.
Should the credential be the service account? How can I change this, if necessary? I ask, because the dialog is grey/unchangeable.
ASKER
Disregard that last question. I've changed it and am testing now. back shortly...
ASKER
Well, I changed the database credential authentication to integrated, and used the service account. the change was accepted in configuration manager successfully. my attempts on that report, however, are still failing w/this message:
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
>>http://msdn.microsoft.com/en-us/library/ms156302(v=sql.110).aspx
This is the reference I am using for the Unattended Exec account. I requested a new account w/read-only access with network connection permissions, enabled across all computers that could provide data to the Report Server
Interesting that I am not logging any failures within the SQL error log. The server is configured to audit failed logins. I will check the event security log.
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
>>http://msdn.microsoft.com/en-us/library/ms156302(v=sql.110).aspx
This is the reference I am using for the Unattended Exec account. I requested a new account w/read-only access with network connection permissions, enabled across all computers that could provide data to the Report Server
Interesting that I am not logging any failures within the SQL error log. The server is configured to audit failed logins. I will check the event security log.
ASKER
Found this in the sec event log on the SSRS box, for the SSRS execution account:
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: accountname
Account Domain: domainname.COM
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
I've got four of them; two for login type 2 (interactive), and 2 for logon type 4 (batch).
What do you think, Daniel?
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: accountname
Account Domain: domainname.COM
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
I've got four of them; two for login type 2 (interactive), and 2 for logon type 4 (batch).
What do you think, Daniel?
ASKER
I've checked, and I believe the account needs to have the log on locally security policy.
secpol.msc\Local Policies->User Rights Assignment->Allow Log On Locally
I believe I should add the exec account here. Can't do it myself, have to get the admin to do it. i'll let you know.
secpol.msc\Local Policies->User Rights Assignment->Allow Log On Locally
I believe I should add the exec account here. Can't do it myself, have to get the admin to do it. i'll let you know.
Sorry, I was off for a moment. If you don't have any error messages on SQL Server it means SSRS is not even going out of its 'box'. You did well by searching for errors in Security log.
Please let me know, thanks.
Please let me know, thanks.
ASKER
Will let you know as soon as I do, Daniel. Thank you again.
ASKER
Well, I changed the credential to the SSRS execution account, restarted the service just fine. The admin says the policy was enabled, but now I cannot open Report Manager... once again.
This is the error output in Report Mgr:
The report server cannot open a connection to the report server database. A connection to the database is required for all requests and processing. (rsReportServerDatabaseUna
Still not making it all the way to SQL, and I've got the same error in the sec evt log -- except it is now pointing to the SSRS service account, NOT the SSRS execution account.
Do both accounts need the log on locally policy? I apologize, Daniel. I missed that policy in all of my references. Please let me know what you think whenever you can. I am stepping offline for a while, but I will be back soon. Again, I really do appreciate all of your input.
This is the error output in Report Mgr:
The report server cannot open a connection to the report server database. A connection to the database is required for all requests and processing. (rsReportServerDatabaseUna
Still not making it all the way to SQL, and I've got the same error in the sec evt log -- except it is now pointing to the SSRS service account, NOT the SSRS execution account.
Do both accounts need the log on locally policy? I apologize, Daniel. I missed that policy in all of my references. Please let me know what you think whenever you can. I am stepping offline for a while, but I will be back soon. Again, I really do appreciate all of your input.
From referenced document:
In case you really need an unattended execution account, it must be granted allow log on locally permission.
The report server uses the unattended report processing account to log on to the computer that hosts the external data source. This account is necessary because the credentials of the Report Server service account are never used to connect to other computers.Can you clear the execution account checkbox and don't use it?
In case you really need an unattended execution account, it must be granted allow log on locally permission.
ASKER
The reporting layer is three tiers... the client, the SSRS server, and then the varied relational database servers that will be targeted within the report data requests. Because Kerberos will be passing the authorized credentials from the report server to the other servers, I question whether the unattended account is even necessary.
ASKER
I removed it (unchecked it in SSRS config manager), and restarted the service successfully. I still, however, am unable to bring up the Report Manager. Same error returns whether I am remote or on the ssrs box.
The report server cannot open a connection to the report server database. A connection to the database is required for all requests and processing. (rsReportServerDatabaseUna
The report server cannot open a connection to the report server database. A connection to the database is required for all requests and processing. (rsReportServerDatabaseUna
Still no errors on SQL Server where ReportServer and ReportServerTempDB are? What security event log shows?
Verify your database connection at reporting services configuration manager. What credentials are being used for database connnection?
This error means that SSRS cannot connect to SQL Server hosting its internal databases.
It would be also usefull to update database connection settings once again.
Verify your database connection at reporting services configuration manager. What credentials are being used for database connnection?
The report server cannot open a connection to the report server database. A connection to the database is required for all requests and processing. (rsReportServerDatabaseUnavailable)
This error means that SSRS cannot connect to SQL Server hosting its internal databases.
It would be also usefull to update database connection settings once again.
ASKER
That is correct. Still no errors logged on the sql server itself . I receive the same error whether I am attempting to launch it on the server, or remotely. The security evt log does include this:
Subject:
Security ID: domainname.COM\serviceAcco
Account Name: serviceAccountName
Account Domain: domainname.COM
Logon ID: 0x79487C7
Logon Type: 4
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: serviceAccountName
Account Domain: domainName.COM
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
The database credentials defined in the database tab of the SSRS configuration manager are the same service account that it has been. The execution account is what I removed, which produced this error. I've just tried to re-add the execution account, which was seemingly successful, but I cannot backup (or delete or restore) the encryption key. It fails with the same error, which I've pasted below. It is not clear to me where the configuration error is.
Microsoft.ReportingService
at Microsoft.ReportingService
at Microsoft.ReportingService
at ReportServicesConfigUI.WMI
Subject:
Security ID: domainname.COM\serviceAcco
Account Name: serviceAccountName
Account Domain: domainname.COM
Logon ID: 0x79487C7
Logon Type: 4
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: serviceAccountName
Account Domain: domainName.COM
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
The database credentials defined in the database tab of the SSRS configuration manager are the same service account that it has been. The execution account is what I removed, which produced this error. I've just tried to re-add the execution account, which was seemingly successful, but I cannot backup (or delete or restore) the encryption key. It fails with the same error, which I've pasted below. It is not clear to me where the configuration error is.
Microsoft.ReportingService
at Microsoft.ReportingService
at Microsoft.ReportingService
at ReportServicesConfigUI.WMI
Subject:
Security ID: domainname.COM\serviceAcco
Account Name: serviceAccountName
Account Domain: domainname.COM
Logon ID: 0x79487C7
Logon Type: 4
I suppose that domainname.COM\serviceAcco
The logon error message is related to logon type = 4 which translates to type Batch. This may be the lack of log on as a batch job system privilege, however this may be logged if password is incorrect. So here I would verify whether this account is not locked in domain and next, as stated before, I would reconfigure Report Server database credential settings using the same account - just to refresh them.
Security ID: domainname.COM\serviceAcco
Account Name: serviceAccountName
Account Domain: domainname.COM
Logon ID: 0x79487C7
Logon Type: 4
I suppose that domainname.COM\serviceAcco
The logon error message is related to logon type = 4 which translates to type Batch. This may be the lack of log on as a batch job system privilege, however this may be logged if password is incorrect. So here I would verify whether this account is not locked in domain and next, as stated before, I would reconfigure Report Server database credential settings using the same account - just to refresh them.
ASKER
It is the same account, the SSRS service account. I've just dummied the names for the posting. I did reconfigure, or refresh the logins in the config mgr., and the service stopped/started successfully, yet I still receive that error when attempting to launch report manager. I am also unable to backup my encryption key. The backup dialog is grey, unavailable. I'm unsure how to correct things.
That's because SSRS cannot connect to SQL Server, please reapply Current Report Server database part of the database configuration - as you did for service account.
One more thing, when you set database credentials you have three options:
*Windows integrated security
*Windows user account
*SQL Server login
If you're using SSRS service account credentials then you may not choose Windows user account option but rather Windows integrated security.
One more thing, when you set database credentials you have three options:
*Windows integrated security
*Windows user account
*SQL Server login
If you're using SSRS service account credentials then you may not choose Windows user account option but rather Windows integrated security.
ASKER
After your last post, I went into the SSRS config mgr and checked the 'current report server database credential. It was using the SSRS service account, but under the authentication type was 'Windows Credentials'.
I changed this to 'Service Credentials'. Still the same account, but different authentication type. Now I can launch the Report Manager without error, both locally on the SSRS instance, and remotely.
I was able to backup the encryption key successfully.
I don't have any errors or warnings in the SQL Server error log, or the system and security event logs. I do have this in the application evt log:
>>The value for UrlRoot in RSReportServer.config is not valid. The default value will be used instead.
Of course, it's difficult to see what value is actually in use when reading the rsreportserver.config file, but I believe that would be the unattended execution account. Is that not correct? I did get a domain account created for this, with limited privies and authorized connections on the varied database servers in the reporting layer. But, when I was unable to launch the report mgr again, I backed that out and replaced it with the ssrs service account.
Lastly, I am still having problems opening a report. This is the error that I saw before when trying to test a report after you helped me through the first problem, caused by the dupe/misconfigured SPNs. I am still receiving this error when attempting to launch a report:
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
What do you think, Daniel?
I changed this to 'Service Credentials'. Still the same account, but different authentication type. Now I can launch the Report Manager without error, both locally on the SSRS instance, and remotely.
I was able to backup the encryption key successfully.
I don't have any errors or warnings in the SQL Server error log, or the system and security event logs. I do have this in the application evt log:
>>The value for UrlRoot in RSReportServer.config is not valid. The default value will be used instead.
Of course, it's difficult to see what value is actually in use when reading the rsreportserver.config file, but I believe that would be the unattended execution account. Is that not correct? I did get a domain account created for this, with limited privies and authorized connections on the varied database servers in the reporting layer. But, when I was unable to launch the report mgr again, I backed that out and replaced it with the ssrs service account.
Lastly, I am still having problems opening a report. This is the error that I saw before when trying to test a report after you helped me through the first problem, caused by the dupe/misconfigured SPNs. I am still receiving this error when attempting to launch a report:
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
What do you think, Daniel?
>>The value for UrlRoot in RSReportServer.config is not valid. The default value will be used instead.Verify what do you have in <UrlRoot> element in the report server config file:
...\Reporting Services\ReportServer\rsre
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErroIt is related to your report's data source, you may need to configure the unattended account. Add it back again and see what will happen. If report still fails go to security log and look for logon messages - just to be sure that your execution account has enough privileges.r)
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
For type None:
For SQL Server, Oracle, ODBC, and OLE DB:
Use the credentials defined in the connection string. The connection fails on the report server if the unattended execution account is undefined.
Reference:
http://msdn.microsoft.com/en-us/library/ms160330.aspx#DataSourceConfigurationConnections
*Edit:
I would also check for error messages at the data source destination for that failing report.
ASKER
>>Verify what do you have in <UrlRoot> element in the report server config file:
Well, last I looked, I just thought I was looking at a bunch of encryption, and couldn't translate. Now that I'm looking closer, it seems as though I don't have an element defined for UrlRoot at all.
I've attached my rsreportserver.config. Any references to the service account or the domain have been changed, like this:
domainName.com\SSRSsvcAcct
My UrlRoot appears to be empty. When during the install/config is this assigned, Daniel?
<UrlRoot>
</UrlRoot>
rsreportserver.config
Well, last I looked, I just thought I was looking at a bunch of encryption, and couldn't translate. Now that I'm looking closer, it seems as though I don't have an element defined for UrlRoot at all.
I've attached my rsreportserver.config. Any references to the service account or the domain have been changed, like this:
domainName.com\SSRSsvcAcct
My UrlRoot appears to be empty. When during the install/config is this assigned, Daniel?
<UrlRoot>
</UrlRoot>
rsreportserver.config
UrlRoot is set up automatically when you configure SSRS Web Service Url. Please review that option in SSRS configuration manager, and refresh all settings - set all option to the same values. There may be some errors due to URL reservation.
http://msdn.microsoft.com/en-us/library/ms157273(v=sql.110).aspx
The report server determines URLs in reports based on the following behavior:Reference:
When UrlRoot is blank (the default value) and there are URL reservations, the report server automatically determines URLs the same way that URLs are generated for the ListReportServerUrls method. The first URL returned by the ListReportServerUrls method is used. Or, if SecureConnectionLevel is greater than zero (0), the first SSL URL is used.
When UrlRoot is set to a specific value, the explicit value is used.
When UrlRoot is blank and there are no URL reservations configured, the URLs in rendered reports and in e-mail links are incorrect.
http://msdn.microsoft.com/en-us/library/ms157273(v=sql.110).aspx
ASKER
Daniel, do you believe both authentication types are necessary? I know NTLM is there by default, and I replaced it with WindowsNegotiate, to allow for the Kerberos. When I did that, I looked and looked, but never found reference to using more than one authentication type... until just now. In the link you provided.
<AuthenticationTypes>
<RSWindowsNegotiate/>
<RSWindowsNTLM/>
</AuthenticationTypes>
<AuthenticationTypes>
<RSWindowsNegotiate/>
<RSWindowsNTLM/>
</AuthenticationTypes>
ASKER
Well, I went back through the config manager, and re-input the service account, the database credentials in the database tab, and the execution account. All using the same ssrs service account. Report Mgr opens up fine for me still, but I don't note any changes to rsreportserver.config.
As for the web service URL, I don't really see any place for me to change this. Everything in the Web Service URL tab is the same as it was at install, all default values. I changed nothing.
Virtual Directory: ReportServer
IP Address: All Assigned (recommended)
TCP Port: 80
SSL Certificate : not selected
SSL Port: grey, nothing there
Report Service Web URLs: http://servername:80/ReportServer
Is there something here that will result in the input of the UrlRoot in the config file?
As for the web service URL, I don't really see any place for me to change this. Everything in the Web Service URL tab is the same as it was at install, all default values. I changed nothing.
Virtual Directory: ReportServer
IP Address: All Assigned (recommended)
TCP Port: 80
SSL Certificate : not selected
SSL Port: grey, nothing there
Report Service Web URLs: http://servername:80/ReportServer
Is there something here that will result in the input of the UrlRoot in the config file?
<AuthenticationTypes>These are set together to support different browsers:
<RSWindowsNegotiate/>
<RSWindowsNTLM/>
</AuthenticationTypes>
Specifying multiple authentication types is necessary if you expect requests from a variety of client applications or browsers that use different types of authentication.
Do not remove RSWindowsNTLM, otherwise you will limit browser support to a portion of the supported browser types. .
Is there something here that will result in the input of the UrlRoot in the config file?Nope, you had error message because Url reservation was missing. As far as I'm concerned there are no more UrlRoot error messages?
What about that broken report? Did you check datasource for errors?
ASKER
I just put NTLM back into the config file, then I re-backed up the encryption key. I realize that may not have been necessary, but I wasn't sure what else to do that would revisit the UrlRoot. Unfortunately, after doing that, this was again written to my app event log, in this order:
5:09:38PM The value for UrlRoot in RSReportServer.config is not valid. The default value will be used instead.
5:09:38PM The RSReportServer.config file has been modified.
5:10:27PM The key used for encrypting data was successfully extracted.
And I still don't have anything in the config file:
<UrlRoot>
</UrlRoot>
>>What about that broken report? Did you check datasource for errors?
Unsure how familiar you are with Great Plains/Dynamics, but the report(s) that I was testing is one of several that we imported/uploaded through the GP 'Reporting Tools Setup' tool. Basically, GP has some 200+ canned reports to be used with SSRS. We uploaded them with the GP support engineer, and that's as far as we got. As I look at the reports now, I am inclined to believe they're just not completely configured. Right now, for example, the one that has been giving me that error -- the RDL is defined to use a shared data source, yet when I check that data source, I can see the data source name and type is there, but that's about it. There is no connection string, and it says 'Credentials supplied by the user running the report'. But that's it.
The intention is to use Kerberos all the way through the report security. The authorized users will be enabled within AD groups for server-level access, and then the same users/groups will receive item level privileges on the varied reports, based on the group/role membership.
Be that the case, my datasources -- shared or otherwise -- would not be looking for users to supply credentials. I want that handled dynamically by the role based security. Having said that, what is the appropriate security setting at the data source?
5:09:38PM The value for UrlRoot in RSReportServer.config is not valid. The default value will be used instead.
5:09:38PM The RSReportServer.config file has been modified.
5:10:27PM The key used for encrypting data was successfully extracted.
And I still don't have anything in the config file:
<UrlRoot>
</UrlRoot>
>>What about that broken report? Did you check datasource for errors?
Unsure how familiar you are with Great Plains/Dynamics, but the report(s) that I was testing is one of several that we imported/uploaded through the GP 'Reporting Tools Setup' tool. Basically, GP has some 200+ canned reports to be used with SSRS. We uploaded them with the GP support engineer, and that's as far as we got. As I look at the reports now, I am inclined to believe they're just not completely configured. Right now, for example, the one that has been giving me that error -- the RDL is defined to use a shared data source, yet when I check that data source, I can see the data source name and type is there, but that's about it. There is no connection string, and it says 'Credentials supplied by the user running the report'. But that's it.
The intention is to use Kerberos all the way through the report security. The authorized users will be enabled within AD groups for server-level access, and then the same users/groups will receive item level privileges on the varied reports, based on the group/role membership.
Be that the case, my datasources -- shared or otherwise -- would not be looking for users to supply credentials. I want that handled dynamically by the role based security. Having said that, what is the appropriate security setting at the data source?
...this was again written to my app event log...It is by default, I totally misunderstood you. I though that you're experiencing this when browsing to Report Server.
Are you sure that these Dynamics GP reports were working fine before whole switch into Kerberos?
You can use Reporting Tools Setup window to verify reports status of each company.
I'm not sure about data source settings for GP, It's a bit late now (01:00 AM here - GMT+1) so I will go off. I'm not sure about current GP deployment in my env, however I'll try to take a look at reports for it.
Regards,
Daniel
ASKER
Won't worry about the entry in he app evt log anymore. :-)
Daniel, your input has been remarkable. I really can't thank you enough. If you have a GP deployment that you could take a look at, that would be awesome!
>>Are you sure that these Dynamics GP reports were working fine before whole switch into Kerberos?
No. I'm sorry, Daniel, I should have been more clear. The whole project is that I am building a new reporting layer for my customer. They have numerous 3rd party pieces, one of which is GP/Dynamics. The GP reports have never been used before. Part of the deployment was just to get our hands on the '200+ canned reports from GP'. No work, however, has been done yet to use them. We just uploaded them using that GP Reporting Tools Setup tool. Having looked further today, I think it's just a matter of bringing the data sources together effectively. My question is what is the right method, given the intent to use Kerberos.
I will do some more reading. Thank you for all of your help, Daniel. I will wait to hear back as to whether you've a GP deployment to review.
Daniel, your input has been remarkable. I really can't thank you enough. If you have a GP deployment that you could take a look at, that would be awesome!
>>Are you sure that these Dynamics GP reports were working fine before whole switch into Kerberos?
No. I'm sorry, Daniel, I should have been more clear. The whole project is that I am building a new reporting layer for my customer. They have numerous 3rd party pieces, one of which is GP/Dynamics. The GP reports have never been used before. Part of the deployment was just to get our hands on the '200+ canned reports from GP'. No work, however, has been done yet to use them. We just uploaded them using that GP Reporting Tools Setup tool. Having looked further today, I think it's just a matter of bringing the data sources together effectively. My question is what is the right method, given the intent to use Kerberos.
I will do some more reading. Thank you for all of your help, Daniel. I will wait to hear back as to whether you've a GP deployment to review.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you very much, Daniel. I have not seen this reference before. Interesting, as we did build the 200+ GP reports per their instructions, and with their engineers online. Yet nobody ever mentioned the CRM tool was the interface between the GP users and the SSRS reports.
I want to thank you for all of your time. Definitely appreciated.
I want to thank you for all of your time. Definitely appreciated.
ASKER
A plethora of information provided from both EE members. Daniel provided insight for the original problem, as well as one that presented itself before the inquiry was closed. Extremely helpful. Thank you, Daniel.
I'm glad I could successfully help :)
Take care,
Daniel
Take care,
Daniel
ASKER
You do the same, Daniel. Thank you, again.
ASKER
attempting to test a report, Daniel. I can open a new inquiry if you'd like. Just attempting to run a report gives me the message below on the unattended execution account. I have validated the data source is correct, and even tests successfully in report builder. yet an attempt to actually call the report gives me this:
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Logon failed. Ensure the username and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors.
In the sql error log for the server that is targeted in the report datasource, I have these two errors:
Message
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. [CLIENT: 10.64.65.178].
Message
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 10.64.65.178]
now, at the moment, the unattended exec account is the same as the ssrs service account. I had another one created with lesser privileges, that was enabled on the remote machines. which account would you typically use for your unattended exec account?
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationErro
Logon failed. Ensure the username and password are correct. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors.
In the sql error log for the server that is targeted in the report datasource, I have these two errors:
Message
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. [CLIENT: 10.64.65.178].
Message
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 10.64.65.178]
now, at the moment, the unattended exec account is the same as the ssrs service account. I had another one created with lesser privileges, that was enabled on the remote machines. which account would you typically use for your unattended exec account?
Hi,
I'd register SPNs for SQL Server.
I'd register SPNs for SQL Server.
setspn -A MSSQLSvc/<SQL Server FQDN>:<port> <Domain\Account>
setspn -A MSSQLSvc/<SQL Server Netbios>:<port> <Domain\Account>ASKER
that port is 80, and the domain account is the ssrs svc account. yes?
Nope, don't use SSRS account and port.
SQL Server default instance works on tcp 1433, you should pick its service account.
SQL Server default instance works on tcp 1433, you should pick its service account.
ASKER
ooooh. I gotcha. this spn is explicitly for the sql server. got it. thanks, Daniel. how do you know that the cause of my error?
dbaSQL, you are trying to authenticate using Kerberos. If an SPN is not configured for a service, a client account will not be able to authenticate to the server using Kerberos.
ASKER
Understood, Daniel. I think I was just speaking in regards to the error that was output. Basically, where in the output does it say 'spn' to you, rather than the unattended exec account. Of course, I should be pretty used to their meaningful error messages by now... ;-)
I've requested the two additional SPNs. Tomorrow I'll let you know how things turn out. Thank you again, Daniel.
I've requested the two additional SPNs. Tomorrow I'll let you know how things turn out. Thank you again, Daniel.
ASKER
>>Tomorrow I'll let you know how things turn out.
Better, I think. :-) I do not have the configuration error anymore. Still have a problem, but it is specific to one of the datasets within the report, but I expected this, since I am still defining the back end of this thing.
Thank you again, Daniel. Your assistance has been remarkable.
Better, I think. :-) I do not have the configuration error anymore. Still have a problem, but it is specific to one of the datasets within the report, but I expected this, since I am still defining the back end of this thing.
Thank you again, Daniel. Your assistance has been remarkable.
ASKER