I've imported a bunch of users into my Active Directory with some custom fields. Then I did a profile import from Active Directory to Sharepoint with all the custom fields and regular fields. After this, I needed each user to be in a site collection with a MySite set up for them. I did that by writing some code that ensured the user existed and then checked the profile attribute "personalspace" to see if a MySite had been created. Everything worked great until some of the users needed to login from outside the network.
I'd like to get rid of the windows authentication pop-up that a user would get if they hit from outside the network (or haven't added the site to their trusted zone in IE). I've extended my web application to create an internet zone. Then I edited the web.config of the internet site to do active directory forms authentication, along with editing the Central Administrator's web.config so that it can see the data source. This is all well and good, the user can login through a nice interface. The only problem is that now the user is detached from their user profile. Essentially Sharepoint views a windows authentication user and a forms authenticated user as two separate users.
Is there a way to link the profiles? Do I have to write a custom membership provider to log a user in and then link them up to their windows account? Is there a way to log a user in from the internet web app and then spoof their windows credentials and pass it to the intranet? Do I need to recreate all the user profiles based on the forms authentication data source?
Is this what are you looking for .. http://grounding.co.za/blogs/brett/archive/2008/01/09/setting-up-dual-authentication-on-windows-sharepoint-services-3-0-forms-and-ntlm.aspx ?
See ya
I've been trying to accomplish the same thing, with exactly the same problem - the "forms-authenticated-me" is not the same as the "windows-authenticated-me" to sharepoint, and I can't see how to map the two.
After a lot of frustrating efforts, I think I've finally realized it's not possible. In retrospect, this isn't too surprising.
here's an excerpt from http://msdn.microsoft.com/en-us/library/bb975136.aspx (my emphasis added)...
Deciding to Use Forms Authentication
Some organizations want to use Windows
users and groups in SharePoint
Products and Technologies, but enter
credentials via forms authentication.
Before using forms authentication,
determine why to use forms
authentication in the first place:
What is the business driver? If user
accounts are stored in a location
other than an Active Directory domain
controller, or if Active Directory is
not available in a particular
environment, using forms
authentication with a membership
provider is a good choice. But if you
want to force logon only via forms
authentication, but still use Windows
and all of the integrated features it
provides, you should consider an
alternative such as publishing the
SharePoint site with Microsoft
Internet Security and Acceleration
(ISA) Server 2006. ISA Server 2006
allows users to log on by using a
forms authentication Web form, but
treats them like Windows users after
authentication. This implementation
provides a more consistent and
compelling experience for end users.
You can set up the Forms Authentication to use the Active Directory Forms Authentication provider. You'll get the best of both worlds.
The login prompt will be the Forms Authentication prompt that you want, but the profile and login info will come from Active Directory.
Follow these instructions to configure the provider:
How To: Use Forms Authentication with Active Directory
Related
We have configured Okta as a trusted authentication provider to out SharePoint 2013 On-Premises environment. The user can log into Okta and access the SharePoint 'app' but when it connects them to the homepage, they are met with 'Sorry this site has not been shared with you'. It's like their account does not have access to SP, or is not being recognised. I can see in the logs that a valid SAML token is coming in, but I think we might be missing a step where that is converted to a valid Active Directory account.
In the deployment guide they talk about 'recommending' that we install the Okta People Picker plugin. I don't want to do this if we don't have to, I was under the impression we didn't need to add 'Okta' users into SharePoint as it would map the SAML claim to their Active Directory account and grant them the same access they would have if they were inside the network...
Any help would be appreciated.
First off, in order for users to be able to be looked up you'll need to definitely add the people picker plugin in. The biggest snag that the documentation doesn't accurately describe is that you'll need to import the okta cert chain to the server and establish trust in central admin for 2013 (not just 2010 only). Following all steps in the guide (including certs) got that going.
Okta-SharePoint on-prem guide: https://support.okta.com/help/articles/Knowledge_Article/Microsoft-SharePoint-On-Premises-Deployment-Guide
As for access to the site: once you get the people picker configured then you need to ensure you have migrated your user profile users from AD as the new type of claim for your identity provider. For the most part you can follow the guide below and just update the appropriate spots for Okta:
https://blogs.msdn.microsoft.com/sambetts/2014/09/03/how-to-migrate-sharepoint-users-to-adfs/
For extended troubleshooting I would recommend leveraging a ULS log viewing tool and to filter the results by the name of your claim identity provider.
I want to set up a website on Azure according to the following requirements and are wondering if it is even possible?
As a internal team member, I must be able to login to the site with Windows Authentication
As a external customer, I must be able to login to the site with user name and password
As a external customer, I must not be able to access a subset of the site
As a unauthorized user, I must not be able to access anything on the site
I guess I have to set up a VPN connection between Azure and the Active Directory in my company. How do I do that?
Is it at all possible to meet my requirements?
Background Information
We are a small project with about 10 team members.
We have four large customers who need access to the site, and there are a few people in each customer who needs to have access to the site.
Customers will just have read only access to static, non-sensitive information.
The team members will have write access, and will also handle some sensitive information.
** Edit **
I have now managed to create efficient synchronization of our projects local AD to Azure, thanks user18044. Unfortunately, the accounts for the team members is located in the company's AD (corp.mycompany.com), and out AD has one-way trust with it.
We have groups in the project-AD pointing to our accounts in the company's AD, but the members in the groups is not synchronizing over to Azure.
Can this be solved?
Yes, I think what you are describing is doable.
Your first two bullet points are about authentication. As Azure Active Directory does not directly support Windows Authentication, federation is the way to go here.
When you as an internal team member log on, you land on what is called a home-realm discovery page, where you pick the realm you want to authenticate in. Picking the realm of your company, you get redirected to the STS (for example ADFS) your company has set up to authenticate you. If you are in the same Windows Active Directory network as the STS is authenticating against, you should be able to use Kerberos to be issued a token.
An external customer would be redirected to another STS that would use forms authentication against a credential store to issue security tokens.
Both security tokens are then posted back to Azure Active Directory which is configured to trust both STS's and issues a token of its own. See here for an example.
As for the second two bullets, the authorization part you can do based on roles you assign to your users. Depending on which STS authenticated your user, you assign them a certain role. Based on that role you can give access to certain parts of your website or not. How to implement this depends on what stack you are using for your web application, but a Google search should give you some leads.
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 two questions on wss 3.0
How to know that kind of authentication is currently in use.
How do I set the authentication in such a way that users on office network don't have to input user name\password? So if users are in the office they can just go straight in without using a password? Those outside the office will obviously still have to use the password.
Detail answer would be really great.
For #2, you also need to make sure that Internet Explorer has your site listed as a trusted site or intranet site so that IE will be willing to pass the credentials to the Sharepoint Server
There are two build-in authentication types: windows and forms.
You can configure it in central administration (as far as I remember in "Application Management" section).
Windows authentication will use current user's windows credentials to login on site. So if SharePoint is configured with windows authentication and permissions were granted to user there will be no request to enter login/password. In other case (outside of office for example) site will ask for credentials.
I need to find out how I can allow our Sharepoint portal to support both windows authentication and form based authentication. The objective is to allow those users in our Active directory to sign into the portal using their active directory credentials, and at the same time we want to allow those users who don't belong to our active directory to register an account online and be able to access our sharepoint portal after their account is approved by an admin.
You need to enable the Dual Authentication for the SharePoint Site. Here one of the class article in the subject
Also you need to deploy the controls for enabling the user to register and create login refer this