View Windows Negotiate SSO on the plugin site for more information.
A SSO plugin for Jenkins 1.586 and above, running on Windows in a domain environment, using only the built-in Jetty web server.
- Jenkins is running as a service
- Jenkins is on a Windows system
- Jenkins is authenticating using the Active Directory plugin
- Service account that Jenkins uses must have kerberos authentication privileges on the domain (see SPN information here)
- Windows system account (on the domain) must be configured to allow kerberos authentication (HTTP SPNs)
- Clients accessing Jenkins must be on the same domain (Not tested in a cross-domain environment)
- Access to Jenkins using a web browser on the hosting system is recommended during initial configuration (as is leaving "Allow Localhost" checked until it all works)
If you see HTTP 413 errors when using this plugin, you might need to increase the request header size. This is done by editing %JENKINS_HOME%\jenkins.xml and adding "
--requestHeaderSize=16384" to the Jenkins command-line argument.
For this plugin to work, Jenkins needs to be running as a service that has permission to perform kerberos authentication, and the system needs to have a domain configuration that allows kerberos authentication. See https://github.com/dblock/waffle/blob/master/Docs/Troubleshooting.md for some tips on this.
My testing configuration has Jenkins running as hostname\Network Service, with HTTP/hostname and HTTP/hostname.domain SPNs. (NOTE: Previously used hostname\Local System, but changed it to hostname\Network Service for security purposes. Doing so originally broke the jenkins restart, until I edited permissions on the jenkins service using the Service Security Editor tool to allow Network Service to start/stop/restart the jenkins service.)
This uses the Waffle security classes to operate the single sign on, and relies the permissions settings of the Active Directory plugin for user permissions.
As a side note, do not enable impersonation unless every user who has permissions to edit job configurations also has write privileges on the corresponding workspaces...
This started because I failed to get KerberosSSO working on a Jenkins instance running on a Windows server, and so, apparently, have the creators of KerberosSSO. So I set out to create an extension that did have working SSO for an ActiveDirectory domain. This started out heavily based on the KerberosSSO plugin (see https://wiki.jenkins-ci.org/display/JENKINS/Kerberos+SSO+Plugin and https://github.com/jenkinsci/kerberos-sso-plugin), and then suffered the massive changes as I replaced the entire functionality of the extension, as well as how it was implemented (from using Plugin to instead use extension points).
Open Tickets (bugs and feature requests)
- Nothing yet...
Fix JENKINS-55697 Security-901 Set user seed on successful authentication
Update baseline Jenkins version to Jenkins 2.150.2
Update parent POM reference to 3.39
Update Waffle-JNA dependency to 1.9.0 (requires Java 8)
FireLoggedIn event does not require reflection anymore - as the pom dependency on the core changed to 1.586
- Adjust the logging
- Reduced the number of times the user is actually authenticated from all requests that should be authenticated to only on requests that should be authenticated when the user session has not been authenticated.
- Update to plugin pom 2.11
- Make sure the settings UI always has the correct information
- Fix JENKINS-32197 More URLs that NegSecFilter should not secure
- Fix JENKINS-30095 Make Jenkins 1.586 the minimum version (Dependency version issue)
- Fix JENKINS-30116 NegSecFilter should not secure notifyCommit URLs
- Remove use of functions only present in Java 1.8
- Update to plugin pom 2.3 (but build against Jenkins 1.586)
- Mirror the method that Jenkins uses to determine if a URI managed by a plugin should be secured (avoid needing to explicitly list each path that shouldn't be secured)
- First release