I am having a problem when setting up ADFS in a web application which have hosted name site collections. Although I put ADFS authentication in a different zone, but in my hosted site name collections, I still can search for ADFS accounts. Please refer to the detailed info below:
My situation is:
I have a web application which have 2 hosted name site collections. It is using NTML authentication in Default Zone.
In order to use ADFS, I extended the web application to Internet Zone
However, during the extending web application, I think the SercurityTokenServiceApplication got some problems. I had to restart application pool of the SecurityTokenServiceApplication. After that I continued to configure ADFS in sharepoint.
Then my problem is:
The login via ADFS works perfectly. However, I have got a problem with the people picker of the hosted name site collections. When I opened the people picker to check permission, I tried to enter an account and the people picker showed both results from ActiveDirectory and ADFS. This problem now is in production farm, but it did not happen in my staging farm. I think it is because the SecurityTokenServiceApplication was not down at the time I set up in the stating environment.
I tried to reproduce the problem in my testing environment by stopping the SecurityTokenServiceApplication during extending web application step, then I got the same problem in the production.
However, the path-based site collections in the web application do not have this problem. Every hosted name site collection have issue.
I even tried to delete the web application and recreate again but the problem still exists.
From my understanding, if I set up that way, only site collections from Internet zone can retrieve users from ADFS. However, I do not know how to resolve the above problem. If there is any one experienced the same problem, please kindly advise.
Thanks a lot.
Related
My app runs on multiple subdomains
i.e. abc.foo.com xyz.foo.com for different regions.
We recently created a PWA for our app which runs on a different subdomain
m-abc.foo.com m-xyz.foo.com
To enable Sign in with Google for the PWAs, I added the redirect_uris and Authorized origins in the API Credentials for Google Cloud Platform.
Now, for these new subdomains I am getting the following error on the consent screen after choosing the google email address
This app is blocked
This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access.
The app currently asks for read/write access for Calendar only.
Could not find anything definitive on support documents either.
Anybody has any idea what I might be missing here?
To check, I added another subdomain def.foo.com and added redirect_uri for it. This time Google Signin worked fine without problem.
Does this have anything to do with the apps being a PWA?
Thanks!
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.
I am planning a Sitecore deployment, I was reading a "Separating Authoring from Delivery" http://www.awareweb.com/AwareBlog/ArchConsideration.aspx.
Do I need to install and configure Sitecore in both envioronments. In that case users can access Delivery/Sitecore and Authoring/Sitecore.
How can I actually seperate two websites? I am bit confused. Please help!
Dhanuka777, as mentioned by techphoria, you'll really have to start reading up on a lot of things before you'll be able to get more direct help.
That being said, this is the basics of what you're trying to achieve:
Delivery: This is a website running the sitecore web application, but it does not allow users to login to the Sitecore editing interface. It can only serve up the content to your extranet users.
Authoring: This is a website running the sitecore web application, but it allows users to login to the Sitecore editing interface. Extranet users cannot access it. This usually means it's running on a VM or server behind a firewall.
You will also need to look at how you want deploy your databases to support these two sites.
My company will be soon switching to Google Apps, and I would like to propose the idea of having our site administration page being authenticated with OpenID. Therefore, any user who is logged into Google Apps would be automatically logged in to our site Administration. Currently, our site administration has it's own list of users and passwords in the DB, but I would like to have the user list based off Google Apps, with their unique identifier saved in our DB. That way, new employees would only have to be set up in Google Apps to access our site Administration.
I've done some research, and come across terms like SSO, OpenID, and SAML, but I can't quite narrow down which route I'm supposed to go. It seems like Google has a lot of paths open for development, and I'm not sure which one I'm supposed to take.
My question is: What kind of Authentication am I seeking for my purpose described above, and can anyone point me in the direction of where to get started? My site is published in ColdFusion 9, so answers specific to that platform are a bonus.
If you just need Web SSO -- I believe you would use your GApps domain as an OpenID Provider. Your application would then act as an RP and consume identities as established by your own GApps domain and company administration. GApps can only act as a SAML Service Provider -- so using SAML for this use case isn't realistic.
HTH
Ian
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.