[JENKINS-16273] Slaves forbidden to request JNLP anonymously but -jnlpCredentials not offered

[jenkins-infra-bot]

All of my windows salve cannot connect to Jenkins master after upgrading to 1.498. Following messages showed up in slaves' jenkins-slave.err:

java.io.IOException: Failed to load http://192.168.30.95/jenkins/computer/Fortify%201/slave-agent.jnlp: 403 Forbidden
at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:238)
at hudson.remoting.Launcher.run(Launcher.java:200)
at hudson.remoting.Launcher.main(Launcher.java:173)

---

Originally reported by beta, imported from: Slaves forbidden to request JNLP anonymously but -jnlpCredentials not offered

• status: Resolved
• priority: Blocker
• component(s): core
• label(s): 1.480.3-fixed, jnlp, regression, security, slave
• resolution: Fixed
• resolved: 2013-01-21T22:18:01+00:00
• votes: 14
• watchers: 26
• imported: 2025-11-24

Raw content of original issue

All of my windows salve cannot connect to Jenkins master after upgrading to 1.498. Following messages showed up in slaves' jenkins-slave.err:

java.io.IOException: Failed to load http://192.168.30.95/jenkins/computer/Fortify%201/slave-agent.jnlp: 403 Forbidden
	at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:238)
	at hudson.remoting.Launcher.run(Launcher.java:200)
	at hudson.remoting.Launcher.main(Launcher.java:173)

• environment: 1.498+, Windows Server 2008 R2

1 attachment

• jenkins-slave-error.jpg

  

[jenkins-infra-bot]

beta:

