Few Useful Tips on Sun LDAP Multi-Master Replication

If you are using Sun Directory Server 5.2, here are few useful tips on Multi Master replications.

(1) The typical steps of configuring multi-master (say M1 and M2 fro reference) is to define replication agreement on each of the LDAP which push changes to other. But initially both the LDAPs has to be in sync. While defining the agreement from console, it usually displays a message that "remote replica of the selected agreement has not been initialized from this replica". The same message will be seen on other LDAP's console's agreement definition screen. This gives an impression as if both the LDAP has to be initialized with each other to be in perfect synchronization to start with. But NEVER do initialize both way.

For example, After defining replication agreement on each of the LDAP, only do a full initialization from M1 to M2. Never do the same from M2, even if agreement in M2 console displays the above said message of "remote replica of the selected agreement has not been initialized from this replica".

(2) While doing full initialization from M1 to M2, the schema MAY NOT not get loaded to M2. So copy ".../slapd-M2/config/schema" directory from M1 to M2 followed by restarting M2. Do the initialization after the schema at both M1 and M2 are same.

(3) Index information does not get loaded to when an initialization is done from one master to other. So export the index from source master and import it to other master followed by a re-indexing.

(4) For some reason, if you have to delete the existing agreement and create the same again, make sure you are assigning a new replica-id. This will avoid possible data corruption.

(5) When exporting data from any of the LDAPs participating in multi-master replication, you will see replication info(e.g. obEnabled;vucsn-49de55e5000000010000;deleted: disabled) in exported data. what if you wanted clean data only? There are many ways, here is one of them.

ldapsearch.exe -h yourHost -p yourPort -D myUser -w myPassword -b obname=o=Finance,dc=company,dc=com -s sub (objectclass=Top) > exported.ldif

OAM Server Issue After Pointing to a New Ldap Instance

Let's say you moved one of your (or the only) LDAP server(s) to a different machine. You did all the correct changes in OAM System Console to reflect your new Ldap's host and port. But your OAM server (CoreId & Access) does not start for some reason. One of the solution could be some of your configuration xml/ lst files has not got the new host information yet.

For CoreId Server :- Check all xml files like AccessDB.xml, AppDB. xml etc in ..\NetPoint\identity\oblix\config\ldap directory.

For Access Server:- Check all lst files like AppDB.lst, ConfigDB.lst etc in ..\NetPoint\access\oblix\config\ldap directory.

Correct the Ldap host and ip address and restart the server. Good luck!

SSO between webgates

I was configuring OAM Load balancing. I had two set of servers (Each set has IDM, Access Svr, Policy Mgr) front ended by two iPlanet webservers (host1.abc.com and host2.abc.com) having respective webgate. To configure the SSO between these two Webgates, I appropriately mentioned the "primary Http Cookie Domain" for both webgates as "abc.com" .

Now it is testing time. I authenticated to http://host1/myPage.jsp and typed http://host2/myPage.jsp on the browser's address bar expecting I am authenticated to http://host2 as well. Nope, I saw that login screen again. I banged my head for whole day till I found my mistake next morning.

The solution was very simple. Start typing http://host1.abc.com/myPage.jsp instead of http://host1/myPage.jsp . After authentication to host1 type http://host2.abc.com/myPage.jsp . This will work as I am mentioning domain name in the URL which is set as "Primary Http Cookie Domain".

Since the set up was inside the network, I do not have mention the domain name(...abc.com) to access my web content. IPlanet was serving me the page even if I typed the URI as http://host1/myPage.jsp .

Helpful Tips for COREid to Ldap Load Balancing Setup

Before doing a any OAM components to Ldap load balancing setup , make sure you have taken the back up of node "obcontainerid=dbagents,o=oblix,dc=abc,dc=com" in your ldap.

The node 'dbagents' has all the existing DB profile data. If you mess up the DB profile while experimenting LB setup, this backup will always come to your rescue. Other wise the respective OAM server will not start.

Reconfiguring your COREid server to a new LDAP

A quick tip here on redirecting your CoreId server to a new Directory server.


-> Shut down the COREid Server
-> Open setup.xml file in .../install Directory/identity/oblix/config directory.
-> change
{..NameValPair ParamName="status" Value="done"...}
to
{..NameValPair ParamName="status" Value="incomplete"...}

-> Restart the COREid server.
-> Now access url http://.../identity/oblix and set it up again with new LDAP parameter

OAM (Oracle Access Manager) and SharePoint Integration using custom HTTPModule

OAM's integration guide has step by step instructions on OAM and SharePoint integration. However, it works only if Active Directory is the User base for your SharePoint. If your OAM is having LDAP user base you are out of luck for a quick integration. Considering the LDAP as OAM backend and Active Directory as SharePoint user base, the integration still can be done by user data reconciliation from LDAP to Active Directory before the integration and a real time provisioning mechanism afterwards.

