CA Service Management

Warning:  Long post

SDM 14.1.03 (no xFlow)

Windows environment.

Customer has current Windows AD DOMAIN_A where all users and the old SDM application reside. This was the only domain. All users were created manually or using the existing LDAP settings in Options Manager to auto create when userid was found in the domain and that is how their ldap_dn value was populated.

The customer is merging/acquiring other AD domains and have created a new DOMAIN_B to eventually be the top of a forest to include all the users in DOMAIN_A and new DOMAIN_C and DOMAIN_D.  The new SDM servers are in this DOMAIN_B.  There are already trusts between these domains. They will be moving accounts from DOMAIN_A to DOMAIN_B in sections.  There are test accounts in DOMAIN_B

After using pdm_export and pdm_load to bring over all contacts from the old SDM, I enabled the LDAP settings in Option Manager in the new SDM server and restarted SDM services.  I tested the trust relationship by setting External Authentication / OS-Use Operating System authentication for a test access type and modifying their userid to 'DOMAIN_A\userid' and they can login.  I verified that the DN credentials to all domains using

  pdm_ldap_test -s DC=DOMAIN-xx,DC=com

changing the domain for each test and this returned accounts from all domains.

I modified the cnt schema in WSP and created the ldap_mod per TEC489029: "How to get pdm_ldap_sync to synchronize the ldap-enabled/disabled status with contact's active/inactive status in servicedesk?" Knowledge Base Articles 

I then followed the instructions in the Wiki: 

How to integrate CA SDM with LDAP - CA Service Management - 14.1 - CA Technologies Documentation 

at section "Manage LDAP Servers Using the LDAP Configuration Utility" by first creating a name for the default ldap domain (DOMAIN_B)

pdm_options_mgr -c -a pdm_option.inst -s LDAP_DOMAIN -v DOMAIN_B
pdm_options_mgr -c -a pdm_option.inst -s LDAP_DOMAIN -v DOMAIN_B -t

and restarted SDM services.

I then ran:

    pdm_ldap_import -n DOMAIN_B

This imported the test contacts from DOMAIN_B and prepended "DOMAIN_B\" to each userid.

I then ran:

   pdm_ldap_sync -n DOMAIN_B

and all the contacts that were deactivated in DOMAIN_B were set to inactive in SDM.

Next, I added the DOMAIN_A using the

    pdm_perl pdm_ldap_config.pl

utility.  Adding the same values as the default, except changing the NX_LDAP_SEARCH_BASE to match the new DOMAIN_A.  I verified these new values were in NX.env and restarted services.

Now, when I try to run:

    pdm_ldap_import -n DOMAIN_A

it fails and I get:

    pdm_ldap_import: Method got_record in Ldap_Catcher failed ()

in stdlog.

