Howto change the name of the Secret Store shared secret name

  • 7013070
  • 19-Aug-2013
  • 18-Sep-2013


NetIQ Access Manager 3.2
NetIQ Access Manager 3.2 Support Pack 2


Any Administrator has created a Secret Store Shared secret name using IDP Server -> Shared Settings -> Custom Attributes -> Shared Secret Names. After creating this shared secret name and corresponding attributes, a formfill policy is used to successfully write the secret values to this shared secret ie.users can hit a formfill policy that references this shared secret, enter the credentials the first time, and have those credentials saved for re-use.

If the Administrator later decides that he/she wants to change the logical name of the shared secret name, there are no UI options allowing this change to be made. There does not appear to be any option to change the shared secret name without losing the shared secret information ie. having users re-enter the credentials to be saved again under the new name.


It is possible to change the shared secret name, but a number of manual instructions are required. In the following example, the shared secret name that was originally configured under IDP Server -> Shared Settings -> Custom Attributes and under Shared Secret Names, I had the following



bootcamp-secrets (

bootcamp-secret-username, bootcamp-secret-password)




This info is actually written to the "nidsCustomCredentialNames" attribute under the following conatiner in the Admin Console configuration store "cn=nids,ou=accessManagerContainer,o=novell"


 <objectDN name="cn=nids,ou=accessManagerContainer,o=novell">
            <attribute name="nidsCustomCredentialNames">

I also had a user that was authenticated and who had already written the credentials to the shared secret store for the above shared secret profile. This info is available under the local AC eDir at




where SCC* is the cluster configuration for the IDP server. You can use an LDAP browser to view the baseURL attribute and confirm that this is the IDP servers config, and not the ESP! Anyway, under this location, you will find 100s and possible 1000s of nidsGUID entries at URS, one for each user who's secret we store. Note the following:


- the nidsGUID ID represents the GID of the user in the user store that we are authenticating too, but is not that important in this case here.

- the nidsWsfSS ID contains the secret store information, encrypted with the approproate key. Although the value is very difficult to decrypt, the name are not eg.


<cp:Secrets xmlns:cp="urn:novell:credentialprofile:2005-03"><cp:Secret><cp:Name>bootcamp-secrets</cp:Name><cp:Entry><cp:Name>bootcamp-secret-password</cp:Name><cp:Value encryptionType="PBEWithMD5AndDES">EE7T6EX+dP0=</cp:Value></cp:Entry><cp:Entry modificationTime="2013-08-19T10:59:09Z"><cp:Name>bootcamp-secret-username</cp:Name><cp:Value encryptionType="PBEWithMD5AndDES">E19H41Vcu55M8sHLC55E9Q==</cp:Value></cp:Entry></cp:Secret></cp:Secrets>



There does not appear to be any other location where the secrets are stored. We can confirm this with an output and seearch for the secret store string that you are looking to change. Assuming that this is the case, we need to change the name in two different areas


- the nidsCustomCredentialNames attribute at "cn=nids,ou=accessManagerContainer,o=novell" and

- the nidsWsfSS  attribute for each user under the "ou=LibertyUserProfile0,ou=SCC*,ou=cluster,ou=nids,ou=accessManagerContainer,o=novell" container

This is what I did ...

a) changed nidsCustomCredentialNames as follows


 <objectDN name="cn=nids,ou=accessManagerContainer,o=novell">
            <attribute name="nidsCustomCredentialNames">

b) modified the nidsWsfSS  attribute with


<cp:Secrets xmlns:cp="urn:novell:credentialprofile:2005-03"><cp:Secret><cp:Name>NAM-bootcamp-secrets</cp:Name><cp:Entry><cp:Name>bootcamp-secret-password</cp:Name><cp:Value encryptionType="PBEWithMD5AndDES">EE7T6EX+dP0=</cp:Value></cp:Entry><cp:Entry modificationTime="2013-08-19T10:59:09Z"><cp:Name>bootcamp-secret-username</cp:Name><cp:Value encryptionType="PBEWithMD5AndDES">E19H41Vcu55M8sHLC55E9Q==</cp:Value></cp:Entry></cp:Secret></cp:Secrets>


c) went back into the Policy that referenced this secret store link and manually re-linked the input field value that had dissapeared with the changes that I had made ... a very quick operation


d) logged back in again and hit the protected resource to verify that the old secret was still filed correctly - which it was.



So we could create a script that changes references to the old name to be the new name, and then go into the iManager tool to re-link the policy. Obviously we would have to test this there but it does appear to be working fine ie. we are not losing any of the secrets.