[Freeipa-users] Jenkins integration?

Fri Mar 24 13:00:03 UTC 2017

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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170324/ec38760d/attachment.htm>