Oh yes, sorry; we all live in Acronyms :-) Yes centos-ds
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> www.4over.com <http://www.4over.com> On Fri, Feb 1, 2013 at 4:35 PM, Rich Megginson <rmegg...@redhat.com> wrote: > On 02/01/2013 05:29 PM, Christian Hernandez wrote: > > And to answer your questions Rich. > > GitHub was working with CDS 8.1.0 > > > What is CDS? Is that centos-ds? > > > > It looks like IPA is using 389 > > ns-slapd --version > 389 Project > 389-Directory/1.2.10.2 B2012.194.51 > > > 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> > www.4over.com <http://www.4over.com> > > > On Fri, Feb 1, 2013 at 4:25 PM, Christian Hernandez > <christi...@4over.com>wrote: > >> Hello >> >> Attached is a TCPDUMP. >> >> Communication is happening between 192.168.114.95 and 192.168.114.114 >> >> Thank you, >> >> Christian Hernandez >> >> >> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson <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 >>> listFreeipa-users@redhat.comhttps://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> >> www.4over.com <http://www.4over.com> >> >> >> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson <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 >>> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >> > >
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users