Please read the attached e-mail, sent to the developer's list recently.
Changes to implement some new restrictions regarding secure admin are
in progress, with some parts implemented and some yet to come.
Please hold off filing bugs until all the relevant issues have been
addressed in the code and the issues closed. At that point if you
find problems please do file bugs.
Thanks.
- Tim
Begin forwarded message:
> From: Tim Quinn <tim.quinn_at_oracle.com>
> Date: November 4, 2011 4:29:09 PM CDT
> To: dev_at_glassfish.java.net
> Subject: New restrictions on the enable-secure-admin command
>
> Hi.
>
> Two days ago Joe D. sent a message describing some upcoming changes
> to how GlassFish enforces admin security.
>
> I have just checked in changes implementing one part of that: the
> enable-secure-admin command will fail if there are any admin users
> with an empty password.
>
> Note that this is currently the default. The "admin" username is
> the only admin username out-of-the-box, and it has an empty
> password. So, now, enable-secure-admin will fail out-of-the-box.
>
> To allow it, you can
>
> asadmin change-admin-password
>
> and respond to the prompts, providing a new, non-empty password. Then
>
> asadmin enable-secure-admin
>
> should work.
>
> Eventually, the invariant GlassFish will enforce is that you cannot
> have secure admin enabled and also have any admin users with an
> empty password. The changes I have checked in affect only the part
> of the enforcement that's done during enable-secure-admin
> processing. Later check-ins will add logic to change-admin-
> password, delete-file-user, update-file-user, and create-file-user
> to prevent users from creating an admin user with an empty password
> once secure admin is already enabled.
>
> Please let me know if you have questions.
>
> - Tim