SPNEGO and Windows 7: POST and GET-parameters lost during authentication

[former_member292569]

Hi,

we are trying to implement SSO on a portal system using spnego. As there is the requirement to have an optional logon with uid and password we created an external logon page that has two forms. One form consists of three invisible parameters:

<input name="login_submit" type="hidden" value="on">
<input type="hidden" name="login_do_redirect" value="1"> 
<input name="j_authscheme" type="hidden" value="spnego">

The second form passes the same variables but with j_authscheme set to z_uidpw and additionally the fields j_user and j_password. spnego is not the default logon stack to make sure that there is no sso with the windows user if a wrong uid or password is entered in the second form.

This configuration leads to the following problem:

On a Windows XP-Client the form data (including j_authscheme=spnego) is still in http header, when using POST as method, or appended to the URL, when using GET, on the second access to the J2EE (after the 401 with header WWW-Authenticate: Negotiate) and SSO works perfect.

On a Windows 7-Client the form data gets lost on the second request (after 401 unauthorized) leading to the situation, that the default logon stack (that doesn't support spnego) is used on the second request and the spnego-token is ignored.

Any suggestions on that problem?

Thanks and kind regards,

Jens

[martin_voros]

What's the IE version on each box? I assume that it will be related to browser. It might be some security feature that prevents disclosing form values to different URLs. Have you tried with Firefox?

Cheers

[martin_voros]

What's the IE version on each box? I assume that it will be related to browser. It might be some security feature that prevents disclosing form values to different URLs. Have you tried with Firefox?

Cheers

[former_member292569]

Hello,

the issue has been solved by enabling DES_CBC_MD5 for Kerberos in the

local security policy for the clients:

Security Settings --> Local Policies --> Security Options -->

Network security: Configure encryption types allowed for Kerberos

Best regards,

Jens

[Former Member]

Hello,

Be aware that DES is considered completely outdated because it is no more secure enough.

For exemple, in my company, the security team forbids the use of Kerberos with DES.

Only AES or RC4 are allowed.

Regards,

Olivier