Skip to main content

asadmin troubles

10 replies [Last post]
chaoslayer
Offline
Joined: 2004-05-18

Hi together,

I am currently trying to set up a new domain and configure it for security but it seems that I get stuck at the very beginning. Being more accurate it's asadmin that gets stuck. I created a domain with the following command:

su - glassfish -c '/opt/glassfishv3/bin/asadmin --user MyRoot --passwordfile /opt/glassfishv3/dom2-pwd.conf create-domain --portbase 9000 --savemasterpassword=true --savelogin=true dom2'

That worked quite well without asking me anything. Then I also can do:

su - glassfish -c '/opt/glassfishv3/bin/asadmin start-domain dom2'

...success. After that I just wanted to get a property from that domain:

su - glassfish -c '/opt/glassfishv3/bin/asadmin --port 9048 get *.admin-listener'

Well, and here we are:

[pre]Authentication failed with password from login store: /opt/glassfishv3/.asadminpass
Enter admin password>
Authentication failed for user: MyRoot
(Usually, this means invalid user name and/or password)
Command get failed.[/pre]

Now THAT is strange! The login via web interface works as expected in contrast to the CLI.

Please help, as I also need to make everything secure (including shutting down the admin web interface) from the command line.

Thanx,

CHaoZ

P.S.: I'm using the latest stuff (updated through pkg), so it is currently b64 (the complete glassfish, not only web)

EDIT:

In the server log it says the following:
[pre]...FileRealm;MethodName=init;|FileRealm : file=/opt/glassfishv3/glassfish/domains/dom2/config/admin-keyfile|#]
...FileRealm;MethodName=init;|FileRealm : jaas-context=ignore|#]
...FileRealm;MethodName=loadKeyFile;|Reading file realm: /opt/glassfishv3/glassfish/domains/dom2/config/admin-keyfile|#]
...FileRealm;MethodName=authenticate;|File authentication failed for: [MyRoot]|#][/pre]

So glassfish tries to authenticate the admin user against the file realm (.../dom2/config/admin-keyfile) but the information has to be correct otherwise I couldn't login via the web interface.

Message was edited by: chaoslayer

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
km
Offline
Joined: 2005-10-28

All right, thanks for reporting the problem. Bill Shannon has fixed it in the current v3 builds ...
Issue Tracker: 9805:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=9805

-Kedar

chaoslayer
Offline
Joined: 2004-05-18

Thanks for investigation.

I didn't even consider that there could be a bug preventing such passwords. However I wonder that nobody else stumbled upon this issue yet.

Regards,

