[Fedora-directory-users] LDAP proxy

Rich Megginson rmeggins at redhat.com
Tue Apr 21 15:18:47 UTC 2009


Michal Rejda wrote:
>> Michal Rejda wrote:
>>     
>>>> 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: [Fedora-directory-users] 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
>>>>
>>>>         
>>> In the attachment is the part of the server error log. I removed all
>>> messages before I click on the exclamation mark before the DN in the
>>> Fedora administration console -> Directory folder tab. I don't
>>> understand this log. It is helpful for you?
>>>
>>>
>>>       
>> Ah, I see. You are using the console to try to browse the AD tree? And
>> you are using the console admin user "admin"? Try ldapsearch from the
>> command line, and attempt to authenticate as an AD user (e.g.
>> cn=administrator,cn=users,dc=example,dc=com).
>>     
>
> Yes, you are right. I use the console to browse AD tree. But I do this because there is attention marker before the root suffix (lib-w2k3r2) in the Directory tab and I just double click on it.
> I tried ldapsearch using AD user (Administrator). I'm able to login but the ldapsearch don't show any results (I use Apache Directory Studio). When I looked into Whireshark log, I now see that another critical extension is missing: 2.16.840.1.113730.3.4.12. The log is in the attachment.
>   
Make sure 2.16.840.1.113730.3.4.12 is not in the transmitted controls.
Set nsProxiedAuthorization to 0 - that should make it not use 
2.16.840.1.113730.3.4.12 which is the proxyauth control.
>   
>>>>>>>>>>>> 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
>>>>>
>>>>>
>>>>>           
>>> ---------------------------------------------------------------------
>>>       
>> -
>>     
>>> --
>>>
>>> --
>>> 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/20090421/91491f1f/attachment.bin>


More information about the 389-users mailing list