[Freeipa-users] Jenkins integration?

[Alexander Bokovoy]

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