C]-[aoZ

km
Offline
Joined: 2005-10-28

Are you still blocked on this one?

Ping me back and I will respond.

-Kedar

chaoslayer
Offline
Joined: 2004-05-18

Sorry for the late response.

Yes, I am! I recently tried investigating the source code to get an idea what might be different between asadmin and admin-web-login.

But to be honest I have no idea why it doesn't work with asadmin.

Please help.

km
Offline
Joined: 2005-10-28

It occurs to me that there are two many things you've tried. Also, there is some conflicting information in what you've said. Is "glassfish" an account on your system? Is that user's home directory in /usr/local? Is the root account's home directory in /opt/glassfishv3?

It seems that "su - glassfish" is causing some issues. I am not able to exactly know what you are running into and hence following facts may help you.

1- asadmin and web admin GUI use the exact same credentials and same "way" of authenticating the admin user. So, it's not likely that it passes in one case and not in other. In default case, both use admin-keyfile and not keyfile.
2- Maybe --savelogin is giving you some trouble as far as its location is concerned. Beginning b64, the domain is created with a single admin user named "admin" and no password by default. If you specify a user name and password in a passwordfile, that will be respected of course.
3- Since you have used a --passwordfile option, I suggest you use it uniformly. For example:
passwordfile:
AS_ADMIN_PASSWORD=secret123
and then use this passwordfile on *all* asadmin commands, without using --savelogin. All commands of interest that need passwords should accept --passwordfile option followed by its path. The actual password will be extracted from the file.
4- Keep your passwordfile safe.

Hope that helps.

chaoslayer
Offline
Joined: 2004-05-18

Sorry for the paths confusion. That was because I have two different installations on two different systems that I mixed in the post somehow but the results are the same on both systems.

The system setup (the one I want to talk about) is an Ubuntu Server 8.04, using glassfish v3 b64 with Sun JDK 1.6.0 update 16. The glassfish installation is installed in "/opt/glassfishv3/".

The user "glassfish" is a system account on that machine, so no remote login is permitted and only root can "su - " into it. The users home directory is set to "/opt/glassfishv3/". Actually when performing multiple operations I don't use "su - glassfish -c '...'" but rather su into glassfish and then working in the shell of that user.

Actually if it is a problem of the .asadminpass file location the paths shown during authentication are correct (a small session here):

[pre]
root@bitch:~# su - glassfish
$ bash
glassfish@bitch:~$ pwd
/opt/glassfishv3
glassfish@bitch:~$ ls -la
total 60
drwxr-xr-x 11 glassfish adm 4096 2009-09-19 13:44 .
drwxr-xr-x 11 root root 4096 2009-09-18 23:45 ..
-rw------- 1 glassfish glassfish 123 2009-09-19 15:04 .asadminpass
-rw------- 1 glassfish glassfish 5240 2009-09-24 14:53 .bash_history
drwxr-x--- 3 glassfish glassfish 4096 2009-09-19 00:36 bin
-rw-r----- 1 glassfish glassfish 133 2009-09-19 10:52 dom2-pwd.txt
drwxr-x--- 9 glassfish glassfish 4096 2009-09-03 13:22 glassfish
drwxr-x--- 3 glassfish glassfish 4096 2009-09-19 10:14 .java
drwxr-x--- 4 glassfish glassfish 4096 2009-09-03 13:34 javadb
drwxr-x--- 2 glassfish glassfish 4096 2009-09-19 11:12 logs
drwxr-x--- 7 glassfish glassfish 4096 2009-09-03 13:36 mq
drwxr-x--- 9 glassfish glassfish 4096 2009-09-19 00:39 .org.opensolaris,pkg
drwxr-x--- 8 glassfish glassfish 4096 2009-09-19 00:36 pkg
drwxr-x--- 2 glassfish glassfish 4096 2009-09-19 10:13 .updatetool
glassfish@bitch:~$ ./bin/asadmin --port 9048 get *.admin-listener
Authentication failed with password from login store: /opt/glassfishv3/.asadminpass
Enter admin password>
Authentication failed for user: MyRoot
(Usually, this means invalid user name and/or password)
Command get failed.
glassfish@bitch:~$
[/pre]

So the problem is that the password hash doesn't match with the stored one, neither from .asadminpass nor directly given through the console (of course I checked that the base64 encoded one in .asadminpass is really correct).

But nevertheless I tried your suggestion to work without --savelogin:

[pre]
glassfish@bitch:~$ ./bin/asadmin --passwordfile dom2-pwd.txt --user MyRoot create-domain --portbase 6000 --savemasterpassword=true dom3
Using port 6048 for Admin.
Using port 6080 for HTTP Instance.
Using port 6076 for JMS.
Using port 6037 for IIOP.
Using port 6081 for HTTP_SSL.
Using port 6038 for IIOP_SSL.
Using port 6039 for IIOP_MUTUALAUTH.
Using port 6086 for JMX_ADMIN.
The file in given locale [de_DE] at: [/opt/glassfishv3/glassfish/lib/templates/locales/de_DE/index.html] could not be found. Using default (en_US) index.html instead.
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=bitch.***********.net,OU=GlassFish,O=Sun Microsystems,L=Santa Clara,ST=California,C=US]
Domain dom3 created.
Domain dom3 admin port is 6048.
Domain dom3 admin user is "MyRoot".
Command create-domain executed successfully.
glassfish@bitch:~$ ./bin/asadmin --passwordfile dom2-pwd.txt --user MyRoot start-domain dom3

Waiting for DAS to start.
Name of the domain started: [dom3] and its location:
[/opt/glassfishv3/glassfish/domains/dom3].
Admin port for the domain: [6048].
Command start-domain executed successfully.
glassfish@bitch:~$ ./bin/asadmin --passwordfile dom2-pwd.txt --user MyRoot --port 6048 get *.admin-listener
Authentication failed with password from file: dom2-pwd.txt
Enter admin password>
Authentication failed for user: MyRoot
(Usually, this means invalid user name and/or password)
Command get failed.
glassfish@bitch:~$
[/pre]

