I'm totally baffled about the interface to ADFS 2.1 in Windows Server 2008 R2. I've installed the Active Directory Federation Services with the Claims-aware Agent. However, I cannot figure out how to add a relying party trust, as I can in ADFS 2.0.
When I look at the ADFS management tool, I see only:
Active Directory Federation Services
Federation Service
Trust Policy
My Organization
Organization Claims
Account Stores
Applications
Partner Organizations
Account Partners
Resource Partners
I don't see the old tree:
AD FS 2.0
Service
Endpoints
Certificates
Claim Descriptions
Trust Relationships
Claims Provider Trusts
Relying Party Trusts
Attribute Stores
I know I'm missing some concept somewhere, but not sure where. Any help would be appreciated.
Somewhat confused by your question?
ADFS 2.1 only runs on Server 2012.
The word "agent" makes me think that you have loaded ADFS 1.0 which is the default on Server 2008 R2.
ADFS 2.0 is a seperate download.
Related
For a 1 day project (call it a hackathon) we will be looking into replacing a custom built authentication and authorization system with one that we can buy.
After all, there are people who are better at this stuff than we are.
Non-cloud, hard requirement is on-premise installation possible
Can authenticate against Active Directory using LDAP
Can authenticate using SAML against ADFS
Management of users, roles etc without a directory is an option (most likely option to actually use during the hackathon)
Use open standards, SAML, OpenID, OAuth2
There are so many SAML-based products, but many are cloud-only, which unfortunately for us is not an option (reason: our products run on closed enterprise networks), so services like Okta are unfortunately not an option :(
The following list is quite complete, but doesn't give me any indication on how hard it is to install + get up and running in a few hours:
https://en.wikipedia.org/wiki/SAML-based_products_and_services
Any suggestions for products to try?
My eye caught these ones:
miniOrange, Ping Identity, 10duke
[addition]
I am using a Java stack for web apps.
How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building a SAML-based Authentication/Authorization Provider using Shibboleth SAML IdP and OpenLDAP.
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
I have validated SAML Single Sign-On (SSO) provided by Docker-running Shibboleth SAML IdP (Identity Provider) and OpenLDAP for the following enterprise applications. In other words, I leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to the following enterprise applications successfully.
Microsoft Office 365
Google G Suite
Salesforce
Dropbox
Box
Amazon AWS
OpenStack
Citrix NetScaler
VMware vCloud Director
Oracle NetSuite
Another StackOverflow question Setting up a new Shibboleth IdP to work with an existing SAML SP discusses the SAML configuration between IdP and SP.
OpenLDAP is not OpenID Connect or OAuth 2.0
Have a look at identityserver4.
It's OpenID Connect / OAuth2 by design and it does have a plug-in SAML stack.
Or if you have a Windows server, use ADFS.
FOSS - Shibboleth or KeyCloak
The definition of 'closed' (network) might be interesting to examine. No access to outside at all, not on any port, noway/nohow? In that case, yes, you want an on-prem service. If there's gated access to outside, it's likely that many hosted identity services could work.
We are trying to federate our application, so that our customers can gain to our application using their respective corporate identities (Ping Identity or their ADFS server).
The web application is non-claims aware and we are trying to find out a solution to federate it without changing the code.
I built an ADFS 3.0 environment with windows server 2012 R2 simulating a future scenario, following my lab environment:
Our side:
1 Active Directory server (domainB)
1 IIS8 web server with our non-claims aware applications (Windows Integrated Authentication supported by Kerberos mechanism) joined on domainB
1 ADFS 3.0 server (service provider) joined on domainB
1 WAP server joined on domainB
Customer side:
1 Active Directory (domainA)
1 ADFS 3.0 server (identity provider) joined on domainA
Application users:
domainB\user1
domainA\user2
I followed these steps to build my lab environment:
Installation and configuration of ADFS 3.0 on domainB
Installation and configuration of WAP server on domainB
Publish ADFS 3.0 on WAP server on domainB
Create a Non-claims aware Relying party Trust pointing the application on ADFS 3.0 on domainB
Publish the Non-claims aware to WAP on domainB
Installation and configuration of ADFS 3.0 on domainA
Trust ADFS 3.0 on domainB with ADFS 3.0 on domainB
Edit claim rules on each federate server
The “domainB\user1” has no problem to access to the application, in my WAP server there are the following events:
Web Application Proxy successfully retrieved a Kerberos ticket on behalf of the user.
Web Application Proxy received an HTTP request with a valid edge token.
The “domainA\user2” cannot access and appears a server error on the screen and in the WAP Event Viewer there are the following errors:
Warning: EventID 13019
Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: The user name or password is incorrect.
(0x8007052e).
Error: EventID 12027
Web Application Proxy encountered an unexpected error while processing the request.
Error: The user name or password is incorrect.
(0x8007052e).
Seems to be an issue with the Kerberos authentication but the domainB\user1 has no problem to access to the application.
Need to understand:
Where is the issue?
Accessing to the non-claims aware applications are supported by only the users members of the same domain of the web application server
I’m spending many days to find out the cause.
Appreciate any direction here.
Thanks
Given that "non claims-aware" apps make WAP+ADFS use WIA, and WIA requires Kerberos, you need to issue a Kerberos token on WAP-B for "domainA\user2", this in turn requires setting domain/forest trusts between domainA and domainB (domainB should trust domainA, at least). I don't see domain-level trusts present, only ADFS-level, therefore Kerberos domain domainB says "unknown user domainA\user2". Check if enabling trusts between domainA and domainB would resolve the issue.
You need Kerberos shadow principals in domain B for users in domain A who will be accessing the application. It is a similar situation to azure B2B guest users accessing an application through azure application proxy. This is a walkthrough for setting that up with sync from Azure (https://learn.microsoft.com/en-us/azure/active-directory/b2b/hybrid-cloud-to-on-premises). It would be similar for your case, except you'd need to replicate the users from their directory.
I've been scratching my head over this issue for over a week. We have a web app that we would like to implement SSO for. SSO with windows active directories of our clients (i.e. we essentially need to authenticate against our clients' active directories without much trouble)
The only thing I am 100% sure about is that I will needed a security token service that will have to communicate with an Identity Provider. My question:
Which service is most suitable for the above scenario (AD FS? OpenID & OAuth 2.0? SAML 2.0 and shibboleth?)
How will I connect to the active directories of the clients? Maybe I'm not understanding how the STS is to be used, could anyone clarify? I'm working with an Azure Web App
Will there have to be a different IdP for each client? Will the client have to do more than just give us standard information? What would this info be?
...should I be using Windows Identity Foundation?
HELP :( ... this is an SOS
If anyone could clarify at all, I will forever be grateful. I normally upvote anything I find helpful and accept whichever answer is the best so feel free to answer with what you think might be useful in helping me understand how I can achieve what I am after.
These are the three options I know:
As you mention one option is ADFS this solution means that your customers should install and expose Adfs. ADFS means Active directory-Federation Services, so in this case your application needs to speak WS-Fed (not oauth). Typically if the user is inside the LAN adfs uses integrated auth, if not it will prompt credentials.
WAAD is a new service from Azure, it allows companies to expose their directories to use in cloud applications. With this approach your customers need an account in Azure, create a directory and use the dir sync agent. Your application will talk SAMLP with WAAD.
Auth0 is an authentication broker that allows developers to use social but also enterprise identity providers like AD but also google apps, waad, adfs, salesforce, etc. if your customer only has AD you will provide him an msi for a windows service, that will bridge the company AD with your auth0 account, you can have as many AD as you want. Your application speak oauth with Auth0. This agent supports kerberos authentication as well. The following graph explains this solution:
Disclaimer: I work for Auth0.
WIF doesn't support SAML or OAuth.
Your application is in Azure.
Suggest add WIF to the application and then "bind" to Azure Active Directory. In VS 2013, use the "Change Authentication" feature for this.
Make the application multi-tenanted.
Each customer has their own tenant. User DirSync to sync. each customer AD with their AAD tenant. (That gives same sign-on). Adding ADFS to each customer gives single sign-on.
However, the customers will probably push back on this because of perceptions around security.
Planning to use ADFS to federate. One big challenge that we find is that not all applications are claims aware, also every application has a different role based access. In such a how can we achieve 100% SSO Authentication and Authorization using Identity Claims.
In case ADFS cannot support such a requirement, What other vendor solutions are available which can supports such a requirement.
A claims-aware application in the .NET world uses WIF / WS-Federation to get a set of claims in a SAML token which are then used to control user access and functionality.
ADFS only answers to WS-Federation or SAML requests.
So to get a non claims-aware application to use AFDS, the application needs to be changed to add support for either of these protocols.
Refer: SAML : SAML connectivity / toolkit and the links inside the post.
Or you could go the other way and put something like an OpenAM agent around the applications and then federate OpenAM and ADFS.
ADFS on Server 2012 R2 has a new feature as part of the Web Application proxy, refer Create a Non-Claims-Aware Relying Party Trust.
There's a walkthrough here - Walkthrough Guide: Connect to Applications and Services from Anywhere with Web Application Proxy
and a good example here - First Impressions – AD FS and Window Server 2012 R2 – Part II.
Our application uses federated single sign-on authentication process and we already have our identity provider set, up and running. I have the application instance running too, that I would like to integrate to MS CRM using our IdP for authentication.
Do you know if I could get, somewhere, steps on what I should do to set MS CRM to use our IdP (upload our idp.xml ...), I didn't manage to find anything on the CRM official sites?
Our IdP is ForgeRock OpenAM and SAML should be used for communication.
Is it possible at all to use other IdPs but ADFS with MS CRM?
Thank you for the time spent on replying!
I don't know if the CRM STS supports SAML directly - if it's similar to the SharePoint STS, it doesn't.
The easiest way is to configure CRM with ADFS in the normal way and then federate ADFS with OpenAM. ADFS has full SAML support.
Note that you need to use OpenAM's federation functionality.