[Freeipa-users] Jenkins integration?

[Maciej Drobniuch]

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?

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