Another quick one today...

So when you start your brand spanking new Liferay environment, you will automatically get your test@liferay.com administrator account (or test@<your company email here> if you've set up the company.default.web.id and/or 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 property too).

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, test@liferay.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 test@liferay.com 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 test@liferay.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 test@liferay.com 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 test@liferay.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 test@liferay.com credentials, then stop doing this. Give yourself and whomever needs it the Administrator role, and then change the test@liferay.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 test@liferay.com 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 test@liferay.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.