Bug 806001

There's no restriction on the number of admins -- an admin isn't  a special kind of user. Rather an admin is a user who happens to have been given the "Administrator" global role. In fact, in the UI an admin can assign full admin rights to any number of other real users.

However, the current situation is still problematic. We could do a couple things:
1) make 'admin creation' optional in -configure
2) only create an admin user if there aren't currently any users with admin rights -- i.e. run a query and if there's already one or more users with the global 'Administrator' role  defined, don't add another.

I think in reality, for any installation that uses ldap users we won't want to use the non-ldap 'admin' user anyway -- we'd want the admins to be regular users with their ldap logins that have been granted 'admin' rights.

Option 2 seems the nicest. Steve, how hard is this to fix? We are considering it for z-stream.

I would like to make admin creation a separate, optional profile. User would need to invoke 'aeolus-configure -p create_admin_user' to have a 'default' user set up. The profile would include login/password as optional parameters with defaults of 'admin'/'password'.

If a user with login 'admin' (or whatever the value of the 'login' parameter in the profile is) exists, do nothing.

I discovered a more substantial problem while considering implementing the above approach.

In several places in our puppet manifests, we use web requests that require valid administrator-level, plain-text login/password information. For example, when we set up ec2 providers in class aeolus::profiles::ec2.

In the presumably typical case where user has retained the login 'admin' but changed the password, we can't extract the plain-text password from the rdbms. Obviously this applies to any other pre-existing un/pw that user has created and is using in an administrative capacity.

I suggest we create, at the start of each puppet run, a temporary user which is granted administrative rights, do whatever configuration work is needed using the temp-user's credentials, and destroy the temp-user at the end of each run.

temp-user login names would follow a set pattern, e.g. 'temp-admin-user-%d%d%d', and we could delete all users that match the pattern prior to creation of a new temp-user. This handles the case where something goes wrong with a puppet run and a 'stale' temp-user is left over.

In any case, we would set the password to a secure random string to prevent access via the temp-user.

rwsu and sseago raised the issue of possibly orphaning objects created during puppet runs. I logged the sql statements of a sample run of aeolus-configure using the default profile, and found no objects created that required a user owner. However, this might affect future enhancements to -configure, for example if we created a profile that created an instance. For the time being, the temp-user approach strikes me as the least disruptive way to address this BZ.

Comments encouraged.

I lean towards option 1 being the better option from the point of 'admin user recovery'.  If you don't have passwords to other user accounts who have admin rights with option 2, there is no way to recover a admin user.  And what if those other users are all 'inactive'?

I like what Steve proposes allow I think it could still be problematic it terms of what Wes's describes.  Users might not necessarily know the implications and still accidently create a 'extra' default admin user???  I am wondering if login/password parameters should be required and perhaps if it exists, the password gets reset.

In terms of the temporary user creating system level objects that only require admin rights, no objections come to mind.  In the scenario of objects requiring a user owner, I would think you would need to specify credentials, which are then passed through permissions to create the desired object.

1a46ebbfde98f9d86498547e50f312b13aa0b49e on conductor master branch.
9bffb2ce99394ee9231734d9830d2977469155d0 on aeolus-configure master branch.

admin/password account is created only once on running aeolus-configure.


Tests :

1) Run aeolus-configure , admin/password is created.
2) Run aeolus-configure again , admin is not created again
3) Change the username of admin to something else (admin123) and run aeolus-configure again, admin is not created


=============================================

rpm -qa|grep aeolus
rubygem-aeolus-image-0.3.0-12.el6.noarch
rubygem-aeolus-cli-0.7.2-1.el6cf.noarch
aeolus-conductor-doc-0.13.14-1.el6cf.noarch
aeolus-all-0.13.14-1.el6cf.noarch
aeolus-conductor-0.13.14-1.el6cf.noarch
aeolus-configure-2.8.7-1.el6cf.noarch
aeolus-conductor-daemons-0.13.14-1.el6cf.noarch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-1516.html