Kerberos Single Sign-on with Passwords through Access Manager

Kerberos Single Sign-on with Passwords through Access Manager

The new PasswordFetch class offers the ability to retrieve passwords from eDirectory when they are not supplied via the original authentication Method. This diagram shows the high level interaction:



In this setup example, the following lists the environment configuration:

  • SLES 12 ( -
  • eDirectory 9 (t=EDIR-TREE)
  • Universal Password Enabled
  • Objects under container: o=DATA
  • Apache running for with SSL enabled
  • Windows Server 2012 ( -
  • Active Directory (dc=ad,dc=domain,dc=com)
  • Domain Controller Server Certificate signed by EDIR-TREE for IDM purposes and AD LDAPS enablement
  • Objects under container: ou=DATA,dc=ad,dc=domain,dc=com
  • Novell Access Manager 4
  • Administration Console & Identity Provider on SLES 12 x64 ( -
  • Linux Access Gateway ( -
  • The LAG protects the IdP, so the Base URL is
  • Windows 10
  • Active Directory Member
  • Internet Explorer 11
  • EDIR-TREE Self Signed Certificate Authority imported into Computer Trusted Roots Store
  • * added to IE's Local Intranet sites

User Stores

Active Directory

Create the User for Kerberos (we will also use this user for NAM Store Access, so give it sufficient domain access).


The User Login Name must be HTTP/ followed by the Access Manager Base URL domain (i.e. HTTP/


For this next screen, you will need to enable Advanced Features in MMC.


Now we need to export the Kerberos Key Tab file:



Create the test user in ou=IDENTITIES,o=DATA and allow IDM to synchronise the user to Active Directory. This will result in:

  • eDirectory Account: cn=bwalter,ou=IDENTITIES,o=DATA
  • Active Directory Account: cn=Ben Walter,ou=IDENTITIES,ou=DATA,dc=ad,dc=domain,dc=com

IDM will write back the DirXML-ADContext value of cn=Ben Walter,ou=IDENTITIES,ou=DATA,dc=ad,dc=domain,dc=com to the cn=bwalter,ou=IDENTITIES,o=DATA object (we will use this attribute as part of the PasswordFetch class).

Access Manager IdP

First, we'll apply the fix for TID7004020 to avoid frame issues with any backend apps. Edit the /opt/novell/nids/lib/webapp/jsp/top.jsp file and change top.location.href='<%=url%>'; to location.href='<%=url%>'; (this is all that is required if you use the new login versus the legacy login).

Next, we create the primary store which will be Active Directory.


Next, we need to create the eDirectory store for the PasswordFetch class to use.


Next, we create the Kerberos Class called "Kerberos". In the Properties, we add the following values to match with Active Directory:


The bcsLogin.conf looks like: { required

While here, we also create the PasswordFetch Class called PasswordFetch. In the Properties, we add the following values:


So, when the Kerberos Token is received by the IdP from the client, it validates with the ticket cache then searches AD (based on userPrincipalName in the token - bwalter@AD.DOMAIN.COM), this returns the DN of the user object (cn=Ben Walter,ou=IDENTITIES,ou=DATA,dc=ad,dc=domain,dc=com). To find the equivalent user in eDirectory, we use this to search for them from the DirXML-ADContext value.

11:20:29 A122EB70 LDAP: ( Search request:
   base: "o=DATA"
   scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
   filter: "(&(objectClass=Person)(DirXML-ADContext=cn=Ben Walter,ou=IDENTITIES,ou=DATA,dc=ad,dc=domain,dc=com))"
   attribute: "GUID"
   attribute: "fullname"

For each Class, we create a Method:

The Kerberos Method uses the Active Directory Store.


The PasswordFetch Method uses the eDirectory Store.


The options to Overwrite User values means that the LDAP DN will be that of eDirectory, not Active Directory (should it be needed).

Now we create the Contract to be utilised:



Because we told the PasswordFetch Method to overwrite the user values, any policy should use the eDirectory values for LDAP. i.e.:


Internal/External Scenario

Consider the situation where your business has one Access Manager solution for both Internal and External resources. The Internal resources utilise the method described above for single sign on, but what about External Users? They have no Kerberos token to send through!

What we need to do is provide a "fallback" class for External Users so they are prompted to authenticate when no Kerberos Token is received. Kerberos Method Properties Example:


The Catch! The IdP still needs an authentication header passed to the Kerberos Contract, even if its empty, otherwise it errors requiring authentication. To do this, the external clients must be configured like internal clients (i.e. setting Internet Explorer to enable Integrated Login and add the domain to the Intranet Sites, or setting the network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris in Firefox)

Labels (2)


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Hi, I have the same setup, but I'm not able to use a policy with a condition check for a container, a group or a role with a validation in eDir to authorize user access.
To have policies that check eDir values, you *MUST* enable "Overwrite Temporary User" and "Overwrite Real User" in the PFC Method, *AND* disable "Retain Previous Principal" in the PFC Class.
Great article. Is it possible to do kerberos constrained delegation with NAM?
Is this applicable to NAM304? As i don't see the PasswordFetch class in there... Thx
A class developped by Bart Andries exist for 3.0.4, I think.
Bart's one operates differently to the Novell one and doesn't contain some of its features such as Principal Replacement.

You do realise that, if you have any issues with your Access Manager environment, the first thing Novell will ask is what release you're running? They only offer decent support if you're running the current release, otherwise they'll just say "upgrade to current release and see if issue continues".
Hi there,
I'm using NAM to authenticate external users to access to some applications hosted on the cloud (sales force), for the internal users, when they want to access those apps, an additional authentication (besides windows (AD) authentication) is required.
How can I authorize internal users to access to those applications once they are logged in to the local domain without entering additional login/password using Kerberos (SSO) ?
What if I'm going to setup the password fetch now and my existing eDirectory is without "Simple Password" or "Universal Password", can these users be fetch? Thanks.
Definitely not.

Your passwords are only held in RSA encryption which is irreversible.
A note on the keytab location
In this article it is :

I suppose in later versions of access manager (Iused the appliance), it should be
Hi, I have NAM4 setup for the external domain, but the internal AD domain is acme.local, so will it work if the login name is HTTP/ or will I need another NAM instance in the AD domain? The internal name for the server in DNS is vnam40app.acme.local. Thanks.
Hi, Does this Kerberos setup compulsory need AD as s user store? Cant it be setup with only eDirectory?

Kerberos is Kerberos, its just that by default most authentication stores for Kerberos are AD....if your eDir correctly issues Kerberos tickets, you should be able to replicate. I haven't played with Kerberos in eDir, so not sure about setting the SPN (I'm guessing there's an attr equivalent).
SPN is multivalue attribute, but I believe your guess would be correct.
Please refer to the version listed at the start of the article, it is likely that Micro Focus will change things going forward.
im trying to authenticate to access manager with kerberos using another access manager (version 4.3.2)
is it possible?
Yes, just need to follow the documentation
Top Contributors
Version history
Revision #:
5 of 5
Last update:
‎2020-01-31 11:37
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.