Web Service requests UN/PW

[John Stevens]

Users are receiving a pop-up dialog box requesting user name and
password when they open my InfoPath form. The dialog box indicates
that the UN/PW is required for the web service.

I developed an Infopath 2007 form with several secondary web service
data sources, some of which query upon opening. The web service is one
I developed and resides on a different server within the domain. I
deployed the form to MOSS and everything works fine for me in the
production environment. All users are within the domain.

The webservice (.Net 2.0) accesses a SQL server 2005 database that is
local to the server (Windows 2003) with the web service.
The users are able to access the SQL tables directly (tested using
Excel data connection)
Windows authentication is enabled, anonymous access is turned off.
Impersonation is set to True.
The users are able to access the web service via browser.
The form has default (Domain) security.

I suspect that there is something lacking with the web.config file in
the web service's directory, because the form had been working for my
test user before I accidentally hosed the web.config when deploying a
different ASP.Net web app to the same directory.

Any help is appreciated.

 

[Clay Fox]

Hey John.

I believe this is a MOSS IIS issue where it cannot pass the windws user
credentials across the domain for the second hop.
I do not remember if there is a setting for this or not but had the same
issue with some SRS reports trying to grab information on another server.

I know in Sharepoint Admin there are some setting on crossdomain situations
and ussually they are restricted by default.

I used a service account for the second connection since I was already
validating the user up front and had permissions on the SQL. Since it was a
dedicated SQL account no one else had the password.

I know that is not complete but hopefully that can help you track it down.

If you need additional webservices, we sell a whole suite of generic ones
for dynamic queries and submits to SQL for way less than it takes to develop
each one.

 

[LCPSFunding]

Thanks Clay.

If this is the case, why would I be able to access the form
successfully without the same error that other users encounter? The
error seems to be user-based, and with my Admin permissions something
works for me that doesn't work for others. I do not own the MOSS
server, so I have no special permissions there at the IIS level.

~John

 

[Clay Fox]

I am not sure since that was the way it worked for me to. I was able to view
the reports fine but no one else could, they would get an authentication box.
I believe it was because I was developing the solution locally to the report
server. Otherwise it has something to do with the admin rights.

I am not sure but that was the identical behavior I saw.

 

[Gavin McKay]

Hi John,

Is this an InfoPath Windows client that is being used to access the form, or
is it browser-based via InfoPath Forms Services? I'm assuming browser-based,
because you said users can access the Web Service using a normal browser and
you mentioned a MOSS box.

I thought that web services which could not be accessed by InfoPath Forms
Services due to security credentials would just report a "failed" message,
not prompt the user for credentials... could it be that there is content on
the InfoPath template itself that the users do not have permission to i.e.
images, embedded contents, etc? Of is the form template trying to save
itself to a document library that the user does not have permission to?

Gavin.

 

[DragonslayerApps]

Gavin~

This error arises when using the InfoPath 2007 Windows Client. Our MOSS does
not have a license for IPFS.

~John

 

[DragonslayerApps]

The problem turned out to be the permissions on the server directory
containing the web service application. I authorized domain users for
Read\Execute and now all is well. Thanks for your eyes & thoughts.

 

[Gavin McKay]

Glad you worked it out, those types of issues can be very frustrating!