Issues assigning Log On Account to Lucee Service

I recently (well a couple of months ago) reinstalled Lucee with AdoptOpenJDK and upgraded to the latest RC for my dev machine.

Server 2019
Lucee 5.3.7.34-RC
Apache Tomcat/9.0.34
Java 11.0.6 (AdoptOpenJDK) 64bit

When testing a page I haven’t looked at in a while which uses cffile to handle files on a network share (and/or through a UNC path) I’m getting an error

Source file [\networkserver\xml\packageTest.xml] is not a file

My first thought was that I hadn’t set the Lucee service LogOn account to something with network credentials…and that was correct (it had been set up and working before the reinstall ie: while still running Oracle Java)

When I went to start Lucee after changing credentials, it refused to start. I’m using exactly the same domain creds as my production server (domain\CFService and also tried CFService@domain.local) which is running Lucee 5.3.6.61. For fun I even tried domain admin as the user…still won’t start.

My production server is running
Server 2012
Lucee 5.3.6.61
Apache Tomcat/8.5.11
Java 1.8.0_121 (Oracle Corporation) 64bit

I just built a test VM that uses

Server 2019
Lucee 5.3.6.61
Apache Tomcat/9.0.35
Java 11.0.7 (AdoptOpenJDK) 64bit

and I can’t start the service under a domain account on that either.

So maybe this is an issue with AdoptOpenJDK ?

Can anyone reproduce?

Does the CFService account have adequate local permissions on the AdoptOpenJDK location folder?

OK this is weird. Didn’t change any perms but…

When I used domain\CFService and also tried CFService@domain.local it didn’t work.

When I used the Browse button to look for accounts I was greeted with options for the local server name and the DC name

So I selected the DC name and the user CFService.

This filled out the input using the DC machine name rather than the domain name and…it worked.

So

DomainControllerName\CFService works

Domain\CFService doesn’t work (works fine on production server using Oracle Java)

So maybe a quirk in AdoptOpenJDK?

OK…apparently doesn’t work.

When I enter the DomainControllerName\CFService and click apply it seems to accept it. (the apply button is disabled) If I close and reopen the Service Control, The account shows Local Service Account is still the Logon and -not- the Log On As I had just set and apparently had accepted.

I think the successful start up in the previous post was under the Local account context, despite the Log On As being populated and apparently accepted.

Tried this in both the dev environment and the new VM. It will apparently not run under any context but Local Service. Or I’m an idiot (which is always on the table)

During installation the tomcat/lucee folders/files are set up with the file permissions to run the service with the user “local service”, which is a very low priviliged in-built windows account to run services in a safe manner. It is so low priviliged that it even hasn’t a password. When ever you change the service to run with another user/credentials, you’ll need to check/add those file permissions manually. Just switching credentials of the service running lucee will only work if the user has permissions to do so. Otherwise the service won’t start. Did you check/add file permissions of your new user running the lucee/tomcat service to those lucee/tomcat folders accordingly?

All right. I went back and re-added the CFService user perms (full) to the lucee folder.

image

Same issue. I add the user account using the browse button to set the DomainControllerName\CFService and click apply. No error. I click to the General tab and click start…service starts without complaint. Click back to the Log On tab the CFService user is still there. Close service panel and reopen…log on is set back to Local Service and still have issues with cffile working.

When I use the “proper” domain\username or username@domain.local combination as the log on I can close and reopen the service panel and the Log On user “sticks” but the service will not start for either style of domain id

This is the behaviour on both my dev machine and the new VM I created to test this.

As noted…my production server running with the Oracle Java doesn’t have this issue. The only differences are server 2012 vs 2019 and Oracle vs AdoptOpenJDK

I wonder if it’s to do with “Log on as a service” rights. Check:

Local Security Policy > Local Policies > User Rights Assignment > Log on as a service

and see if the domain account is there. If not try adding it and then see if the details will “stick” in the Tomcat/Lucee service panel.

1 Like

That’s done it. Should have thought about that…sigh

Thanks Julian.:slight_smile:

2 Likes

@Julian rocks!!!

Didn’t find that valuable information on the docs. Going to add this as contrib to the Lucee docs as soon as I can.

1 Like