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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-users
