I am trying to deploy my first cube in SSAS but the deployment fails because a connection isn't established. The problem is related to giving privileges to SSAS from windows. It seems I have to create or change privileges to something called Local Windows Security Group that is associated with the SSAS.
I found a document on the internet that describes how to do it, but I am not a security expert and was not able to follow https://msdn.microsoft.com/en-us/library/ms175371(v=sql.120).aspx
Within the above document it says: The permission holder in Analysis Services is not the logon account, but a local Windows security group created by Setup that contains the per-service SID. Assigning permissions to the security group is consistent with previous versions of Analysis Services.
Anyone can explain how to connect to SSAS when you're on a local machine with windows authentication in simple English would be greatly appreciated.
The exact error message is: Error 13 Parser: The syntax for the ImpersonationInfo object is incorrect. If the ImpersonateAccount value is used for ImpersonationInfo, then the Account property cannot be empty. 0 0
Related
I am trying out a Microsoft business intelligence solution which consists of a on-prem database/datawarehouse running on a SQL Server 2014 Windows server. On the same sql server is SSIS running a set of SSIS packages stored in the SSIS Catalog. A SQL SSAS Tabular cube is running on the azure portal. Power BI reports are using SSAS live connection.
Well, here is the problem. The customer has not yet an azure portal so I have been testing on free users, but this will be fixed soon. My problem is to get the on-premises datagateway to work with the azure analysis services. I have to mention that the customer already has an on-prem datagateway running on an other machine using a windows service user that they have created.
Well here is what I did. I created access to the datawarehouse for that on-prem windows service user. To create a gateway to the azure portal, I had to ask the db admin person to assist me to create an on-prem gateway on azure from the on-premises data gateway dialog using the registrated account (onmicrosoft.com mail) for that service (not mine). So far so good. He helped me to get into the portal using the onprem service account on azure and there I created a free account and set up analysis services and connected it to the datagateway. I also gave my #onmicrosoft.com account on azure admin rights. Then we logged out of that azure account. From Visual studio 2017 I could now deploy the SSAS tabular using Do not Process. Just before deploying, I correct the data source setting for the SSAS tabular to the IP address like 10.xxx.x.xxx,1433 and set impersonation to Service Account, clicked save and unchecked the encryption and set privacy level to public (will change that later). Then I deployed and that went ok.
BUT I need to process the cube either from SSMS or from a SSIS package. I hade hoped that my #onmicrosoft.com account that has also admin rights on azure could be used. Maybe I have to use the other #onmicrosoft.com account that was created on azure, but I don't have the password to that. I believe this is a credential problem, but I am asking if there is a way around this. On SSMS, I tried running the code below using my Account #onmicrosoft.com account on user name with MTA setting and the asazure://northeurope.asazure.windows.net/xxx on server name
{
"refresh": {
"type": "automatic",
"objects": [
{
"database": "My Cube"
}
]
}
}
It runs some seconds but the it fails with this message
The JSON DDL request failed with the following error: Failed to execute XMLA. Error returned: 'An error occurred during On-Premise Gateway related activity.
Additional error details: DM_GWPipeline_Gateway_DataSourceAccessError
Received error payload from gateway service with ID 371137: An exception encountered while accessing the target data source.
An exception encountered while accessing the target data source
The specified length exceeds maximum capacity of SecureString.
Parameter name: length
Technical Details:
RootActivityId: f4989df9-60c3-445f-8ef7-85fa9f7c48ac
Date (UTC): 3/16/2019 8:00:33 AM
0: PFError::SetLastError() line 2160 + 0x0 (sql\picasso\engine\src\pf\eh\pferror.cpp)
1: PFSetLastError() line 2918 + 0x0 (sql\picasso\engine\src\pf\eh\pferror.cpp)
2: PFSetLastErrorExTag() line 3474 + 0x27 (sql\picasso\engine\src\pf\eh\pferror.cpp)
3: 0x00007FF913041541 (symbolic name unavailable)
I hope somebody can tell me what I am doing wrong or lead me in a correct direction here
Regards
I have done much searching on this without a solid solution.
I just set up a new SSRS instance on the same server as my SQL 2016 instance. Everything is running fine report wise, etc. The problem is that when a report is scheduled, it creates a Sql Agent Job in SQL Server, and the SQL Agent is erroring out with the following:
The job failed. Unable to determine if the owner
(MyDomain\ReportService) of job 17F8E31D-0838-4829-8C3C-E3FE5BBD3483
has server access (reason: Could not obtain information about Windows
NT group/user 'MyDomain\ReportService', error code 0x5. [SQLSTATE
42000] (Error 15404)).
Current setup:
SSRS using an Active Directory account as the service account called
Report Service
Sql Server 2016 Engine is using an Active Directory account as the service
account called SqlService
Both SSRS and SQL Database are on the same machine
I double checked that SqlService is SysAdmin and has all other
permissions, and non-SSRS jobs run fine
From my research, I can solve this in one of three ways:
Change the SSRS SQL Agent job created by SSRS to be owned by SA (by
default the job is owned by MyDomain\ReportService). The problem
with this is that I would have to do this every time a user creates
a new subscription via SSRS or create an ongoing script because SSRS
by default will use the service as the owner. And I KNOW that this
was not done at my previous employer.
I could make the SqlService a
domain administrator. I don't want to do this for security reasons,
obviously.
I could give the SqlService "SeImpersonatePrivilege"
(Impersonate a client after login) on my domain via the security
policy. This also works, but there seems like there would be a
better way, and I would think this is also a security risk as
setting this doesn't explicitly limit SqlService to only
impersonating the ReportService.
So, my question is hopefully from those who have set SSRS up, what is the best practice for allowing SQL Server to run the SSRS subscriptions? It's possible that something in our environment is messed up permissions wise, but I guess mostly I'm looking for advice on how should this be set up. Thank you greatly in advance.
I eventually discovered that we had some kind of limitation on the active directory rights of the service account. I wasn't unable to pinpoint the exact permissions, but after adding the account to a group that explicitly allowed viewing active directory users and groups, it worked. So, this was due to abnormal limitations for basic domain user rights.
Link
From the site listed above:
Could not obtain information about Windows NT group/user ‘domainuser’, error code 0x5. [SQLSTATE 42000] (Error 15404)(ConnIsLoginSysAdmin)
The solution to this is to add the SQL Server service account to the ‘BUILTINWindows Authorization Access Group’ on your DC.
You can then run “EXECUTE AS USER = ‘domainuser’” on SQL Server to check.
I have created a SSIS Package and now want to deploy it, for that I am required to create the Integration Service Catalog,so I have SQL Server Evaluation Set up in that when I m trying to connect the integration service, I am getting following error,
Connecting to the Integration Services service on the computer
"RESHMAJADHAV"
failed with the following error: "Access is denied."
By default, only administrators have access to the Integration Services service.
On Windows Vista and later,
the process must be running with administrative privileges in
order to connect to the Integration Services service.
See the help topic for information on how to configure access to the service.
Also I have observed that my instance for SQL Server Evaluation edition is RESHMAJADHAV\SQL_SERVER_EVALU but when I am trying to connect this server, then this option is not shown under Integration Services as shown below,
.
I am unable to sort this out, since I am entirely new to this, please explain what can be the solution.
Please make a note, I also have sql server express edition ,but since it doesn't support to create the SSIS Integration service catalog then I installed the SQL Server Evaluation edition .
Also when I am trying to connect via SQL Database as shown in below image,
then while creating the integration service catalog, it is given the following error
Password validation failed.
The password doesn't meet the requirements of password of the password filter DLL.
Change database context to SSISDB.
One fact I have observed, I don't know whether it is related or not but when I am trying to enter password for my system, then also it's giving same error that password doesn't meet the requirement and also when while installing the SQL Server edition, it gave the same error, no doubt my password was very strong and fulfill all the requirements of strong password, currently I am trying to run my SQL Server with windows authentication mode and also I have tried to disable the strong password policies from the administrative tools but it's totally futile....any help will be greatly appreciated.
Go to all programs
Click on Microsoft SQL Server 2012 folder
Right click on SQL Server Management Studio
Click on Run as Administrator
This should take care of problem for now. (With this you need to always repeat the same process). To avoid this every time and for a more persistent solution you need to get permission(s). Please do the following process and you should be good.
In previous versions of SQL Server, by default when you installed SQL Server all users in the Users group had access to the Integration Services service. When you install the current release of SQL Server, users do not have access to the Integration Services service. The service is secure by default. After SQL Server is installed, the administrator must grant access to the service.
To grant access to the Integration Services service
Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.
In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.
Right-click Microsoft SQL Server Integration Services 11.0, and then click Properties.
On the Security tab, click Edit in the Launch and Activation Permissions area.
Add users and assign appropriate permissions, and then click Ok.
Repeat steps 4 - 5 for Access Permissions.
Restart SQL Server Management Studio.
Restart the Integration Services Service.
(Source MSDN)
I hope this will help
I researched little bit and then I came to know it was actually the problem of HP Security Tool Manager service of HP Laptop which was messing with the password of system,SQL Setup and catalog of Integration Service,I uninstalled it from PC and now my problem is resolved..
look like you don't have a admin privilege.
so start->sql server->right click->run as administrator
it might solve !!!
it's not clear whether this is due to your windows password or the SSISDB encryption password http://fendy-huang.blogspot.com.au/2012/01/sql-server-2012-integration-services.html.
I suggest you think of a very long complicated password with a mixture of upper, lower and punctiation like this:
~~AgFcDeUk17aP9%3(5#hY,lTSs9+
and put that into the encryption field when creating the catalog. If that doesn't get around your error, try changing your windows password to that. The only way to solve thedr things is divide and conquer. Once you know which password is the issue you can attack it further.
I have an analysis services cube in SQL server 2005 which I'm connecting to via an excel front end.
When I connect via one user its fine, but when I log on to the same machine as another user I get an error in my excel spreadhseet - "user...does not have access to the [Cube name] database"
Obviously the first user has the correct permissions, but how do I set up analysis services to allow other users to join the party?
Login to the machine with an account that is an administrator (Domain\CubeAdmin) on the cube. Connect to the cube in BIDS (run devenv.exe and open Analysis Services Database).
Under Roles, create a reader role and in the Membership tab, add the user account (Domain\NewUser).
All this will only work if the SSAS Server Administrator gives the Domain\NewUser access to the server.
The Windows user accounts that you are trying to access SQL Analysis Services with need to be added to the Roles in the Cube that would allow the permissions you want.
If you are connecting over HTTP using msmdpump.dll through IIS you need to turn on Authentication for that site and allow the Windows user account to access the site.
If the IIS site using msmdpump is on another machine and you aren't using a domain then the accounts would need to exist on both servers with the same password.
I know this is old but for other's reference, I had to repair the MS Office install to resolve a connectivity issue with SSAS. The user was added to the role, but the error "Cannot connect to server" was displayed when connecting.
Raj has already answered the initial question... You need users to be set up with at least read access to your SSAS instance.
However, the error "Cannot connect to server" does not necessarily mean it's an authentication issue, it actually doesn't mean much. I've seen this error on Excel 2007 on various occasions, where the underlying error could be anything, this is just a generic error from Excel.
Several aspects that caused problems on my end were (things to check):
User has access to the web site (if not using anonymous auth)
ADOMD and OLEDB for Analysis Services are installed locally (correct version)
User propagated to SSAS has read access to instance (are you using ApplicationPoolIdentity?)
Handler mapping (script mapping for *.dll) is set up
For a complete guide of how to set up HTTP access for SSAS check:
Microsoft - Configure HTTP Access to SSAS via IIS
Cheers
I'm having a very confusing error between SharePoint and SQL Server 2k5.
My SQL Server acting as backend to my MOSS farm has several logins in it which correspond to the web front end servers in my farm, with the pattern: {my-domain}{my-machine}$
Now, those accounts do not exist in AD anywhere, despite the login name syntax, and were generated somehow (assume by MOSS, but can't confirm). One (and only one) of the servers is throwing login failures every 2 minutes; that server was the first in the farm and holds most of the services, just not search and indexing.
I did a number of traces in SQL Profiler, and all I can tell is that the failure is a type 16 error on 'master'; so the login exists but doesn't have rights to 'master'.
Having found that, I went back in and gave it progressively greater rights on Master, including db_owner, and eventually making it a sysadmin. Still no joy, same error.
Diggin further w/ tracing, I found that the actual failure was due to the SSO db not existing; probably b/c it wasn't configured in MOSS. When I tried configuring the error, I got a "Sorry, you're not authorized to do that" error in Central Admin, even though I was logged in as the farm admin, who's also a forest-level admin w/ rights to everything I can think of.
Turning off SSO as a windows service worked, but I'm concerned about my inability to configure it in MOSS, so I dont' want to leave that as a solution.
I'm out of ideas, anyone else have thoughts or experience on this?
Thanks
The {my-domain}{my-machine}$ account is an alias for the NETWORK SERVICE built-in local machine account. NETWORK SERVICE is a low privilege predefined account that was introduced in Windows 2003. It has network credentials and can therefore connect to remote databases (as long as they're within the same domain).
It sounds like you've created your SharePoint web applications with the default application pool identity. This will create the logins named {my-domain}{my-machine}$ in SQL Server. So yes, SharePoint created the SQL logins, but they're based on the built-in NETWORK SERVICE machine accounts on the servers in your farm.
I'd check that the account you're using to configure SSO has the rights to create the SSO database. Have a look at the table in Plan for single sign-on. It lists all the privileges required for all the different types of SSO accounts. For the configuration account, the document lists:
SSO configuration account:
Must be a user domain account. Cannot be a group account.
The user account must be a server farm administrator.
Must be a member of the Administrators group on the
encryption-key server computer.
Must be a member of the following SQL Server security roles on the
computer running SQL Server:
Dbcreator
Securityadmin
Must be either the same as the SSO administrator account, or be a member
of the group account that is the SSO
administrator account.
If that doesn't help, follow Alex Angas' advice and post this question to serverfault.com.
Try and follow this to configure SSO:
http://technet.microsoft.com/en-us/library/cc262932.aspx
We had this same problem - the source of your "Not authorized to do that" message when you configure SSO is that you need to be logged into Sharepoint Central Admin as the SSO user (in our case, it was DOMAIN\SSO_Proxy). This allowed us to make the changes we needed.
Good luck!