ApacheDS replacement for WindchillDS

[rpike]

Version: Windchill 13.0

Use Case: WindchillDS to ApacheDS migration

Description:

Is there any documentation on how to migrate from WindchillDS to ApacheDS? Environment is Windows/Oracle/Windchill 13.0.2. Thanks.

[Catalina]

Hi @rpike 

Thank you for your question! 

I’d like to recommend to bring more details and context to your initial inquiry. For example:

• What specific steps have you taken so far to migrate from WindchillDS to ApacheDS?
• Can you provide more details about your environment setup (Windows/Oracle/Windchill 13.0.2)?
• What specific challenges or issues have you encountered during the migration process?

Please add screenshot(s) to better understand what you are trying to do in your process. 

Please refer to this guideline to make your questions more likely to receive a quick and useful answer. 

This will increase your chances to receive meaningful help from other Community members. 

Here's what a good question for Windchill looks like. 

Thank you for your participation and please let me know if you need further assistance! 

Best regards,

[rpike]

Thanks Catalina. I was hoping there might be some step-by-step article that describes the process (just as there is for OpenDJ) but since that doesn't appear to be the case then I'll provide more detail here. The Windchill system in question consists of 2 servers (Windchill server and database). WindchillDS is installed on the Windchill server. Windchill system is at 13.0.2 running PDM/ProjectLink. All servers running Windows Server 2019. Database is Oracle 19. I'm looking at replacing WDS with ApacheDS. I have installed Apache Directory Studio on the Windchill server and exported the current LDIF from WDS. I am assuming I need to import that LDIF into ApacheDS but I'm pretty sure I need to modify the LDIF before that (or maybe after import). Currently ApacheDS looks like this:

Not sure what to do next.

Thanks.

[avillanueva]

The most important thing is that the users go into the same branch path as they are currently in WindchillDS (which is really OpenDJ repackaged). The database has that path stored so if they are not aligned, you will get disconnected users. The commands for import and export might be different but process should be the same.

[mmeadows-3]

To add some color to the conversation as it looks like ApacheDS is being used as a standalone LDAP for supporting Windchill...

I dug into ApacheDS a while ago.  My Cyber Security contacts said it doesn't release updates/security patches frequently enough to pass their requirements.  Google explained it was frequently used for development environments and occasionally in pre-packaged software deployments, but it can have stability and scalability issues.  I know it doesn't directly support OAuth2, SSO, or OIDC.  I'm not sure if that causes issues with Windchill fully supporting IAM, SSO, OAuth2, OpenID Connect (OIDC), or SAML.

PTC's official statement is we can use any v3 compliant LDAP.  But, PTC officially tested OpenDJ and the Windchill PSI installer's default values align to WindchillDS (OpenDJ as @avillanueva mentioned) or Active Directory.  Also, the article @Fadel referenced is OpenDJ centric.  Thus, the implied guidance is that we should use OpenDJ for standalone LDAP installations and whatever the company uses for corporate LDAP integrations.

I would caution against going with a product that isn't well documented by PTC or this community.  There can be a lot of time invested in learning how to migrate user accounts from WindchillDS to ApacheDS and that effort will likely be duplicated if you decide to migrate from ApacheDS to something else (e.g. Active Directory) later.  It will also take some trial and error to correctly map the ApacheDS LDAP attributes to the Windchill JNDI Adapter(s).

We can provide high-level instructions if you still want to go down the path of ApacheDS,

[rpike]

Thanks. Unfortunately OpenDJ is not an option as it's not approved for use within our company so I'm having to look for alternatives. ApacheDS is just one of the options I'm investigating. It may be that we have to procure something if I can't find something suitable for free.

[avillanueva]

Curious why it was not approved? I am sure you have similar cyber security requirements as other companies. If WindchillDS was allowed, OpenDJ should be no different. Was there a reason they said no or was it just an unknown?

[rpike]

It is down to licensing. If there was a commercial license then that might be different...but I don't think there is?

[mmeadows-3]

Here are the general steps for any LDAP: OpenDJ, OpenLDAP, ApacheDS, etc.

Assuming:

• The current Windchill installation is configured to use WindchillDS
  ApacheDS or other target LDAP is already installed, configured, and the WindchillDS user accounts have been migrated to it.

There are two paths to replacing WindchillDS:

1. Move all users in one planned outage.
   Directly modify the Ldap (default) JNDI Adapter to point to the new LDAP and migrate all accounts at once.
   
   
2. Move users individually or in groups over time.
   Define separate JNDI Adapters (CS29454) for source and target LDAP and migrate accounts over time.
   The same username cannot be visible to Windchill from both JNDI Adapters at the same time.  Options:

1. Use different username mapping attributes (e.g. sAMAccountName vs userPrincipalName, or uid in WindchillDS vs ??? in ApacheDS).
2. Use different filter groups to hide the user from WindchillDS when showing it in ApacheDS.
3. Delete the user from WindchillDS as it is added to Apache DS.

Once the JNDI Adapters are configured, go through the participant healing process.

1. Repair your default site administrator first at the database level (CS94037 and CS109367) so you can start Windchill.
2. Start Windchill and repair at least one user from each JNDI Adapter through the UI to ensure the Repository table is fully populated before going the database route.
3. For a few dozen users, just repair the disconnected participants one at a time through the UI.
4. If there are hundreds/thousands of accounts, then do it all at the database level.
5. When finished, remove the old JNDI Adapter (if following option B) and restart Windchill.

Validation

• Search disconnected participants to confirm repairs.
  Run WinDU to ensure there are no LDAP/participants issues.

[rpike]

Thanks for all the information and advice. Much appreciated. I assume there is no commercial offering for OpenDJ?

[avillanueva]

I think there is. https://backstage.forgerock.com/ They were acquired by PingIdentity in 2023.

https://en.wikipedia.org/wiki/OpenDJ

"Since November 2016, ForgeRock closed OpenDJ source code, renamed OpenDJ to Forgerock Directory Services and started to distribute it under commercial license"

[mmeadows-3]

@avillanueva  beat me to it.  I guess that rule excludes ApacheDS too since it doesn't have a commercial version.

PingIdentity sells "Forgerock Directory Services" and "PingDS".  Both are forks of OpenDS and should be structured similarly.  Forgerock Directory Services would be easiest for Windchill if their sales team are allowed to sell it to "new" customers.

Just some more options....

• OpenLDAP has a commercial version is provided by Symas: https://www.symas.com/symas-openldap.
• 389 Directory Server is an option if you are in a RHEL Linux environment.
• Then there is always Active Directory...

[rpike]

The issue is not the fact that OpenDJ is open source but it's all down to whatever is found within the licensing detail. I don't claim to understand the process but I can see that no version of OpenDJ has ever gained approval. OpenLDAP (open source version) seems to have been approved in the past but I think that needs to be built for Windows which sounds like it might be more complicated. Always wondered about AD. We use that for authentication but since it's read-only I'm assuming we can't use it directly. Thanks for all your help on this.

[rpike]

Thanks I'll take a look at that. Looks like it ended up as PingDS (I can see references to OpenDJ in the release notes) https://docs.pingidentity.com/pingds/release-notes/preface.html

[Fadel]

Take a look at this hub article https://www.ptc.com/en/support/article/CS337554