Re: [Freeipa-users] Jenkins integration?
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 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 >> 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. >
Re: [Freeipa-users] Jenkins integration?
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... No, Jenkins sends a bind request with the user's bind-DN and clear-text password. Password check is done server-side. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: [Freeipa-users] Jenkins integration?
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 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 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 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. >> >> Bu
Re: [Freeipa-users] Jenkins integration?
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 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 >> 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 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. > >>>
Re: [Freeipa-users] Jenkins integration?
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 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 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
Re: [Freeipa-users] Jenkins integration?
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 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 >> 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 >> > > -- > /
Re: [Freeipa-users] Jenkins integration?
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/main/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 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 -- 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
Re: [Freeipa-users] Jenkins integration?
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 ;) * 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 ;-) Ideas & suggestions are welcome! M. On Sat, Feb 11, 2017 at 4:28 PM, Michael Ströder 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 -- 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
Re: [Freeipa-users] Jenkins integration?
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. smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: [Freeipa-users] Jenkins integration?
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. Your mileage may vary, indeed, but I'd rather re-use what is available to you than implement a parallel infrastructure, including reliability aspects. Anyway, I think we are distancing away from the original topic. -- / Alexander Bokovoy -- 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
Re: [Freeipa-users] Jenkins integration?
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. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: [Freeipa-users] Jenkins integration?
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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-users] Jenkins integration?
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. Regards Harri -- 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
Re: [Freeipa-users] Jenkins integration?
Alexander Bokovoy wrote: > On la, 11 helmi 2017, Michael Ströder wrote: >> Harald Dunkel wrote: >>> On 02/10/17 15:07, Tomasz Torcz wrote: On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: > did anybody succeed in using Freeipa for Jenkins' LDAP module? > I can't make it work :-(. I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. I have Jenkins set to PAM authentication, which in turn goes thru SSSD. It works fine, groups are resolved correctly, too. >>> >>> Thats plan B. Its good to know that this works, but I >>> don't give up that easy. >> >> Jenkins' LDAP integration is pretty good and flexible. I made it work with >> various >> LDAP servers in customer projects. I did not have do that with FreeIPA yet >> but I'd >> be very surprised if it doesn't work. >> >> (Personally I'd avoid going through PAM.) > > Any specific reason for not using pam_sss? At the end it's a matter of personal taste. In my deployments PAM logins have most times nothing to do with the services running on a host which might even use a completely different LDAP service. > Remember, with SSSD involved you get also authentication for trusted users > from Active > Directory realms. You don't get that with generic LDAP way. This might be a use-case for which to prefer going through pam_sss. As usual your mileage may vary. But we both know next to nothing about the original posters infrastructure. > Also, you'd be more efficient in terms of utilising LDAP connections. Hmm, IMHO this depends very much on the client software used. Modern Java software has decent LDAP connection pooling. Ciao, Michael. (not a Java fan though) smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: [Freeipa-users] Jenkins integration?
On la, 11 helmi 2017, Michael Ströder wrote: Harald Dunkel wrote: On 02/10/17 15:07, Tomasz Torcz wrote: On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: did anybody succeed in using Freeipa for Jenkins' LDAP module? I can't make it work :-(. I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. I have Jenkins set to PAM authentication, which in turn goes thru SSSD. It works fine, groups are resolved correctly, too. Thats plan B. Its good to know that this works, but I don't give up that easy. Jenkins' LDAP integration is pretty good and flexible. I made it work with various LDAP servers in customer projects. I did not have do that with FreeIPA yet but I'd be very surprised if it doesn't work. (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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-users] Jenkins integration?
Harald Dunkel wrote: > On 02/10/17 15:07, Tomasz Torcz wrote: >> On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: >>> did anybody succeed in using Freeipa for Jenkins' LDAP module? >>> I can't make it work :-(. >> >> I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. >> I have Jenkins set to PAM authentication, which in turn goes thru SSSD. >> It works fine, groups are resolved correctly, too. > > Thats plan B. Its good to know that this works, but I > don't give up that easy. Jenkins' LDAP integration is pretty good and flexible. I made it work with various LDAP servers in customer projects. I did not have do that with FreeIPA yet but I'd be very surprised if it doesn't work. (Personally I'd avoid going through PAM.) Being in your position I'd try to analyze 389-DS' logs to see whether Jenkins contacts your LDAP server and which queries it sends. Most times it's a trivial config item missing. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: [Freeipa-users] Jenkins integration?
On 02/10/17 15:07, Tomasz Torcz wrote: > On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: >> Hi folks, >> >> did anybody succeed in using Freeipa for Jenkins' LDAP module? >> I can't make it work :-(. > > I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. > I have Jenkins set to PAM authentication, which in turn goes thru SSSD. > It works fine, groups are resolved correctly, too. > Thats plan B. Its good to know that this works, but I don't give up that easy. My major problem ist that jenkins doesn't write propper log files. Java is as awkward as it was 20 years ago. Thanx Harri -- 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
Re: [Freeipa-users] Jenkins integration?
On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: > Hi folks, > > did anybody succeed in using Freeipa for Jenkins' LDAP module? > I can't make it work :-(. I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. I have Jenkins set to PAM authentication, which in turn goes thru SSSD. It works fine, groups are resolved correctly, too. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- 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
[Freeipa-users] Jenkins integration?
Hi folks, did anybody succeed in using Freeipa for Jenkins' LDAP module? I can't make it work :-(. On the command line the jenkins user appears to have read access to the LDAP database. The config UI for Jenkin's LDAP plugin doesn't complain, either. Jenkins System Log appears to be fine. But if a "freeipa user" tries to login in Jenkins, then he gets an "invalid login information". For Confluence (both are Java Webapps) there was no such problem. Every helpful hint is highly appreciated. Harri -- 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