HowTo: Separate LDAP servers for internal / external employees

HowTo: Separate LDAP servers for internal / external employees

Hi all

while planning many IC5 updates nearly all customers think about how to benefit from the external feature.
But it is not that easy to simply say: “okay, let´s invite some externals”… these users need to be registered in the configured LDAP Server.

And here we might have a problem… There are several disadvantages when using only one LDAP server:

  • Security concerns
  • Administrative overhead
  • When using a self registration app the customer needs to allow write access for its LDAP server – which feels like a big risk for many administrators cause their sensitive LDAP structure could be destroyed.

… and some more.

In my position as IT-Architect I have to advise my customers when it comes to such concerns. And a solution for this is rather easy to implement 😉

simply install SDS 6.3.1 (free of charge, as it comes with your IBM Connections license) and store your external users in this directory

I want to roughly show what you need to do / change want to make use of this “idea”:

1) setup the SDS server

2) configure the 2nd LDAP Server as federated repository in WAS / ISC (take care that you do not have duplicate UIDs in both LDAP servers)

external1

3)  duplicate the tdisol folder and rename both folders to e.g. (tdisol_int and tdisol_ext):

external2

4) Make the following changes to the corresponding tdisol folders

–> tdisol_int

This holds your customers LDAP information (make the changes to profiles_tdi.properties, map_dbrepos_…)

IMPORTANT – set the following three properties  in profiles_tdi.properties to “true” – without it a sync of 2 different repositories is not possible

external3

sync_store_source_url --> Stores the LDAP source URL in the profiles database (LDAP Server + searchbase + searchfilter ...)

sync_source_url_enforce --> Makes the assemblyline only synchronize entries that match the current "LDAP source URL" - through this you can synchronize more than one LDAP source without everytime inactivating other users

source_source_url_override --> overrides the force to match the "LDAP source URL". This is important, when you e.g. change the searchfilter - then the entries gets synched if a matching UID / GUID was found

–> tdisol_ext

This holds your SDS LDAP information – external users (make the changes to profiles_tdi.properties, map_dbrepos_…)

IMPORTANT – set the following three properties  in profiles_tdi.properties to “true” – without it a sync of 2 different repositories is not possible

external3

Additionally you need to take care of the following repositories:

external4

Here comes the crucial step! We set the same values for:

source_ldap_url = source_ldap_url_visitor_confirm

source_ldap_search_base = source_ldap_search_base_visitor_confirm

source_ldap_search_filter = source_ldap_search_filter_visitor_confirm

Through this setting you define that all users from the defined search_base will be treated as external users.

Additionally in order to make this work, you need to set (in the map_dbrepos_from_source.properties file):

external5

As the text already proposes, you do not need to take care to reset the “_visitor_confirm” properties…

5) Now… let`s test the whole thing

tdisol_int:

external6

Okay, cool… No members inactivated 😉

let`s try the external tdisol too:

external7

And yes, this works too. No changes to the LDAP … So no users got inactivated. This is only possible, when you set three mentioned “sync_store…” / sync_source_…” sync properties to “true”

6) another verification that externals are externals and internals are internals

When you take a look at the IBM Connections Profiles database (EMPLOYEE table), the attribute PROF_MODE is “1” for EXTERNALS and “0” for INTERNALS.We can easily verify this by issuing the SQL-query:

INTERNALS (UIDs are shortened):

external9

 

EXTERNALS (UIDs are shortened):

external8

7) automate it

Now create crontab entries for both “sync_all_dns`s”. These should not be executed at the same time! You could use the same lock file location – as it is used in the sync_all_dns`s script:

external10

Replace the LOCK_FILE variable with a shared folder e.g. /ibm/TDI/V7.1.1/sync_all_dns.lck in BOTH tdiol`s.

You also need to change the path in the script clearLock.sh in BOTH tdisol`s:

external11

Then you cannot start both tdisol`s sync_all_dns Assembly Lines at the same time.

8) Resumé

Now we can authenticate and synchronize external users from an additional LDAP server. In my opinion this make a lot of sense for most of the IBM Connections users. But it even makes more sense, when you have a selfregistration app in place, where externals can register and the administrator simply needs to confirm the new account. Good that GIS AG already has this selfregistration app for IBM Connections 😉

6 thoughts on “HowTo: Separate LDAP servers for internal / external employees

  1. Do you have a part number or link to download the SDS package? We are using the limited entitlement of IBM Connections 5 Files and Profiles.

    • HI Zack,

      You can find the detailed download document for IBM Connections 5 here:
      http://www-01.ibm.com/support/docview.wss?uid=swg24037654

      IBM still calls the package “TDS” – Tivoli Directory Server, even tough it has been renamed to “SDS” – Security Directory Server
      SDS 6.3.1 has the partnumber:
      (CIS17ML ) IBM Security Directory Server 6.3.1 with entitlement (ISO File) for Linux x86-64 Multilingual

      You can download the iso file, where you have everything you need (eWas, SDS, DB2 …) – but please check, if you`re allowed to use this package with the limited entitlement.
      Julius

  2. Thanks Julius, I knew this time will come, and you will be helping me to deal with TDI – Connections fun

    • HI Marco,

      I wrote some findings about this in my blog post for the IBM Connections 5 release –> http://techblog.gis-ag.info/2014/08/04/my-experiences-with-ibm-connections-5-part-2/

      The access is controlled by the application. Each application has the external flag in its database table so that the application knows if this is an internal or external user. How exactly the differentiation is done… I have no idea 😉

      But the reaction of the applications when accessing the features directly as an external user is inconsistent.
      I got into contact with the developers and I got the following answer:

      “We have written code to prevent users to access areas they do not have access to, even if they use the URLs. Our concern was to make sure that a company’s data would be safe, even if someone tries to use a URL to access an area that they would not have access to.

      From your email, it sounds like the data is being protected, but you are seeing some inconsistency in the behaviors:

      forums – access denied
      wikis – redirect to communities
      activities – I can see this feature as external user but no content is visible then

      I will notify the team and we can work to fix the inconsistencies.

      We do not currently have a way to customize this behavior. ”

      I did not further check if this is fixed in CR1 or CR2 but I believe it is not.

Leave a Reply

Your email address will not be published. Required fields are marked *