Managing LDAP changes in Connections Wannes Rams Ramsit

About me www.ramsit.com/blog twitter.com/wannesrams linkedin.com/in/wannesrams www.ramsit.com Socialconnections.info

Overview • Task: Migrate from 1 ldap to another
 • Difficulty: DN for users changes
 • Migrate as is à Issues
 • Solution

Disclaimer

Migrate from 1 ldap to another

Difficulty: DN for users changes • Customer LDAP team decided to change the user DN from 
 
 
 
 To


Issue #1 • If using default as GUID and no special config • à Users deactivated à New users

Issue #2 • Cognos Administrative user is an LDAP user • Does not exist on new system • Even if you create identical user and have custom GUID, you will have to remove and re- add from application roles due to different realm


Issue #3 • IBM Forms field mapping for Displayname
 • Our old LDAP had another attribute name for the users displayname then the new one.
 • As IBM Forms does not use the Profiles DSX services, you need to change the IBM Forms config

Issue #4 • Users will lose all access to CCM files
 • With the default configuration (no custom guid) Filenet will generate new users (just like the TDI Sync for profiles).

Solution: General approach • Implement custom GUID GUID LoginName • We already had a custom GUID (best practice) for users • Add one for groups as well if you plan on using groups in connections !!! • Do this before you add CCM to your deployment

Solution: General approach • The Identifier for Users and Groups in Connections is the GUID
 • A GUID for an object does not change

Solution: General approach • If an object is deleted, and recreated in LDAP, that object is recreated with a NEW ID (GUID) • Need to choose something “other” than the default! (e.g. uid, employee ID etc). • Custom GUID must follow following guidelines: • Must be unique and static • Must not exceed 256 char, for better performance se fixed length • Must be one to one mapping with the object
 http://www-01.ibm.com/support/knowledgecenter/SSYGQH_4.5.0/admin/install/ t_specify_dif_guid.dita?lang=en

Solution: General approach

Solution: General approach • Must exist in LDAP Schema and in WebSphere Virtual Member Manager (VMM) schema • If not, add the attribute to the wimxmlextension.xml to make it available to WebSphere • Connections must be told about these attributes • LotusConenctions-config.xml • Must be specified in map_dbrepos_from_source.properties • Must be available in each object class assigned to your user or group

Solution: General approach

Solution: General approach

Solution: General approach • On WebSphere
 level, 
 wimconfig.xml is
 the place to be


Solution: General approach

Solution: General approach • We used a non-standard VMM Attribute for groups à wimxmlextension.xml

Solution: General approach • Corresponding LotusConnections-config.xml • On Connections you can override using LotusConnections-config.xml • I prefer not to override, especially when also using IBM Forms, IBM Cognos and IBM Filenet

Solution: #Issue 1 • The TDI Solution directory provided offers a solution to migrate your users (even if no custom GUID)
 • You can configure a mapping field that the sync process can use to identify the user in the old and new LDAP
 • Source LDAP is stored in the Profiles DB

Solution: #Issue 1 • Before Migration • Change following parameter in profiles-tdi.properties • Sync_updates_hash_field • And make sure you enter a unique cross LDAP value

Solution: #Issue 1 • Change all other needed parameters in the config file (LDAP, base entry, credentials, …) • Make the necassary changes to map_dbrepos_from_source.properties • Run the sync_all.dns script

Solution: Issue #2 • You will need to backup
 all users in the Cognos
 Admin role

Solution: Issue #2 • Update admin user and password in 
 /apps/ibm/bin/CognosConfig/cognos- setup.properties

Solution: Issue #2 • Run the following command while Cognos is running • Add the new account as admin in WebSphere • Update the J2C alias • Re-add Metrics Admins and remove Everyone

Solution: Issue #2 • Remove and add users from WebSphere roles


Solution: Issue #3 • Check /apps/ibm/data/Forms/extensions/ Builder_config.properties and verify that this is reflecting your new LDAP à Restart

Solution: Issue #4 • Make sure you have custom GUID setup for Users and Groups à It is that simple
 • If you do not, your users will lose all access to libraries and documents
 • Don’t listen to IBM, they tell you you need a Filenet services team* for this migration

Solution: Issue #4 • Check Waltz debug log to see if FileNet picks up the Custom GUID • Download and copy log4j.xml to your server and place it in the Application server log folder • Add the following arguments to your JVM configuration
 -Dlog4j.configuration=/apps/ibm/data/WebSphere/profiles/ AppSrv01/logs/log4j.xml -DskipTLC=true

Solution: Issue #4 • Screenshot JVM arguments`…


Solution: Issue #4 • Restart Filenet and check waltz.sonata.trace.log • Custom User Id Attribute is set to UID • Custom Group Id Attribute is set to null. This will change after migration to new LDAP

Solution: Issue #4 • Check FileNet SID’s for some users before migration as reference • 2 ways to do this • Database: UT_CLBUSERIDENTITYMAPPING (FNOS) • Command line: generateSID.sh

Solution: Issue #4 • After migration, check again for the same users after uploading a document with that user. If configuration is good you should see the user only once…

Recap: Migration steps • Backup Cognos and CCM Security • Migrate Profiles using TDI • Migrate LDAP in WebSphere • Migrate Cognos • Migrate Forms • Migrate CCM • Clearscheduler on all db’s

Questions?

Resources • Special thanks to Gabriel Nkuite, IBM France • http://www.slideshare.net/gabturtle/ connections-and-directory-integrationURL • http://www-01.ibm.com/support/ knowledgecenter/SSYGQH_4.5.0/admin/ install/t_specify_dif_guid.dita?lang=en

PLATINUM & CHAMPAGNE SPONSORS GOLD SPONSORS SILVER SPONSORS BRONZE SPONSORS