Import location hierarchy from LDAP Active Directory user

[corzakiewicz]

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• [X] I have searched the existing issues

Version

10.0.4

Bug description

Hi,

Our current GLPI is version 10.0.14 We have only one instance : Production.

LDAP Active Directory synchronization is set up on our GLPI server. This allow to import users and to automatically create location mapping the AD User field "City". The automatic creation of locations using hierarchy methode (using the symbol > to specify the child and parent) was working great on GLPI v9. We migrated to GLPI v10 on December 2023. Today, I discovered new locations in GLPI have automatically been created the day after we migrated to GLPI v10. It seems that GLPI is no more able to "interpretate" correctly the symbol > to create hierarchy in locations, so GLPI created new locations.

I have read an article that seems to be similar to this case but I don't understand what I have to do to solve this issue : https://github.com/glpi-project/glpi/issues/15812 In addition, I understood this "bug" was solved in v10.0.11 but as we are running a more recent version, I am confused.

Could you please tell me if the separator symbol > is still the one to user ? If yes, how could I solve the issue ?

Thank you very much for your help.

Relevant log output

No response

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

No response

Anything else?

No response

[trasher]

Please try with latest stable release.

[corzakiewicz]

Thank you for your quick answer. I'll try soon and I let you know :-)

[corzakiewicz]

Hi, My GLPI has been updated to v10.0.15, unfortunately, the bug still occurs. Do you have an idea on how I could solve this ? Thank you.

[corzakiewicz]

Hi, Do you need additional information from me to investigate ? Thank you.

[trasher]

Could you try if #17187 does solve your issue? It's maybe not the final fix, but at least we can be sure it's the same as the inventory related one.

[cedric-anne]

@corzakiewicz

Could you check if #17187 solves your issue?

[trasher]

Someone else has confirmed the fix works for users and inventory

[corzakiewicz]

cedric-anne commented 35 minutes ago @corzakiewicz

Could you check if https://github.com/glpi-project/glpi/pull/17187 solves your issue?

---

Hi,

I am still looking for how to proceed to apply this patch. Do I have to replace the files Inventory.php and CommonTreeDropdown.php ? Is there a way to find their path ?

Thank you.

[corzakiewicz]

I have just tried after replacing the two mentionned files. The location import does not work anymore, here is an error in sql-errors.log file :

[2024-06-04 13:36:58] glpisqllog.ERROR: DBmysql::doQuery() in /var/www/glpi/src/DBmysql.php line 403 *** MySQL query error: SQL: UPDATE glpi_users SET date_sync = '2024-06-04 13:36:57', locations_id = '-1', date_mod = '2024-06-04 13:36:57' WHERE id = '529' Error: Out of range value for column 'locations_id' at row 1 Backtrace : src/DBmysql.php:1503 DBmysql->doQuery() src/CommonDBTM.php:689 DBmysql->update() src/CommonDBTM.php:1698 CommonDBTM->updateInDB() src/AuthLDAP.php:2970 CommonDBTM->update() src/AuthLDAP.php:398 AuthLDAP::ldapImportUserByServerId() src/MassiveAction.php:1420 AuthLDAP::processMassiveActionsForOneItemtype() src/MassiveAction.php:1398 MassiveAction->processForSeveralItemtypes() front/massiveaction.php:62 MassiveAction->process() public/index.php:82 require() {"user":"422@GLPI-V10"}

[cedric-anne]

I take a quick look at the code. Is it possible that your LDAP is returning a non empty value that contains on spacing chars and/or > for the location field ?

[corzakiewicz]

Indeed, location field in our LDAP contains spacing chars and the character ">" as separator to specify the hierarchy This has been like this from the beginning we setup GLPI 4 years ago and was working well since recently

[cedric-anne]

Indeed, location field in our LDAP contains spacing chars and the character ">" as separator to specify the hierarchy This has been like this from the beginning we setup GLPI 4 years ago and was working well since recently

What is the exact value ? We could add a test for it in our test suite.

[corzakiewicz]

The exact value is : Mycompanyname Agences>Caen

PS : I have switched the company name for privacy reason

[corzakiewicz]

Hi,

