amadmin and dsameuser are "special" users and are not vanilla LDAP user entries. For example, their passwords are not stored via userPassword attribute in ldap - but rather stored as key/value pairs - encrypted with an OpenAM instance key.
These specials entries significantly complicate installation and are constant source of problems when people attempt to change these passwords. The password change procedures are very complex, and subject to breakage. As far as I can tell, the change process for dsameuser has never been documented - and it is not clear what the correct process is.
Further complexity comes with the interplay of the directory manager password (cn=Directory Manager), which starts off the same as amadmin / dsameuser - but is not the same thing, and does not get changed when amadmin is changed. Throw in replication passwords - and it gets even more fun.
A great deal of this complexity arises because the amadmin / dsameuser passwords are not vanilla ldap passwords, and can not be managed using standard ldap tools.
How to fix this:
- Eliminate dsameuser altogether. I will file a separate JIRA for this. It is not clear that this user adds any value at all. It represents the "internal" actions of OpenAM, but this does not require a separate user in ldap.
- The admin user and admin group should be configurable. This should be a plain old ldap user that happens to be in an admin group. A configurable "ldap admin group" should be created
- Separate the concept of the amadmin user from the configuration store directory manager. They are two completely unrelated things. Trying to sync them just confuses users as to their purpose.
Aside: This is further complicated by the use of the embedded configuration store. The easy all-in-one bundle makes the getting started case easier at the expense of making a production configuration much harder than it needs to be.