Troubleshoot NTLM SSO

If you look at the properties of your NTLM SSO profile, you'll see two "source" variables which are the values used to perform the NTLM auth to the server. You have one for username (usually session.sso.token.last.username), and one for password (usually session.sso.token.last.password). There's also one for the input domain. If you're collecting the username and password from a login page, they'll be stored in the session.logon.last.username and session.logon.last.password variables, respectively and the password will be stored encrypted. In order to use that password in an SSO, you'll want to add an SSO Credential Mapping agent in the visual policy right before the ending Allow block which will copy both values to their respective session.sso.token.last.* variables and decrypt the password.

Hi Kevin,

Thanks for the input.

The NTLM profile is Configured as below,

Domain Source: session.logon.last.domain (when i see the logs under logs/apm i do not find this variable with the domain information)

NTLM Domain: domain

And the Access Policy is configured

Start --| Logon Page --| Ad AUTH --| Variable assignment --| SSO Crediential Mapping --| Allow

The Variable assigned is

session.logon.last.username = expr { [concat "domain\\[mcget {session.logon.last.username}]"] }

Still the SSO is failing.

Regards.

Have you tried setting the domain session variable instead of creating a new variable?

Yes i tried replacing the session.logon.last.domain to session.logon.actual.domain as i noticed in the logs but that did not help.

The SSO is failing and i am seeing the Logon Page Prompt.

Because on the application authentication side we need to have DOMAIN/Username.

Thanks.

You shouldn't have to modify the username to add the domain. The NTLMv2 SSO should handle this for you. You need to do the following:

1. Ensure that your access policy correctly populates the session.sso.token.last.username variable with the user's userPrincipalName or sAMAccountName value. This is generally accomplished with the SSO Credential Mapping agent from some other input source like session.logon.last.username from the logon page agent.

    

2. Ensure that your access policy correctly populates the session.sso.token.last.password variable with the user's password. This is accomplished with the SSO Credential Mapping agent from some other encrypted source like session.logon.last.password from the logon page agent.

    

3. Ensure that your access policy correctly populates the session.logon.last.domain variable with the user's domain name, or statically populate the NTLM DOMAIN value in the NTLMv2 SSO profile.

    

You may need to test enabling and disabling the Username Conversion option in the SSO profile.

Otherwise, how would you authenticate to the server directly from a client in the domain? Are you certain that the server accepts NTLMv2?

Hi Kevin,

Thanks for your help.

For ensuring that the domain is correctly populated I will enter it statically *eg:domain* in the ntlm domain source so that it will use from the defined one.

For accessing the portal directly its integrated with our windows domain machine and the credentials are fetched from there and access is given accordingly.

Regards.

hi Kevin,

i am unable to see any value related to userPrincipalName or sAMAccountName in the APM logs.

Is there a way where i can fix this or make the SSO work without the values?

Regards.

i am unable to see any value related to userPrincipalName or sAMAccountName in the APM logs.

You have to create one of these values. Generally speaking, the logon page is going to create the session.logon.last.username value, and the SSO Credential Mapping agent is going to dump that value into the session.sso.token.last.username variable. NTLM is a challenge response authentication protocol. The server is going to challenge the client with some piece of information, and the client (APM SSO) is going to respond to that challenge to prove knowledge of the user's password.