The new PasswordFetch class offers the ability to retrieve passwords from eDirectory when they are not supplied via the original authentication Method. The workflow diagram shows how PasswordFetch sits in the architecture of the solution:

Click to view.

Environment

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

• SLES 11 (lnxwlgmulti01.directoryconcepts.co.nz - 192.168.10.9)
• eDirectory 8.8.6 (t=DCNZ)
• Universal Password Enabled
• Objects under container: o=IDENTITIES
• Apache running for office.directoryconcepts.co.nz with SSL enabled (signed by DCNZ)

• Windows Server 2008 R2 (w2k8.ad.directoryconcepts.co.nz - 192.168.10.11)
• Active Directory (dc=ad,dc=directoryconcepts,dc=co,dc=nz)
• Domain Controller Server Certificate signed by DCNZ for IDM purposes and AD LDAPS enablement
• Objects under container: ou=BASEDN,dc=ad,dc=directoryconcepts,dc=co,dc=nz

• Novell Access Manager 3.1.3-247
• Administration Console & Identity Provider on SLES 11 x64 (idp.ad.directoryconcepts.co.nz - 192.168.10.4)
• Linux Access Gateway (lag.ad.directoryconcepts.co.nz - 192.168.10.7)
• The LAG protects the iDP, so the Base URL is https://office.directoryconcepts.co.nz:443/nidp

• Windows 7 x64 SP1
• Active Directory Member
• Internet Explorer 9
• DCNZ Self Signed Certificate Authority imported into Computer Trusted Roots Store
• *.directoryconcepts.co.nz added to IE's Local Intranet sites

User Stores

Active Directory

Create the User for Kerberos (we will also use this user for AM3 Store Access, so give it Domain Admin membership).

Click to view.

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

Click to view.

Click to view.

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

Click to view.

Now we need to export the Kerberos Key Tab file:

Click to view.

eDirectory

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

• eDirectory Account: cn=bwalter,ou=ACTIVE,o=IDENTITIES
• Active Directory Account: CN=Ben Walter,OU=Users,OU=BASEDN,dc=ad,dc=directoryconcepts,dc=co,dc=nz

IDM will write back the DirXML-ADContext value of CN=Ben Walter,OU=Users,OU=BASEDN,dc=ad,dc=directoryconcepts,dc=co,dc=nz to the cn=bwalter,ou=ACTIVE,o=IDETNTIES object (we will use this attribute as part of the PasswordFetch class).

Access Manager iDP

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

Click to view.

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

Click to view.

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

Click to view.

The bcsLogin.conf looks like:

com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required
debug="true"
useTicketCache="true"
ticketCache="/opt/novell/java/jre/lib/security/spnegoTicket.cache"
doNotPrompt="true"
principal="HTTP/office.directoryconcepts.co.nz@AD.DIRECTORYCONCEPTS.CO.NZ"
useKeyTab="true"
keyTab="/opt/novell/java/jre/lib/security/nidpkey.keytab"
storeKey="true";
};

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

Click to view.

So, when the Kerberos Token is received by the iDP from the client, it validates with Active Directory (based on userPrincipalName in the token - bwalter@AD.DIRECTORYCONCEPTS.CO.NZ), this returns the DN of the user object (CN=Ben Walter,OU=Users,OU=BASEDN,dc=ad,dc=directoryconcepts,dc=co,dc=nz). To find the equivalent user in eDirectory, we use this to search for them from the DirXML-ADContext value.

11:20:29 A122EB70 LDAP: (192.168.10.4:50259)(0x0002:0x63) Search request:
   base: "o=IDENTITIES"
   scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
   filter: "(&(objectClass=Person)(DirXML-ADContext=CN=Ben Walter,OU=Users,ou=BASEDN,dc=ad,dc=directoryconcepts,dc=co,dc=nz))"
   attribute: "GUID"
   attribute: "fullname"

For each Class, we create a Method:

The Kerberos Method uses the Active Directory Store.

Click to view.

The PasswordFetch Method uses the eDirectory Store.

Click to view.

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:

Click to view.

Policies

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

Click to view.

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" contract for External Users so they are prompted to authenticate when no Kerberos Token is received. First we configure the Kerberos Contract with an Authentication Level, etc

Click to view.

Click to view.

Then we configure our "fallback" contract, in this case the Secure Username/Password Form:

Click to view.

Click to view.

Then we disable the Authentication Cards for all other unused Contracts to make the Secure Username/Password Form the default:

Click to view.

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).

Alternate

As of version 3.1.4 of Novell Access Manager, new capabilities have been added to the Kerberos Class. These are documented.

Kerberos Method Properties Example:

• FALLBACK_AUTHCLASS: com.novell.nidp.authentication.local.ProtectedPasswordClass
• MainJSP: true
• JSP: custom_page