Access Manager

From ZENworks Ninja
Jump to: navigation, search

NetIQ Access Manager

A typical Access Manager configuration includes an Identity Server with LDAP directories and an Access Gateway with a protected Web server. Figure 2-1 illustrates the process flow that allows an authorized user to access the protected resource on the Web server. ag_flow_a.png

  1. The user requests access to a resource protected by the Access Gateway.
  2. The Access Gateway redirects the user to the Identity Server, which prompts the user for a username and password.
  3. The Identity Server verifies the username and password against an LDAP directory (eDirectory, Active Directory, or Sun ONE).
  4. The Identity Server returns an authentication success to the browser and the browser forwards the resource request to the Access Gateway.
  5. The Access Gateway verifies that the user is authenticated and retrieves the user’s credentials from the Identity Server.
  6. The Access Gateway uses an Identity Injection policy to insert the basic authentication credentials in the HTTP header of the request and sends it to the Web server.
  7. The Web server grants access and sends the requested page to the user.

Useful links

Configuring the Global Advanced Options

Applications I have protected with NAM

I thought it would be good if I provided a list of known applications that I have worked with. Obviously, some of these are simple, while others can be very complicated.

Application Name Difficulty Authentication Type
Google Apps Easy SAML 2.0
ServiceNOW Moderate SAML 2.0
Novell User App Difficult Identity Injections
IBM WebSphere Difficult J2EE Agent
Silk Road Difficult SAML 2.0

Custom Authentication

Posting Login to the IDP

It is possible to post, from a web form, the credentials so that the user is authenticated seamlessly. Basically if you have a script or webapp that can contain the <form></form> elements, then you can post the Ecom_username and Ecom_password to the IDP.

Here's what a sample form would look like.

<form action='' method='post'> 
  <input id="target" type="hidden" name="target" value="" />
  <input id='Ecom_User_ID' name='Ecom_User_ID' type="hidden" value='userID'>
  <input id='Ecom_Password' name='Ecom_Password' type="hidden" value='password'>

Here's an example if you want to use Federation after authentication.

The example would be if you want to initiate a SAML federation after authenticating to NAM.

Notice that the TARGET value has to be URL Encoded.

Here is the URL not encoded, so you can see easily what it says.
<form action='' method='post'> 
  <input id="target" type="hidden" name="target" value="" />
  <input id='Ecom_User_ID' name='Ecom_User_ID' type="hidden" value='userID'>
  <input id='Ecom_Password' name='Ecom_Password' type="hidden" value='password'>

You can also pass in the Authentication Contract to the IDP. Otherwise by default the IDP picks the default contract specified.

In this example the Contract ID = myExampleContract

I don't like to use Numbers as NAM could overwrite those.

<form action='' method='post'> 
  <input id="target" type="hidden" name="target" value="" />
  <input id='Ecom_User_ID' name='Ecom_User_ID' type="hidden" value='userID'>
  <input id='Ecom_Password' name='Ecom_Password' type="hidden" value='password'>

Deep Linking

  1. First link is the URL to the IDP and the authentication contract you want to use<contract_id>
  1. Second is a query string parameter that tells the IDP where to redirect the user to next

To access Access Manager intersite transfer URL with a specific contract, modify the web URLs to the following format:

<identity server login URL>?id=<contract>&target=<identity consumer URL>?PID=<entityID>&TARGET=<final_destination_URL>

The <identity_server_Login_URL> is the location of where the authentication request can be processed. and the <contract_Authentication Card_IDP> is contract authentication card Identity Provider. For example:

Modified Web URL Example

Kerberos Authentication

