Can't log in to Jenkins in Docker container after plugins were updated

Using Jenkins
1

Hi,

There’s Jenkins instance running in Docker container.
It’s Jenkins version 2.303.2 and it has domain authentication configured.
On the server there is file system /jenkins/home which is mapped to /var/jenkins_home in the container.

The problem is that after the plugins have been updated lately, users can no longer log in to Jenkins.
I suspect it might be due to the fact there were “Active Directory” and “Credentials” plugin included in the bunch of plugins to be updated and maybe something went wrong with the update.

I already tried few things but nothing works in this case:

  1. Checked for the file /jenkins/home/secrets/initialAdminPassword (which should have admin password inside) - there was no such file.
    I created one with some password but it doesn’t work - I can’t log in with admin user and this password.

  2. I added the following content to /jenkins/home/users/[MyUserDirectory]/config.xml →
    <hudson.security.HudsonPrivateSecurityRealm_-Details>
    #jbcrypt:[bCryptPasswordHash]
    </hudson.security.HudsonPrivateSecurityRealm_-Details>
    Still can’t log in to Jenkins with my user and the hashed password.

  3. Changed useSecurity value from ‘true’ to ‘false’ in /jenkins/home/config.xml file
    It doesn’t work - change is reverted after I restart Jenkins container (when I check the file, this parameter has ‘true’ value again).

  4. I added the below to config.xml file
    false
    It doesn’t work too - change is also reverted after I restart Jenkins container.

What else can I do to restore normal Jenkins operation ?

Thank you in advance!

2

Your best bet is to shutdown Jenkins, then edit the file, then start it up. It’ll probably sync the file on shutdown.

You may be able to edit the file then sigterm the process which should prevent any cleanup from happening but it’ll be at your own risk

3

I tried it but it’s not working. I observed this useSecurity value is being changed again from ‘false’ to ‘true’ not on shutdown but during startup. Unfortunately I have no idea what is changing this file and why…

I stop the container, change the value in file to ‘false’, start the container again and this happens:

[root@jnk-master ~]# grep useSec /jenkins/home/config.xml
false
[root@jnk-master ~]# docker ps | grep master
634331a1ed95 repo-server.com/jenkins_prod_repo/jenkins:3.1.5-develop.15.fdb6660 “/sbin/tini – /usr/…” 6 seconds ago Up 1 second (health: starting) 8080/tcp, 50000/tcp jenkins-support-on-prem_master.1.plauvwleohbbyziy3ei3panpi
[root@jnk-master ~]# grep useSec /jenkins/home/config.xml
false

Then when I check after 20-30 seconds it looks like this:
[root@jnk-master ~]# grep useSec /jenkins/home/config.xml
true

4

my guess is that this is a custom version of the jenkins image that has an groovy init script or jenkins configuraiton as code yaml file.

Jenkins doesn’t just enable security on its own

1 Like
5

Ok, there are files
/jenkins/home/config/jenkins.yaml
/jenkins/home/init.groovy.d/seed.groovy
/jenkins/home/init.groovy.d/security.groovy

Can I set some parameters in these files, so that I would be able to log in to Jenkins without password or with some default / predefined password ?

6

I would confirm that you still need the groovy files if you have config as code, they might be overlapping quite a bit.

config as code example for using internal user db - configuration-as-code-plugin/demos/embedded-userdatabase at master · jenkinsci/configuration-as-code-plugin · GitHub

1 Like
7

That was very useful, thanks :slight_smile: Using this method I managed to log in to Jenkins with ‘admin’ account and fixed password. Now the question is how can I make Jenkins accept users with accounts from AD again ?

Should I somehow restore previous plugins (including ‘Active Directory’ plugin and maybe also ‘Credentials’ plugin) or how can I determine what went wrong ?

By the way - when I try to switch back Security Realm to Active Directory in Jenkins GUI, just adding fall-back user (according to information here - https://plugins.jenkins.io/active-directory/ ), I set the confguration for AD (domain name, controller, etc) and when I click “Test Domain”, then I get below error:

javax.naming.NamingException: LDAP connection has been closed
at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133)
at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:443)
at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365)
at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2895)
at java.naming/com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2797)
at java.naming/com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2770)
at java.naming/com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2699)
at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:723)
at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:601)
at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:566)
at hudson.plugins.active_directory.ActiveDirectoryDomain$DescriptorImpl.doValidateTest(ActiveDirectoryDomain.java:337)

8

Ok, so there is JCASC installed and /jenkins/home/config.xml file is being created/updated every time on Jenkins container startup with the content depending on what is actually defined in /jenkins/home/config/jenkins.yaml

I managed to get Jenkins working first with local ‘admin’ user, then in GUI I changed the configuration so that (after reload) I was able to log in with my AD credentials. But now the question is how to make this change persistent ?
I mean if I have already working config.xml file (which is not persistent), how can I “translate” it into jenkins.yaml file, which would also work, even after restarting docker container with Jenkins ?

9

I managed to fix it by myself, now Jenkins is running fine again with AD authentication. I had to use ‘requireTLS’ parameter in Jenkins configuration file.

1 Like