Forum Discussion
AltocumulusUsing Login Page to trigger NTLM Authentication with server
Hello,
I have been looking all day at docs for NTLM authentication. Maybe I can't see the forest of for the trees. There is NTLM SSO and Client to Server NTLM. But its not what I am looking for. Maybe I have missed it.
We have clients external to the network that will be given a Login Page for the user to enter username, password etc. Then we want NTLM authentication with the internal server.
There is plenty of documentation for doing AD, LDAP, RADIUS, Kerberos, in this manner, but not NTLM.
The closest I can get is to:
- Have an access policy with a Login page and nothing else.
- I then associate a NTLM SSO profile with this.
- Then I apply the access policy to the virtual server.
I think this might work like this:
When the client access the Virtual server the login page is presented and the user provides the required information. Access is then provided to the application on the internal server. This then requests NTLM authentication in a response. The APM sees the request for NTLM authentication and uses the NTLM SSO profile to do the NTLM authentication using the information via the system variables set from the Login page.
Is this the correct way to NTLM authentication for external clients?
Many thanks,
2 Replies
- Kevin_Stewart
Employee
If I may add, server side "SSO" NTLM is the client side of an NTLM challenge-response negotiation. If you notice in an NTLM profile, you have "Credentials Source" session variables - one for username, one for password, and one for domain. So basically the way it works, somewhere in the access policy you have to populate these session variables with valid user/password/domain values. When you get to the Allow block in the visual policy, the SSO is triggered. For NTLM specifically, an initial request is sent for which the server should send back a 401 Unauthorized response. This starts the challenge-response. The server sends some information in its 401 response and the client encrypts that value with its password and sends it back to the server to indicate it knows the password. In David's visual policy, you see an SSO Credential Mapping agent. When you enter a password into a Logon Page, that password is stored encrypted in the session.logon.last.password session variable. When you use an SSO that requires access to the user's password (ie. NTLM, Basic, Forms), the SSO Credential Mapping agent at the end of the visual policy is responsible for pulling a cleartext copy of the password into another session variable for use in the SSO profile: session.sso.token.last.password. How you populate those NTLM SSO source session variables is completely arbitrary, but as you can see a logon page is a common use case.
Michael_61068Hi thanks for both the comments,
So I have updated the Access Policy to have the SSO credential mapping after the logon form:
Also the NTLMv2 SSO policy is also updated to now use the SSO session variables:
I will test this. Any other comments and thoughts welcome.
