ADFS 3.0 and non-claims aware application, authentication issues - authentication

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.

Related

How to configure a SAML 2.0 service provider for an ADF application

I have successfully configured a SAML 2.0 Identity provider in a separate Weblogic domain
We have an ADF application deployed in Weblogic in another domain with non-SAML form-based authentication (ReadOnlySQLAuthenticator is used to verify credentials)
I want to configure the second domain as a Service Provider (to enable the existing application to login with the Identity provider.
I did the folowing:
Configure a SAML 2.0 Identity Asserter
Enable the Service Provider in the federated services for the server
Add and enable the "service provider partners" and exchange metadata on both IDP and SP side
Configure the "redirect URI" on the SP side
Add the SAML 2.0 Authenticator (the documentation doesn't mention this, but some blogs do)
This should be enough to make the SSO work, but it doesn't.
opening the application doesn't trigger a redirect to the IDP (even when the URL is configured in the provider partner config)
after logging into the application, other applications still have to log in with the IDP (SSO doesn't work)
The "other application" is the Spring SAML sample application and I verified that SSO works with 2 different instances of that app (which means the IDP side should be configured correctly).
We've had some Oracle experts come over to our company to solve various issues.
In the end even they could't help with this and suggested that SAML support may not really work that well.
They suggested that we try to use Oracle Access Manager, that's supposed to support both OAUTH and SAML. We didn't get to that yet and maybe never will.
Still if you need SSO in Weblogic, you could give it a go.

Always error authenticating through ADFS 2.0

I've managed to setup two virtual machines in my local windows 7 laptop. Both of them are Windows server 2008 R2. One acts as Active Directory Domain controller and also as Active Directory Federation Services, and one other as the web app server. This second one is where I've set up my claims aware asp.net mvc web application and I also plan to setup ThinkTecture Identity Server later as my way to authenticate against custom username and password outside AD.
I've successfully implemented the installation and configuration needed for connecting our ASP.NET MVC apps through ADFS. They include :
Configure first server as Domain Controller and add domain account store (add user as testing -> this user belongs to Domain Users Group).
Configure first server also as active directory federation services.
configure relying party trust identifier from federation metadata generated from FedUtil.exe in second server.
Configure group claim mapping and assign Domain Users to this group.
Configure web apps server to be claims aware agent.
The one that's always troubled me is that every time I access my apps, it successfully prompts login dialog box. Once I enter My AD account and password, it always gives me the following error message : "There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Reference number: c558ed55-b203-42cc-b6bd-3d66bddb96cd".
Any idea from you guys how to get this to work?? Any suggestion and ideas will be highly appreciated.
Have you looked in the event log?
Open Event Viewer > Go to Applications and Services Logs > AD FS 2.0
You'll see an list of errors which should give you some more guidance.
If you see the ADFS login screen, you can get to ADFS so I suspect it's something to do with your RP configuration.
Just to check - you are using ADFS 2.0 which you downloaded?

Unable to setup ADFS on different domain and mvc app with window auth on different domain

My MVC 4 application (https://testapp.com) with WIF and windows authentication is on Domain A and my ADFS and users are on domain B.
Requirement: Users in Domain B will browse my application https://testapp.com which is hosted in Domain A and my application should use their local windows user creds and redirect to the ADFS in Domain B.
I believe I dont require a AD cross Domain trust between A and B and that is what ADFS and SAML authentication is meant for.
I dont see such much materials for reference in such scenarios also. Kindly help understand how to configure such an MVC application in Domain A.
You need to establish a trust between your MVC4 application and your ADFS. In ADFS lingo this is called "Relying Party". You will need to have an endpoint in your application that accepts a HTTP POST message and processes the payload generated by ADFS.
I had to recreate these a long time ago but you can spare the pain. There are more options available -
http://saml2.codeplex.com/ (open source)
http://www.componentspace.com/Products/SMLv20.aspx
Configuring ADFS can be tricky but there are lot of guides out there.

How to configure Identity Provider (IP-STS) with ADFS?

I am attempting to set up a test configuration for IdentityProvider(IP-STS)-Initiated SSO using ADFS 2.0 as my RP STS and a Active Directory identity provider. Here is my set up:
Identity Provider - Domain Active Directy
RP-STS - ADFS 2.0 instance with an RP trust relationship with my asp.net application.
RP Application - ASP.NET web application (WIF) with an STS reference to my ADFS 2.0 STS.
I know I need to create some kind of trust between ADFS and my IP but I don't know what that might be. My issue is I can't find any good resources for instructions on how to do this. Most of what I find assumes that ADFS is also the Identity Provider and is configured. I am not finding the right resources
please any one help me with right example.
Thanks,
sampath.
When you say "Identity Provider - Domain Active Directory", what IP are you using?
AD is not an IP?
ADFS (which uses AD as its repository) is.
When you install ADFS it "binds" to the AD DC in the domain - that's the trust relationship. You don't need to do anything explicit.
If you indeed have another IP, then you set up a CP / RP relationship between the two IP with the normal metadata exchange.
Yes, AD is an IP(Identity Provider).
I've Installed ADFS in one machine(VM), and my Identity Provider(Ipd) is in another VM.
Now i want to establish trust relationship between these two.
you are saying When you install ADFS it "binds" to the AD DC in the domain - that's the trust relationship means I need to setup ADFS and AD DC in the same machine(VM)?
i have another IP, then how to set up a RP relationship between the two IPs with the normal metadata exchange?
i've added the AD DC as relying party trust in adfs. but getting the following error
*HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Module IIS Web Core
Notification MapRequestHandler
Handler StaticFile
Error Code 0x80070002
Requested URL
Physical Path C:\inetpub\wwwroot\ClaimsApp_STS\
Logon Method Anonymous
Logon User Anonymous*
Thanks,
Sampath.

Cannot open database "our database" requested by the login. The login failed. Login failed for user 'ADUser'

We are rolling out our first .net 4.0 entity framework application and are having an issue with security.
We have it working on our alpha site inside our development environment with the following setup:
SQL2005
IIS6
.NET 4.0
asp.net mvc 2
Entity Framework
NTLM
But when we moved it to our production environment for beta testing we are getting the following error via asp.net
SqlException (0x80131904): Cannot open
database "our database name"
requested by the login. The login
failed. Login failed for user
'Domain\User'.
The only difference between the between the 2 environments is we are using Kerberos instead of NTLM in our production environment. We have several other .net 3.5 sites using LinqToSql that run on both environments.
We have already done the following:
Replaced an active user on another test site with the user that is failing to make sure it isn't an issue with the way the user is set up. - worked
Dropped and re-added the user from sql2005 - did nothing
The issue appears to be related to .net 4.0 as this is our first...
The difference between NTLM and Kerberos is huge. With NTLM, you can use pass-through authentication with Kerberos you cannot. With Kerberos and Windows Authentication, you need to setup a Service Principal Name (SPN for short) that tells SQL Server that it can be accessed by whatever IIS account you use.
Understanding Kerberos and NTLM authentication in SQL Server Connections
Here's another article on setting up Kerberos. Jump down to the section titled "Configure a service principal name for the domain user account"
Based on the error message, 2 questions:
Does the login have access to the database in your production site?
Does the database that you specified in the connection string on the SQL server that is specified in the connection string?
These are the 2 most common causes of that issue. A Kerberos issue usually manifests itself in SQL Server a little differently.
Thanks,
Eric