<div dir="ltr">Just tried with LDAPs over jxplorer and jenkins. <div><br></div><div>Unfortunately it's not working.</div><div><br></div><div>The master jenkins release supports ipa auto detection.</div><div><br></div><div><a href="https://gerrit-review.googlesource.com/#/c/94925/">https://gerrit-review.googlesource.com/#/c/94925/</a><br></div><div><br></div><div>I will give it a try.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 24, 2017 at 2:06 PM, Alexander Bokovoy <span dir="ltr"><<a href="mailto:abokovoy@redhat.com" target="_blank">abokovoy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On pe, 24 maalis 2017, Maciej Drobniuch wrote:<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see now what you mean.<br>
<br>
The SSHA decoding is handled on the client side by using acegi not on the<br>
ldap server side...<br>
<br>
Am I inline with this?<br>
</blockquote></span>
No, you are not. There are multiple LDAP authentication providers<br>
(authenticators) in Acegi Security framework. When using<br>
org.acegisecurity.providers.ld<wbr>ap.authenticator.BindAuthentic<wbr>ator, it<br>
does actual LDAP bind against LDAP server and never checks the password<br>
by itself. Successful LDAP bind is considered a successful password<br>
check. Jenkins extends BindAuthenticator code with a very small wrapper<br>
to allow better error messaging. It is called BindAuthenticator2. But it<br>
doesn't change the fact that it uses LDAP bind.<br>
<br>
I believe it is actually a default configuration in Jenkins ldap auth<br>
plugin. However, LDAP servers may require that LDAP bind is executed<br>
over a secure channel because your password is passed to LDAP server in<br>
clear text form. Such secure channel has to be established either with<br>
LDAP StartTLS (preferred) or by using LDAPS protocol.<br>
<br>
I guess what you have is a situation where both LDAP StartTLS and LDAPS<br>
aren't in use.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm logging in with cn=Directory Manager (no issues) but it fails with the<br>
user dn(jxplorer)<br>
<br>
I'll try figure this out with the jenkins mailing list.<br>
<br>
Thanks Alex.<br>
<br>
<br>
On Fri, Mar 24, 2017 at 11:57 AM, Alexander Bokovoy <<a href="mailto:abokovoy@redhat.com" target="_blank">abokovoy@redhat.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On pe, 24 maalis 2017, Maciej Drobniuch wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Alex,<br>
<br>
Even while using LDAP a browser (jxplorer) I can not login with the<br>
following user DN<br>
uid=admin,cn=users,cn=accounts<wbr>,dc=mydomain,dc=com<br>
<br>
javax.naming.AuthenticationExc<wbr>eption: [LDAP: error code 49 - Invalid<br>
Credentials]<br>
<br>
Only the Directory Manager cn and pwd works.<br>
Any ideas what am I doing wrong?<br>
<br>
</blockquote>
LDAP error code 49 means you actually trying to authenticate using LDAP<br>
bind but your credentials aren't correct.<br>
<br>
I don't understand how jxplorer use is relevant to Jenkins plugin setup,<br>
though. jxplorer does not use the same Java stack (acegi security) as<br>
Jenkins.<br>
<br>
I cannot test jxplorer on Fedora 25 machine because it fails to launch<br>
with Wayland.<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks!<br>
<br>
On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy <<a href="mailto:abokovoy@redhat.com" target="_blank">abokovoy@redhat.com</a>><br>
wrote:<br>
<br>
On pe, 24 maalis 2017, Maciej Drobniuch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi All,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm trying to integrate Freeipa with jenkins and ldap auth plugin.<br>
<br>
The thing with the Freeipa LDAP server is:<br>
* Only Directory Manager can read userPassword field (not sure yet how<br>
to<br>
create a sysaccount which can read the field. ldifs are welcome ;)<br>
<br>
This is absolutely not needed. You should configure Jenkins to perform<br>
</blockquote>
LDAP bind with user password against IPA LDAP server, that's all. This<br>
is supported by acegi security framework that Jenkins LDAP plugin is<br>
using. For example,<br>
<a href="https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai" rel="noreferrer" target="_blank">https://github.com/jenkinsci/l<wbr>dap-plugin/blob/master/src/mai</a><br>
n/resources/hudson/security/LD<wbr>APBindSecurityRealm.groovy<br>
actually uses<br>
org.acegisecurity.providers.ld<wbr>ap.authenticator.BindAuthentic<wbr>ator2 which<br>
does support normal LDAP bind.<br>
<br>
I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so<br>
you actually needed to do something to disable this path.<br>
<br>
<br>
* The userPassword field contains the password in salted SHA (SSHA)<br>
format.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From what I've observed the standard LDAP auth functions do not do the<br>
SSHA<br>
or any other type of calculations. The password is compared to the plain<br>
text that's usually(in a typical OpenLDAP server) stored in the<br>
userPassword field(correct me if I'm wrong)<br>
* I've managed to integrate CACTI with freeipa by base64 decoding the<br>
userPassword field then calculating the salted hash and comparing to the<br>
userPassword field. (php code modification was required).<br>
* I think the only way is to modify the jenkins LDAP plugin (?).<br>
<br>
The problem:<br>
* I don't want to use sssd PAM because we have OTP enabled and that<br>
would<br>
annoy users(?) additionally it's causing some unidentified build issues<br>
BTW> Can I disable OTP per server?<br>
* I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not<br>
connected to the principal(no control over them yet)<br>
* I want simple LDAP auth ;-)<br>
<br>
So use simple LDAP bind.<br>
</blockquote>
<br>
<br>
<br>
Ideas & suggestions are welcome!<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
M.<br>
<br>
On Sat, Feb 11, 2017 at 4:28 PM, Michael Ströder <<a href="mailto:michael@stroeder.com" target="_blank">michael@stroeder.com</a>><br>
wrote:<br>
<br>
Alexander Bokovoy wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> On la, 11 helmi 2017, Michael Ströder wrote:<br>
>> Alexander Bokovoy wrote:<br>
>>> On la, 11 helmi 2017, Harald Dunkel wrote:<br>
>>>> On 02/11/17 11:57, Alexander Bokovoy wrote:<br>
>>>>> On la, 11 helmi 2017, Michael Ströder wrote:<br>
>>>>>><br>
>>>>>> (Personally I'd avoid going through PAM.)<br>
>>>>> Any specific reason for not using pam_sss? Remember, with SSSD<br>
involved<br>
>>>>> you get also authentication for trusted users from Active<br>
Directory<br>
>>>>> realms. You don't get that with generic LDAP way. Also, you'd be<br>
more<br>
>>>>> efficient in terms of utilising LDAP connections.<br>
>>>>><br>
>>>><br>
>>>> I would prefer if the users are not allowed to login into a<br>
>>>> shell on the Jenkins server. Surely this restriction can be<br>
>>>> implemented with pam as well.<br>
>>><br>
>>> Yes, you can use HBAC rules to prevent them from access to the<br>
host.<br>
>><br>
>> But this introduces a hard dependency on host system administration<br>
which I personally<br>
>> always try to avoid.<br>
>><br>
>> As said: Your mileage may vary.<br>
><br>
> So we are talking about FreeIPA and a system enrolled to FreeIPA.<br>
This<br>
> system is already managed in FreeIPA.<br>
<br>
Please don't get me wrong. Of course I assume that the original poster<br>
wants to integrate<br>
Jenkins with FreeIPA and make use of users and their group membership<br>
already maintained<br>
therein.<br>
<br>
Let's further assume that the service (here Jenkins) might be operated<br>
by<br>
another team<br>
than the system - not so unusual case at my customers' sites - relying<br>
on<br>
defining HBAC<br>
rules for the system's sssd might not be feasible.<br>
<br>
> Your mileage may vary, indeed, but I'd rather re-use what is<br>
available<br>
> to you than implement a parallel infrastructure, including<br>
reliability<br>
> aspects.<br>
<br>
Of course we both agree on the benefits of using what's already<br>
available.<br>
<br>
> Anyway, I think we are distancing away from the original topic.<br>
<br>
Especially since we both can only make rough assumptions about<br>
requirements and<br>
operational constraints of the original poster.<br>
<br>
Ciao, Michael.<br>
<br>
<br>
--<br>
Manage your subscription for the Freeipa-users mailing list:<br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/freeipa-users</a><br>
Go to <a href="http://freeipa.org" rel="noreferrer" target="_blank">http://freeipa.org</a> for more info on the project<br>
<br>
<br>
<br>
</blockquote>
<br>
--<br>
Best regards<br>
<br>
Maciej Drobniuch<br>
Network Security Engineer<br>
Collective-Sense,LLC<br>
<br>
<br>
</blockquote>
--<br>
/ Alexander Bokovoy<br>
<br>
<br>
</blockquote>
<br>
<br>
--<br>
Best regards<br>
<br>
Maciej Drobniuch<br>
Network Security Engineer<br>
Collective-Sense,LLC<br>
<br>
</blockquote>
<br>
--<br>
/ Alexander Bokovoy<br>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Best regards<br>
<br>
Maciej Drobniuch<br>
Network Security Engineer<br>
Collective-Sense,LLC<br>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
/ Alexander Bokovoy<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Best regards</div><div dir="ltr"><br><div><span style="font-size:12.8px">Maciej Drobniuch</span></div><div>Network Security Engineer</div><div><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div style="font-size:12.8px">Collective-Sense,LLC</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>