On 02/01/2013 05:25 PM, Christian Hernandez wrote:
Hello

Attached is a TCPDUMP.

Communication is happening between 192.168.114.95 and 192.168.114.114

Thanks. The problem is that 389 doesn't like the fact that the search request includes the control tag but the length is 0. You said you were using CDS 8.1 - if that was centos-ds running on EL5, that used mozldap for the ldap sdk. 389 now uses openldap for the ldap sdk. Looks like there is a slight difference between how mozldap and openldap handle this situation. Please file a ticket at https://fedorahosted.org/389/newticket

In the meantime, is there some option in github server to either completely disable LDAP controls in the LDAP search request? Or, alternately, is there a way to add some control to the search request? The goal is to figure out some way to tell github not to pass in a 0 length LDAP control sequence.


Thank you,

Christian Hernandez


On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:

    On 02/01/2013 01:42 PM, Christian Hernandez wrote:
    We are trying to configure our internal GitHub server to use Our
    IPA server's LDAP for user logins.

    We successfully configured it; but users can't seem to login.

    So, before you ask, yes we do have an active support case with
    githubenterprise about this; but wanted to see if anyone else ran
    into the same issue.

    Attached is the screenshot of the config.

    This is the errors I'm seeing in the DirSrv logs


    [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241
    connection from 192.168.114.95 to 192.168.114.114
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND
    dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128
    version=3
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97
    nentries=0 etime=0
    dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com"
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2
    filter="(uid=chrish)", failed to decode LDAP controls
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101
    nentries=0 etime=0
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1

    Anyone has run into this?

    Looks like DS is receiving some LDAP controls that it doesn't know
    how to process.  Does this work with any other LDAP server?  Can
    you run wireshark/tshark and capture the network traffic?  I'd
    like to see what the BER looks like.


    Also, I haven't tried connecting with TLS because I don't know
    where to find the cert! So if someone can point me in the right
    direction there  I would appreciate it :)

    Thank you,

    Christian Hernandez


    _______________________________________________
    Freeipa-users mailing list
    Freeipa-users@redhat.com  <mailto:Freeipa-users@redhat.com>
    https://www.redhat.com/mailman/listinfo/freeipa-users




Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com <mailto:christi...@4over.com> <mailto:christi...@4over.com <mailto:christi...@4over.com>> www.4over.com <http://www.4over.com/> <http://www.4over.com <http://www.4over.com/>>


On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:

    On 02/01/2013 01:42 PM, Christian Hernandez wrote:
    We are trying to configure our internal GitHub server to use Our
    IPA server's LDAP for user logins.

    We successfully configured it; but users can't seem to login.

    So, before you ask, yes we do have an active support case with
    githubenterprise about this; but wanted to see if anyone else ran
    into the same issue.

    Attached is the screenshot of the config.

    This is the errors I'm seeing in the DirSrv logs


    [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241
    connection from 192.168.114.95 to 192.168.114.114
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND
    dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128
    version=3
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97
    nentries=0 etime=0
    dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com"
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2
    filter="(uid=chrish)", failed to decode LDAP controls
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101
    nentries=0 etime=0
    [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1

    Anyone has run into this?

    Looks like DS is receiving some LDAP controls that it doesn't know
    how to process.  Does this work with any other LDAP server?  Can
    you run wireshark/tshark and capture the network traffic?  I'd
    like to see what the BER looks like.


    Also, I haven't tried connecting with TLS because I don't know
    where to find the cert! So if someone can point me in the right
    direction there  I would appreciate it :)

    Thank you,

    Christian Hernandez


    _______________________________________________
    Freeipa-users mailing list
    Freeipa-users@redhat.com  <mailto:Freeipa-users@redhat.com>
    https://www.redhat.com/mailman/listinfo/freeipa-users



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to