After not getting much help on the last question, I decided to blow away the VM and re-create it as I already lost a week on this issue. And of course still issues, btu a little different.
I am using WSS on a 2008 server. I removed from the SharePoint admin the blocked asmx page types. I am using the administrator account with password and the domain, which is the IP of the VM machine. Normally I would never recommend using the admin account, but since I am just running a test to connect to SharePoint web services, so be it.
When accessing this site via a webbrowser, no issues whatsoever.
When accessing the web services from the browser using the admin credentials, no problem.
Then when trying to access the web service via Visual Studio I get the windows security dialog;
Followed by a discovery credential for the list;
Followed by another Discovery Credential for access to the error.aspx page, but as you can see, I can see the list of services for lists.asmx;
Followed by yet another Discovery Credential asking for permission to the $metadata and this just continues continually -it will NEVER authenticate via visual studio 2010;
And then, of course, when the code is ran, what do we get - ACCESS DENIED.
Call made; code not listed makes connection.
Make call to service:
And receive the error.
And IIS for SharePoint is set top Windows Authentication and Impersonate. All defaults.
It has now been going on 5 days; does anyone at all have any clue as to what is causing this? I have used this code and technique for years with Windows Server 2003 and WSS 2.0 and / or MOSS 2007 connecting from remote machines and NEVER, I mean NEVER had issues like this.
I would really appreciate any help.
Related
I have a portal running using claim base authentication (windows and FBA) and enabled anonymous access , it was working fine until 19-06-2022 windows server 2016 ask for restart to install updates, after that the portal is still working only for anonymous access when try to login as FBA form login default page its just refresh without login, dont know why is that and can not login as FBA, also when try to login as windows authentication, its gives an error :
"System.ArgumentException: Exception of type
'System.ArgumentException' was thrown. Parameter name: encodedValue
at
Microsoft.SharePoint.Administration.Claims.SPClaimEncodingManager.DecodeClaimFromFormsSuffix(String
encodedValue) ......."
After check windows update history the updates related to sharepoint is :
Security Update for Microsoft SharePoint Foundation 2013 (KB5002219)
Security Update for Microsoft SharePoint Enterprise Server 2013
(KB5002062)
those two updates are released in JUNE 14, 2022.
tried many old solutions all over the net and not fixed
tried to crate new empty web application with enable Windows and FBA authentication also not fixed the issue.
but web application works fine when disable FBA and just enable Windows authentication.
Any suggestion !?
Are you accessing your site via HTTPS/SSL? If not, that is probably the problem. Chrome made some changes to it's cookie handling a while ago, and when SharePoint released updates to handle them it broke the ability to login via FBA without SSL. All of the latest SharePoint updates require the site to be hosted with SSL for FBA login to work.
I have a provider hosted app (a normal asp.net web forms application) deployed on a typical web server IIS 7.5.
While launching the app from SharePoint Site in Office 365 Multi Tenant, it's throwing the below issue on App launch.
On capturing details using Fiddler, found the following when the app is launched
SPAppToken=&SPSiteUrl=https%3A%2F%2Fabc.sharepoint.com%2Fsites%2Fspdev%2Famsdev%2Famitamsdev&SPSiteTitle=amitamsdev&SPSiteLogoUrl=%2Fsites%2Fspdev%2FSiteAssets%2Flogo.gif&SPSiteLanguage=en-US&SPSiteCulture=en-US&SPRedirectMessage=EndpointAuthorityMatches&SPCorrelationId=31477a9c-2902-204a-8393-67eced1a10b8&SPErrorCorrelationId=31477a9c-2902-204a-8393-67eced1a10b8&
SPErrorInfo=The+requested+operation+requires+an+HTTPS+%28SSL%29+channel.++Ensure+that+the+target+endpoint+address+supports+SSL+and+try+again.++Target+endpoint+address
The SPErrorInfo Part is interesting. I am unable to confirm whether we really need the remote site to be configured for https?
Additional Information - Identity Provider is ACS and it is a low trust app.
Can someone suggest?
Regards,
Nitin Rastogi
In a production environment, you should always be using HTTPS. If you don't, you're exposing yourself (and your organization) to many risks.
If this is your development environment and you are confident this isn't an issue, you may want to look at the accepted answer to this question on the MSDN forums, which mentions the same error message. Their solution to bypass the HTTPS checking:
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp=$true
$c.Update()
When packaging the SharePoint App from Visual Studio, you must ensure that the URL you use is using HTTPS:
In IIS, add an HTTPS binding to the site to achieve this. You would have to reupload the App to SharePoint after packaging it with the new HTTPS URL.
More information here.
In all cases we are running .NET Framework 3.5
My company has a server running Windows Server 2003 R2 (Service Pack 2), 32-bit processor. The IIS instance on this machine runs several Websites. One of the Websites we are running is Microsoft CRM 4.
When I attempt to log in to CRM from my local PC, everything's perfectly straightforward. I receive a prompt for username and password, I enter the details, I'm authenticated, and I pass through. Easy.
However: I can RDP into the 2003 Server and open IE. If I then browse to our CRM website I am prompted for a username and password. I provide exactly the same details - including the correct domain - as I enter from my local PC. But nothing. I'm denied access.
I am an administrator both of my local PC and of the 2003 Server.
This is very weird. I don't even know where to begin looking on this one. I don't even know what key terms to hit into Google.
Any help would be very much appreciated.
Context
Now, knowing what developers are like (I am one) the first response is going to be: "If you can log in from your PC, why do you care?"
There's more going on.
We have another website on that server that does nothing but host a set of critical web services. This is because the critical web services themselves rarely change but the other features change all the time. We don't want the critical web services to go down while maintenance is performed on other areas, so they were split off into their own independent web site about 18 months ago.
I am developing a web service for the critical site. This Web Service itself includes a proxy that points to the CrmService of CRM 4. The idea is that we want people to be able to submit certain information - such as lead contact information - into our CRM. However, we don't want to give just anyone access to the whole CRM system (obviously). So by publishing our own WebService that sits in the middle we can expose only the functionality that we want other people to have.
This new web service is now ready for deployment. All scenarios are met, all unit tests pass, everything that should fail does. It's all hunky-dory.
When I put that WebService on the 2003 Server, suddenly it can't communicate with CrmService any more due to authentication failure. ???
In my attempts to diagnose the problem, I noticed that no-one - not even administrators - can log into the CRM Website from within the 2003 Server. So I'm suspecting that whatever is causing that issue is also responsible for my web service to be unable to access the CrmService too.
For additional context, we have a new multi-domain SSL cert on the 2003 Server and we're splitting access to all our websites via host-headers.
I can't think of any more relevant information. If I've left out something critical, just ask.
Found it!
http://support.microsoft.com/kb/896861
Did the trick.
I'm getting an error when attempting to call SharePoint's webservices on one of our platforms. To start, we have Development (DEV), Testing (QA) and Production (PROD) SharePoint servers. The QA and PROD servers are pretty much identical. We have an ASP.NET web service that sits out as a seperate application on each of them. Our data entry forms hit the web services to insert/update into a SQL database and in some cases make calls to some of SharePoints web services (lists, dws).
We’re having trouble calling SharePoint’s web services on PROD from our web services however, have no problems on QA(or DEV). In our web service code we have a web reference to the SharePoint web services (lists and dws). We attempt to call these web services to create list items/folders when a new entry is made through one of our forms. On QA, there is no problem creating the list items/folder. The form is filled out, calls our web services – which call the SharePoint web services and the list item/folder is created.
On PROD we get the following error when we attempt to call the SharePoint web services:
Unable to connect to the remote server
at System.Net.HttpWebRequest.GetRequestStream()
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
...
However, to make it more interesting, if I call the PROD SharePoint web services directly from my personal computer I have no problem creating the list items/folders. We only have the problem when our web service attempts to call the PROD SharePoint web services. We’ve looked through many different web.config files looking for differences on QA and PROD and are yet to come up with anything.
If anyone has any pointers, they would be greatly apppreciated. Thanks.
Update: I just attempted to refactor the above method to use the SharePoint Object Model API and I'm getting an unauthorized error. When using the Object Model API the credentials do not seemed to be passed properly, because it's attempting to use the MOSS Server credentials. Is there any way to tell it which credentials to use as you do with the web service api?
docLibList.Credentials = System.Net.CredentialCache.DefaultCredentials;
Thanks.
Sean,
I'm not sure I completely understand your calling pattern, but if you are indeed looping back to web services on the same box, you might be running into the infamous loopback issue:
https://serverfault.com/questions/32345/ie-8-authentication-denied-on-local-sharepoint-site/32485#32485
In short: executing hostname-based HTTP calls that loopback to the server from which they're issued can get blocked. If the loopback issue is in-play, you'll be able to call the web services in PROD from another box ... but not from the PROD box itself (i.e., looping back). I think this is consistent with the behavior you described above.
If Windows patch levels are different between your environments, it might explain why your code is failing in PROD but not in your other environments.
I hope this helps!
This probably is not the problem, but is your reference to the web service pointing to the production server correctly. I had a problem before when trying to access a SP service that was referenced incorrectly. The dev server I was pointing to was on a seperate domain and could not be found.
Regarding the update to your question about the unauthorized error using the object model:
Depending on the context that your code runs in you will sometimes need to elevate privileges. See this Elevation of Privilege MSDN article for details (also note the community comment at the end). There's also a Visual How-To.
Another method is to create a new SPSite object using a SPUserToken object. There is more information in this blog post by Daniel Larson. For the system account this would be done with the code:
SPSite site = new SPSite(SPContext.Current.Site.ID,
SPContext.Current.Site.SystemAccount.UserToken);
By the way, this would be better in its own question next time so that it can be correctly voted and answered.
So here is the scenario:
I have a MOSS 2007 box and I want my clients to be able to access a SharePoint site via the internet. I am told that I will be using an IPA and AD for authentication. However I have a DB outside of SharePoint that holds various business data and I want to use Web Services to access the data, manipulate it, and send it back to SharePoint via web parts.
The issue is that, from what I understand, I am going to have to authenticate the AD user every time a request to the Web Service happens. Obviously I dont want to do this every time because they have already authenticated to get onto the site, however I do want each call to have some form of security so its not open calls to my db. I do plan on having other applications access this service outside of SharePoint, so I dont want to have to reinstall the service for each application or even again.
Has anyone had to perform this task or something similar or do you have any suggestions on how to do this?
Thank you in advance and happy coding!
Why not just deploy the webservice to Sharepoint using a Sharepoint solution and a Feature.
That way it will be running under the sharepoint app pool and all authentication is done by sp.
Edit:
Seeing that SharePoint should not be in "control" (as stated in the comment), you should create the webservice, and run the application it's under in as using Windows Authentication. IMHO you should create a WCF Service. The, using the information found in this article you make the Service authenticate users against the AD usergroups they are in. see the "Security: Authentication" section of the article.
Then in Visual Studio you create a webpart and add a service reference to the project, pointing to your newly created Service. Have the webpart perform the needed logic (i.e. display data etc.)
Deploy the webpart to SharePoint using a SharePoint solution (.wsp files, created with WSPBuilder). Google for SharePoint + wspbuilder + tutorials. The solution should contain 1 feature to deploy the webpart. WSPBuilder integrates with VS and allows for the creation of WSPBuilde project. add a webpart feature item to the project (it will create the xml (deployment related) and code file for the webpart.