search

IBM-Security / isam-ansible-roles

Ansible Custom Modules, Handlers and Tasks for ISAM. Requires "ibmsecurity" python package.
Apache License 2.0
24 stars 43 forks source link

set_ldap_user_pw: AAC Restart required ? #65

Closed sygilber closed 6 years ago

sygilber commented 6 years ago

Hi,

We have found that when using role 'set_ldap_user_pw' to set an existing embedded_ldap account's password (such as the one for easuser) that it only become effective after the AAC Runtime is restarted. This would be quick code change to add a "Runtime Restart" after the "Commit". But is it a good thing ? Woud there be cases where the AAC Runtime should not be restarted right away ?

Just looking for advise. Will test the code and submit a pull if I found that it resolves this behavior.

jldement commented 6 years ago

I did not think easuser was stored in an LDAP, I thought it was stored in a WAS local datastore "someplace". And WAS is not going to cache any LDAP results.

Are you sure an AAC runtime restart is required?

=================================================== Jeffrey L. DeMent IBM Security Systems | Directory & Security Architect 602.284.0100 (cell) | jdement@us.ibm.com

From: Sylvain Gilbert notifications@github.com To: IBM-Security/isam-ansible-roles isam-ansible-roles@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Date: 03/16/2018 03:22 PM Subject: [IBM-Security/isam-ansible-roles] set_ldap_user_pw: AAC Restart required ? (#65)

Hi,

We have found that when using role 'set_ldap_user_pw' to set an existing embedded_ldap account's password (such as the one for easuser) that it only become effective after the AAC Runtime is restarted. This would be quick code change to add a "Runtime Restart" after the "Commit". But is it a good thing ? Woud there be cases where the AAC Runtime should not be restarted right away ?

Just looking for advise. Will test the code and submit a pull if I found that it resolves this behavior.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

sygilber commented 6 years ago

My understanding is that it is stored in the "Embedded LDAP" of the appliance where the AAC runs. It is kind of local system "account", nothing to do with External LDAP user registry that you would configure along the Policy Server topology.

I tested the role that updates the password of easuser and yes, it becomes only effective after the AAC Runtime is restarted. Maybe because like as you say it is stored in some internal WAS/Liberty registry, or that it is really stored in an embedded_LDAP (openldap) and that then the "WAS/Liberty" runtime caches the cred/password for some time, or some other reaason.

It is easy to reproduce.

  1. Use role 'set_ldap_user_pw' to update password of existing easuser

  2. Use this URL to test if the password change is immediate (fails for us)

https://aacruntimehost/TrustServerWS/SecurityTokenServiceWST13 (will get BA prompt)

  1. Restart AAC Runtime

  2. Use URL again and then it works

So my proposal is to notify that at end of play to restart the Runtime:

notify:

ram-ibm commented 6 years ago

As Jeff indicated - the easuser is stored in WebSphere Liberty config files. Adding the Restart AAC Runtime should be okay - the handler gets triggered only at the end of a run. Besides AAC Runtime will not restart unless it is flagged for it.

sygilber commented 6 years ago

Really ? Thanks for clearing that out. The api name, role name can lead one to think this is really an embedded "ldap". But it explains all. If it had been really an "LDAP" server, then normally a password change should not have required an WebSphere/Liberty restart.

sygilber commented 6 years ago

Issue resolved with merged pull request https://github.com/IBM-Security/isam-ansible-roles/pull/66