Logon failure for service

Microsoft Windows server 2003 standard e...
January 8, 2010 at 14:33:23
Specs: W2K3 Standard SP2
Trying to start JBoss:

"Could not start the JBoss Application Server 4.2.3 service on Local
Computer.

Error 1069: The service did not start due to a logon failure."

Event Viewer says:

"User not allowed to logon at this computer" Event ID 533

The user in question is allowed to "Log on as a service"


See More: Logon failure for service

Report •

#1
January 10, 2010 at 15:08:16
Try adding the account to the local administrator group.

Report •

#2
January 11, 2010 at 07:49:42
No.

This worked before without being in the administrator group, and that's a HUGE security hole. And I have Jboss running on another Windows VM with no problems.


Report •

#3
January 11, 2010 at 08:16:41
Try it for 10 minutes, only to make sure if it works or not. 10 minutes shouldn't be much of a threat.

If it does work, it'll be much easier troubleshooting why it doesn't work when not an admin.


Report •

Related Solutions

#4
January 11, 2010 at 10:03:44
OK, the service will start with the jboss user in the local Administrators group. What else can we look at to figure out what went wrong?

Thanks all.


Report •

#5
January 11, 2010 at 10:08:17
compare user rights to the one that is working starting with the account password
.

Report •

#6
January 11, 2010 at 10:26:11
When you say, "compare user rights"... could you be a little more specific for me? I'm not a Windows guy by trade, and I might easily be missing looking at the correct info.

Thanks.


Report •

#7
January 11, 2010 at 14:17:26
compare things like
same type of server? ie not a DC. Member servers have local accounts. DC's only have domain accounts.

Look at the local security policy of the working one.
who is a member of the log on as a service? Check the different security aspects and see if there is a right that is missing from the nonworking that exists for the working.

Check the program ntfs rights at the file level looking for differences


Report •

#8
January 11, 2010 at 14:28:16
It is telling you there is a logon failure. That tells me the password of the account starting the service may have been changed. If so, it will also need to be changed in the service properties. If the service account that starts the account can't log in, the service won't start.

Report •

#9
January 11, 2010 at 15:09:27
If the password was wrong, how would it be able to log in just because it's in the Administrators group?

Just to be sure, I manually reset the user password and then the password in the service. No change.


Report •

#10
January 11, 2010 at 15:11:17
wanderer - Both VMs are standalone, no domain. The jboss user is allowed to log on as service on both.

I'm not clear on what item(s) in the file system I'd look at permissions on when the issue isn't an "access denied" or similar, but a logon issue.


Report •

#11
January 11, 2010 at 16:20:31
Might have better luck posting the in jboss forums. You need someone more familiar with this application server.

Report •

#12
January 11, 2010 at 16:35:50
This has nothing to do with jboss. Or, if it does, that's very well concealed.

The user that the jboss server runs as is no longer allowed to start as a service unless it's an Administrator. I don't see how that could be a problem with JBoss.


Report •

#13
January 11, 2010 at 19:22:16
Um OK...?

Have you tried just deleting the account and recreating to the specs to then see if it works?

Or perhaps Jboss got a update that changed the rules?

You have two systems; OS and Application.
If both are identical, my choice is the application has a fault.

This is because the OS is nothing but a foundation for the app. It in itself should not be able to disable an app. This is what the apps install process is supposed to secure.

I suspect you are missing the user being a part of a key service. But without an intimate knowledge of the foibles of jboss, and since the OS settings match, most reasonable approach is to find those more familiar with jboss.

Just my thought. Best of luck.


Report •

Ask Question