I have seen this morning that invetory does not work anymore since I applied the patch on June, 4th. So, I have just moved back to the previous version of files inventory.php and CommonTreeDropdown.php and it works correctly now.

When it did not work, here is the error message I found in php-errors.log :

glpiphplog.CRITICAL: *** Uncaught Exception Error: Class "InventoryTestCase" not found in /var/www/glpi/front/inventory.php at line 48 Backtrace : index.php:93 include_once() public/index.php:82 require()

[trasher]

Sounds like you made something wrong.

[trasher]

The only relevant changes to apply are ones on src/CommonTreeDropdown.php. Or you can test with nightly build.

It's a bad idea to put a patch test on production if you're not 100% sure what you are doing.

[corzakiewicz]

Sounds like you made something wrong.

I totally agree. I asked for some more information about how to proceed to apply these patch but I got not answer :-( So I tried to apply anyway, which is a bad idea as you mentionned. If you agree, please give a quick explaination to me on how to apply the patch, then I will be a little more "skilled" on it :-) Thanks again for your help.

[trasher]

There are tons of docs about aplying patches; this differs regarding of your environment. You can also just consider applying the few lines changes by hand.

[corzakiewicz]

That's clear, thank you very much👍

[CLcdiazp]

Hello everyone, raise a ticket to GLPI https://github.com/glpi-project/glpi/issues/17304 with the following:

In the LDAP server configuration for users, the default settings include the following AD attributes:" Surname: sn Email: email Given Name: givenname Title: title The root rule is:

Global Criterion - LDAP Server is Server Name Actions: Action Entity assign Entity > Subentity This ensures that when the LDAP is synchronized, the username, Surname, Email, and Title are synchronized in the subentity, and this process works correctly.

However, when adding a location attribute configuration:

Surname: sn Email: email Given Name: givenname Title: title Location: l Upon synchronization, the location is loaded into the root of the entity rather than the subentity.

When checking the root rule, I noticed that the location criterion is missing from its criteria.

LDAP Criteria:

(AD)User ID (LDAP)MemberOf (LDAP) Title (LDAP) Common Name (LDAP) Department Number (LDAP)DistinguishedName (LDAP) Email (LDAP) Employee Number (LDAP)Manager (LDAP) Organization (LDAP) Telephone Number (LDAP) User ID Object Class Therefore, if I add the parameter l in the LDAP server's location, it will load it into the root entity, which has caused a problem for me.

I'm not sure if this is a bug.

Let me know if you need any further assistance!

His response was This issue has been closed as we only track bugs here.

So if it is not a bug, where can I request this improvement for the next version of GLPI?

[trasher]

So if it is not a bug, where can I request this improvement for the next version of GLPI?

On suggestion website.

[cedric-anne]

Mycompanyname Agences>Caen

I am not able to reproduce.

• I tested with Mycompanyname Agences>Caen and it created me a Mycompanyname Agences>Caen location.
• I tested with Mycompanyname Agences > Caen and it created me a Caen location as a child of a Mycompanyname Agences location.

For me, the initial bug is fixed, but maybe there is something else to fix.

Could you try to install the GLPI nightly build (https://nightly.glpi-project.org/glpi/10.0-aa4ad2c.tar.gz) on a test server and see if you can reproduce the issue ?

[trasher]

We release 10.0.16 today; I consider initial issue is fixed; therefore I close this one.

Feel free to open another issue with all details to reproduce issue on a fresh 10.0.16 install.

[CLcdiazp]

I just ran the tests and it still has the same problems, the locations are not imported into the subentities and it duplicates the existing locations

The l attribute is not synchronized with the subentities "It would be beneficial to update GLPI to ensure that Active Directory attributes, such as the 'City' field (l), synchronize correctly according to configured rules. Currently, even when the main entity rule specifies that all LDAP synchronization should go to the subentity, the City field synchronizes to the main entity, causing duplication issues with locations. Enhancing the synchronization rule interpretation could resolve this issue and optimize location management within GLPI."

[trasher]

Anyone has mentionned "sub entities" before; this is certainly another issue. Current issue is closed, please open a new one, with all details and how to reproduce problem on a fresh stable install.

[cedric-anne]

The l attribute is not synchronized with the subentities

It seems to be the same issue as described in #9287.