Symantec Access Management

Admin UI updates not seen in any other policy server other than the one that created the object 

10-21-2014 11:27 PM

Problem Summary :

==============

 

Two Policy Servers having their own WAMUI/Policy stores/key stores. Policy store/Key stores are replicated.

Objects created from primary WAMUI (connected to primary policy server ) can't be seen in secondary WAMUI and vice versa.

Replication is confirmed to be working (verified by searching the newly created object using external ldap browser in secondary policy store)

The changes however is seen after restarting secondary policy server.

 

Environment:

==========

SiteMinder version : R12.52 CR1/ R12.52 SP1

Policy store : CA Directory

 

Working Hypothesis:

===============

The way it works is Policy server has an XPS housekeeping thread which regularly (default interval of 5 minute) synchronizes its XPS cache. Admin UI then read the Policy server's XPS cache and displays all the object within it.

However, when doing the XPS synchronization,it only fetches the XPS object which has "modifytimestamp" set. (we have observed this behavior only with CA Directory)

 

Now, in case of CA Directory, by default when a new object is created ONLY "createtimestamp" is set.

That's is why when the XPS synchronization thread runs on the Policy server, it will not be able to fetch the newly created object as it doesn't have the modifytimestamp set.

 

Workaround:

===========

  • From the CA Directory DSA Console execute following command and restart the instance :

        set modify-on-add = true;

        Reference : https://support.ca.com/cadocs/0/CA%20Directory%20r12%200%20SP11-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?set_modify-on-add_command.htm

 

      When the set modify-on-add is true, a "modifytimestamp" attribute is also updated when a new entry is created.

 

  • You can execute "getoper" command on the DSA console to check the current setting for "modify-on-add".

 

Before applying the workaround , if you want to confirm if your issue falls into the bug discussed here, you can perform following two tests :

 

1. Check if the newly created object is displayed in FSS UI. As the FSSUI read only the legacy policy store (and not the XPS store) it displays the object.

2. Check if the newly created object is displayed after modifying it on the primary admin ui. This should get displayed after modifying because then the modifytimestamp will have been updated.

 

Update 11/3/2014 : We have recently discovered another bug with R12.52SP1 release which also might result in the XPS synchronization issue leading to the object being not displayed in other WAMUI.

Update 27/4/2015 : The fix for this defect in 12.52Sp1 has now been delivered in r12.52 Sp1 CR1 release. From the release note :

Updates Made in One Administrative UI Fails to Display in Another UI (128073)

Symptom:

Updates made in one Administrative UI fails to display in another UI.

Solution:

This issue is fixed.

STAR Issue: 21930685-01, 21956903-01, 21957651-01, 21966265-01, 21986117-01

 

 

Hope this helps.

 

Cheers,

Ujwol Shrestha

Statistics
0 Favorited
1 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

03-01-2017 05:21 AM

Thanks for your reply Ujwol.

 

Best regards,

 

Ludovic.

03-01-2017 12:10 AM

Hello Ludovic,

 

Please open a new thread for it.

This issue is applicable only to CA Directory.

 

Regards,

Ujwol

02-27-2017 10:10 AM

Hello,

 

I have the same issue but i'm using an AD LDS policystore.

Can someone help me ?

 

Regards,

 

L

11-12-2016 01:54 AM

This is old thread, but setting up modify-on-add=true using dxserver command line do not actually resolve the issue. It doesn't update the modify timestamp. You will have to add setting in policy store.dxc under settings folder and restart the DSA instance. This will set the modify timestamp for any newly created object.

 

Regards,

12-23-2014 10:48 PM

I tired above steps with no luck. I am using two different policyserver pointing to the same CA Policy store. Two different adminui point to each of the policyserver was used for our testing.

Related Entries and Links

No Related Resource entered.