I'm sorry if this is a stupid question. I've read many articles about ADFS setup and what-not, but what I'm failing to understand (since this is not my primary area of work or interest) is if its actually capable of handling what I need handled.
That is: I have a Sharepoint server on domain "domainA". Now, I've been told that using ADFS, I can "delegate" permissions to other external AD's. The way I'm understanding it is, that I can say this other company using "domainB" is allowed to login to my sharepoint server? Is this at all correct? So users of both "domainA" and "domainB" is allowed to login, and I can set sharepoint permissions with users of both AD's?
ADFS is an instance of a Security Token System (STS).
SP 2010 has its own STS which can be federated with an instance of ADFS in Domain A which allows users to authenticate via the Domain A AD. These users are configured to receive a set of claims from the Domain A AD which SP 2010 uses as permissions (i.e. authorisation).
If you have another domain - Domain B - the normal practice is to install another instance of ADFS on that domain and then federate the two ADFS. These users will also receive a set of claims.
Now users in Domain A authenticate on the Domain A AD and users in Domain B authenticate on the Domain B AD and both have access to the SP2010 application.
To decide where to authenticate, the user will be presented with a Home Realm Discovery screen which will ask them where they want to authenticate. This is out-of-the-box behaviour.
For anything ADFS related, look here.
Related
We have created an SSO solution using IdentityServer4. Our public/affiliated users are authenticated by an account stored in a database and our corporate/internal users are authenticated using their Active Directory accounts.
The problem we're having is that when we host our IdentityServer solution on a DMZ (not on our domain) it cannot access Active Directory (on our domain) to verify a user's login credentials and roles/claims.
My goal is to know the best solution to this problem.
Is the best practice to implement Active Directory Federation Services?
Do we need to host IdentityServer on our domain so that it has AD access and then create a second application to host externally and call in to our actual IdentityServer?
Is there a secure solution our networking team can implement to allow the external server to access AD on our domain (ie: somehow grant AD permissions to the IIS Application Pool Identity)?
At a bit of a loss on what the best practice is here. Not sure if this is a problem for our networking/operations team or for our development team.
Thanks in advance.
IdentityServer4 supports to deploy UI (Login Pages) as a separate application. So one solution is to have UI in DMZ and other BE server in Domain.
In all other cases, you will be providing Database Access to a Server in DMZ (which is not supposed to be best thing).
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.
I have a website (azure), that has a login page for the user to insert it's username and password.
Currently, the login is using LDAP to autenticate the user.
Now the client wants to use/activate the single sign on functionality, but using their Windows Server Active Directory (they don't want to use the Azure Active Directory).
Is this possible to do? Whats the best approach?
These are the two options I know:
You can use Microsoft Active Directory Federation Services (aka ADFS). This is a component that should be installed in your customer infrastructure and talks with the AD, your website will talk WS-Federation with ADFS. Authenticating a user means basically redirecting the user to a ADFS, if the user is in the LAN and is already authenticated to AD, ADFS will login automatically, but if is outside it will prompt user credentials.
Another approach will be to use a third party authentication broker. Auth0 is an authentication broker that you can add from the azure store, you will need to create an AD "Connection", which will require to install an small MSI on your customer infrastructure. For this case it works more or less like ADFS but your application talks OAuth with Auth0 rather than Ws-Federation so in lot of cases it is easier to implement.
Disclaimer: I work for Auth0.
I'm customizing an ACS home realm discovery page and want to accommodate users who have either a "microsoft account" (aka LiveID/Passport) or a Office365/Azure Active Directory account.
In this situation, it's possible for the following workflow to happen (as far as I understand it)
User logs in using ACS custom page
User selects "Microsoft Account"
User types in their company / corporate ID
The HRD process at http://portal.microsoftonline.com redirects them to their ADFS server
Their ADFS server redirects them to their company.
Once sign-in passes (or fails) the login would cascade back to the ACS page.
What is the most efficient way (for the end user) to integrate Azure ACS, with Azure Active Directory / Office 365, with a custom HRD page that I create?
Or more plainly, is there a JSON web service that I can query to determine if a given domain or account exists within the "Microsoft Account/LiveID" world, and also check AzureAD for the same thing.
You cannot treat "microsoft accounts" (Windows Live ID / Outlook.com / hotmail / xbox /etc) the same as WAAD accounts when using ACS. When you set up your identity providers in ACS you will need to enable a Windows Live IDP and one IDP for each WAAD instance you are going to allow users to authenticate with. One thing that is not clear to me from your question is if you are needing for you users to be able to authenticate against a single WAAD tenant or from multiple. If one then you only need to configure one WAAD tenant in ACS. If you need to allow users to authenticate against multiple WAAD tenants then you will need to set up and IDP for each in ACS. For example if your web app is a SAAS application with users from companies "Contoso" and "Northwind" and you want them to be able to authenticate against their company's on-premise active directory then you will need two WAAD tenants setup. Each WAAD tenant will need to have federation configured with their given on-premise active directory. Each WAAD tenant in turn would need to be configured in ACS as an IDP. You could name those IDPs distinctly in ACS something like "Contoso WAAD" and "Northwind WAAD". Then in your custom implementation of the HRD page you can either just list all the IDPs and let the user choose, or if you want to be fancier you could parse the JSON results from the ACS endpoint that lists IDP and present them to the user (or just redirect them) based on some other selection they had made.
I am currently trying to understand the combination of Azure ACS with Claims-based Auth and the option of using a custom STS and I am only slowly getting through the (unfortunately few) info sources.
Before I spend more hours on this I would like to confirm if my plan is even possible.
I have multiple azure roles (web+worker) that are being accessed over the internet by both employees and customers. Additionally, employees access these roles and desktop apps from inside our local network.
User data comes from two sources. Our azure app has user data about customers and employees, our (local) AD only from employees.
To make the login experience as efficient (and ergonomic) as possible, when accessed via our local network, employees should be automatically authenticated (Windows Integrated Auth?) on both the desktop app (automatically because of Windows User Profile Context) and on the azure apps (hopefully w/o login page).
Customers, on the other hand, should enter their user credentials when accessing the azure app, but should not have to decide between different "Credential-sources", they should just get the username+password form.
In other words
Employee visits Azure app from local network -> Auto-login with Integrated Auth / AD data
Employee visits Azure app from internet -> Username+Password form
Customer visits Azure app from internet -> Username+Password form
While writing this question, two more came to mind:
1) Is it even possible to auto-login based on source/cookie/wizardry or would that require a manual user choice for selecting the "Credential-Source"?
2) If Azure ACS "knows" that AD account with Username X is the same as Azure App User Y, does it matter with which one logins? Can the app access the same claim-data on either login route?
Are you sure you need a custom STS? It sounds like to start you just want to enable your AD users to sign in to your azure applications using their windows credentials if they are on the domain (no password prompt). ADFS 2.0 and WIF will facilitate this. In addition, if you set up an ADFS proxy server so that when those same users browse to your app from outside of the domain they will get prompted for their domain credentials.
Now your AD users are set up, but if you want your applications to be accessible to users outside of your domain, you can federate ADFS with another organization's ADFS server, or use ACS to enable login using consumer identity providers such as Google, Yahoo, and LiveID, which are provided as built in options. If you did introduce ACS like this, you would configure your corporate ADFS server as an identity provider on your ACS instance alongside google, yahoo and what not, so that when your users browse to your site they will be prompted to select which identity provider they wish to sign in with.
Here's a fantastic whitepaper that demonstrates using ADFS to authenticate to cloud applications:
http://www.microsoft.com/download/en/details.aspx?id=13789
More detailed info about deploying ADFS (such as deploying the ADFS proxy) can be found in technet.
And for ACS, there are guides and samples on how to integrate it into azure applications, and how to add ADFS identity providers: http://msdn.com/acs
One thing that you could do is look at the user credentials when a page is requested in order to get the authentication info.
If you look at...
HttpContext.Current.User.Identity
You can get info about the user's identity. If they are on the domain you will see that they have a domain name and you could programmatically choose to direct them to a login page.
Let me also say that I've never tried to do this so I don't know if there's a built in way to do this by simply configuring something in web.config.