Forum Discussion

cgallimore_1748's avatar
cgallimore_1748
Icon for Nimbostratus rankNimbostratus
Jan 12, 2016
Solved

APM Question: Is Multiple-Domain NTLM authentication possible for one URL domain?

We currently have an access profile setup to have a user select their domain from a dropdown menu on the login page. We are also using SSO Across Authentication Domains on the access profile and for ...
application delivery
BIG-IP Access Policy Manager (APM)
LTM
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Jan 12, 2016

    I'm pretty sure it's not possible to detect the domain prior to using ECA when using NTLM passthough. When ECA is utilized, it must be turned on with a specific ECA profile that's already connected to a specific already-established SCHANNEL connection.

     

    However, I think it's possible to establish a trust relationship so that one DC can use its own SCHANNEL connection to a different domain's DC to use passthrough authentication. This MSDN blog article talks a bit about it:

     

    http://blogs.technet.com/b/isrpfeplat/archive/2010/11/05/optimizing-ntlm-authentication-flow-in-multi-domain-environments.aspx

     

    Microsoft would probably be able to help in this situation if you aren't sure how to set up the trust. The important thing to understand is that APM uses NTLM passthrough authentication via SCHANNEL from the (configured in APM) NTLM Authentication Profile.

     

    One other thing: When using NTLM Passthrough, APM does not have access to the user's password (this is a limitation of the encryption used in the NTLM protocol), so SSO types that rely on it won't function correctly.

     

Lucas_Thompson_'s avatar
Lucas_Thompson_
Historic F5 Account
Jan 12, 2016

I'm pretty sure it's not possible to detect the domain prior to using ECA when using NTLM passthough. When ECA is utilized, it must be turned on with a specific ECA profile that's already connected to a specific already-established SCHANNEL connection.

 

However, I think it's possible to establish a trust relationship so that one DC can use its own SCHANNEL connection to a different domain's DC to use passthrough authentication. This MSDN blog article talks a bit about it:

 

http://blogs.technet.com/b/isrpfeplat/archive/2010/11/05/optimizing-ntlm-authentication-flow-in-multi-domain-environments.aspx

 

Microsoft would probably be able to help in this situation if you aren't sure how to set up the trust. The important thing to understand is that APM uses NTLM passthrough authentication via SCHANNEL from the (configured in APM) NTLM Authentication Profile.

 

One other thing: When using NTLM Passthrough, APM does not have access to the user's password (this is a limitation of the encryption used in the NTLM protocol), so SSO types that rely on it won't function correctly.

 

  • cgallimore_1748's avatar
    cgallimore_1748
    Icon for Nimbostratus rankNimbostratus
    Jan 12, 2016
    Thanks for your quick response Lucas. Two questions... 1) At what point is the ECA profile associated with its SCHANNEL connection? I wouldn't think that it would be established before the 401 occurs, would it? If not would it theoretically be possible to change the NTLM auth via an apm iRule event or does it have to happen after/during the SCHANNEL establishment? 2) Even with the domain trust relationship wouldn't the configured NTLM sso object have to be modified due to the fact that the NTLM object requires you to put in the ntlm domain when creating it?
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Jan 12, 2016
    1: This happens at config time. 2: Don't confuse NTLM SSO with NTLM AAA, these are completely different things. NTLM SSO is for APM to transmit username/password to a web server (usually IIS) via NTLM over HTTP. NTLM AAA (ECA, etc) is used to allow web clients to authenticate via APM to a Domain Controller. For NTLM AAA, you can't use very many irule events because it happens way before access profile execution in APM. The access profile basically just checks the return status from ECA.