Windows Authentication Scheme from Level 4 to Level 5

[Anon Anon]

I have an application(A) protected with Windows Auth Scheme template , the auth level for scheme is Level 4.

I have a requirement where uses accesses this application and then accesses other application(B) protected with Windows Auth Scheme with Auth Scheme Level 5.

 

What im facing is that, once user is successfully logged and accesses application A but when navigating to application B, user gets prompted with windows prompt.

Is this expected behavior?

Both apps protected with Windows Auth(connected to same AD Domain), so ideally user should not be prompted with windows prompt as NTLM authN is failing which should not happen.

Does auth scheme level in two Windows Auth Scheme prompt the user with Windows credentials??

[Karmeng]

Hi,

The windows prompts means the IIS web server negotiation with the AD failed and that's why you get the prompt.

Is the user has access to both application? Are both application point to same AD user store?
Header trace will give more information on what happen when user navaigate from application A to application B.

 

Thanks.

Kar Meng

[Anon Anon]

Thanks Kar for the response.

Yes user has access to both applications. On the side note, there are no authorization rules , so ideally if user getting windows prompt then its not enforced by Siteminder certainly NTLM auth is failing.

And yes both applications pointing to same user AD user store. We opened case with CA and CA advised to put "EarlyCookieCommit =YES" in the ACO, we are testing with this fix but not sure if this will fix.

 

As this seems to be more of a Windows Auth issue rather tha Siteminder.

Can you please let me know how SIteminder will behave when two auth schemes(Windows Auth Scheme) are level 4 and level 5 ?

 

I will keep posted if the ACO parameter fixes the issue or not.

 

Thanks

[Karmeng]

Hi lavsinha

In general, when two resources protected by two authentication scheme that have different protection level, the SMSESSION cookie need to be updated to reflect the protection level. In your case, I don't expect to see a challenge (due to Windows authentication sheme) as the IIS web server negotiate at the backend with AD to get the user information when user navigate from level 4 to 5.

Siteminder kicks in when the negotiation complete and the user information (ie: Domain\uid) will pass to policy server for following process. From header trace log, I would expect to see few 401 when IIS web server negotiate with AD.

 

If you navigate from level 5 to level 4, did you experience any issue?

 

Thanks.

Kar Meng

[Anon Anon]

Thanks for the clarification, even im with you that NTLM negotiation failed that's why user gets prompted. Leve 5 to Level 4 is ok, there is no issue. Even we tested with all other schemes(html, custom,2 factor, basic) they work as expected.

Issue is only with IWA auth scheme.

 

We could capture one successful and one failure request as out of many requests, one request passes where user does not get prompted for windows prompt and he is taken to next level.

Compared the web agent trace logs on web server, i see only following difference in the logs.

For successful request, i see generated NTLMCRED cookie. Does this log make any sense??

 

dvancedAuthCore.cpp:162][SmAdvancedAuthCore::GatherCredentials][00000000000000000000000001000000-2eb0-561fcc4d-356c-037a68db][*172.26.41.183][][/][][Validating target for 4.x compatibility mode.]

[10/15/2015][10:54:53][11952][13676][SmAdvancedAuthCore.cpp:933][SmAdvancedAuthCore::validateTargetDomain][00000000000000000000000001000000-2eb0-561fcc4d-356c-037a68db][*172.26.41.183][][][][][Target's c and agent configured match.]

[10/15/2015][10:54:53][11952][13676][SmAdvancedAuthCore.cpp:202][SmAdvancedAuthCore::GatherCredentials][00000000000000000000000001000000-2eb0-561fcc4d-356c-037a68db][*172.26.41.183][][][Credential Collector using 4.x compatibility mode.]

[10/15/2015][10:54:53][11952][13676][SmNTC.cpp:545][SmNtc::processCompatMode][00000000000000000000000001000000-2eb0-561fcc4d-356c-037a68db][*172.26.41.183][][][][][Generated NTLMCRED cookie.]

[10/15/2015][10:54:53][11952][13676][SmPluginUtilities.cpp:481][HandleCredCollectorReturn][00000000000000000000000001000000-2eb0-561fcc4d-356c-037a68db][*172.26.41.183][]][][POST preservation, handling return from credential collector.]

[10/15/2015][10:54:53][11952][13676][SmPluginUtilities.cpp:618][HandleCredCollectorReturn][00000000000000000000000001000000-2eb0-561fcc4d-356c-037a68db][*172.26.41.183][]][][http response ]

[Karmeng]

Hi,

Based on your update, it seems the issue is intermittent. For the snippet of log of success request, I didn't see any problem as it is generated the Siteminder session cookie. In fact, the header trace should able to give more information on what happen during the fail request compare to success request.

Regards,

Kar Meng

[wonsa03]

Hi lavsinha

 

There is an known issue pertain to the step-up IWA with R12.51 and R12.52 webagent.

 

As part of ntc processing by the webagent, it compares the user authenticated by the IIS (since this is NTLM authentication) with the user passed in the CHALLENGE query string. If they matched, we throw the NTLM challenge again. In the NTLM Challenge box, if the credentials for the same user are provided we repeat the above process and end up with the challenge again. Hence, user is running into an infinite loop upon accessing step-up authentication with IWA. Providing credentials of a different user will not cause this issue.

 

Tentatively, the fix will be made available with R12.51 CR8 and R12.52 SP1 CR4 webagent releases.

[Anon Anon]

Hi,

 

Thanks for your reply,

You mean to say there is know issue with IWA authentication when navigating from Level 4 Auth IWA Scheme to Level 5 Auth IWA Scheme.

The scenario we tested was user logs into application with Level4 Auth scheme, gets authenticated and on the same browser if accessing another application protected with Level 5 Auth Scheme web server sent HTTP 403 forbidden error. On refreshing the browser, Windows Prompt again comes up. Is this expected behavior, we are using 12.52 CR01 web agent.

 

Can you let me know if this issue is not surfaced with any lower web agents like 12.50, i can try protecting app with 12.50 web agent also

[wonsa03]

Hi lavsinha,

 

The known issue is pertain to Windows Authentication Scheme, the problem was first reported against R12.51 release. Hence, I'm not too sure if R12.5 webagent release has the same issue or not.

[Anon Anon]

Thanks. Your post really helped us in nailing donw the issue.

We had opened a case with CA, and they also confirmed us that this is an existing issue with Windows auth scheme for 12.52 cr01 web agents.

 

Thanks again