Product:TIBCO Spotfire Server
Versions:All Versions
Summary:
This article helps understand why Kerberos authentication doesn't fall back to NTLM when login fails for the user machines that are not part of domain.
Details:
Some of the common questions that we get are:
1) Kerberos authentication fails when accessing Spotfire via the browser on machines which are not part of the Windows domain. With NTLM, this was not a constraint.
2) If the primary authentication fails through Kerberos, then Spotfire throws an error rather than falling back to NTLM. Can Spotfire be configured to fallback to NTLM when kerberos authentication fails?
3) Why is it that using MS Edge browser on a Windows workgroup machine we get prompted to enter username & password, following which we can access the Spotfire visualization successfully? This is in contradiction to the statement "All machines must belong to the AD domain to access Spotfire with Kerberos authentication".
Resolution:
When a web server challenges a client with "WWW-Authenticate: NTLM", it requests the client to authenticate using NTLM over the NTLMSSP protocol. When a web server challenges a client with "WWW-Authenticate: Negotiate", it requests the client to authenticate using Kerberos or NTLM over the SPNEGO protocol. On Windows, SPNEGO is often called "integrated authentication".
TIBCO Spotfire Server only supports NTLM authentication over NTLMSSP. TIBCO Spotfire Server does not support NTLM authentication using SPNEGO.
If a TIBCO Spotfire Server is configured for NTLM authentication, it will challenge the client with "WWW-Authenticate: NTLM" and expect it to authenticate using NTLM over NTLMSSP. If a TIBCO Spotfire Server is configured for Kerberos authentication, it will challenge the client with "WWW-Authenticate: Negotiate" and expect it to authenticate using Kerberos over SPNEGO. If a client cannot retrieve all the information that is necessary for using Kerberos authentication, it will either fail authentication or fall back to using NTLM over SPNEGO. With TIBCO Spotfire Server, the fallback attempt will also fail as the server does not support NTLM authentication using SPNEGO.
Coming to the Questions
* Authentication fails when accessing Spotfire via the browser on machines which are not part of the Windows domain. With NTLM, this was not a constraint
A client that is not part of a Windows domain can actually use Kerberos authentication as long as it has access to all necessary information. See the last bullet below. The client does not need as much information to use NTLM as it needs in the Kerberos case.
* If the primary authentication fails through Kerberos, then spotfire throws an error rather than falling back to NTLM. Can Spotfire be configured to fallback to NTLM when kerberos authentication fails?
This use case is not supported as IBCO Spotfire Server does not support NTLM authentication using SPNEGO. No, we do not have such feature.
* Why is it that using MS Edge browser on a Windows workgroup machine we get prompted to enter username & password, following which we can access the spotfire visualization successfully? This is in contradiction to the statement "All machines must belong to the AD domain to access spotfire with Kerberos authentication".
If the end user, on a computer which is not part of a Windows domain, uses Microsoft Edge or Google Chrome to access the TIBCO Spotfire Server, Kerberos authentication will typically work assuming the end user provided a fully qualified username in the form "user@sub.domain". If the username is provided in the form "SUBDOMAIN\user", the client will typically not know which domain controller it needs to contact and Kerberos authentication will not be possible. Unfortunately, it seems Mozilla Firefox does not prompt end users for credentials when running on a computer in a Windows workgroup and being challenged with "WWW-Authenticate: Negotiate".
Versions:All Versions
Summary:
This article helps understand why Kerberos authentication doesn't fall back to NTLM when login fails for the user machines that are not part of domain.
Details:
Some of the common questions that we get are:
1) Kerberos authentication fails when accessing Spotfire via the browser on machines which are not part of the Windows domain. With NTLM, this was not a constraint.
2) If the primary authentication fails through Kerberos, then Spotfire throws an error rather than falling back to NTLM. Can Spotfire be configured to fallback to NTLM when kerberos authentication fails?
3) Why is it that using MS Edge browser on a Windows workgroup machine we get prompted to enter username & password, following which we can access the Spotfire visualization successfully? This is in contradiction to the statement "All machines must belong to the AD domain to access Spotfire with Kerberos authentication".
Resolution:
When a web server challenges a client with "WWW-Authenticate: NTLM", it requests the client to authenticate using NTLM over the NTLMSSP protocol. When a web server challenges a client with "WWW-Authenticate: Negotiate", it requests the client to authenticate using Kerberos or NTLM over the SPNEGO protocol. On Windows, SPNEGO is often called "integrated authentication".
TIBCO Spotfire Server only supports NTLM authentication over NTLMSSP. TIBCO Spotfire Server does not support NTLM authentication using SPNEGO.
If a TIBCO Spotfire Server is configured for NTLM authentication, it will challenge the client with "WWW-Authenticate: NTLM" and expect it to authenticate using NTLM over NTLMSSP. If a TIBCO Spotfire Server is configured for Kerberos authentication, it will challenge the client with "WWW-Authenticate: Negotiate" and expect it to authenticate using Kerberos over SPNEGO. If a client cannot retrieve all the information that is necessary for using Kerberos authentication, it will either fail authentication or fall back to using NTLM over SPNEGO. With TIBCO Spotfire Server, the fallback attempt will also fail as the server does not support NTLM authentication using SPNEGO.
Coming to the Questions
* Authentication fails when accessing Spotfire via the browser on machines which are not part of the Windows domain. With NTLM, this was not a constraint
A client that is not part of a Windows domain can actually use Kerberos authentication as long as it has access to all necessary information. See the last bullet below. The client does not need as much information to use NTLM as it needs in the Kerberos case.
* If the primary authentication fails through Kerberos, then spotfire throws an error rather than falling back to NTLM. Can Spotfire be configured to fallback to NTLM when kerberos authentication fails?
This use case is not supported as IBCO Spotfire Server does not support NTLM authentication using SPNEGO. No, we do not have such feature.
* Why is it that using MS Edge browser on a Windows workgroup machine we get prompted to enter username & password, following which we can access the spotfire visualization successfully? This is in contradiction to the statement "All machines must belong to the AD domain to access spotfire with Kerberos authentication".
If the end user, on a computer which is not part of a Windows domain, uses Microsoft Edge or Google Chrome to access the TIBCO Spotfire Server, Kerberos authentication will typically work assuming the end user provided a fully qualified username in the form "user@sub.domain". If the username is provided in the form "SUBDOMAIN\user", the client will typically not know which domain controller it needs to contact and Kerberos authentication will not be possible. Unfortunately, it seems Mozilla Firefox does not prompt end users for credentials when running on a computer in a Windows workgroup and being challenged with "WWW-Authenticate: Negotiate".
Comments
0 comments
Article is closed for comments.