Another quick one today...
So when you start your brand spanking new Liferay environment,
you will automatically get your firstname.lastname@example.org
administrator account (or test@<your company email
here> if you've set up the
company.default.virtual.host.mail.domain property keys
before first launch, or <your
admin>@<your company email here> if
you've also set the default.admin.email.address.prefix
test@<your company email
admin>@<your company email here>
And conveniently Liferay provides you basic instructions such as
log in as the administrator to start making changes in configuration,
creating pages, etc.
But actually, the first thing you want to be doing is creating
effective administrator accounts.
The real admin account, email@example.com (or
whatever yours ends up being), that one you want to set aside. Give
the credentials to your devops folks, but otherwise ignore them.
For each user who needs administrator access, go ahead
and grant them the Administrator role.
Don't use the administrator account (save that for devops when
there is no other available admin), but otherwise use the real
accounts of your users, give them the Administrator role, and then let
them do their thing.
Why do this?
Well, number one it protects you when someone leaves. If
the user who has the firstname.lastname@example.org credentials leaves
your employ, if you haven't planned for this you may have trouble
gaining access to the system again. By separating out that admin
account and just giving the Administrator role, when that person
leaves you still have the main email@example.com account
so you can get access and give the Administrator role to someone else
(don't forget to remove it from the person that left, just to be safe,
even if their account is disabled).
Another reason is it provides accurate Auditing details.
There is the Auditing framework in Liferay which OOTB does very
minimal auditing, but as a framework you can extend it as necessary to
capture any detail you want. But if your users are sharing the
administrator credentials, the audit is useless because you'll see
that firstname.lastname@example.org is doing everything and you won't
really know who might have done what.
What should I do?
So, after you start your new environment, log in as the
email@example.com administrator and create your own
personal account, and give this account the Administrator role. Then
immediately log out and log in using your personal account, and then
proceed from there.
If you have an established environment and have been sharing your
firstname.lastname@example.org credentials, then stop doing this. Give
yourself and whomever needs it the Administrator role, and then change
the email@example.com password so folks are forced to use
their personal accounts instead. In fact, this may be a great way to
do a security audit - don't give anyone else the Administrator role,
just change the firstname.lastname@example.org password, and then wait
for folks to come to you about logging in as the administrator. Make
them justify the need to have full Administrator access and, if they
need it, then give them the Administrator role.
Let your devops team have the credentials for the
email@example.com admin account (they may even want to
change the password so you won't know it), and maintain a policy to
assign the Administrator role to user accounts that need Administrator access.
You might even go a step farther and make an Administrator group
that has the Administrator role and then you add/remove users from the
group. This is not necessary (you can see who has the Administrator
role via the Roles control panel), but it may make maintenance easier.
And finally, consider not giving the Administrator role out at
all. Liferay's permissioning system is quite robust, so you could
create custom roles that have a specific subset of permissions.
Instead of giving someone blanket Administrator access, consider
creating a role that only gives the permissions they need.