So you see the problem is exactly the same on a completely new fresh domain. Login via web admin GUI works as expected. So this is really confusing me.

But wait... I just tried using another (much less secure) password for the admin user and now it works:

[pre]glassfish@bitch:~$ ./bin/asadmin --passwordfile dom3-pwd.txt --user MyRoot create-domain --portbase 6000 --savemasterpassword=true dom3
Using port 6048 for Admin.
Using port 6080 for HTTP Instance.
Using port 6076 for JMS.
Using port 6037 for IIOP.
Using port 6081 for HTTP_SSL.
Using port 6038 for IIOP_SSL.
Using port 6039 for IIOP_MUTUALAUTH.
Using port 6086 for JMX_ADMIN.
The file in given locale [de_DE] at: [/opt/glassfishv3/glassfish/lib/templates/locales/de_DE/index.html] could not be found. Using default (en_US) index.html instead.
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=bitch.**********.net,OU=GlassFish,O=Sun Microsystems,L=Santa Clara,ST=California,C=US]
Domain dom3 created.
Domain dom3 admin port is 6048.
Domain dom3 admin user is "MyRoot".
Command create-domain executed successfully.
glassfish@bitch:~$ ./bin/asadmin --passwordfile dom3-pwd.txt --user MyRoot start-domain dom3

Waiting for DAS to start.
Name of the domain started: [dom3] and its location:
[/opt/glassfishv3/glassfish/domains/dom3].
Admin port for the domain: [6048].
Command start-domain executed successfully.
glassfish@bitch:~$ ./bin/asadmin --passwordfile dom3-pwd.txt --user MyRoot --port 6048 get *.admin-listener
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.address=0.0.0.0
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.enabled=true
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.jk-enabled=false
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.name=admin-listener
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.port=6048
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.protocol=admin-listener
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.thread-pool=http-thread-pool
configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.transport=tcp
configs.config.server-config.network-config.protocols.protocol.admin-listener.name=admin-listener
configs.config.server-config.network-config.protocols.protocol.admin-listener.security-enabled=false

Command get executed successfully.
glassfish@bitch:~$
[/pre]

So the real problem with asadmin seems to be that I am using some special characters for my passwords (some colons) so this test password works:
[pre]321test123[/pre]
But this doesn't:
[pre]321:test:123[/pre]

Curious but true somehow. Can this be a file encoding issue (although I doubt that since ASCII characters should be the same)?

km
Offline
Joined: 2005-10-28

Wow, Thanks, Chaoslayer!

It looks like a genuine problem. Let me look into it and get back to you.

-Kedar

shannon
Offline
Joined: 2003-06-10

Kedar asked me to look into this.

Yes, it's a bug. I'll fix it ASAP.

FYI, the problem is that the HTTP Authorization header field includes data
that follows this syntax:

[code]
basic-credentials = base64-user-pass
base64-user-pass = except not limited to 76 char/line>
user-pass = userid ":" password
userid = *
password = *TEXT
[/code]
That is, the username may not include a colon, but the password may.
The code was using String.split(":") to separate the two fields. Oops.

shannon
Offline
Joined: 2003-06-10
chaoslayer
Offline
Joined: 2004-05-18

Even more confusion:

now I just tried the asadmin login command and it seemed to work:
[pre]Enter admin user name [default: admin]>MyRoot
Enter admin password>
Admin login information for host [localhost] and port [9048]
is being overwritten with credentials provided because the
--savelogin option was used during the create-domain command.
Login information relevant to admin user name [MyRoot]
for host [localhost] and admin port [9048] stored at
[/usr/local/glassfishv3/.asadminpass] successfully.
Make sure that this file remains protected.
Information stored in this file will be used by
asadmin commands to manage the associated domain.
Command login executed successfully.[/pre]

...however in the logs again I see:
[pre]2009-09-19 15:04:06.926 [ FINE] FileRealm : file=/opt/glassfishv3/glassfish/domains/dom2/config/admin-keyfile
2009-09-19 15:04:06.926 [ FINE] FileRealm : jaas-context=ignore
2009-09-19 15:04:06.927 [ FINE] Reading file realm: /opt/glassfishv3/glassfish/domains/dom2/config/admin-keyfile
2009-09-19 15:04:06.927 [ FINE] File authentication failed for: [MyRoot][/pre]