What if your organization decided to have SharePoint with LDAP instead of Active Directory? (Our organization has set up SharePoint server for external users (non - employee) who are not in our Active Directory. All our externals users are already available in Sun LDAP). In this unusual scenario, OAM cannot be integrated as it is. Here is how we did it.

Overview of the Integration
(1) User access the SharePoint URL.

(2) OAM's webgate (IIS plug-in/ ISAPI filter developed by Oracle responsible for checking Access policy and authentication etc) intercepts the URL and display our generic login page to user. User put his credentials. OAM webgate then validate it and allow the user to access SharePoint URL. It also set the SSO token in the browser so user can have single sign on with other applications.

(3) At this point SharePoint does not know about the authenticated user even our SharePoint already has LDAPmembership to the same LDAP that used by OAM.

(4) Now the HTTPModule will come to the rescue. It will

a. read the USER_ID from header (set by OAM after the authentication) and

b. create a GenericPrincipal for SharePoint.

The outcome of this model is,

(1) Share point will not display its login page to the user.

(2) The user -to-role assignment can still be possible inside SharePoint as SharePoint is also connected to the same LDAP that is used by OAM for authentication (which is also the user db for OAM) through LDAP-membership.

1. Writing an Http Module
My assumption is reader is familiar with OAM set up and knows how to set up a Webgate for IIS server that hosts SharePoint. LDAP set up. My other blog already detailed out on how to set up SharePoint with LDAP as user base. I will focus more on the point 4 mentioned in the overview section which require writing an HttpModule for SharePoint.

The HttpModule does the followings:-

1. Reads the USER_ID from header (set by OAM after the authentication). This header variable (say HTTP_OBLIX_UID) is set by OAM after successful authentication and authorization. This can be defined in 'authorization success event' in the SharePoint URL policy inside OAM.

2. Create a GenericPrincipal for SharePoint.

Step 1: Write an HttpModule Code

If you are a java guy like me, you need to learn little bit of c# programming. Install visual studio or Visual studio C# express as an IDE for compiling the code below.

using System;

using System.Security;

using System.Security.Principal;

using System.Web;

using System.Web.Security;

using System.Collections.Generic;

using System.Collections.Specialized;

using System.Text;

using System.IO;

namespace OamHttpModule {

class OamAuthenticator : IHttpModule {

public void Init(HttpApplication app) {

app.AuthenticateRequest +=(new EventHandler(this.Application_AuthenticateRequest));

app.PreSendRequestHeaders +=(new EventHandler

this.Application_PreSendRequestHeaders));

}

private void Application_AuthenticateRequest(object sender, EventArgs e)

{

if (HttpContext.Current.Request.Headers["HTTP_OBLIX_UID"] != null)

{

NameValueCollection coll = HttpContext.Current.Request.Headers;

string midmsUser = coll["HTTP_OBLIX_UID"];

HttpApplication app = (HttpApplication)sender;

string[] roles = new string[1];

roles[0] = "viewer";

GenericIdentity id = new GenericIdentity(midmsUser, "Forms");

GenericPrincipal p = new GenericPrincipal(id, roles);

app.Context.User = p;

}

}

private void Application_PreSendRequestHeaders(object sender, EventArgs e) {

HttpApplication app = (HttpApplication)sender;

if (app.Response.RedirectLocation != null) {

if (app.Response.RedirectLocation.Contains("AccessDenied.aspx?Source") &&

app.User.Identity.Name == "Visitor") {

app.Response.Redirect("/_layouts/login.aspx?ReturnUrl=" + app.Request.RawUrl);

}

}

}

public void Dispose() {

}

}

}

Now, create a strong name key for this module. This key will be used later in webconfig, so SharePoint will honor this code. The snaps shot is taken from Visual C# express studio. Select the Project Properties :-

Enter the KeyName here.

From the dropdown select new and enter the Key file name (say OamHttpModule) in the popup box. Next build the solution. Building the solution will result a .dll file (say OAMHttpModule.dll). Now register this key in Window Assembly. From command prompt type "assembly". Drop the OAMHttpModule.dll to assembly window (shown below) from the solution area.

Right click to get "OamHttpModule" properties , note down the generated public key token.

This Public key token value will be used in webconfig file.

Step 2 : Web.config Changes

We have completed building the OAMHttpModule.dll. Let's include it webconfig so SharePoint will able to access it.

Step a : Include HttpModule in webconfigAdd HttpModule class name under <httpModules> tag

<httpModules>

:

:

<add name="OamAuthenticator" type="OamHttpModule.OamAuthenticator,

OamHttpModule,

Version=1.0.0.0, Culture=neutral, PublicKeyToken=57773ac73696c406" />

</httpModules>

Mention the Public Key Token copied from Assembly window. SharePoint will not allow this code to run inside without this public key token.

