Michal Rejda wrote: >> Michal Rejda wrote: >> >>>> Michal Rejda wrote: >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: fedora-directory-users-bounces at redhat.com [mailto:fedora- >>>>>> directory-users-bounces at redhat.com] On Behalf Of Rich Megginson >>>>>> Sent: Tuesday, April 14, 2009 4:25 PM >>>>>> To: General discussion list for the Fedora Directory server >>>>>> >> project. >> >>>>>> Subject: Re: LDAP proxy >>>>>> >>>>>> Michal Rejda wrote: >>>>>> >>>>>> >>>>>> >>>>>>> I tried to use http://tinyurl.com/culeft. But the database link >>>>>>> >>>>>>> >>>>>>> >>>>>> doesn't work. I setup the database link to the Active Directory >>>>>> >> (and >> >>>>>> OpenLDAP). When I looked into Wireshark log, FDS send search >>>>>> >> request >> >>>>>> with controls: >>>>>> >>>>>> >>>>>> >>>>>>> 2.16.840.1.113730.3.4.2 >>>>>>> 2.16.840.1.113730.3.4.12 >>>>>>> And the AD server responded: Unavailable Critical Extension. >>>>>>> >>>>>>> I tried to remove this two controls from Database Link Settings >>>>>>> >> (in >> >>>>>>> >>>>>> administration console) but it didn't help. The server didn't >>>>>> >> return >> >>>>>> the message above, but the administrative console show error >>>>>> >> dialog. >> >>>>>> What error? >>>>>> >>>>>> >>>>>> >>>>> I tried it again and the error message is exactly: >>>>> >>>>> Error fading object 'dn: dc=example, dc=com'. >>>>> The error send by the server was: >>>>> ". >>>>> >>>>> In the Whireshark log was still the search request witch control: >>>>> 2.16.840.1.113730.3.4.2 >>>>> >>>>> Why is this control needed by the server when I removed it from >>>>> >>>>> >>>> Database link settings? >>>> >>>> I'm not sure - maybe the console is not working correctly. Try this: >>>> 1) Shutdown the server >>>> 2) cd /etc/dirsrv/slapd-yourinstance >>>> 3) edit dse.ldif - look for the entry >>>> dn: cn=config,cn=chaining database,cn=plugins,cn=config >>>> 4) edit the nsTransmittedControls attribute - remove >>>> 2.16.840.1.113730.3.4.2 >>>> 5) save and restart the server >>>> >>>> >>> I looked into dse.ldif for a nsTransmittedControls attribute. There >>> >> is only the 1.3.6.1.4.1.1466.29539.12. , not the problematic >> 2.16.840.1.113730.3.4.2. >> >>> Isn't the 2.16.840.1.113730.3.4.2 hardcoded? >>> >> If it is, I don't see it. There is no mention of managedsa or >> 2.16.840.1.113730.3.4.2 anywhere in the chaining backend code. The only >> place it is mentioned is in the default list of nsTransmittedControls >> in >> the template-dse.ldif used during new instance creation. >> >>> Why is this so necessary? >>> >>> >> It's not necessary, and I'm not sure where it is coming from. Once >> place >> might be an internal operation, but I'm not sure what internal >> operation >> would be doing this. You might also try to remove >> nsActiveChainingComponents and nsPossibleChainingComponents to see if >> one of those components is doing an internal operation with managedsait >> set. >> > > I removed nsActiveChainingComponents and nsPossibleChainingComponents and it didn't help. > Then I'm not sure where it's coming from. I suppose you could enable tracing in the directory server and see if there is anything interesting in the error log - see http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > >>>>>>>> Michal Rejda wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I?m trying to setup proxy on FDS to another LDAP server >>>>>>>>> >> (OpenLDAP >> >>>>>>>>> and Active Directory). I tried two ways, but none of these >>>>>>>>> >> works: >> >>>>>>>>> 1) New database link to LDAP server. >>>>>>>>> >>>>>>>>> - The remote LDAP server (OpenLDAP) returns: null. manageDSAit >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> control >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> value not found >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> You might have to tweak the controls used by chaining - see >>>>>>>> http://tinyurl.com/culeft >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2) Create multiple-master replication and setup other server as >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> consumer. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> - But this show error: 255 Replication error acquiring replica: >>>>>>>>> unknown error. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Replication will only work to a SunDS, not to any other vendor. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> My question is: Is there way how to setup proxy to access >>>>>>>>> >> another >> >>>>>>>>> >>>>>>>>> >>>>>>>> LDAP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> server from Fedora DS? I know that is possible to use AD sync, >>>>>>>>> >>>>>>>>> >>>> but >>>> >>>> >>>>>> I >>>>>> >>>>>> >>>>>> >>>>>>>>> cannot install anything on the AD server. The second reason why >>>>>>>>> >> I >> >>>>>>>>> >>>>>>>>> >>>>>>>> need >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> to setup proxy is to use data stored in LDAP server (OpenLDAP, >>>>>>>>> Open Direcoty Server and Active Directory) in one place. I need >>>>>>>>> >>>>>>>>> >>>> to >>>> >>>> >>>>>> update >>>>>> >>>>>> >>>>>> >>>>>>>>> them too. It is not necessary to synchronize passwords. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> See also >>>>>>>> >>>>>>>> >> http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration >> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you for reply. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Michal >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20090417/41483592/attachment.bin
