How to troubleshoot Access Manager Form Fill policies



This documents explains the process troubleshooting form fill policies in NetIQ Access Manager 3.2 and later. Basically by following this quick and dirty process you will be able to see how the values configured in a form fill policy are being sent from Access Manager to the back end server in a practical approach.

Although Access Manager Application offers you an easy way to diagnose what is going on (by enabling the Application Component File Logger Levels in verbose or debug mode, sometimes is not possible to do any configuration change. (especially if you are in production and you have multiple proxy services serving resources successfully)


Form fill policies are a very useful mechanisms that Access Manager uses in order to integrate enterprise applications that holds its own login form. The process of evaluation and logging is performed by the Embedded Service Provider and the proxy service, so first you need to isolate the issue and focus in the ESP.


There is a quote that says “Learning by watching is never as effective as learning by doing”, so in this cool solution I’ll show you how to assure that your form fill policy is working as expected or not without modify any configuration in NAM.

  • The SysAdmin of MyApp is saying that this issue is happening because no credentials are being injected through the NAM FF policy

  • The Architecture looks like the following image.

Architecture Architecture

The very first approach should be to recognize the login form in the application that is presenting the problem (In my case I have downloaded the form using wget command and then using web Developer Firefox Addon in my Workstation it’s easy to look at the fields )

Form_fields Form_fields

  • Once the login form fields are identified, the easiest way to diagnose (when log files are not available) is to the capture tcp traffic using tcpdump in your AG servers while the final user is trying to log in the App . The syntax could be something like this:

    tcpdump -vvv -i any -s 65535 host <AppServerIP>-w /tmp/$HOSTNAME-APP.log

    (Replace <AppServerIP with the IP address of the Back end server)

  • After capture all the tcp traffic download the output file ($HOSTNAME-APP.log) and open it up with wireshark

    Note: If the communication between the AG’s and the backend server is done using SSL you need the public and private key in order to decrypt the tcp traffic

  • Wireshark has a cool feature that allow you to search for specific strings in all the tcp traffic, simply press Ctrl F, select String, Packet details as a search parameters, and find for the filter the name of one of the fields (in my case the field is “password”)

    password search password search

  • The first packet matching the search parameters is highlighted, select it and click in the “Follow TCP stream” option

    Follow tcp stream Follow tcp stream

  • Dig inside the tcp stream (html code) looking for the execution of the action set in the log in form (in my case form name=”loginForm” method=”POST” action=””) and you will see the user data that login form need (in my case username and password)

  • If you can find something like this:


    Then you can be sure that Access Manager is doing what is configure to do, once the app is receiving the user credentials it probably need to validate them against an authentication sources (Database, LDAP server, etc) , so the SysAdmin can troubleshoot the issue.

If something else is happening you will have to dig inside the NAM components (time synchronization, backchannel communication, NAM certificates, UserStore up and running, etc )


How To-Best Practice
Comment List