Step b: Change the error display setting in webconfigCHANGE under <SharePoint><SafeMode… tag

<SafeMode MaxControls="200" CallStack=" false " DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">

TO

<SafeMode MaxControls="200" CallStack=" true " DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">

CHANGE under <system.web> tag

<customErrors mode="On" />

TO

<customErrors mode="Off" />

Step c: Change the trust level in webconfig so the HttpModule can be executed

In the web.config

CHANGE under <system.web> tag

<trust level="WSS_Minimal" originUrl="" />

TO

<trust level="WSS_Medium" originUrl="" />

Restart the IIS server.

2.OAM IntegrationI am assuming that you are familiar with Webgate setup for IIS server. After completing the Webgate set up for IIS (that hosts SharePoint), define appropriate URL policy for SharePoint on OAM access manager.

Let's test the setup.

Step 1: user enters the SharePoint URL http://mde-mossdev:87/ protected by Oracle's form authentication.

Step 2: The webgate then intercept the URL and check for the authentication policy. Since the authentication policy is defined as a form, it displays the configured form based authentication screen. User put his credentials; webgate then validate it and allow the user to access SharePoint URL.

Step 3: At this point our custom HTTPModule read the USER_ID from header (set by OAM after the authentication) and creates a GenericPrincipal for SharePoint and set the SSO token in the browser so user can have single sign on with other applications. Below is the screen, which shows the SP home page with the above said user already, logged in (see "Welcome Celuser1" in the screen top right hand side corner).

Yep, we are done ….

Technorati : SharePoint HttpModule
Del.icio.us : SharePoint HttpModule
Zooomr : SharePoint HttpModule
Flickr : SharePoint HttpModule

SharePoint with Sun LDAP as Membership

Why someone will attempt to set up a SharePoint site with a Sun's LDAP as its user database? There could be number of possibilities in the real world requirements. Our recent requirement was to set up a SharePoint server for external users (non - employee) who are not in our Active Directory. All our externals users are already available in Sun LDAP. So we decided to have LDAP as SharePoint user's database. Now, how to make SharePoint happy with Sun LDAP as its user provider. Here are some quick steps from my learning.

Step 1 : Provide the LDAP connection detail in web.config file of IIS server that hosts your SharePoint.

Step 2 : Change SharePoint authentication to Form and provide the LDAPMembership name.

Step 3 : Change the IIS 'Directory Security' authentication set up to Window authentication.

Step 4 : Finally select LDAP user(s) as site owner or other SharePoint defined roles.

Step 1 : Changes in Web.Config file

:

:

<membership defaultProvider="LdapMembership">

<providers>

<add connectionUsername="cn=oblix" connectionPassword="password" name="LdapMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="192.168.1.78" port="389" useSSL="false" userDNAttribute="entryDN" userNameAttribute="uid" userContainer="dc=educ,dc=mde" userObject"Inetorgperson" userFilter="(Object)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />

</providers>

</membership>

</system.web>

:

:

Make sure of no line breakage for the entire <add …/> entry. Do an iisreset from the command prompt.

Step 2 : Change SharePoint authentication from Windows to Forms.

Now change the authentication from Windows to FORM. Again you are changing this for your SharePoint site that you just provided the LDAP Membership; NOT for SharePoint admin website. Go to Central Administration > Application Management > Authentication Providers > Edit Authentication.

è Change the "Authentication Type" from 'Windows' to 'Forms'.

è Check the "Enable Anonymous Access".

è Enter membership provider name as "LdapMembership". This is the tag we just configured in web.config

è Keep the RoleManager name as blank.

è Select NO for client integration.

Do a iisreset from the command prompt.

Step 3: Some setting in IIS Properties

Select your IIS properties and navigate to 'Directory Security'. Check the option 'Integrated Window Authentication'. LDAP authentication will not work without this change.

Do a iisreset from the command prompt.

Step 4: Select users from LDAP and assign them site ownership and other roles

Now your SharePoint site is connected to LDAP. So the site owner(s) required to be selected from LDAP.

From the Sharepoint Application Administrator screen select the website and Navigate to 'Application Management' > 'Site Collection Administrators' >

The LDAP user list can be pulled up directly. Of course LDAP connection set up is done correctly as mentioned in the previous steps.

If you have already defined roles inside the SharePoint, you can pull users from LDAP and assign them to SharePoint roles.

Step 5: Finally login to your SharePoint site with your LDAP userId and password.

Now login to your website using the ldap userId and password. If the user is already having assigned role in the previous steps, he gets in to SharePoint site based on his role. Otherwise user sees "Authorization Failed" message and asked to request an Role/ access.

Technorati : LDAP, SharePoint
Del.icio.us : LDAP, SharePoint
Zooomr : LDAP, SharePoint
Flickr : LDAP, SharePoint