When using a older Access Server SDK (7.0.4) with a newer Access Server (10.1.4) running in backward compatibility mode recently, the Access Server SDK always returned cookies that were logged out. The reason turned out to be because the time was never set on the machine the SDK was installed on.

However, the Access Server SDK installed correctly when it was installed. In previous incarnations the Access Server SDK would have never been able to be configured properly if a significant time difference existed.

This definitely falls squarely in the realm of user error, as the documentation clearly stipulates that when cert or simple mode are used the times have to be synchronized between client and server. In previous releases though you would never have been able to complete the SDK configuration. I can only imagine this has something to do with "backward compatibility" mode.

You create a change attribute workflow. Call it as a portal insert and it works. By work i mean updates the user's entry in the underlying directory when you change the value and click the save button in the OAM UI.

Having demonstrated successful configuration, your real objective is to invoke this through IdXml. So you create the IdXml and test it out. It seems to work, however, the attribute in the underlying directory is not changed.

It turns out if you cannot read the attribute you cannot request it to be changed via IdXml. However, it works if you request the change attribute using a portal insert instead. Sure enough if you test it with a canIRequestUserAttrModification request it will return Denied if you do not have read access.

This is an odd problem. And I am not going to dump any more time into it. But if you change the attribute so that the participant has read access on the attribute everything works as expected.

My specific situation involved a change attribute workflow where the participant was self.

Labels: AAC, Change Attribute, IDXML, Workflow

In order to be able to search for deactivated users, the logged in user need to be a participant in a reactivate user workflow definition.

If the user is not a participant in a reactivate user workflow then the following message will be received when the "Deactivated User Identity" button is clicked:

You do not have sufficient access rights.

Labels: Deactivate, OAM, Reactivate

Here are a few simple notes for handling OID indexes. If you want to search on an attribute in OAM where the data is stored in OID it must be indexed. Sometimes you might want to remove and then possible re-add an index. Index adding and removal can be handles with LDIF, however, if you need to recreate an index on existing data then you need to use a command line tool called catalog.

Index an attribute

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: attributename
-

Remove an index

dn: cn=catalogs
changetype: modify
delete: orclindexedattribute
orclindexedattribute: attributename
-

Re-index an attribute
that was previously removed. If you remove an index form an attribute and the data remains and you need to re-index the data in place then you need to use the catalog command line tool.

$ORACLE_HOME/ldap/bin/catalog connect=oiddev add=&quotTRUE" attribute="attributename"

Unwilling to perform
If after the attribute has been re-indexed the directory server will still not allow it to be searched and returns an unwilling to perform error, try restarting the OID gateway.

$ORACLE_HOME/opmn/bin/opmnctl restartproc ias-component=OID

Current Indexed Attirbutes
Use ldapsearch to get the current indexed attributes

ldapsearch -h localhost -p 389 -x -s base -b "cn=catalogs" "objectclass=*"


Labels: Index, OID, Reindex