https://bugs.openldap.org/show_bug.cgi?id=9196

Bug ID: 9196 Summary: Problem using ldapsearch across forests with trust Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs@openldap.org Reporter: kleber.s.carvalho@avanade.com Target Milestone: ---

Created attachment 695 --> https://bugs.openldap.org/attachment.cgi?id=695&action=edit Problem using ldapsearch across forests with trust

Hello, We are in a project where the client has an application developed in Java that has a library developed by the client himself that uses the openldap tool to authenticate users that exist in the minca.com domain. However, this company is undergoing a drastic business change and this minca.com domain that belongs only in one forest must have a one-way trust relationship with another forest called klabs.com and its respective domains children (subtree), the general drawing can be checked in the file 1_forest_trust.pdf. The trust relationship between the two forests was successfully carried out as can be seen in the files 2_trust_minca.JPG and 3_trust_klabs.JPG A user named minca was created in the minca.com domain, that is, minca@minca.com according to files 4_mincauser_1.JPG and 4_mincauser_2.JPG (to observe the SID). Meanwhile, in the domain child.klabs.com, the group CHILDADMINS was created and the user minca from the forest minca.com was successfully added according to file 5_childadminsgroup.JPG. First, we performed a valid test by performing authentication and a simple query directly to the minca.com domain, with the command: ldapsearch -H 'LDAP: //minca.com: 3268' -D 'cn = Administrator, cn = users, dc = minca, dc = with' -w Avanade @ 2020! -b 'cn = users, dc = minca, dc = com' According to the 6_openldap_direct_sucess.JPG file, it is possible to observe that the result became what was expected. However, when performing this procedure and authenticating the user minca@minca.com in the child.klabs.com domain using the ldapsearch tool, the result was an error according to file 7_openldaperror_indirectaccess.JPG stating invalid credentials In addition, searching the internet, we verified that the LDAP call should be LDAP: //child.klabs.com/dc=minca,dc=com, however, ldapsearch returned PARSE LDAP URI (s) error, as per file 8_openldaperror_parse.JPG. However, a .net application was created to perform this same function and it worked, as per file 9_dotNetApp_success.JPG After that, we tried to understand if the openldap tool would be able to perform the same action on the same tree (subtree) and we obtained the expected success result according to the file 10_openldap_subtree_success.JPG So, we tried to list the members of the CHILDADMINS group that are in the child.klabs.com domain and have as a member a user from the minca.com forest, using the command: ldapsearch -H 'LDAP: //child.klabs.com: 3268' -D 'cn = Administrator, cn = users, dc = child, dc = klabs, dc = with' -w Avanade @ 2020! -b 'cn = CHILDADMINS, cn = users, dc = child, dc = klabs, dc = com'

and it was observed that openldap I find the user in question bringing his SID according to the figure 11_openldap_GroupMemberOf_SSID.JPG and, afterwards with a treatment in the openldap tool itself through the command: ldapsearch -H 'LDAP: //child.klabs.com: 3268' -D 'cn = Administrator, cn = users, dc = child, dc = klabs, dc = with' -w Avanade @ 2020! -b "cn = ForeignSecurityPrincipals, dc = child, dc = klabs, dc = com" "CN = S-1-5-21-1644185942-511557352-3723172775-1107" msDS-PrincipalName We managed to get the PrincipalName property of the user the figure 12_openldap_SSID_to_PrincipalName.JPG Finally, the conclusion we are reaching is that the openldap tool does not work directly between forests, but only on the same tree. We would like to know if this understanding is correct or if this is really a bug in the tool. Well, I tried to detail the situation as much as possible, please help us understand this. Thank you very much for your attention.