Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-10341

Active Directory plugin produces excessive Logon Audit records in domain controller

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • Windows Server 2003 R2 64-bit; Jenkins 1.419; Active Directory plugin 1.18

      I just got a visit from one of our IT guys who noticed that we're getting a large volume of Logon Audit records in the event log of our domain controller that are all coming from our Jenkins install. In particular, several of our developers are using the "Hudson Tray Tracker" tool to monitor status of our jobs, and it appears that every refresh causes multiple logon events to fire. We're seeing 10+ events per second per user, which seems excessive.

      Some of the blame may lie with the tray tracker app, but even if it's checking every second, that's still an impressive number of Logon events to be firing. Our IT guys tell me it's overwhelming their logs and they're having trouble dealing with it. Is there anything Jenkins can do to reduce this problem?

          [JENKINS-10341] Active Directory plugin produces excessive Logon Audit records in domain controller

          I think here is what's going on. The tray tracker application is a stateless client, and each request it makes it sends a credential via HTTP BASIC auth. Jenkins is authenticating this to AD every time it gets that. So 1 auth attempt per 1 request.

          I also suspect the tray app is making multiple requests per each round. So when you combine those, multiplied by several developers, you can get 10+ logins per second. To validate this theory, you need to check the access log of Jenkins, but I think this is plausible.

          Recent versions of Jenkins support API tokens, which Jenkins can authenticate by itself without resorting to the backend server, so this might be one possibility. We can also locally cache the authentication and its outcome, although there's some risk if we make the cache time out too long.

          Kohsuke Kawaguchi added a comment - I think here is what's going on. The tray tracker application is a stateless client, and each request it makes it sends a credential via HTTP BASIC auth. Jenkins is authenticating this to AD every time it gets that. So 1 auth attempt per 1 request. I also suspect the tray app is making multiple requests per each round. So when you combine those, multiplied by several developers, you can get 10+ logins per second. To validate this theory, you need to check the access log of Jenkins, but I think this is plausible. Recent versions of Jenkins support API tokens , which Jenkins can authenticate by itself without resorting to the backend server, so this might be one possibility. We can also locally cache the authentication and its outcome, although there's some risk if we make the cache time out too long.

            Unassigned Unassigned
            dpryden Daniel Pryden
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: