I have a working DS and AM servers. It sems they works great. Now I am exploring the backup/restore functions of ForgeRock Directory Server and I am trying to understand how the restore (dsbackup" restore ...) connects to the used cryptographic keys. But I am a little bit confused.
I use my self signed private CA infrastructure and the certs behind of DS and AM are self signed server cers signed by my private CA.
I configured my AM to use external DS stores for identity and config as well. I remember that it was mentioned that I can use File Based Configuration but it is not clear how to install AM this way at the moment.
Anyway, I logged in to AM as a amadmin and I created a new user, then I executed a DS backup and I got a am-identity-store-ldap_2023-07-21_14.31.31.tar.gz file. Then I droped my ForgeRock stack (docker containers) and I started a fresh one. Then I used the dsbackup restore. After that I see the user that I created earlier using the previous stack. Great.
But there are two thinks that do not work as I expected (or read in the docs):
In this doc it is mentioned that the backup files (or some data in it) are encrypted somehow with the deployment ID or shared-masterkey, not sure which one. But if I create a new DS environment with a completely new deployment ID + pwd how that possible to restore the identity store from the backup gzip file that was encrypted with a different keys? The shared masterkey if I am corrrect is generated based on the deployment ID and its password and if I use the same deployment ID then as I see the shared masterkey is exactly the same in the keystore. But when I start I new ForgeRock docker stack using a new deployment ID I can restore the identity store properly from the backup that was created by a completely different DS instance with different deployment ID. Plus the password of my test user is also correct after the restore because I can login with this user and see my profe using the AM web console.
This question is more importand for me then the previous.
Identity store backup/restore work fine so as a next step I am trying to backup/restore the AM config store LDAP data using am-config as a backend name. The gzip is generated properly. Then I restored the config backup file to a new ForgeRock stack. But after that I am not able to login with amadmin anymore despite the restore run successfully.
I executed another tests to create and restore am-config-store using the same AM_ENC_KEY in the config.properties file as it is mentioned in this doc. But I got the same result. After the config store restore I am not able to login with amadmin user anymore.
What I am missing in Q2?
And if I can restore AM identity store from backup using different shared keys then what is the point of having this shared key?
I have forgotten to mentioned that I am also backing up/restoring the AM secret store directory mentioned here. And I restore AM directories at the same time when I restore the config LDAP store.
o.f.o.s.c.CtsSessionPersistenceStore: 2023-07-21T16:41:07.023Z: Thread[https-openssl-nio-443-exec-10]: TransactionId[1b265278-7174-44a9-aa41-0ef18db71ced-77]
ERROR: Unable to persist session to data store, check documentation for CTS configuration to ensure reads and writes may occur, and all appropriate virtual at
org.forgerock.am.cts.exceptions.CoreTokenException:
[CONTINUED]CTS: Error in data layer
[CONTINUED] at org.forgerock.openam.cts.impl.CoreTokenAdapter.create(CoreTokenAdapter.java:88)
[CONTINUED] at org.forgerock.openam.cts.CTSPersistentStoreImpl.create(CTSPersistentStoreImpl.java:81)
...
...
[CONTINUED] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[CONTINUED] at java.base/java.lang.Thread.run(Thread.java:829)
[CONTINUED]Caused by: org.forgerock.openam.sm.datalayer.api.LdapOperationFailedException:
[CONTINUED]Operation failed:
[CONTINUED]Result Code: Object Class Violation
[CONTINUED]Diagnostic Message: Entry "coreTokenId=5DTytTV0fuWjVd1o0js7j6HWAAU=,ou=famrecords,ou=openam-session,ou=tokens,ou=am-config,dc=hello,dc=com" violate
[CONTINUED]Matched DN:
[CONTINUED] at org.forgerock.openam.cts.impl.LdapAdapter.create0(LdapAdapter.java:194)
[CONTINUED] at org.forgerock.openam.cts.impl.LdapAdapter.lambda$create$0(LdapAdapter.java:183)
[CONTINUED] at org.forgerock.openam.cts.impl.LdapAdapter.monitorToken(LdapAdapter.java:588)
[CONTINUED] at org.forgerock.openam.cts.impl.LdapAdapter.create(LdapAdapter.java:183)
[CONTINUED] at org.forgerock.openam.cts.impl.CoreTokenAdapter.create(CoreTokenAdapter.java:84)
[CONTINUED] ... 138 common frames omitted
[CONTINUED]Caused by: org.forgerock.opendj.ldap.ConstraintViolationException: Object Class Violation: Entry "coreTokenId=5DTytTV0fuWjVd1o0js7j6HWAAU=,ou=famre
[CONTINUED] at org.forgerock.opendj.ldap.LdapException.newLdapException(LdapException.java:241)
...
...
CONTINUED] at java.base/sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
[CONTINUED] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[CONTINUED] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[CONTINUED] ... 1 common frames omitted
[CONTINUED]org.forgerock.am.cts.exceptions.CoreTokenException:
CTS: Error in data layer
at org.forgerock.openam.cts.impl.CoreTokenAdapter.create(CoreTokenAdapter.java:88)
at org.forgerock.openam.cts.CTSPersistentStoreImpl.create(CTSPersistentStoreImpl.java:81)
at org.forgerock.openam.cts.CtsTokenManagementLayer.create(CtsTokenManagementLayer.java:59)
at org.forgerock.openam.session.cts.SessionPersistenceStore.create(SessionPersistenceStore.java:115)
DS servers use cryptographic keys to sign and verify the integrity of backup files, and to encrypt data. Servers protect these keys by encrypting them with the shared master key for a deployment. For portability, servers store the encrypted keys in the backup files.
Any server can therefore restore a backup taken with the same server version, as long as it holds a copy of the shared master key used to encrypt the keys.
This is here a description of how is handled the amAdmin user: Secure administrative access :: AM 7.3.0. This might help you determine what’s gone wrong with the restore process.
w.r.t. q2, it is difficult to respond without looking at the installation in some depth but maybe the am-config backend was not enough. Other backends, or profiles may be needed (i.e. CTS, or User Store). E.g. if there was no CTS configured in the original deployment AM may have used the external DS config store to store sessions too, in which case a CTS profile would be needed. Also Fully Qualified Domain Names (FQDNs) should be matched for every store.