Re: Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- From: Jéjé <willgart_A_@xxxxxxxxxxxxxx>
- Date: Mon, 13 Nov 2006 17:26:02 -0500
search on the MS website these keywords:
IIS Kerberos.
the 2 servers must be member of the same domain.
you have to download the setspn tool
after this,
change the IIS configuration :
cscript adsutil.vbs set w3svc/<1>/NTAuthenticationProviders "Negotiate,NTLM"
where <1> is the IIS virtual server ID
this cause that your virtual server support both kerberos and NTLM security.
setspn:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&displaylang=en
execute this command:
Setspn -A HTTP/<URLUsedbytheenduser> <webserver1>
<URLUsedbytheenduser> like "www.mydomain.com"
<webserver1> is the server name on the network, registered in the Active directory.
if your application pool use a domain user and NOT the network service or local service account replace <webserver1>
by <domain\username of the app pool>
you MUST use the same account for ALL the applications deployed on an IIS virtual server because the kerberos is applied only at the domain name level (<URLUsedbytheenduser>) and NOT at the application level (<URLUsedbytheenduser>/myxmla)
if you have some application which use 1 account and another application which used another account this can break the kerberos delegation.
take care its HTTP/ and NOT HTTP://
if you are using a port which is not the default 80 port add it:
Setspn -A HTTP/<URLUsedbytheenduser>:<myport> <webserver1>
and finally, trust the server for delegation:
http://support.microsoft.com/kb/326985/en-us#4
If this IIS server is a member of the domain but is not a domain controller, the computer must be trusted for delegation for Kerberos to work properly. To enable this, follow these steps:
1. On the domain controller, click Start, point to Settings, and then click Control Panel.
2. Double-click the Administrative Tools folder, and then double-click Active Directory Users and Computers.
3. Under your domain, click the Computers folder.
4. In the list, locate the IIS server. Right-click the server name, and then click Properties.
5. Click the General tab, click to select the Trusted for delegation check box, and then click OK.
now, when you access SSAS thourgh this IIS connection, make sure that the URL is <URLUsedbytheenduser>
if the name is not EXACTLY the same, the kerberos delegation will not work.
you can add aliases using the setspn utility like HTTP/<mynetbiosname> or HTTP/<mynetbiosname.mylocaldomain.local> ...
also, if you change your application pool's account from the machine to a domain user AFTER the kerberos setup, make sure you'll remove ALL the entries using the setspn utility and then add them again to the new account.
if you don't do this you'll suffer issues because the system will detect duplicates entries.
and to finish...
kerberos is really sensitive to the network architecture, users outside a firewall will not be authorized. Generally firewalls dislike this protocol.
good luck!!!!
"Mitak" <dkfake@xxxxxxxxxxx> wrote in message news:#yyRlF1BHHA.4764@xxxxxxxxxxxxxxxxxxxxxxx
I use integrated windows authentication. So you are suggesting to try basic authentication?.
How would I setup this kerberos delegation system? I have never done this so far.
"Jéjé" <willgart_A_@xxxxxxxxxxxxxx> wrote in message news:uUk5W70BHHA.4256@xxxxxxxxxxxxxxxxxxxxxxxyou can use 2 different servers.
but you have to setup the kerberos delegation system if you use the NTLM authentication
using the basic authentication method the access should works fine.
which authentication method do you use for your /OLAP virtual directory?
"Mitak" <dkfake@xxxxxxxxxxx> wrote in message news:ujVO2x0BHHA.2316@xxxxxxxxxxxxxxxxxxxxxxx>I think the ascmd utility cannot be used with the HTTP access.the HTTP (XML/A) is designed for client access not administrative access.
It is OK to use ascmd with http.
can you access your server using a client tool through the HTTP connection?
(Like from Excel)
If no, verify your Kerberos setup.
If yes, then the problem is related to the ascmd utility which cannot access through HTTP.
No, I can't access the server through http with the setup described in my initial post. However, I can access the server with no http.
I have http access setup on two other SSAS servers and it works in both cases. What I have tried is to point the http setup on one of the servers to the other and it didn't work. This kind of convinces me that http connection setup on a different server than the one which hosts SSAS is not possible.
Thanks
"Jéjé" <willgart_A_@xxxxxxxxxxxxxx> wrote in message news:OIJ0uf0BHHA.4808@xxxxxxxxxxxxxxxxxxxxxxxI think the ascmd utility cannot be used with the HTTP access.
the HTTP (XML/A) is designed for client access not administrative access.
can you access your server using a client tool through the HTTP connection?
(Like from Excel)
If no, verify your Kerberos setup.
Also, have you try to remove the " (quote) around the HTTP server name?
"Mitak" <dkfake@xxxxxxxxxxx> wrote in message news:#TULXjPBHHA.2304@xxxxxxxxxxxxxxxxxxxxxxxHi All:
I am trying to setup HTTP access (msmdpump.dll) to SSAS on a web server box where there is no Analysis Services installed. The goal is to prevent IIS running on SSAS box itself. I have no luck so far. Is this configuration even possible?
I have installed the following components on the web server in the order below:
1. msmdpump.dll: http://www.microsoft.com/technet/prodtechnol/sql/2005/httpasws.mspx
2. MSXML 6.0
3. Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB Provider
4. Microsoft SQL Server Native Client
5. Microsoft SQL Server 2005 Management Objects Collection
When I try to connect and execute a query against msmdpump.dll via ascmd utility I am getting an error "ascmd: AMO connection error on connect string (Provider=MSOLAP.3;Data Source="http://webserver/olap/msmdpump.dll";SspropInitAppName=ascmd): An error was encountered in the transport layer. The peer prematurely closed the connection."
Everything is OK in case msmdpump.dll is setup on SSAS server.
Has anyone succeeded in this?
- References:
- Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- From: Mitak
- Re: Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- From: Jéjé
- Re: Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- From: Mitak
- Re: Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- From: Jéjé
- Re: Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- From: Mitak
- Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- Prev by Date: Re: Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- Next by Date: RE: Is this bug in partition merge
- Previous by thread: Re: Problem with HTTP access (msmdpump.dll) to SSAS on a machine different than the one where Analysis Services is installed.
- Next by thread: Custom MDX for RS report
- Index(es):
Relevant Pages
|
