Skip to main content

After enabling ADFS, Aurena is working as expected but Enterprise Explorer is not working.

User logon to EE get a Bad Request 400 and detail log showing this:

Ifs.Fnd.AccessProvider.Interactive.FndLoginDialog.AuthenticateCredentials(FndLoginCredentials loginCreds) ---> System.Net.WebException: The remote server returned an error: (400) Bad Request.

 

 

Debugging network traffic will not give any clue what's happening, not even Fiddler will give you anything.

To see whats happening on the middleware, change the log level to Trace

Enabling trace log on the HTTP server, logon to the Server Admin Console and change:

 

On the middleware server go to the following directory

>instance home]\wls_domain\ainstance]\servers\HttpServer1\logs

open httpserver1.logs

the following will be showed, simplest to search for this

AH00561: Request header exceeds LimitRequestFieldSize: Authorization
AH00567: request failed: error reading the headers

 

This error is due to that the user is a member of a large set of Active Directory groups and the HTTP request header files have a standard limit of 8k. 

To overcome this change the Limit Request Field Size from standard 8190 to 32760

 

 

Press Save and Restart service

 

Tell the user to logon to EE.

Don´t forget to set logging to Warning.

 

/Karl

 

 

Thanks for the info @karllinder 

Would this have a potential downside, and if so, what?  We haven’t seen this error yet but we are still rolling out Apps10…. I’m wondering whether there would a risk or any problem with implementing this now to be proactive.

Thoughts?

Nick

Hi @NickPorter 

The downside that I can think of is a DDoS attack, but normally you put a reversed proxy in front of IFS if you plan to publish it on the Internet.

But if you don´t have any issue I would recommend to leave the default value.

/Karl

Hi@karllinder ,

We recently had the same issue with another customer. There were some users which had connected to 250 - 650 Windows-User-Groups.

The parameter ‘Limit Request Field Size’ is not an IFS specific parameter. It is a standard HTTP configuration. Please refer the following article we found on the internet:

https://www.fabasoft.com/en/support/knowledgebase/bad-request-size-request-header-field-exceeds-server-limit

We also had a discussion with IFS PD as well. In ADFS, user groups are considered as “claims” in access tokens and it adds length to the token which is sent in the Authorization header in HTTP. When the claims part contains many user groups, the size of the token is increased. If tokens are too large, the OHS cuts them due to, it only having a certain amount of characters allocated for Authorization HTTP headers, hence ends up with a 400-error. Therefore, we recommended them to increase the “Limit Request Field Size”.  

Later, the customer had found another possible workaround to avoid this. According to the information we received,

The issue was with the claim rule "All Claims". This rule asks for a token with all windows-user-groups. They have changed it to a claim rule, which only returns the LDAP Attributes "User-Principal-Name" and “SAM-Account-Name” without any Windows user groups.

Your feedback on this?

 

Best Regards,

Isuru

Hello. I think both solutions are viable options if you do run into the problem.

The ADFS setup in the documentation is very simplistic and returning only the relevant claims is a viable alternative also. The ADFS parts of the IFS technical documentation should be seen as a reference example. It is by no means an exhaustive list of everything you can do with ADFS. Having a more intricate ADFS claim rule setup than described in the documentation will reduce token size, which might make more sense than expanding the request header field size. But most of the time, you could go with either solution.

It’s possible that SAM-Account-Name can also be omitted from the tokens (IFS checks identity on the “upn” claim from ADFS which usually contains User-Principal-Name), but I haven’t tested that personally.

For most installations, we do not see this problem occurring at all.

I’ve seen something very similar happen with Apps 9 SSO once also. In that case, it could be solved by expanding the header field size.

Best regards, Björn.

Thank you for the update @Björn Kihlström 

Reply


Terms & ConditionsCookie settings