Getting Kerberos Authentication working isn't that complicated, but here are a few tips that can really help out.

  • Kerbtray.exe (It's in the MS Resource Tool Kit)
  • LDAP Browser
  • catalina.out (search for krb)

More details later

CAPTCHA A CAPTCHA is a program that can tell whether its user is a human or a computer. You've probably seen them — colorful images with distorted text at the bottom of Web registration forms. CAPTCHAs are used by many websites to prevent abuse from "bots," or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs. The reCAPTCHA Java Library provides a simple way to place a CAPTCHA on your Java-based website, helping you stop bots from abusing it. The library wraps the reCAPTCHA API.

To use reCAPTCHA with Java/JSP, you can download the reCAPTCHA Java Library here (contributed by Soren) and unzip it. Typically the only thing you'll need is the jar file (recaptcha4j-X.X.X.jar), which you have to copy to a place where it can be loaded by your java application. For example, if you are using Tomcat to run JSP, you may put the jar file in a directory called WEB-INF/lib/.

Build a custom Authentication Class


To make this work, you need a custom login.jsp and a custom Authentication Class.

You can use the default login.jsp as your base template, just copy it as login_captcha.jsp

  1. Download the NAM SDK from
  1. Get a copy of nidp.jar from your IDP.

  1. Create a new project in Eclipse (You can use NetBeans or other programs too)
  2. Add a Build Path reference to nidp.jar
  3. You might also have to get higgins-sts-api and add that as a reference.
  4. Create a new class, call it CaptchaCustomAuthenticationClass
  5. Add two import statements
import net.tanesha.recaptcha.ReCaptchaImpl;
import net.tanesha.recaptcha.ReCaptchaResponse;
  1. Add a new method, call it ValidateCaptcha The method should contain the following code
  	 * Validates that the user provided Captcha answer is valid.
  	 * Returns true if it is.
  	 * @author jjennings <Sept 28, 2012>
  	 * @return boolean
	private boolean ValidateCaptcha ()
		String remoteAddr = m_Request.getRemoteAddr ();
		ReCaptchaImpl reCaptcha = new ReCaptchaImpl ();
		reCaptcha.setPrivateKey ("your_private_key");

		String challenge = m_Request.getParameter ("recaptcha_challenge_field");
		String uresponse = m_Request.getParameter ("recaptcha_response_field");
		ReCaptchaResponse reCaptchaResponse = reCaptcha.checkAnswer (remoteAddr, challenge, uresponse);

		if (reCaptchaResponse.isValid ()) {
			return true;
		} else {
			return false;

  1. Next add a reference to the Method, I added the reference before the class validate the username and password
 handlePostedData() {
      // Look for a name and password
      String id       = m_Request.getParameter(NIDPConstants.PARM_USERID);
      String password = m_Request.getParameter(NIDPConstants.PARM_PASSWORD);
      // validate the captcha before we attempt to find a user in the directory. This hopefully will cut down on scripts and other attacks.
      ValidateCaptcha ();
  1. Expire the new custom class as a jar, NOT RUNNABLE
  2. copy the jar to
  1. Now create a custom authentication class in NAM. see
  2. Create custom authentication method to reference the class
  3. Follow the steps for editing the login...jsp as referenced here.
    <%@ page import="net.tanesha.recaptcha.ReCaptcha" %>
    <%@ page import="net.tanesha.recaptcha.ReCaptchaFactory" %>

        <form action="" method="post">
          ReCaptcha c = ReCaptchaFactory.newReCaptcha("your_public_key", "your_private_key", false);
          out.print(c.createRecaptchaHtml(null, null));
        <input type="submit" value="submit" />

NAM CaptchaExample.png

Custom Logout Options

Using the following code in the JSP (between the <head></head>) tags will work wonders.

<meta http-equiv="refresh" content="0; url=/" >

This code would cause the user to be redirected to the ROOT of whatever site called /AGLogout

Federation Configurations with other Vendors

Service Now

More information can be found at

ServiceNow recommends customers using an existing SAML 2.0 integration upgrade to the latest SAML 2.0 integration update.

Example ServiceNow (SP) Metadata

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="">
 	<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
		<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="" />
		<AssertionConsumerService isDefault="true" index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=""/>

Authentication with a specific contract or Class


Unknown Settings and Touch Files


In "/opt/novell/nam/adminconsole/conf/tomcat7.conf", there is a line that contains "DeploymentMode=SingleMachine". If you comment that out and restart the services, you should no longer have the single mode restrictions.

Cache Maintenance

Versions 3.2 and 4.0 of Access Manager use Apache for the proxy engine. Thus the Apache caching system is used. By default the cache is not cleared of old entries and you must use the htcacheclean process to do this.

htcacheclean is located in


Example command to clear the cache manually which will limit the cache to 1024M

./htcacheclean -D -v -t -l 1024M -p /var/cache/novell-apache2/

Dry Run


Be verbose and print statistics. This option is mutually exclusive with the -d option.


Delete all empty directories. By default only cache files are removed, however with some configurations the large number of directories created may require attention. If your configuration requires a very large number of directories, to the point that inode or file allocation table exhaustion may become an issue, use of this option is advised.


A whole list of troubleshooting pieces and information about log files can be found at NAM Troubleshooting

Very useful stats pages

Advanced Options

These options are for the Linux Service

The # comments the line (option) out.

NAGGlobalOptions DebugFormFill=on 

Messages are logged to "/var/log/novell-apache2/error_log" for FormFill debug messages on matching the page

Debug Formfill Issues

NAGGlobalOptions DebugFormFill=on

NAGGlobalOptions FlushUserCache=on
IgnoreDNSServerHealth on
NAGGlobalOptions ForceUTF=on
ProxyErrorOverride On
NAGGlobalOptions DebugHeaders on
NAGVia on
LogLevel debug
DumpHeadersFacility local6
DumpResponseHeadersFacility local6

enable dumping headers to error_log

DumpHeaders On
DumpResponseHeaders on

Log settings

LogLevel Debug

Error Messages

I've compiled a list of my favorite eror messages in NAM. Even though the errors appear to be complicated, they are not.

Please see NAM Error Messages

Log Files

Purpose of this file is unknown at this time

Form Fill Tips and Tricks

Javascript tricks

The other day I needed to modify the password that the FF Policy was injecting into the form. The backend system only allowed passwords up to 8 characters, but users were allowed to use much longer passwords. The FF policy doesn't allow you to call a data injection class, like you can in Identity Injection.

So here is how I was able to accomplish this.

var field1 = document.forms[0].password.value;
field1 = field1.toUpperCase();
field1 = field1.substring(0,8);
var cleanString = field1.replace(/[^QWERTYUIOPASDFGHJKLZXCVBNM@#$1234567890!]/ig, "@");
document.forms[0].password.value = cleanString;

Screen Shot 2013-08-02 at 11.13.36 PM.png