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.
Related
I have recently inherited a Web API development that exposes key endpoints to a company that is hosting and running our website.
We use Octopus to deploy the API to our webserver.
I have duplicated the API and added the appropriate configuration variable to Octopus and deployed it to a secondary webserver (as a development API) for our 3rd party to use.
We are using identity server along with OpenID connect for authentication.
This has built and deployed however authentication is failing.
I know this is a vague description, but I am looking for pointers for an analysis path.
I have compared the logs of the current Api and the test Api and results are the same. (Stating authentication is successful)
Not really enough information to properly answer this question - but I would start by:
1) Checking all the log files you can find for a more detailed exception message. (application logs, IIS logs, event log)
2) Try to narrow down the issue. Does authentication fail for everyone/all the time? Or is this an issue intermittent? Does it work locally? For certain providers only?
3) Slowly start making the new website look like the old website. Comparing web.config files, copy/pasting the old website code onto the new server etc.
4) Check or restore old service accounts, firewall settings, database values, urls etc.
If all else fails - bring everything back to a working state and start changing one thing at a time until you have a little more experience with the application.
I have developed a REST web service using JAX-RS, hosted on Apache Tomcat server. I used Eclipse for developing this and hosted on a Windows 7 Enterprise machine. Now I need to provide Kerberos Authentication to access my service from any client (for example SoapUI). I have tried to get information from many sites but, all I get is configurations on linux machines.
I'm a newbie to the security concepts and authentication mechanisms and architectures, I would appreciate a good detailed explanation.
Here is a good description of how to integrate Tomcat with Windows authentication:
https://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
Please note that there might be 2 separate things you might want, I'm not sure which one you are looking for.
Authenticate transparently with the Kerberos tickets the user already has.
Authenticate with username+password always, using MS AD to check them.
The first is always transparent, meaning the user does not have to enter username+password again. In the second one she obviously has to.
If you are looking for other services (like SoapUI) to access your services with Kerberos tickets, then those services would need to get a ticket themselves. If you just want those services to use username+password (instead of Kerberos), then you don't need a ticket of course.
Edit after clarification: Using username+password from a windows domain actually does not involve Kerberos at all. It is using LDAP to authenticate, which maps to JNDI in Java. There is a JNDIRealm in Tomcat to set it up, described here:
https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JNDIRealm
Good Day Everyone,
Excuse the newbie question, I am new to Microsoft Sync Framework. I've done extensive research on the Internet in order to find my way in this puzzle with the different versions of Sync Framework, of SQL Server, of Sync Services for ADO.NET, of SyncAgent vs SyncOrchestrator, etc. etc. and what should be used in which type of scenario. Unfortunately, after about a week of struggling all day long with how to code my ASP.NET 2.0 C# web application right, I am still lost.
My current situation is this: I am developing applications for a large Department and I cannot expect to get approval for installing new stuff on the server side. I am stuck with SQL Server 2008 and (I believe), the server has Sync Framework 1.0 installed on it. However, I have the freedom to install later versions on the client computers that will connect to the server. These will have SQL Server 2008 Express (NOT Compact) and will each run the web app. in their localhost IIS. The synchronization model is centralized in that the clients will only connect to the server for bidirectional synchronization (in a star-shaped network topology, do we call this the hub-spoke model?) but will not connect to each other (no peer-to-peer collaboration).
I have prepared both sides of the database for synchronization (enabled Change Tracking, put GUID data type for Primary Keys, etc. etc.)
The core of the synchronization, the program that makes the interface between the two nodes to synchronize, seem to be exclusively the web application on the client side. Right?
QUESTION: If I want to use Sync Framework v2.0 or v2.1, can I just ignore what version is installed on the server? In other words, is the Sync Framework on the server side even doing something? The SQL Server does not have the web application installed on it.
Unfortunately I could not find answer to this rather simple question on the web!
Thanks very much for your help! Have a great day!
Kindest Regards,
Zyxy
No, you don't need to install sync framework on the central sever. All you need from the central database is a connection string. As long as you can access the central database with a login that has sufficient rights, then you don't need to install anything on it. The sync application can run from anywhere as long as it is able to connect to the central server.
depends how you build your application.
if all sync code is on your app and you simply point it to connect the central sql server, then no need to have sync framework on the server.
if however you decide to use WCF such that you have a service component of the sync on the server side, then you need sync framework on the server. you client will have a proxy for the server side service and part of the synchronization will be executed server side on the wcf service.
with regards to SQL Express on the client side, SQL Ce is the only supported client database is you use VS Local Database Cache Project item or if you manually code against the SyncAgent/SQLCeClientSyncProvider/DbServerSyncProvider.
if you use SQL Express, you will have to use the newer SyncOrchestrator/SqlSyncProvider combo but that doesnt use the built-in SQL Change tracking.
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.
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.