import

[Popleys]

Hi There,

Am trying to export a specific application domain from LAB env and importing it into Dev env and able to import successfully and could see all the policy-related objects in QA alike dev structure.But the reality is, it doesn't work which mean the policy doesn't get triggered at all, if a protected resource is access within that domain, if I again re-create it manually it works.Is there any bug with this kind of import option? The below are the syntax am using to export and import it.

 

XPSExport Test_App1Domain.xml -xo CA.SM::Domain@03-000901d2-07ca-1757-b609-00017f004087 -npass –vT

XPSImport Test_App1Domain.xml -validateOnly -npass –vT (After this validaiton success msg,running the below one)

XPSImport Test_App1Domain.xml  -npass –vT

 

 

Sm version being used is 12.7 

[raope01]

Hi, 

 

Post importing the domain, can you check in the environment, whether the agent corresponding to the domain exists or not ? 

 

Regards,

Ram,

[raope01]

Apart from checking the above, reproduce the issue and send us the Policy Server Trace log as well, ?

[raope01]

Hi, 

Could you send the Policy Server Trace log as per my previous update, 

 

Regards,

Ram,

[Popleys]

Sorry for the delay could not reproduce it. Essentially this we noticed a month ago and when we look at the logs of agentTrace & Smtrace, I couldn't see anything logged about this communication, which means it's idle, in other words the policy didn't trigger for the requested resource, then we did manully it worked.This for not all domains out 5 domains 2 of this issue which means this 2 domain has custom code and regular expression.

[Legacy User]

A Domain references other objects in the CA-SSO environment. In a standard configuration we are talking about:

• Agent
  • This is determined by a parameter in the Web Agent's ACO (DefaultAgent or Agent)
• User Directory - Referenced in the Domain but not actually part of the Domain
  • The User Directory is actually referenced not by name, but by a unique value called an OID.
• Authentication Scheme - Referenced in the Domain but not actually part of the Domain
  • The User Directory is actually referenced not by name, but by a unique value called an OID.
• Global Objects

When I Import a Domain, I do need to go in and modify the domains. Sometimes it is just to remove UserDirectory1, then add UserDirectory1; thus fixing the OID. I do the same for the Authentication Scheme. There are ways you can set the OIDS to match between test and prod environments, or do a selective edit of the export file prior to import.

 

There are pros and cons to linking by OID vs. name, export/import is one of the cons. There are different options to help find Policy Store objects that have OIDs to non-existent objects (often called ghost objects).

[Legacy User]

The latest versions of CA SSO do not purely rely on OIDs any more.

 

The Design has changed (pretty sure it was sometime starting R12.5). CA SSO XPSImport does a "NAME" match before import. If the "NAME" and "OBJECT TYPE" matches, but OID differs then CA SSO maps it using the NAME.

 

Hence.......

 

DEV-ENV-Pstore

• Domain-1 : OID-ab-1234
• UD1 : OID-cd-1234
• AuthScheme1 : OID-ef-1234

 

TEST-ENV-PStore

• UD1 : OID-cd-5678
• AuthScheme1 : OID-ef-5678

 

Now if I export Domain-1 from DEV and import into TEST. CA SSO XPSImport in TEST will identify that in XML file being imported Domain-1 is mapped to UD1 (OID-cd-1234), however within TEST-ENV-PStore UD1 already exists with a different OID (OID-cd-5678). So CA SSO XPSImport will map Domain-1 to UD1 using a NAME match in TEST-ENV-PStore. Hence we no longer need the custom logic outside of import to do the OID translation. Same goes for the Auth Scheme.

 

 

Regards

Hubert