Active Directory (AD) plugin concerns
Martijn Verburg
Several of my clients in London run AD (and often these are fairly
complex or non-standard installations). They also typically have very
strict requirements in place with regards to having software be
integrated with AD.
Jenkins does have an AD plugin, but it's currently fundamentally
broken (several Blockers and Criticals) and has been for some time. My
clients in general love Jenkins and what it offers, but have not fully
or formerly adopted Jenkins because of this existing plugin issue.
They're aware that this is a free open source project and that they
don't just simply get fixes when they want them without effort on
their part *wry grin*. Hoever, they are concerned that there is no
'lead' developer listed for the AD plugin (whereas there is for many
others).
Although they don't have the complete expertise to fix the issues
themselves (and nor do I) they can possibly put some internal resource
on trying to fix some of these issues.
In short, is there a Jenkins developer that I/we can work with on a
regular basis who understands this plugin?
In the interests of transparency this is being x-posted to the Hudson
dev mailing list as we'd be happy to help fix the issues in both
projects (we suspect the code hasn't changed much in that plugin).
Cheers,
Martijn
Nigel Magnay
Martijn Verburg
Thanks for your response, my comments inline.
On 5 May 2011 17:00, Nigel Magnay <nigel....@gmail.com> wrote:
> By 'integrated with active directory' do you mean 'authenticated via', or
> single-sign on?
>
> The former can be achieved by just treating AD as any old LDAP server -
> getting the CN= names et al correct can be annoying, but it can be done.
> The latter - NTLM authentication - is *notoriously* painful and unreliable.
> Acegi (spring security) which is what I think is being used effectively
> abandoned trying to get it to work, and later versions from memory go down a
> Kerberos route instead.
Most of my clients would prefer the NTLM support but will grudgingly
drop down to LDAPS but are extremely reluctant to drop down to LDAP.
I can't say they've been hugely successful with the LDAPS or LDAP
methods with this plugin though.
Typically thy want authentication and authorisation.
Cheers,
Martijn
Nord, James
Make sure to use the correct (federated/forest?) port if you have multiple domains though. (search the archives for a mail I sent which points to the ms kb article.
There is only one critical (the other is a dupe) issue for the ad plugin and that is it does ldaps by default on Linux (which sounds like what you client will accept) (and it has a workaround) so I would hardly say it is fundamentally broken.
The other major is timing - which I have seen if you have many distributed AD servers - it may connect to a sub-optimal one - but droping the AD plugin and using LDAP solved this (and speeds up the login time dramatically!).
Also the AD plugin recursively gets all groups (and groups from the groups) this adds to some slowdown due to the recursive queries - and is my fault but was expected as that is how windows permissions would work!) LDAP IIRC behaves differently.
/james
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
Martijn Verburg
Kohsuke Kawaguchi
> Hi all,
>
> Several of my clients in London run AD (and often these are fairly
> complex or non-standard installations). They also typically have very
> strict requirements in place with regards to having software be
> integrated with AD.
>
> Jenkins does have an AD plugin, but it's currently fundamentally
> broken (several Blockers and Criticals) and has been for some time. My
> clients in general love Jenkins and what it offers, but have not fully
> or formerly adopted Jenkins because of this existing plugin issue.
I'm the main guy behind the AD plugin. My perception of it is somewhat
different from "fundamentally broken", but I'd love to hear the specifics.
And I'd also love to make it work with NTLM or Windows Integrated
Authentication.
> They're aware that this is a free open source project and that they
> don't just simply get fixes when they want them without effort on
> their part *wry grin*. Hoever, they are concerned that there is no
> 'lead' developer listed for the AD plugin (whereas there is for many
> others).
>
> Although they don't have the complete expertise to fix the issues
> themselves (and nor do I) they can possibly put some internal resource
> on trying to fix some of these issues.
>
> In short, is there a Jenkins developer that I/we can work with on a
> regular basis who understands this plugin?
>
> In the interests of transparency this is being x-posted to the Hudson
> dev mailing list as we'd be happy to help fix the issues in both
> projects (we suspect the code hasn't changed much in that plugin).
>
> Cheers,
> Martijn
>
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Kohsuke Kawaguchi
>
> Several of my clients in London run AD (and often these are fairly
> complex or non-standard installations). They also typically have very
> strict requirements in place with regards to having software be
> integrated with AD.
>
> Jenkins does have an AD plugin, but it's currently fundamentally
> broken (several Blockers and Criticals) and has been for some time. My
> clients in general love Jenkins and what it offers, but have not fully
> or formerly adopted Jenkins because of this existing plugin issue.
>
> They're aware that this is a free open source project and that they
> don't just simply get fixes when they want them without effort on
> their part *wry grin*. Hoever, they are concerned that there is no
> 'lead' developer listed for the AD plugin (whereas there is for many
> others).
BTW the plugin does list me as the maintainer:
https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin
>
> Although they don't have the complete expertise to fix the issues
> themselves (and nor do I) they can possibly put some internal resource
> on trying to fix some of these issues.
>
> In short, is there a Jenkins developer that I/we can work with on a
> regular basis who understands this plugin?
>
> In the interests of transparency this is being x-posted to the Hudson
> dev mailing list as we'd be happy to help fix the issues in both
> projects (we suspect the code hasn't changed much in that plugin).
>
> Cheers,
> Martijn
>
Martijn Verburg
> BTW the plugin does list me as the maintainer:
> https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin
This is correct! However the view that my clients normally look at is at:
i.e. The list of components and their leads in JIRA. This doesn't
list you as the maintainer. I've pointed my clients to the page you
mention above, I think that will help!
Cheers,
Martijn
Martijn Verburg
>> Jenkins does have an AD plugin, but it's currently fundamentally
>> broken (several Blockers and Criticals) and has been for some time. My
>> clients in general love Jenkins and what it offers, but have not fully
>> or formerly adopted Jenkins because of this existing plugin issue.
>
> I'm the main guy behind the AD plugin. My perception of it is somewhat
> different from "fundamentally broken", but I'd love to hear the specifics.
You're right, 'fundamentally broken' is emotive wording (but rightly
or wrongly, that's the feeling my clients have). Jenkins-8132 (8280
should be closed as a duplicate) and Jenkins-4948, 9412, 8461 + a few
others make it a very frustrating plugin to work with for them. They
are holding off promoting Jenkins as an official CI solution as they
are waiting for this particular plugin to become 'mature'.
This is always a difficult subject. I also run a couple of open source
projects and I understand that there needs to be a two way effort to
resolve issues. It always frustrates me users are demanding quick
fixes to software they haven't paid for or contributed towards :).
I guess what I was trying to get across is that I think I can get 1-2
of my clients to apply some resource to this (hopefully myself and
other internal resources), provided that they have a regular AD plugin
contact to work with in the Jenkins community. I'm aware that you have
an awful lot on your plate right now and have more important issues to
worry about! If there is another Jenkins developer who knows it
reasonably well, it would be great to get in touch.
> And I'd also love to make it work with NTLM or Windows Integrated
> Authentication.
Jenkins-3730 would be a major coup for 'traditional' enterprise users.
I understand this is a hard problem to solve, but it's hard to battle
with 'The MS product can do it!" statements :|
Look forward to meeting you in May, I'm hopefully taking some Japanese
clients with me who are keen to meet you in person :)
Cheers,
Martijn
Kohsuke Kawaguchi
Indeed. Thanks for the catch! I made myself the maintainer.
Kohsuke Kawaguchi
> Hi Kawaguchi-san
>
>>> Jenkins does have an AD plugin, but it's currently fundamentally
>>> broken (several Blockers and Criticals) and has been for some time. My
>>> clients in general love Jenkins and what it offers, but have not fully
>>> or formerly adopted Jenkins because of this existing plugin issue.
>>
>> I'm the main guy behind the AD plugin. My perception of it is somewhat
>> different from "fundamentally broken", but I'd love to hear the specifics.
>
> You're right, 'fundamentally broken' is emotive wording (but rightly
> or wrongly, that's the feeling my clients have). Jenkins-8132 (8280
> should be closed as a duplicate)
Done. Looks like my understanding of AD was still "buggy" --- I assumed
that LDAPS is always there (and with the AD deployments I've used this
with, it was indeed the case), but given the # of people reporting a
problem and so on, that was clearly not the case.
So I agree that it's badly broken. This seems like the #1 issue we need
to fix quickly.
> and Jenkins-4948, 9412, 8461 + a few
> others make it a very frustrating plugin to work with for them. They
> are holding off promoting Jenkins as an official CI solution as they
> are waiting for this particular plugin to become 'mature'.
I fixed JENKINS-9412 toward 1.413, and I put comments on other tickets
you mentioned.
> This is always a difficult subject. I also run a couple of open source
> projects and I understand that there needs to be a two way effort to
> resolve issues. It always frustrates me users are demanding quick
> fixes to software they haven't paid for or contributed towards :).
>
> I guess what I was trying to get across is that I think I can get 1-2
> of my clients to apply some resource to this (hopefully myself and
> other internal resources)
Great! Let me know your GitHub ID so that I can give you the write access.
> ... , provided that they have a regular AD plugin
> contact to work with in the Jenkins community. I'm aware that you have
> an awful lot on your plate right now and have more important issues to
> worry about! If there is another Jenkins developer who knows it
> reasonably well, it would be great to get in touch.
I see that the plugin is getting some contributions from various other
folks, so between them and myself, I'd like you to give us a shot :-)
We can provide you extra eyeballs and hand-holding where you feel
necessary, and hopefully you can provide the heavy-lifting and the
actual real-world environment to verify the code against.
>
>> And I'd also love to make it work with NTLM or Windows Integrated
>> Authentication.
>
> Jenkins-3730 would be a major coup for 'traditional' enterprise users.
> I understand this is a hard problem to solve, but it's hard to battle
> with 'The MS product can do it!" statements :|
>
I think we have the right libraries in place to do what native clients do.
> Look forward to meeting you in May, I'm hopefully taking some Japanese
> clients with me who are keen to meet you in person :)
Cool!
When I went to Japan I talked to some German guy who happened to be
visiting Tokyo, and now that I'm going to London I'm talking to Japanese
guys? What kind of crazy world we live in...
Kohsuke Kawaguchi
> On 05/10/2011 05:54 PM, Martijn Verburg wrote:
>> Hi Kawaguchi-san
>>
>>>> Jenkins does have an AD plugin, but it's currently fundamentally
>>>> broken (several Blockers and Criticals) and has been for some time. My
>>>> clients in general love Jenkins and what it offers, but have not fully
>>>> or formerly adopted Jenkins because of this existing plugin issue.
>>>
>>> I'm the main guy behind the AD plugin. My perception of it is somewhat
>>> different from "fundamentally broken", but I'd love to hear the specifics.
>>
>> You're right, 'fundamentally broken' is emotive wording (but rightly
>> or wrongly, that's the feeling my clients have). Jenkins-8132 (8280
>> should be closed as a duplicate)
>
> Done. Looks like my understanding of AD was still "buggy" --- I assumed
> that LDAPS is always there (and with the AD deployments I've used this
> with, it was indeed the case), but given the # of people reporting a
> problem and so on, that was clearly not the case.
>
> So I agree that it's badly broken. This seems like the #1 issue we need
> to fix quickly.
After thinking about this some more, I think the right thing to do is to
connect to LDAP (not LDAPS), and then attempt StartTLS. This enables a
fully secure authentication where LDAPS is available, and graceful
fallback to LDAP where LDAPS isn't available, and things just work (TM)
without any user configuration.
I've attached the new version in JENKINS-8132 [1]. Feedback appreciated.
[1]
https://issues.jenkins-ci.org/secure/attachment/20465/active-directory.hpi
Martijn Verburg
I really appreciate the responses! I certainly did not expect the
JIRA items to be instantly fixed :). I am currently in Prague fro a
JUG leaders meeting and will be in Krakow at Geecon for the rest of
the week, so apologies for not being able to work on this immediately!
I've let my main clients know that they should go ahead and allocate
some resource to test the plugin thoroughly. I'm personally looking
forward to diving into the code!
I will respond in depth next week when I return to London.
Cheers,
Martijn
