[Freeipa-users] Jenkins integration?

Fri Mar 24 15:14:18 UTC 2017

Just tried with LDAPs over jxplorer and jenkins.

Unfortunately it's not working.

The master jenkins release supports ipa auto detection.

https://gerrit-review.googlesource.com/#/c/94925/

I will give it a try.

On Fri, Mar 24, 2017 at 2:06 PM, Alexander Bokovoy <abokovoy at redhat.com>
wrote:

> On pe, 24 maalis 2017, Maciej Drobniuch wrote:
>
>> I see now what you mean.
>>
>> The SSHA decoding is handled on the client side by using acegi not on the
>> ldap server side...
>>
>> Am I inline with this?
>>
> No, you are not. There are multiple LDAP authentication providers
> (authenticators) in Acegi Security framework. When using
> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator, it
> does actual LDAP bind against LDAP server and never checks the password
> by itself. Successful LDAP bind is considered a successful password
> check. Jenkins extends BindAuthenticator code with a very small wrapper
> to allow better error messaging. It is called BindAuthenticator2. But it
> doesn't change the fact that it uses LDAP bind.
>
> I believe it is actually a default configuration in Jenkins ldap auth
> plugin. However, LDAP servers may require that LDAP bind is executed
> over a secure channel because your password is passed to LDAP server in
> clear text form. Such secure channel has to be established either with
> LDAP StartTLS (preferred) or by using LDAPS protocol.
>
> I guess what you have is a situation where both LDAP StartTLS and LDAPS
> aren't in use.
>
>
>
>> I'm logging in with cn=Directory Manager (no issues) but it fails with the
>> user dn(jxplorer)
>>
>> I'll try figure this out with the jenkins mailing list.
>>
>> Thanks Alex.
>>
>>
>> On Fri, Mar 24, 2017 at 11:57 AM, Alexander Bokovoy <abokovoy at redhat.com>
>> wrote:
>>
>> On pe, 24 maalis 2017, Maciej Drobniuch wrote:
>>>
>>> Hi Alex,
>>>>
>>>> Even while using LDAP a browser (jxplorer) I can not login with the
>>>> following user DN
>>>> uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com
>>>>
>>>> javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
>>>> Credentials]
>>>>
>>>> Only the Directory Manager cn and pwd works.
>>>> Any ideas what am I doing wrong?
>>>>
>>>> LDAP error code 49 means you actually trying to authenticate using LDAP
>>> bind but your credentials aren't correct.
>>>
>>> I don't understand how jxplorer use is relevant to Jenkins plugin setup,
>>> though. jxplorer does not use the same Java stack (acegi security) as
>>> Jenkins.
>>>
>>> I cannot test jxplorer on Fedora 25 machine because it fails to launch
>>> with Wayland.
>>>
>>>
>>>
>>> Thanks!
>>>>
>>>> On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy <
>>>> abokovoy at redhat.com>
>>>> wrote:
>>>>
>>>> On pe, 24 maalis 2017, Maciej Drobniuch wrote:
>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>>>
>>>>>> I'm trying to integrate Freeipa with jenkins and ldap auth plugin.
>>>>>>
>>>>>> The thing with the Freeipa LDAP server is:
>>>>>> * Only Directory Manager can read userPassword field (not sure yet how
>>>>>> to
>>>>>> create a sysaccount which can read the field. ldifs are welcome ;)
>>>>>>
>>>>>> This is absolutely not needed. You should configure Jenkins to perform
>>>>>>
>>>>> LDAP bind with user password against IPA LDAP server, that's all. This
>>>>> is supported by acegi security framework that Jenkins LDAP plugin is
>>>>> using. For example,
>>>>> https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai
>>>>> n/resources/hudson/security/LDAPBindSecurityRealm.groovy
>>>>> actually uses
>>>>> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2
>>>>> which
>>>>> does support normal LDAP bind.
>>>>>
>>>>> I think it is, in fact, a default setup for Jenkins LDAP auth plugin,
>>>>> so
>>>>> you actually needed to do something to disable this path.
>>>>>
>>>>>
>>>>> * The userPassword field contains the password in salted SHA (SSHA)
>>>>> format.
>>>>>
>>>>> From what I've observed the standard LDAP auth functions do not do the
>>>>>> SSHA
>>>>>> or any other type of calculations. The password is compared to the
>>>>>> plain
>>>>>> text that's usually(in a typical OpenLDAP server) stored in the
>>>>>> userPassword field(correct me if I'm wrong)
>>>>>> * I've managed to integrate CACTI with freeipa by base64 decoding the
>>>>>> userPassword field then calculating the salted hash and comparing to
>>>>>> the
>>>>>> userPassword field. (php code modification was required).
>>>>>> * I think the only way is to modify the jenkins LDAP plugin (?).
>>>>>>
>>>>>> The problem:
>>>>>> * I don't want to use sssd PAM because we have OTP enabled and that
>>>>>> would
>>>>>> annoy users(?) additionally it's causing some unidentified build
>>>>>> issues
>>>>>> BTW> Can I disable OTP per server?
>>>>>> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not
>>>>>> connected to the principal(no control over them yet)
>>>>>> * I want simple LDAP auth ;-)
>>>>>>
>>>>>> So use simple LDAP bind.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ideas & suggestions are welcome!
>>>>>
>>>>>>
>>>>>> M.
>>>>>>
>>>>>> On Sat, Feb 11, 2017 at 4:28 PM, Michael Ströder <
>>>>>> michael at stroeder.com>
>>>>>> wrote:
>>>>>>
>>>>>> Alexander Bokovoy wrote:
>>>>>>
>>>>>> > On la, 11 helmi 2017, Michael Ströder wrote:
>>>>>>> >> Alexander Bokovoy wrote:
>>>>>>> >>> On la, 11 helmi 2017, Harald Dunkel wrote:
>>>>>>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote:
>>>>>>> >>>>> On la, 11 helmi 2017, Michael Ströder wrote:
>>>>>>> >>>>>>
>>>>>>> >>>>>> (Personally I'd avoid going through PAM.)
>>>>>>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD
>>>>>>> involved
>>>>>>> >>>>> you get also authentication for trusted users from Active
>>>>>>> Directory
>>>>>>> >>>>> realms. You don't get that with generic LDAP way. Also, you'd
>>>>>>> be
>>>>>>> more
>>>>>>> >>>>> efficient in terms of utilising LDAP connections.
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>> I would prefer if the users are not allowed to login into a
>>>>>>> >>>> shell on the Jenkins server. Surely this restriction can be
>>>>>>> >>>> implemented with pam as well.
>>>>>>> >>>
>>>>>>> >>> Yes, you can use HBAC rules to prevent them from access to the
>>>>>>> host.
>>>>>>> >>
>>>>>>> >> But this introduces a hard dependency on host system
>>>>>>> administration
>>>>>>> which I personally
>>>>>>> >> always try to avoid.
>>>>>>> >>
>>>>>>> >> As said: Your mileage may vary.
>>>>>>> >
>>>>>>> > So we are talking about FreeIPA and a system enrolled to FreeIPA.
>>>>>>> This
>>>>>>> > system is already managed in FreeIPA.
>>>>>>>
>>>>>>> Please don't get me wrong. Of course I assume that the original
>>>>>>> poster
>>>>>>> wants to integrate
>>>>>>> Jenkins with FreeIPA and make use of users and their group membership
>>>>>>> already maintained
>>>>>>> therein.
>>>>>>>
>>>>>>> Let's further assume that the service (here Jenkins) might be
>>>>>>> operated
>>>>>>> by
>>>>>>> another team
>>>>>>> than the system - not so unusual case at my customers' sites -
>>>>>>> relying
>>>>>>> on
>>>>>>> defining HBAC
>>>>>>> rules for the system's sssd might not be feasible.
>>>>>>>
>>>>>>> > Your mileage may vary, indeed, but I'd rather re-use what is
>>>>>>> available
>>>>>>> > to you than implement a parallel infrastructure, including
>>>>>>> reliability
>>>>>>> > aspects.
>>>>>>>
>>>>>>> Of course we both agree on the benefits of using what's already
>>>>>>> available.
>>>>>>>
>>>>>>> > Anyway, I think we are distancing away from the original topic.
>>>>>>>
>>>>>>> Especially since we both can only make rough assumptions about
>>>>>>> requirements and
>>>>>>> operational constraints of the original poster.
>>>>>>>
>>>>>>> Ciao, Michael.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Manage your subscription for the Freeipa-users mailing list:
>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>> Go to http://freeipa.org for more info on the project
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Best regards
>>>>>>
>>>>>> Maciej Drobniuch
>>>>>> Network Security Engineer
>>>>>> Collective-Sense,LLC
>>>>>>
>>>>>>
>>>>>> --
>>>>> / Alexander Bokovoy
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Best regards
>>>>
>>>> Maciej Drobniuch
>>>> Network Security Engineer
>>>> Collective-Sense,LLC
>>>>
>>>>
>>> --
>>> / Alexander Bokovoy
>>>
>>>
>>
>>
>> --
>> Best regards
>>
>> Maciej Drobniuch
>> Network Security Engineer
>> Collective-Sense,LLC
>>
>
> --
> / Alexander Bokovoy
>

-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170324/e509af57/attachment.htm>