I have sharepoint 2010 application that has default zone and an extended internet zone. The application uses classic mode authentication. I want to convert the application to use claims based authentication. I followed this article http://bit.ly/9StUpd and http://technet.microsoft.com/en-us/library/gg251985.aspx to create a sample application and it works fine.
I have configured default zone to use windows auth and the extended zone to use Forms based authentication. I have only modified the web.config of extended application to use the connection string and membership provider settings as mentioned in the article.
Now my question is do I need to configure web.config of Default zone to use the asp.net membership provider settings.
I'm not able to search asp.net membership provider users in the people picker. The reason is I want to assign a user in asp.net sql membership provider database as site collection administrator so that they have access to all the site menu items.
Related
I am trying to implement SSO with my office add-in. To do this, I am using the office IdentityAPI, which requires you to have an application ID URI, that has some restrictions (such as you owning the domain and it being verified). Using MS lingo, we own www.contoso.com and www.contoso.onmicrosoft.com, so I have set up the AppID URI to be www.contoso.com/{appId}, as is suggested in the documentation. However, my add-in is being hosted on Azure static storage, which has a domain www.contoso.z12.web.windows.net, which is different to the the AppID URI. This means that I get the error in the question when trying to use this setup. Changing the AppID URI to the domain that the static website is on does not work. Does anyone have any suggestions?
You need to host the add-in on the custom domain with a valid certificate. Public Azure web sites are not accepted by the Azure AD services. This is a well-known restriction for using the SSO with Azure AD.
The error on the SSO configuration page should state that explicitly.
I want use Mixed mode authentication in my application.
I want Windows AD Authentication for intranet users and Forms authentication for internet users.
How can I configure this.
Check out the Kentico documentation for Mixed Mode Authentication.
Essentially you will:
determine if you want to import AD roles or not (web.config key)
Add an LDAP connection string to your web.config
Modify the membership and roleManager elements under congfiguration/system.web section in your web.config to use the AD connection string and provider
map the username field
It's not a hard setup really and much easier if you don't have users already in the Kentico system. If the username already exists in Kentico, the user will NOT be imported into Kentico from AD.
We have a SharePoint 2013 web application using claim based authentication where identity provider is windows. There are some custom web services in a "sub-application" within SharePoint website in IIS. What we want is to make those custom web services claim aware. So that in custom web services we should know that who is the current logged in user in SharePoint, whether he is authenticated SP user or not etc.
When we access the custom web service using an AJAX Web Part then the web service know the current logged in user, but using a content query (XSLT) Web Part the web service shows Application Pool's user as current logged in user, sort of double-hop problem.
Any idea how to fix this issue or how could I use the STS of SharePoint site in my custom web services application?
We have to HNSC https://division1.corp.com https://division2.corp.com on the same SPWebApplication using Claims and Forms Authentication. When logging in to https://division1.corp.com we should have access to https://division2.corp, but we get the logon dialog box again. The UserInformationList are synchronized between this HNSC. By looking at the cookie, they are different.
How shall we solve this?
SharePoint 2010 out of the box does not provide a way to share authentication between its own web applications. This is primarily because each application authenticates users independently and the cookies that it issues are marked with the HTTP Only flag. This means the cookie cannot be accessed by other applications on different DNS names (even if they are part of the same SharePoint farm).
The most common resolution to this is to set up an external federated trusted identity provider (such as ADFS) and have each of your web applications trust it. Then you can configure your federated identity provider to authenticate against your forms provider.
Here's some more detailed info about how the authentication structure in SharePoint works and how you can develop against it: http://msdn.microsoft.com/en-us/library/gg430136.aspx
is it possible to configure federated trust without using ADFS. This article "Claims-Based Single Sign-On for Microsoft SharePoint 2010" link walks you through an example of integrating two web applications into a sso environment for intranet and extranet web users. The article describes how to configure a New-SPTrustedIdentityTokenIssuer where you can add ProviderRealms to SPTrustedIdentityTokenIssuer. In our scenario we set -SignInUrl https://division.corp.com/_layouts/fba/fbalogin.aspx. But I cant find out how to configure the section federatedAuthentication.
I have created an authetication provider and went to central administration >> Authentication Providers and changed the authentication settings to Forms and filled in Membership provider and Role manager details.
Now, when i go to create a site collection under the above mentioned web application, the people picker in the create site collection page still refers to the active directory(central admin has windows authentication).
Can any one explain this behaviour?
I actually expected the People picker in the Create site collection page to refer to the Forms database rather than active directory.
Thanks
In the web.config for your web app, you need to change the value in the <PeoplePickerWildcards> node. Change the key to your membership provider.
You need to add your the configuration information for the membership provider to the web.config file for Central Administration. This will allow Central Admin to find from both AD and your own membership. There are examples on Technet for a SQL Server and an LDAP membership provider. Note how it mentions that the membership provider info needs to be added to both the web app's web.config and to Central Admin's. If you're using a Role Manager though, don't put that info in the Central Admin web.config, or at least not unless you really know what you're doing and why. :)
Once you do this the people picker should be able to find people from your FBA solution's membership provider. One little caveat if you happen to be using the same AD store (or some kind of replica) for both Windows auth and LDAP auth. You'll need to use the "prefix" of your membership provider name when specifying the user, otherwise the people picker will always lookup the native AD version of that user. For example, looking up "jdoe" will always find "domain\jdoe" first. If you want jdoe from an LDAP provider pointing at that AD, you'll have to explicitly put in "ldap:jdoe" (substituting whatever you called your membership provider in the web.config for "ldap"