Project

General

Profile

Actions
Copy link

Task #2294

closed

Add support for escaped characters in LDAP/AD

Added by Tomáš Doischer over 4 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Peter Štrunc
Target version:
1.3.5.1
Start date:
06/04/2020
Due date:
% Done:

100%

Estimated time:
Owner:

Description

There are some characters in LDAP/AD which need to be escaped in DN (https://ldapwiki.com/wiki/DN%20Escape%20Values), incl. the forward slash "/". Ideally, they should not be used in naming attributes but they often are and we should be able to handle that.

The goal of this ticket is to add support for using those special characters in DN in the connector itself.

Actions
Copy link
 #1

Updated by Petr Fišer over 4 years ago

  • Project changed from winrm-ad-connector to ad-connector
Actions
Copy link
 #2

Updated by Roman Kučera over 4 years ago

  • Status changed from New to In Progress
  • Target version set to 1.3.5
Actions
Copy link
 #3

Updated by Roman Kučera over 4 years ago

  • % Done changed from 0 to 10

I did some testing on local environment and found the place where this problem is caused.
This is bug directly in connector and there is no way how we can make some workaround in IdM.
This issue is now in update method when you updating some attributes, connector load DN from system and use this value for update operation, we need to escape this value to make it work.
Class ADUpdate::update line 172 I did some PoC and it works. So now I need to check other places in connector if this issue is somewhere else and implement some universal escape method which will perform escape for all chars which are specified in the link from Tomas.

Actions
Copy link
 #4

Updated by Alena Peterová over 4 years ago

The same thing happened in our project where OU contains the forward slash. The exception from the provisioning is:

javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031007E5, problem 5012 (DIR_ERROR), data 0

Actions
Copy link
 #5

Updated by Roman Kučera about 4 years ago

  • Target version changed from 1.3.5 to 1.3.5.1
Actions
Copy link
 #6

Updated by Roman Kučera over 3 years ago

Fixed encoding in update as mention in previous commend.
But changing DN is still not working because not all characters are encoded.
Next step is to implement encoding in ADUpdate::getNewName line 139

Maybe easier will be to do this encoding already in LDAP connector, but forking, releasing, administration around it would be bigger then direct solution in AD connector.

For create add encoding to ADCreate::executeImpl line 94 and it should work

So I will implement some universal method for encoding which will be used in mentioned places

Actions
Copy link
 #8

Updated by Marcel Poul over 1 year ago

  • Assignee changed from Roman Kučera to Peter Štrunc
Actions
Copy link
 #9

Updated by Peter Štrunc over 1 year ago

  • % Done changed from 10 to 50

I created a PoC implementation that escapes group membership values by encoding them to base64. This is inspired by the behavior that Apache Directory Studio does when there is a character that needs escaping.

It needs some testing, which I will do tomorrow when I have the appropriate testing environment.

This approach should be the least error-prone but needs thorough testing before release. Just to be safe, I added a configuration property that enables and disables the base 64 encodings.

Once this is tested on group memberships, I will expand this behavior for other needed attributes.

Actions
Copy link
 #10

Updated by Ondřej Kopr over 1 year ago

We made the check on project with new connector version - it was success!

Actions
Copy link
 #11

Updated by Peter Štrunc over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100
Actions
Copy link
 #12

Updated by Peter Štrunc over 1 year ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF