Symantec Access Management

  • 1.  XPSDDInstall SmMaster.xdd

    Posted Oct 18, 2016 01:47 PM
      |   view attached

    We recently migrated/upgrade our policy server from r12.0 to r12.52 SP1 CR05 and all seemed to be going well. The only thing that we noticed which only happened in our production environment is that after we migrated all of the SAML Service Providers that we created in the r12.0 PS using the Legacy FSS UI, now if I use the r12.52 Legacy FSS UI, all the SAML Service Provider config looks exactly the same as it did before with the r12.0 but when I open these config up using the r12.52 Admin UI under the "Legacy Federation" I noticed that in the "Users" tab there are no users specified for access and also in the "Attribute" tab the attributes that is supposed to show up is not there either. I opened a case with CA and they asked me to run XPSSweeper and based on the result they think that this could be caused by the initial XPSDDInstall SmMaster.xdd that we did when initially installing the r12.52 policy server.

     

    Bottom line is, CA support asked me to run XPSDDInstall SmMaster.xdd again in my production environment but I am afraid that this could possibly cause issues to the policy store or cause some kind of outage. The CA support person said that this "should not" cause any kind of outage or interruption to my production environment but I just want to get a second opinion.

     

    Thanks in advance  

    Attachment(s)



  • 2.  Re: XPSDDInstall SmMaster.xdd
    Best Answer

    Posted Oct 18, 2016 02:08 PM

    Hi Duc,


    It is mandatory requirement to import the XDD and Smpolicy.xml files after upgrading from r12.0 to 12.52. That's quite a jump and the schema and default policy would have a lot of changes.


    You can refer to : 

    https://communities.ca.com/community/ca-security/blog/2016/07/17/tech-tip-ca-single-sign-on-policy-servercr-apply-process


    and yes, importing XDD files should not cause any issues, but if you want to have a poece of mind always take a backup.


    Cheers,

    Ujwol



  • 3.  Re: XPSDDInstall SmMaster.xdd

    Posted Oct 18, 2016 02:55 PM

    Hi Ujwol,

     

    Thanks for the quick response.  Yes, updating the r12.52 policy store scheme with the following scripts was part of our process:

    XPSDDInstall SmMaster.xdd
    XPSImport smpolicy.xml -npass

     

    I am quite sure I had already ran the XPSDDInstall SmMaster.xdd in our production environment prior to the r12.0 policy data export/import.  CA support suggest running this again against our production environment, but I am just a bit worry some because it is our production environment and do not want to take any chances.  But you think that if I backup the policy store data and run XPSDDInstall SmMaster.xdd again then that should be fine?

     

    Also, should I shut down the policy server and then run this or could I run it while the policy server is still running?  We have three policy servers in our production environment with each policy server talking to it's own CA Directory Server policy store so I should only need to run this on one of the three servers right?



  • 4.  Re: XPSDDInstall SmMaster.xdd

    Posted Oct 18, 2016 05:25 PM

    Hi Duc,

     

    I would suggest you to follow the below sequence -

    1. Take full export of SM Policy store - XPSExport -xb XPSExportFullBackup.xml -npass -vT

    2. It would be good idea to take full Env backup as well - XPSExport -xe -xp XPSExportEnvBackup.xml -npass -vT

    3. Run XPSDDInstall SmMaster.xdd -vT

    4. Run XPSImport smpolicy-secure.xml -npass -vT

    5. Take full export of SM Policy store as stated in Step 1

    6. Restart the policy server and run the XPSSweeper to see stale objects.

     

    "We have three policy servers in our production environment with each policy server talking to it's own CA Directory Server policy store so I should only need to run this on one of the three servers right?" - Does it mean each of your policy server is pointing to separate CA Directory Server DSA? Is there any replication in between them?

     

    If all policy servers are referring to same CA directory servers, then you will have it to run it on first server.

     

    Regards,

    VVK



  • 5.  Re: XPSDDInstall SmMaster.xdd

    Posted Oct 19, 2016 08:12 AM

    I agree with VVK for most part.

    I will additionally suggest stopping policy server while you import .xdd file as that is data definition (xps schema) change.

    Also, back up policy store at LDAP/ODBC level just in case.

    If the policy stores are replicated, then it is sufficient to run it only in the master policy store.


    (@VVK -xb is full back up and does include everything : environmental data -xe , policy data -xp and configuration data -xc . So, you don't need to run the second export command)


    Also to add, based on my experience I haven't seen importing .xdd causing any issue so far.



  • 6.  Re: XPSDDInstall SmMaster.xdd

    Posted Oct 19, 2016 01:06 PM

    Ujwol / VVK / Venkata,

     

    Thank you for your advise and information.  A new twist/development with this case. 

     

    As I initially explained, we recently completed the upgrade/migration to r12.52 about three weeks ago in our production environment.  So far everything is working exactly as expected even the federation services.  We have been using the Legacy FSS UI to create SAML Service Provider and also to create SAML Authentication Scheme.  With the r12.52 we have the option to use the Admin UI "Legacy Federation" menu to pull up these SAML Service Provider config and modify them, so one day I was curious and I used the Admin UI to view the config for one of the SAML Service Providers and noticed that there were no users specified for this SAML Service Provider and also the user attributes that is configured to pass as SAML attributes were not listed under the "Attribute" tab, BUT the SAML SSO for this partner still work just fine.  I then contacted CA Support and was asked to run the XPSSweeper and it showed errors related to the federation attributes.

     

    Here is the new development.  After the first XPSSweep that CA Support asked us to run, even though it returned multiple errors "Invalid Attributes", as I get back into the Admin UI and open the "Legacy Federation" menu now I see the users specified in the SAML Service Providers as well as the user attributes.  It appears that the XPSSweep must have updated those SAML Service Providers.  I verified this with the Admin UI on all three of the production policy servers.  I then ran the XPSSweep again on other other PROD policy servers and same results as well, still showing errors regarding invalid attributes:

     

    (ERROR) : [sm-xobsm-01110] CA.SM::UserPolicy@0f-00042125-673b-11b7-956f-87960a161006: [CA.SM::UserPolicy.UserDirectoryLink]: Invalid attribute: [CA.SM::UserDirectory@0e-000df07d-e216-116d-baa7-87960a161006].

     

    So my question is, should I just leave it as is since it is not breaking anything or should I still take the risk of trying to fix this?  As an additional test, I then used the r12.52 Legacy FSS UI to create a new test SAML Service Provider config and then go into the r12.52 Admin UI "Legacy Federation" menu and open up that new SAML Service Provider and I do see the users specified in the "Users" tab and likewise the attributes specified in the "Attributes" tab..

     

    Thanks in advance for you responses.

     

    Duc Tran.



  • 7.  Re: XPSDDInstall SmMaster.xdd

    Posted Oct 20, 2016 04:51 AM

    If it's not breaking anything I would leave it as it is.




  • 8.  Re: XPSDDInstall SmMaster.xdd

    Posted Oct 19, 2016 10:38 AM

    Hi DMT,

     

      I did this update recently as there were new attributes added for WSFED. The following are the steps i have executed.Our policy store environment is OUD multi tenant with replication enabled.

     

    1. I took complete policy store back up by using XPSExport

    2. Created a standalone clean ldap instance by using scheme definitions which are part of XPS and db directories from /siteminder/ ( pick appropriate schema files based on your environment). Better use the CA documentation to configure policy store. Make sure the replication is not enabled with other ldap server instances.

    3. Point your policy server to that newly created policy store instance

    4. Goto XPS directory and install DD ( data definitions and smpolicy-xml)

    5. Stop the policy server (Policy store back copy was extracted from other ldap server, due to this smregistry value for ldap instance overwriting)

    6.import the policy store back up using XPSImport

    7. start the policy server, and take XPS export of the store to make sure all the objects were in place. I feel SM Policy reader good to verify from GUI

    8.If everything looks clean, replicate the new store data with others.

     

    Hope this works, good luck

     

     

    Thanks

    Venkata Kuchipudi