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 <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
-- 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