I am using ADFS to do federated logins with a number of different RPs, including our own custom web app, Office 365 and some other third-party services. I have run into a problem where logins silently fail when the wfresh=0 is specified in the URL. It just keeps asking for my password over and over again. When I click the "Login" button, it doesn't log you in and redirect you to back to the RP, nor does it fail and give you an error message. Instead, it redirects you back to the STS login page, so it looks to the user like it's silently failing.
I found this question: wfresh not working with WS-Federation via ADFS, which seems to be on the right track. However, while I am definitely seeing issues with integrated logins, I am getting similar issues with Forms logins as well. The outward symptoms are different, but the behavior seems to be the same: If you specify wfresh=0, it sends you directly to /adfs/ls.
Is there any way to configure ADFS to treat wfresh correctly, or at least to ignore it?
Update: Cross-posted to MSDN Geneva Forums: http://social.msdn.microsoft.com/Forums/vstudio/en-US/7acbbd11-cd69-466b-8faa-f129f24fe1fe/wfresh-parameter-causing-adfs-login-to-fail
Update: Microsoft today released their hotfix for this: http://support.microsoft.com/kb/2896713. It is not a public hotfix, so you will need to contact Microsoft support to get the update.
Previous: I spoke with an Escalation Engineer in Global Escalation Services for Microsoft. The EE said they are aware of this issue, tracking impacted customers, and working on a solution. Anyone who is experiencing this same problem should contact Microsoft support and open a support case so they are notified when the solution is available. Microsoft support is tracking this issue internally under solution id number 2879919.
I am seeing the same thing as of lately. We have connections with some RPs and also use Office 365. If I leave my machine logged into portal.microsoftonline.com it will eventually show "page cannot be displayed" with the URL showing the long string and "wfresh=0" at the end.
Externally, if i leave my browser logged into the portal it will take me back to the form but never accept my new credentials. If I change the value of "wfresh=0" to "1" it allows me back in external and internal. I'm trying to review event logs to see anything but have not found any clues. still looking.
Would it be a good or bad solution (if possible) to use MS IIS URL rewrite to replace or remove wfresh=0 from the URL when hitting the IIS?
Best would of course be if the default installation of ADFS worked with wfresh=0 in the first place :-)
IIS URL Rewrite1
Update:
My problem was that only internal clients experienced the error while external clients (using the ADFS proxy servers) did not.
With URL rewrite on the internal ADFS 2.1 servers and the following URL rewrite rule in /adfs/ls/web.config works:
<rule name="wfresh0to1" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{QUERY_STRING}" pattern="(.*)wfresh=0(.*)" />
</conditions>
<action type="Rewrite" url="{R:0}?{C:1}wfresh=1{C:2}" appendQueryString="false" />
</rule>
Related
I have a question regarding SQL Server Reporting Services 2019:
We have received a HTTPS-certificate and added a URL for both Web Service and Web Portal. When we try to access either /Reports or /ReportServer on HTTP we can get through with no problem, but when we try to access on HTTPS then we are met with a logon dialog which will give three attempts at log on before displaying a white page. All attempts at entering a valid combination of user name and password returns a 401 error.
We've tried removing and reinserting all bindings for HTTP, HTTPS, SSL, changing logon mechanism in the config file to use Kerberos, NTLM or a combination of those but nothing works.
Does anyone what the source of this problem might be and how to solve it?
We figured out what the problem was. Authentication issues did not behave the same for HTTP and HTTPS. My test user wasn't a member of the correct user group. Once we gave it "System User" access then we could log in.
First of, sorry for not posting any actual code, but I just want to be pointed in some direction. Might post code later if needed.
So, I have 3 applications running in IIS
1 - Application itself
2 - Authentication and Access Management
3 - NTLM
All use application pool with framework 2.0 Classic Mode.
1 and 2 uses annonymous and form authentication,
3 uses windows authentication.
The flow is, when you access 1 or 2, it redirects to NTLM for auth and returns with the authentication.
If I access the first one its all good, it goes to the ntlm and even if I dont have a valid windows account it returns to the app login page.
When I try to access the second one I get a redirect loop from the ntlm to the login page to the ntlm and so on...
Both have the same configuration.
I know this might not be very explicit, but I going insane over this and don't now where more to look.
Weird as it may sound, when setting the machineKey on web.config, I put decryption="Auto", which is totally normal... because it's the same setting in IIS console. But that was causing the error in event viewer saying invalid ticket.
Still can't figure out why... anyway if someone come across this same weird issue, here you have what I have done. I took out that "decryption" setting from web.config
I got a problem with OpenAM. Need your help.
I installed OpenAM and simply configured it as an IDP - set name and circle of trust. Then I added a remote SP by uploading SP metadata, see below
<?xml version="1.0" encoding="UTF-8"?>
<EntitiesDescriptor Name="urn:mace:shibboleth:testshib:two" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" mlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<EntityDescriptor entityID="http://192.168.0.6:8080/employee/">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol http://schemas.xmlsoap.org/ws/2003/07/secext">
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
</NameIDFormat>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://192.168.0.6:8080/employee/" index="1" isDefault="true" />
</SPSSODescriptor>
</EntityDescriptor>
</EntitiesDescriptor>
SP and IDP are in the same Circle of Trust.
When I do SAML request for auth from SP to IDP, I get to login page of OpenAM with SAMLRequest=... as URL params. Decoded SAMLRequest is below
<samlp:AuthnRequest AssertionConsumerServiceURL="http://192.168.0.6:8080/employee/"
Destination="http://192.168.0.7:8181/openam/" ForceAuthn="false"
ID="ID_479ff8a2-8dc5-44b5-997f-0438a2d87417" IsPassive="false"
IssueInstant="2015-01-07T13:31:01.067Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<saml:Issuer>http://192.168.0.6:8080/employee/</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
</samlp:AuthnRequest>
Then i do login and come to user profile page in OpenAM, instead of redirect to SP. Why it happens? What should I configure to enable redirect back to SP?
There are several things you could do:
Don’t use IP address when installing OpenAM, because cookies will not be saved on such addresses, so you can easily encounter weird problems like this.
If you have goto URL validation enabled (by default it'd disabled), then there were some old bugs around not handling redirect URLs correctly. Not sure which version you are using, so this may not really apply to you.
You should capture the network traffic with tools like LiveHTTPHeaders Firefox plugin or similar, so you can see how the HTTP requests go around. That should help you determine where exactly are things going wrong.
I have tried searching for this and can't find anything.
I want users to have a true SSO experience. Meaning they login to their computer and when they hit a web app that we have set up trust with in ADFS they are taken straight to that website. Right now no matter what they are taken to the ADFS forms login page. We only want the forms login page to appear if the user is not already connected to the network. Otherwise, ADFS should recoginize that the user is on the network and use the windows authentication.
What do I have to change in ADFS to make this happen?
In ADFS web.config, what order do you have for:
<localAuthenticationTypes>
<add name="Integrated" page="auth/integrated/" />
<add name="Forms" page="FormsSignIn.aspx" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>
Is Forms on top?
Are these users on the internet or intranet?
Do you use an ADFS proxy?
One option is to add a handler for the RedirectingToIdentityProvider event by placing the code just below this paragraph in your global.asax. This gives you a chance to jump in before the browser is redirected to ADFS and modify what the request (query string) looks like. You can do this to specify authentication types, or home realms (if you have multiple federations and want to skip HRD), and probably a lot of other stuff I don't know about.
void Application_Init()
{
FederatedAuthentication.WSFederationAuthenticationModule.RedirectingToIdentityProvider += new EventHandler<RedirectingToIdentityProviderEventArgs>(WSFederationAuthentication_RedirectingToIdentityProvider);
}
Then you would add code to your handler that might look something like this:
void WSFederationAuthentication_RedirectingToIdentityProvider(object sender, RedirectingToIdentityProviderEventArgs e)
{
WSFederationAuthenticationModule instance = FederatedAuthentication.WSFederationAuthenticationModule;
SignInRequestMessage request = instance.CreateSignInRequest(Guid.NewGuid().ToString(), instance.Realm, true);
request.AuthenticationType = "urn:federation:authentication:windows";
Response.Redirect(request.WriteQueryString());
}
When you set the request.AuthenticationType to that value, you're telling ADFS that you want to do windows (integrated) authentication. This was all that was required for me to get it to work. I didn't have to bother with switching the order of the authentication types in the web.config as nzpcmad suggested.
Also, for this to work, IIS and your web browser are working some magic outside of AD FS and your relying party, so in IE your users have to go to tools > Internet Options > Security and add the site to your Local Intranet sites. There's probably a way to push this out with group policies or something, but that's another question. Anyway, now that I think of it, this may be the only step you're missing.
I'm developing an intranet web app and I'm learning how to hook VB into the Active Directory. We're going to be doing some location specific permissions, and my boss wants (if possible) me to hook into the Active Directory to get the users location.
I think that all I need to do is get the user name, but I'm not sure what is the best way to do that. We're a Microsoft only shop, so IE and IIS are the order of the day. To access the intranet you have to log on to the computer using our domain, so that's one level of security, but then I need to authenticate and make sure that user has permissions to make the changes. I'm thinking we'll either have a modifier (if there's not one already) in the AD info, or keep a permissions table in a database, but the former is probably preferred.
I know that IIS has a feature that allows/requires authentication but I'm not exactly sure how that's supposed to work.
So what's the best/easiest/somewhat(most?) secure way to get the users credentials? I could always do a login page but it would be much nicer if I could just get their AD credentials in the background.
Thanks!
you need to disable anonymous auth for your IIS site and enable windows-auth instead.
now go to your web.config and change the following
<authentication mode="Windows">
...
</authentication>
see http://msdn.microsoft.com/en-au/library/532aee0e(v=VS.80).aspx
&
if neccesary
<identity impersonate="true" />
see http://msdn.microsoft.com/en-us/library/aa292118(VS.71).aspx
now you should be able to get the current user with
HttpContext.Current.User.Identity.Name
to check if the user is in a specific group you can use
HttpContext.Current.User.IsInRole("YourActiveDirectoryGroup")
IIS can be configured to use Integrated Authentication which will give you access to the samaccountname (pre-Windows 2000 logon) of the user. With that you can do an LDAP query against AD and check group membership. If the user is a member of the CanModifyStuffGroup (that you have created within AD and added users to) then let them make changes, otherwise give them the read-only version - or whatever.