Hi Brian, All versions which are less than 4.0 reached their end of life. Unfortunately they are not covered in community support. >> Please route this to Davin Cooke @gluu Done.

Ref: 8. Brian got roadblocked in the middle of setting up the test Gluu 4.x server, "I've moved the trust relationships, however they aren't showing in the interface. The biggest issue I'm having now is the original DN's id is: @!13A3.08A9.8106.3629!0001!80A5.E1DE and the lab server can't change it's ID, so the users don't show up outside of a direct ldapsearch. Honestly I'm unsure how to get around this. When I imported users, they imported, but once I wanted to actually use them, I couldn't because the original DN's didn't match. I tried to modify them in the export, and that didn't work either." -----------------> from my email . 3.1 to 4.0 does have architecture changes and OpenLDAP is no longer supported so a migration is the only safe recourse. We don’t have any tickets that ask about 4.X presently we can action. Brian or you can ask any questions about the inability access the user attributes on a 4.X server in community support and I can get these escalated. I’ll assume the users are already copied over to OpenDJ (Wren) with the custom schema attributes and the installation recognized these? As for Drupal.. we aren’t using the “Plugin” are we? Drupal - oxd 3.1.4 Docs (gluu.org) Looks like a Bind issue on the DN: our support can probably help with that.. over my head sorry. Some links with a possible checklist here: Upgrade to 4.x - Gluu Server 4.0 Docs Convert the Schema in OpenLDAP to OpenDJ OpenDJ 3.5 > Administration Guide (forgerock.com) https://backstage.forgerock.com/docs/opendj/3.5/admin-guide/#ldap-client-server-communication

**Commenting simply to enable email notifications on this ticket**

Hello all, Just sharing my suggestions.... >> It appears that there was some customized install during the chroot environment we were unable to overcome Possible to describe a bit on "customized installation" please? >> The upgrade was difficult due to the chroot environment, and specific componentents not being located where scripts expected them to be. I am sorry but can't understand "due to the chroot environment" part. :-) May be little explanation will help. >> "I've moved the trust relationships, however they aren't showing in the interface. The biggest issue I'm having now is the original DN's id is: @!13A3.08A9.8106.3629!0001!80A5.E1DE and the lab server can't change it's ID Actually, we don't need to think much about Trust Relationship's DN's id ( or, `inum`, we call them ). Because, SAML transactions doesn't rely on inum but application and Gluu server communicate with `entityID` value. So, best route would be.. just create those Trust Relationships again in new 4.x Gluu Server. You will just need to collect those SAML SP's metadata from old server `/opt/shibboleth-idp/metadata/` location. >> When I imported users, they imported, but once I wanted to actually use them, I couldn't because the original DN's didn't match. Are you using User's `inum` ( DN id ) for any kind of production operation? If not then we also don't need to bother those inums as well. You can actually _pull_ those users from old server into your new server by using [Cache Refresh](https://www.gluu.org/docs/gluu-server/4.3/user-management/ldap-sync/) feature.

Hi, Please reopen the ticket if required. Thanks!