I've researched this online and I do not have any spaces between elements in my ldap_search_base. There are at least two open questions here in the Community that don't have an answer (or they were resolved and the OP didn't update)

LDAP Problems importing contacts of more than one LDAP Domain 

SDM 14.1 PDM_LDAP_IMPORT error 

I have a case open with CA Support but they have had it for several days and I am waiting on them.They keep asking me to walk through the procedure I used, so I decided to post it here for more eyes.

Has anyone successfully complete multiple domain integration and, if so, can you post the correct procedure or point out what I am missing?

thanks,

J.W.

We're working with JW on this via the support case in question. Will update it once it gets sorted out

_R

At this point, we are waiting for a meeting between CA Support and the customer's AD Admin to discuss the AD relationships.  In the meantime, does anyone have any notes on the procedure I've outlined above?

J.W.

Hi J.W.

May I ask which AD is the current main AD of the SDM ? The AD that you configure in the option manager.

If domain_A is the main AD, can you try just pdm_ldap_import without any other parameter?

Best regards,

Conan

Thanks, ConanLam

The current main AD in SDM is DOMAIN_B.   This is where the new SDM resides. There were no issues with the import/sync as this as the 'default' without setting NX_LDAP_DOMAIN.

I did test by setting the Options Manager to DOMAIN_A and completed an import/sync (again, without setting NX_LDAP_DOMAIN) without any parameters.

Everything changes once I set NX_LDAP_DOMAIN and add another domain.  At that point, it didn't matter if the Options Manager was using DOMAIN_A, the 'named' domain syntax fails.

I am now constrained on making changes as they have gone live and we are either going to schedule a bulk transfer of contacts from DOMAIN_A to DOMAIN_B and update their ldap_dn and userids manually OR else they will migrate in batches and they will use the Merge LDAP function to update their ldap_dn and userid from the GUI.  (I added the ldap_dn field to the contact detail screen for Administrators which will save a few steps if they have a list of the new DNs).  We are not running import/sync at this point to prevent any accidental inactivation of accounts.

J.W.

Bumping the topic here and elsewhere as I need to know if anyone has this working in SDM (alone or with EEM).  Note, I am talking about the import/sync function across multiple domains and not just authentication into the application.

thanks,

J.W.

Not sure if it is possible, standart ldap import functionality is quite limited so 10 years ago we wrote our own import utility and it is still better than original one when you need to import organization structure and other classificators from LDAP or multiple LDAPS. Unfortunately i can not share it with you since this is the property of the company. But my suggestion would be to write your own application. You can get a lot of functionality by using standart LDAP filters in conjunction with pdm_deref and CA webservices.

Thanks, Gutis

I'm sure I can script basic import and sync by manipulating the userid and ldap_dn fields before and after the SDM utilities run - as rusty and inelegant as my scripting skills are - but all I need is for the SDM utilities to work as documented - or - if my understanding of the procedures are wrong - or - if no one is able to get this to work for CA to withdraw it as delivered and the Wiki and the Community updated to reflect this.

J.W.

Hi J.W.

Finally managed to solve your problem? Currently I present the same issue when trying to connect multiple LDAP, the documentation and the own CA are not clear on how to achieve this.

Thanks

No.  We did resolved the Ldap_Catcher failed ()  error message, however..  The solution was to not create a 'named' instance of the default LDAP_DOMAIN .  This should be left with no name as it is out-of-the box when set up using Options Manager.  Since the majority of users when we started were in DOMAIN_A, this is the default.  CA then added DOMAIN_B as a named instance using the Wiki procedures.

I then cobbled together a PowerShell script to pull all the users and their DN from DOMAIN_B.  I used Excel to do a lookup of the matching userids in SDM and update their ldap_dn with the one in DOMAIN_B.  Then, prepend DOMAIN B\ to their userid so they could authenticate.  (pdm_cache_refresh all around)

When no issues were reported, I then ran my pdm_ldap_import script against DOMAIN_B but limited to just the last names starting with 'a'.

Results:  So far, no 'Employee' users have reported problems but every analyst who logged in who had an updated ldap_dn ended up have a duplicate account created on the first login after the update - and this was the 'Employee' access type.  The kicker is that the new account is using the EXACT SAME userid. (Force unique userid is installed).

So, I've thrown this back over to CA Support.

J.W.

Maybe I didn't catch on your long post and may look stupid but did you try to connect to the global catalog of the Domain B DC vs. querying  directly domain A?

Global catalog of DOMAIN_B must contain the records for all your domains in the forest if trust are set correctly.

Agree with youGutis we have move  aways to our  own tools many years ago due to the limited functionality of this ldap_sync.

In fact we have never used as this has never meet our requirements)

Hope this help

/J

No problem - I'm not too proud to admit I may have missed something.

Yes, we are going against the Global Catalog ( on port 636 ).  I can test by using pdm_ldap_test and just change the search base to the appropriate DC and it brings back anything I search for.

J.W.

Hi J_W

Port 636 is usualy for ldaps 

Global catalog is using 3268 fo  plaintext and 3269 for SSL.

Using Global catalog there is no need to change your base search to specific domain. All users for all domains in the forest will be returned.

Hope this help.

/J

Thanks.  I commented the same to the customer and they said it was pointing the the Global on that port.  Hmmm.

J.W.

Hi J_W, We experienced exactly the same situation 5 years ago when we acquired a 2nd organization. We had two ADs with a trust between the two but for several months we had to live the ability to authenticate and syncronize users with both domains. Quickly the provided CA utility (pdm_ldap_import / sync) limited us on the possibilities we had. We used EEM to create a proxy server between two domains to manage authentication with products. The advantage is that once EEM is configured as an AD proxy, when you use it in the servicedesk configuration as ldap_host, the pdm_ldap_sync and pdm_ldap_import command is able to bring back users in domain A and domain B even if they Have a different ldap_dn. However, the day the users are migrated to domain B and you leave pdm_ldap_import roll, you will have duplicates in your ca_contact table. We had to adjust via SQL queries. I just wanted to add my experience ... and maybe it will be useful ...

Thanks a lot.  This may be a solution for one customer with the full license.  I'm not sure if this current customer's license includes EEM.  It may be included at all levels now . . . or CA won't complain if it resolves the issue.

Did you get duplicates even if you scripted an update to the user's ldap_dn to the DOMAIN_B after the move but before the pdm_ldap_import and sync?  If this was working as advertised then the contact would not be inactivated because the ldap_dn is current when the import is run and if their userid is updated to DOMAIN_B\userid before the next time they login, then it should not create a duplicate.  But as I mentioned in my reply to jperez, I did this and duplicates were created anyway.

J.W.