InfoPath Credentials Login?


Badge +6

Users are experiencing a login credentials window when opening an InfoPath client event within a K2BP process, deployed to a forms library in SharePoint 2007.


Upon opening the form initially from a form library to complete and submit it to start the process, no login problems
to SharePoint is experienced.


When receiving a infopath task in the next step/activity within the process, the login window is popped, the users
need to login again before the form opens. This only occurs for some users though, not with all.


1. Might this be DNS related since it only occurs with some users?
2. Does MOSS2007 Single Signon need to be configured for specific settings in Central Admin?


The InfoPath form's security level is configured as Domain within Form Options, and does not contain any
managed code.


Any help appreciated.


18 replies

Badge +8
Simple issue, Add your k2 workspace(URL) to the local intranet zone and enable windows authentication in the internet explorer. That should solve it.
Badge +6

Hi Maxpirate


 I also asked the users to check all their security settings in IE. I have come to realise now that some are accessing the MOSS site and tasks from outside the network via VPN connection. They are able to access the MOSS site, and the site and library. Also they are able to open the form's first view from the New menu in the library, complete and submit it.


As soon as they want to access and open their second+ tasks, they receive the popped logon screen, and when entering the credentials, it makes no difference, the logon screen is poppsed again and again?? Then I also asked them to try and access their tasks from workspace, by entering the workspace url directly in IE, upon also getting the logon screen and unable to login???


 I feel that is it defenitely security on the VPN level that is not set properly. But then why is it possible to access the MOSS site over the VPN connection?


 

Badge +8

I've seen some cases where users are prompted for credentials, sometimes intermittently, sometimes constantly. If there are no Kerberos in the works and your IE zone settings are correct, try applying the DisableLoopbackCheck setting, method 2 in the MS article:

http://support.microsoft.com/kb/896861 

 

Badge +8

Sagrys,


I develop and test my applications using VPN alone. Never had this issue.

Badge +6

I have checked all IE settings and applied the registry entry for the DisableLoopbakCheck, but still no luck?!


 


Maxpirate, did you assign any extra authentication permissions, etc for the VPN with regards to SharePoint/K2 in order to access and process tasks?


Surely the login credentials must be forwarded to SharePoint and the to K2, this one is really a pain!

Badge +8

Hi Sagrys,


You've never mentioned whether your environment is configured  to use Kerberos. If so, ensure that Port 88 isn't blocked. Kerberos needs that for both TCP and UDP protocols.


If all components are on one machine, check what IIS is configured to use:



  1. Open command prompt and change your working directory to C:InetpubAdminscripts
  2. Type: cscript adsutil.vbs get w3svc1NTAuthenticationProviders where 1 is the site ID. 
  3. If this is not set, set it to NTLM: cscript adsutil.vbs set w3svc1NTAuthenticationProviders "NTLM"
  4. Do an IIS reset.

Again, this should only be done if all components are in one machine. If it's a distributed environment, ignore this and enable Kerberos logging. Chances are its a Kerberos problem. 

Badge +8

Sagrys,


I have not given any extra auth perms for vpn. Can you tell me from which domain does the users log in to access sharepoint. Are both same or diff. Like company-ususername and company-mxusername??

Badge +6

Hi dc


 


I did not install/setup either SharePoint nor K2BP in the environment, but know for a fact that Kerberos has not been setup.


 


SharePoint and K2 is installed on the same server, running on a VM at this point. I will send these instructions to the administrator to check what IIS


authentication was setup to use, think chances are good that it has not been set at all. How do I get the ID of the site? I know the Default Web Site


in IIS has an ID of 1, but K2Workspace and SharePoint are off course installed to run on their own ports within IIS.


 


Should NTLM then only be set for the K2Workspace site, because I know a default installation of SharePoint enables NTLM authentication for SharePoint?


 

Badge +6

Hi Maxpirate


There is only one domain within this environment. Single Sign On has been setup on the network. Users are able to access SharePoint from both the VPN connection outside the network as well as within the network. They are able to access the form library, open the first view of the InfoPath form, complete and submit the form which starts the K2BP process.


Only users connecting via VPN outide the network cannot access/open their tasks further within the process, i.e. from the form view 2 and onwards. They are prompted with a logon screen that keeps on popping, even though they supply their login credentials. They have attempted to login using domainusername and password, as well as just the username and password. The FQDN was also attempted.

Badge +8

Sagrys,


What's the HTTP error code when you click "cancel" in the credentials prompt window (and/or when you type wrong password 3 times)?

Badge +6
I will have to ask the client as I do not have VPN access to their network, but I think it might be 401.1
Badge +8

Hi Sagrys,


You can get the site ID by opening IIS Manager and clicking on the Sites node (left hand pane). In the details pane, you should see all the sites created for the server, Name, ID, Path, etc. The ID you see there is the ID to be used in the script. Note that if its empty, it will default to Kerberos (I think since Windows 2003 SP1 or R2, its the default), so set it to NTLM.


For Nicolas' question, you can check the IIS logs for the K2 Runtime services, that's where the web service called by InfoPath resides and you should see all authentication messages in the IIS logs (RuntimeServices/InfoPathService.asmx)

Badge +8

Sagrys,


The for users havin the problem, the moss site must have been added to their local intranet zone and not the K2workspace site. Thats why they are able to access moss and submit the infopath and not open the task list item since it has k2workspace url.

Badge +6

Hey Maxpirate


Both the moss site and k2 site has been added to the user's IE trusted sites. Because moss and k2 are installed on the same server, only one entry is added off course, for example.... http://mossServer:1000 for MOSS and http://mossServer:81 for K2, thus only entry http://mossServer is added to the trusted sites list.


 

Badge +6

Hi dc


Thanks, I will defenitely check the IIS logs.

Badge +6

Hi dc


Should the NLTM setting for AuthenticationProviders using the AdminScripts be set for only the K2Workspace site?

Badge +8
Yeap, I believe your SharePoint site is already configured to be NTLM (default setting). You can verify though by using get script.
Badge +6

The login credential access problem is now finally solved by...


1. Applying the DisableLoopbackCheck registry entry


2. Setting the authenctication type NTLM on the K2Workspace site in IIS using the Inetpub AdminScripts (cscript command)


 

Reply