CA Siteminder: Can we modify .ntc file to include some custom logic during Windows Authentication?

[Legacy User]

Hi all,

We have a requirement where we have to run through some logic during the window authentication (IWA) process. Can we modify .ntc file (such as creds.ntc) to include our custom logic during windows authentication?

Any help is appreciated.

Thanks

[Vipin Jain]

What kind of logic we thinking of Abhishek?

[Legacy User]

Hi,

When a user accessed an application from outside the network/internet, we want to show user a custom login page instead of default basic authentication pop-up. We are thinking of modifying the credential collector (.ntc) file during Windows Native Authentication (IWA). Please let me know your thoughts.

Thanks in advance.

[Legacy User]

Also, can anyone please share the location of .ntc file. I couldn't locate it under siteminder webagent folder. This would be really helpful.

Thanks

[Patrick Dussault]

Hi Abhisheck,

 

The .ntc file is not a file you will find in the file system. It's rather an extension that will point to an internal function of the Web Agent to do the Windows Authentication. You can choose also another extension if you want by using ACO Parameter NTCExt=.

 

Remember that for the Windows Authentication, the IIS server does the authentication, and the Web Agent does trust the IIS Authentication.

 

Hope this helps,

 

Best Regards,

Patrick

[Legacy User]

Thanks Patrick.

I have a below query.

Can we throw a custom login form instead of default basic authentication pop-up in case the user accesses the application outside company's network (internet)? If yes, where do we make this change? Do we have to tweak windows authentication template (auth. scheme)?

[Chris Bertagnolli]

One way I've found to handle 'fallthrough' logic if you don't use a public/private split (i.e., public goes through Web Agent "Pub" and private through Web Agent "Priv" therefore just assign different auth schemes) is below. I'm sure there are other ways, but this has worked pretty well for my setup that uses a centralized credential collector for all apps.

 

The pop-up itself is really browser behavior more so than SiteMinder. Since it sends WWW-Authenticate:Negotiate and if proper credentials aren't automatically negotiated browser prompts such that user 'can enter valid creds' -- which of course means nothing if you have IIS setup to do only "Negotiate:Kerberos" for example since no matter what you put in that popup it will never pass .

 

------------------

Pre-setup: Win 2012 R2 and IIS 8.5. Configured for Negotiate:Kerberos provider only (cause NTLM is just...bad).

 

1 - Create a centralized "redirect.jsp" (or whatever you want...aspx anything really) that takes an 'originaltarget' parameter to send the user back to what they originally requested (be sure to validate redirect domain so someone can't bounce things off it to trick users).

 

1a - Create application object to protect /redirect.jsp?auth=forms&originaltarget=*   protected with forms auth

 

2 - Create a custom error page - for example formredirect.html - which is nothing but a simple redirect that snags the original target URL from the request (i.e., the app or page they were going to) and redirects to /redirect.jsp?auth=forms&originaltarget=[the URL you snagged]

 

3 -

Go to the folder location you specified for the .ntc (or if using inline credentials whatever folder is doing the windows auth). Set error mode to 'custom' and configure

 

401 = File and point to your redirect html file

401.1 = Execute URL and point to the same file location

 

Note: This step can adjust if you have anything going on in IIS. I specifically have some other filters in play that requires I set custom error only for 401 and 401.1 to be consistent across IE, Chrome and Firefox. If I do things with 401.2 it hoses it up. In testing I've also found differences between browsers when doing "File" vs "Redirect" vs "Execute URL"....So YMMV depending on specific setup.

 

You may have to play with adding in 401.2 possibly.

------------------

 

Now when a user hits the IWA protected page, if they are on domain and it works then they'll just passthrough normally. If they're off domain, or don't have IWA properly enabled, it will invoke the error file, redirect them to the "forms" protected resource and upon successful log in they'll get the right auth level (IWA scheme must be same or lower than Forms of course) and redirected back to their original target location without being prompted again for creds.

 

At least from my testing, when I hit it from a different domain or off the domain I don't get that popup using the 401 + 401.1 combination.

 

Of course the specific configs will depend on your overall app structure. Hopefully has some pointers that might be helpful to figuring it out for your setup..

[Legacy User]

Thank you CBertagnolli for your response. Your solution makes sense.

Also, has anyone implemented this solution - https://communities.ca.com/docs/DOC-231151411

 

[Chris Bertagnolli]

Tried the solution linked, didn't like it much but can work (we had to adjust it a bit in the one we tried - was a while back now).

 

Just seemed like more than is necessary and was still getting the browser login prompt when on a different domain (without actually doing NTLM, that never passes anyhow); doing the combo of 401/401.1 seems to have resolved getting the login prompt for our use cases.

[Legacy User]

Hi CBertagnolli, i am unable to achieve the above mentioned solution. I am not been redirected to custom page upon making the above conf. I modified 401 and 401.1.

Are we missing anything?

Thanks

[Chris Bertagnolli]

Might need to set the following:

 

- Go to Configuration Editor

- Under system.webServer/httpErrors set "allowAbsolutePathsWhenDelegated=True"    (if the section is locked, may have to unlock or set at server level...been a while since I've done this with base IIS install)

 

And on the folder where you are setting the error web.config should look something like

 

<configuration>

    <system.webServer>

        <httpErrors errorMode="Custom" existingResponse="Replace">

            <remove statusCode="401" subStatusCode="-1" />

            <error statusCode="401" subStatusCode="1" path="/local/formredirect.html" responseMode="ExecuteURL" />

            <error statusCode="401" path="D:\Sites\MySite\local\formredirect.html" responseMode="File" />

        </httpErrors>

    </system.webServer>

</configuration>

 

**In this specific setup, since ExecuteURL is used that file has to exist in that location of the site itself.

[Chris Bertagnolli]

AbhishekK  have you been able to try this further to see if any of the values mentioned make a difference?

[Legacy User]

CBertagnolli - I was facing issues with the solution you provided. However, i am able to achieve the same using the add-on provided by CA - Windows IWA Failover to HTML Form Login.docx

This solution is pretty easy to implement. Please let me know if you have any questions. Thanks,

[Chris Bertagnolli]

Cool, glad that one worked for ya .

[Legacy User]

Thank you for your assistance CBertagnolli.

I observed one strange thing - when we access the application from internet - we now get HTML form login page onstead of windows authentication pop-up. The user enters his/her credentials on the html form login. After successful authentication, the windows authentication basic pop-up comes again. The user has to enter his credentials again to see the application homepage.

If you have experience this issue or know anything about it, please share.

Thanks

[Legacy User]

Guys, the above issue has been resolved. We had to disable the windows authentication and enable the anonymous authentication on the application folder.

Thanks and cheers.