...just exactly the same I see on all other commands:
[pre]2009-09-19 13:44:03.460 [ FINE] FileRealm : file=/opt/glassfishv3/glassfish/domains/dom2/config/admin-keyfile
2009-09-19 13:44:03.460 [ FINE] FileRealm : jaas-context=ignore
2009-09-19 13:44:03.460 [ FINE] Reading file realm: /opt/glassfishv3/glassfish/domains/dom2/config/admin-keyfile
2009-09-19 13:44:03.461 [ FINE] File authentication failed for: [MyRoot][/pre]

Then I issued a login using wrong password at the web interface to see the log output:
[pre]2009-09-19 14:00:06.649 [ FINE] [Web-Security] Setting Policy Context ID: old = null ctxID = __admingui/__admingui
2009-09-19 14:00:06.651 [ FINE] [Web-Security] hasUserDataPermission perm: (javax.security.jacc.WebUserDataPermission /j_security_check POST)
2009-09-19 14:00:06.652 [ FINE] [Web-Security] hasUserDataPermission isGranted: true
2009-09-19 14:00:06.653 [ FINEST] Processing login with credentials of type: class com.sun.enterprise.security.auth.login.common.PasswordCredential
2009-09-19 14:00:06.654 [ FINE] Logging in user [MyRoot] into realm: admin-realm using JAAS module: fileRealm
2009-09-19 14:00:06.655 [ FINE] Login module initialized: class com.sun.enterprise.security.auth.login.FileLoginModule
2009-09-19 14:00:06.655 [ FINE] File authentication failed for: [MyRoot]
2009-09-19 14:00:06.656 [ FINE] JAAS authentication aborted.
2009-09-19 14:00:06.657 [ INFO] SEC5046: Audit: Authentication refused for [MyRoot].
2009-09-19 14:00:06.658 [ FINEST] doPasswordLogin fails
javax.security.auth.login.LoginException: Failed file login for MyRoot.
at com.sun.enterprise.security.auth.login.FileLoginModule.authenticate(FileLoginModule.java:80)
at com.sun.enterprise.security.auth.login.PasswordLoginModule.authenticateUser(PasswordLoginModule.java:90)
at com.sun.appserv.security.AppservPasswordLoginModule.login(AppservPasswordLoginModule.java:141)
...[/pre]

...and here the log for a web interface login using correct credentials:

[pre]2009-09-19 14:38:50.314 [ FINE] [Web-Security] Setting Policy Context ID: old = null ctxID = __admingui/__admingui
2009-09-19 14:38:50.315 [ FINE] [Web-Security] hasUserDataPermission perm: (javax.security.jacc.WebUserDataPermission /j_security_check POST)
2009-09-19 14:38:50.315 [ FINE] [Web-Security] hasUserDataPermission isGranted: true
2009-09-19 14:38:50.317 [ FINEST] Processing login with credentials of type: class com.sun.enterprise.security.auth.login.common.PasswordCredential
2009-09-19 14:38:50.318 [ FINE] Logging in user [MyRoot] into realm: admin-realm using JAAS module: fileRealm
2009-09-19 14:38:50.319 [ FINE] Login module initialized: class com.sun.enterprise.security.auth.login.FileLoginModule
2009-09-19 14:38:50.320 [ FINE] File login succeeded for: MyRoot
2009-09-19 14:38:50.320 [ FINE] JAAS login complete.
2009-09-19 14:38:50.321 [ FINE] JAAS authentication committed.
2009-09-19 14:38:50.322 [ FINE] Password login succeeded for : MyRoot
2009-09-19 14:38:50.323 [ FINE] Default CTOR of SecurityContext called
2009-09-19 14:38:50.324 [ FINE] SecurityContext: newInstance method called
2009-09-19 14:38:50.325 [ FINE] SecurityContext: setCurrentSecurityContext method called
2009-09-19 14:38:50.326 [ FINE] Set security context as user: MyRoot
...[/pre]

So what comes to mind is that the logging information is somewhat incorrect as the file realm (which is used by asadmin) points to file ...config/keyfile whereas the admin-realm (used by web interface) points to .../config/admin-keyfile. So the admin-keyfile file itself is correct. The keyfile is empty what is just fine so I wonder why the hell does the asadmin commands use the "file" realm for authentication?