• Original comment link
• Raw content of original comment:

  Stop the Jenkins slave service. Pasting the jnlp url ( http://192.168.30.95/jenkins/login?from=%2Fjenkins%2Fcomputer%2FFortify%25201%2Fslave-agent.jnlp ) in my browser and input my credential, the Jenkins slave agent starts.
  
  But after I click the File / Install as a service, the attached error message showed up to me.
  

Stop the Jenkins slave service. Pasting the jnlp url ( http://192.168.30.95/jenkins/login?from=%2Fjenkins%2Fcomputer%2FFortify%25201%2Fslave-agent.jnlp ) in my browser and input my credential, the Jenkins slave agent starts.

But after I click the File / Install as a service, the attached error message showed up to me.

[jenkins-infra-bot]

schultemarkus:

• Original comment link
• Raw content of original comment:

  I confirm this bug for Jenkins 1.498 - it appears although User "anonymous" has Overall-> Read access. Jenkins 1.497 works fine.
  

I confirm this bug for Jenkins 1.498 - it appears although User "anonymous" has Overall-> Read access. Jenkins 1.497 works fine.

[jenkins-infra-bot]

trevora:

• Original comment link
• Raw content of original comment:

  We had this issue and were finally able to resolve it by granting the Anonymous user the "Connect" privilege under the "Slave" section.  The permissions can be found in the "Authorization" section of the "Configure Global Security" page under "Manage Jenkins."
  

We had this issue and were finally able to resolve it by granting the Anonymous user the "Connect" privilege under the "Slave" section. The permissions can be found in the "Authorization" section of the "Configure Global Security" page under "Manage Jenkins."

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  This is intentional—part of the security fix. In order to retrieve slave-agent.jnlp now, you need to provide authentication demonstrating that you are permitted to connect to the slave. This is generally done using an API token. Alternately, download the JNLP from your browser (while logged in as an admin) and save that, rather than attempting to connect to slave-agent.jnlp on the fly.
  
  @trevora: granting the Anonymous user the "Connect" privilege effectively bypasses (part of) the security fix. Do not do this unless you are on a trusted, closed network (in which case why are you running with security at all?).
  

This is intentional—part of the security fix. In order to retrieve slave-agent.jnlp now, you need to provide authentication demonstrating that you are permitted to connect to the slave. This is generally done using an API token. Alternately, download the JNLP from your browser (while logged in as an admin) and save that, rather than attempting to connect to slave-agent.jnlp on the fly.

@​trevora: granting the Anonymous user the "Connect" privilege effectively bypasses (part of) the security fix. Do not do this unless you are on a trusted, closed network (in which case why are you running with security at all?).

[jenkins-infra-bot]

trevora:

• Original comment link
• Raw content of original comment:

  @jglick: Could you please point me to some information on how to properly configure Windows slave agents after the security fix?  We are running on a closed network, but I'd prefer to configure it the right way if possible.  Any information would be greatly appreciated.
  
  If I understand correctly, the Windows service downloads and runs the slave-aget.jnlp when it starts using the parameters in the slave-agent.xml file.  I'm not sure how to provide it an API key.
  
  While we are on a closed network, we run security to control who may administer the Jenkins server and who can set up build projects.  We thought it best to leave our Anonymous user restricted so non-developers would not have access to the server.  We only added the "Connect" privilege to get our system back up and running after the upgrade.
  

@​jglick: Could you please point me to some information on how to properly configure Windows slave agents after the security fix? We are running on a closed network, but I'd prefer to configure it the right way if possible. Any information would be greatly appreciated.

If I understand correctly, the Windows service downloads and runs the slave-aget.jnlp when it starts using the parameters in the slave-agent.xml file. I'm not sure how to provide it an API key.

While we are on a closed network, we run security to control who may administer the Jenkins server and who can set up build projects. We thought it best to leave our Anonymous user restricted so non-developers would not have access to the server. We only added the "Connect" privilege to get our system back up and running after the upgrade.

[jenkins-infra-bot]

raspy:

• Original comment link
• Raw content of original comment:

  Same issue here. Reading through the comments above it made me think: would it be possible to make when jnlp is first started through a web browser to save this jnlp to local Jenkins directory and automatically configure service to use this cached copy instead of requesting it from the server? This would make setting up slaves automatic again without altering security fix.
  

Same issue here. Reading through the comments above it made me think: would it be possible to make when jnlp is first started through a web browser to save this jnlp to local Jenkins directory and automatically configure service to use this cached copy instead of requesting it from the server? This would make setting up slaves automatic again without altering security fix.

[jenkins-infra-bot]

nerdmachine:

• Original comment link
• Raw content of original comment:

  @Jesse: This is broken for the "Logged-in users can do anything" authorization policy.  The help on that	suggest that this is not "security" but instead record keeping, so it really shouldn't be locked down like this.  Could we allow slaves access to jnlp in this mode?  Or, allow a --auth user:password option to the slave start command which doesn't seem to work right now.
  
  Context help on "Logged-in users can do anything" from the configureSecurity page:
  "This mode is useful to force users to log in before taking actions, so that you can keep record of who has done what. This setting can be also used in public-facing Jenkins, where you only allow trusted users to have user accounts."
  

@​Jesse: This is broken for the "Logged-in users can do anything" authorization policy. The help on that suggest that this is not "security" but instead record keeping, so it really shouldn't be locked down like this. Could we allow slaves access to jnlp in this mode? Or, allow a --auth user:password option to the slave start command which doesn't seem to work right now.

Context help on "Logged-in users can do anything" from the configureSecurity page:
"This mode is useful to force users to log in before taking actions, so that you can keep record of who has done what. This setting can be also used in public-facing Jenkins, where you only allow trusted users to have user accounts."

[jenkins-infra-bot]

jesperjensen:

• Original comment link
• Raw content of original comment:

  The slave agent windows service install is also broken by this change.
  

The slave agent windows service install is also broken by this change.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  @nerdmachine: regardless of what the help on “Logged-in users can do anything” may suggest, it is a true security policy and it means that any operation requiring authentication—even GET requests which do produce any “records” to keep—must be accompanied by a valid login token.
  
  I do not know much about the Windows service; someone who understands this code will need to evaluate how it should be provided with an API token. Without any special (Windows-specific) tool you can always download a *.jnlp file, run it manually, and when prompted ask to save it as a service; this is just a feature of Java WebStart.
  

@​nerdmachine: regardless of what the help on “Logged-in users can do anything” may suggest, it is a true security policy and it means that any operation requiring authentication—even GET requests which do produce any “records” to keep—must be accompanied by a valid login token.

I do not know much about the Windows service; someone who understands this code will need to evaluate how it should be provided with an API token. Without any special (Windows-specific) tool you can always download a *.jnlp file, run it manually, and when prompted ask to save it as a service; this is just a feature of Java WebStart.

[jenkins-infra-bot]

trevora:

• Original comment link
• Raw content of original comment:

  @Pei-Tang, @Jesper: For what it's worth, we found that the Windows service install wasn't broken per se but that it failed if the service already existed.  We were able to log onto one of our Windows build servers, manually uninstall the service, rename or delete jenkins-slave.exe and jenkins-slave.xml, reboot the system, and then successfully reinstall the service by logging in as an admin, downloading the .jnlp file, and using the Java WebStart to install it.
  
  However, even after reinstalling the service the build slave was unable to register with master server because the service was trying to retrieve the the .jnlp from the master each time it started and was being denied.
  
  I have not tried manually running the .jnlp file outside the browser and installing as suggested above.
  

@​Pei-Tang, @​Jesper: For what it's worth, we found that the Windows service install wasn't broken per se but that it failed if the service already existed. We were able to log onto one of our Windows build servers, manually uninstall the service, rename or delete jenkins-slave.exe and jenkins-slave.xml, reboot the system, and then successfully reinstall the service by logging in as an admin, downloading the .jnlp file, and using the Java WebStart to install it.

However, even after reinstalling the service the build slave was unable to register with master server because the service was trying to retrieve the the .jnlp from the master each time it started and was being denied.

I have not tried manually running the .jnlp file outside the browser and installing as suggested above.

[jenkins-infra-bot]

beta:

• Original comment link
• Raw content of original comment:

  I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue 
  
  The remote management facility of Windows is hard for me to set correctly, I spent more than 6 hours to make all of my 6 Windows slaves run as well as before.
  

I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue

The remote management facility of Windows is hard for me to set correctly, I spent more than 6 hours to make all of my 6 Windows slaves run as well as before.

[jenkins-infra-bot]

oldelvet:

• Original comment link
• Raw content of original comment:

  I managed to fix this fairly simply on my windows slaves (tested on XP, Vista & Win 7).
  
  1 - autheticate as a Jenkins admin in a browser of your choice and download the slave-agent.jnlp file for the slave. The download URL will be something like
  http://<jenkinsurl>/computer/<slavename>/slave-agent.jnlp
  and can be found in the jenkins-slave.xml file on the slave.
  
  2 - transfer slave-agent.jnlp to the slave and store in the same folder as slave.jar and jenkins-slave.xml files
  
  3 - edit jenkins-slave.xml and change the URL of slave-agent.jnlp to be
  file:///%BASE%/slave-agent.jnlp
  That means that the arguments line in jenkins-slave.xml will likely read
  
   <arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpUrl file:///%BASE%/slave-agent.jnlp</arguments>
  
  Now just start the slave service as normal and all should work.
  
  Disclaimer: I haven't studied the security implications of storing slave-agent.jnlp at that location in the slave. I suspect it is fine but it would be good if someone could comment on whether there is a better location.
  

I managed to fix this fairly simply on my windows slaves (tested on XP, Vista & Win 7).

1 - autheticate as a Jenkins admin in a browser of your choice and download the slave-agent.jnlp file for the slave. The download URL will be something like
http:///computer//slave-agent.jnlp
and can be found in the jenkins-slave.xml file on the slave.

2 - transfer slave-agent.jnlp to the slave and store in the same folder as slave.jar and jenkins-slave.xml files

3 - edit jenkins-slave.xml and change the URL of slave-agent.jnlp to be
file:///%BASE%/slave-agent.jnlp
That means that the arguments line in jenkins-slave.xml will likely read

-Xrs -jar "%BASE%\slave.jar" -jnlpUrl file:///%BASE%/slave-agent.jnlp

Now just start the slave service as normal and all should work.

Disclaimer: I haven't studied the security implications of storing slave-agent.jnlp at that location in the slave. I suspect it is fine but it would be good if someone could comment on whether there is a better location.

[jenkins-infra-bot]

jesperjensen:

• Original comment link
• Raw content of original comment:

  Based up @Trevor and @Richard instructions here is how I got the windows slaves to run as a service again:
  1 - Stop service
  2 - Uninstall the service if it exists dos (sc delete jenkinsslave-C__Jenkins)
  3 - Delete the old jenkins-slave.exe, slave.jar and jenkins-slave.xml
  4 - Start the web client and let it install the service
  5 - Edit the jenkins-slave.xml  so the it looks like this the important part is the jnlpCredentials <arguments>-Xrs  -jar "%BASE%\slave.jar" -jnlpCredentials <user>:<password> -jnlpUrl http://<your server>/computer/<slave name>/slave-agent.jnlp</arguments></arguments>
  6 - Stop your web client if it not already and restart your service.
  
  Mine are now running.
  
  Note it is very important that you delete your old slave.jar and get the new one via the web install. This works with version 1.499
  
  To the developer please make a note that slave.jar needs to be updated on the slave when you make a new revision!
  

Based up @​Trevor and @​Richard instructions here is how I got the windows slaves to run as a service again:
1 - Stop service
2 - Uninstall the service if it exists dos (sc delete jenkinsslave-C__Jenkins)
3 - Delete the old jenkins-slave.exe, slave.jar and jenkins-slave.xml
4 - Start the web client and let it install the service
5 - Edit the jenkins-slave.xml so the it looks like this the important part is the jnlpCredentials -Xrs -jar "%BASE%\slave.jar" -jnlpCredentials : -jnlpUrl http:///computer//slave-agent.jnlp
6 - Stop your web client if it not already and restart your service.

Mine are now running.

Note it is very important that you delete your old slave.jar and get the new one via the web install. This works with version 1.499

To the developer please make a note that slave.jar needs to be updated on the slave when you make a new revision!

[jenkins-infra-bot]

rainerw:

• Original comment link
• Raw content of original comment:

  You have to pass in an user to authenticate via "-jnlpCredentials jenkinsuser:secret":
  My cmd line:
  java -Xrs -jar "slave.jar"  -classpath "patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci/computer/winnt-1/slave-agent.jnlp
  
  or my jenkins-slve.xml :
  
  <arguments>-Xrs -jar "%BASE%\slave.jar" -classpath "%BASE%\patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci.../slave-agent.jnlp</arguments>
  
  The difference to 1.480.1 is that there is now an slave connect/disconnect right which must be given to the "jenkinsuser" (Beside overall read)
  
  The slave installer has the bug that it does not write a correct .xml file with credentials, you have to add this manually. (For LTS the common-codec-1.5.jar had to be added to the classpath, because otherwiese the authentication is missing a base64 codec : JENKINS-9679)
  
  -> this works on 1.480.2
  

You have to pass in an user to authenticate via "-jnlpCredentials jenkinsuser:secret":
My cmd line:
java -Xrs -jar "slave.jar" -classpath "patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci/computer/winnt-1/slave-agent.jnlp

or my jenkins-slve.xml :

-Xrs -jar "%BASE%\slave.jar" -classpath "%BASE%\patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci.../slave-agent.jnlp

The difference to 1.480.1 is that there is now an slave connect/disconnect right which must be given to the "jenkinsuser" (Beside overall read)

The slave installer has the bug that it does not write a correct .xml file with credentials, you have to add this manually. (For LTS the common-codec-1.5.jar had to be added to the classpath, because otherwiese the authentication is missing a base64 codec : JENKINS-9679)

-> this works on 1.480.2

[jenkins-infra-bot]

alexlombardi:

• Original comment link
• Raw content of original comment:

  @Pei-Tang Huang: "I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue"
  
  I tried this but kept getting error:
  
  Connecting to JenkinsSlave1
  ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins
  java.net.UnknownHostException: JenkinsSlave1
  	at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
  	at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source)
  	at java.net.InetAddress.getAddressFromNameService(Unknown Source)
  	at java.net.InetAddress.getAllByName0(Unknown Source)
  	at java.net.InetAddress.getAllByName(Unknown Source)
  	at java.net.InetAddress.getAllByName(Unknown Source)
  	at java.net.InetAddress.getByName(Unknown Source)
  	at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:202)
  	at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204)
  	at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
  	at java.util.concurrent.FutureTask.run(Unknown Source)
  	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
  	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
  	at java.lang.Thread.run(Unknown Source)
  
  Even though I have verified that's the correct slave/service name.
  

@​Pei-Tang Huang: "I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue"

I tried this but kept getting error:

Connecting to JenkinsSlave1
ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins
java.net.UnknownHostException: JenkinsSlave1
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source)
at java.net.InetAddress.getAddressFromNameService(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:202)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Even though I have verified that's the correct slave/service name.