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 <aboko...@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 <aboko...@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 < >>>> aboko...@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 < >>>>>> mich...@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
-- 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