I'm guessing you are right. The "Registered Users" is every user entry in the database. These are created when someone performs a wildcard participant search in Windchill and the search base is set to the root of the DN structure, or when there isn't a defined search filter in the JNDI Adapter. These responses are specific to Active Directory. Attributes like memberOf will change if using OpenDJ or another LDAP.
Always do cleanup in a non-production environment first.
I would clean up the 354 Disconnected Users first. Clear and delete their workspaces, undo check outs, reassign open tasks, and finally delete the disconnected participants. Once cleanup is complete, define the following JNDI Adapter mappings, purge participant cache, and restart Windchill. If I am right, you should get well over 10k disconnected participants. It is safe to delete them if they have never touched the system. Otherwise, go through the cleanup process on them too. User reporting to find disconnected participants who own workspaces, checked out objects, and open task.
The correct answer for your environment depends on how your LDAP is structured and where all potential Windchill users reside in the LDAP. There are four properties that can help reduce the number of wtUser entries in the database.
1. {adapter name}.searchBase=dc=company,dc=com
Starting point for finding user accounts for this JNDI Adapter.
There can be more than one JNDI Adapter, especially for organization/site mapping and when Windchill users belong to a few unique search bases.
Search Bases must be unique across all JNDI Adapters and cannot be nested.
2. {adapter name}.searchScope=SUBTREE
Determines if the search for user accounts is recursive (SUBTREE) or flat (ONELEVEL).
3. {adapter name}.windchill.mapping.user.objectClass=user
Excludes conference rooms, groups, and other non-user entries.
4. {adapter name}.windchill.mapping.user.filter=(memberOf={DN of 'filter' group})
This group includes all Windchill users.
Users who are members of this group must have the memberOf attribute pointing to the DN of this group.
Windchill searches for users with the memberOf attribute with a value matching the DN of this group.
The LDAP Administrators (IT) must add Windchill users to this security group before Windchill can see them.
Note: each JNDI Adapter also maps users to organizations. If you have more than one organization, use these properties to map JNDI Adapter members to a specific Windchill organization. The user filter above does not apply to organization mapping. Any user under the search base will be mapped according to these LDAP mapping attributes.
{adapter name}.windchill.mapping.user.o=organization
This maps the organization name to the organization attribute value in the corporate LDAP.
The attribute value can be different for every user.
A blank value in the LDAP attribute will map the user to the Site.
{adapter name}.windchill.mapping.usersOrganizationName={organization name}
This sets the organization name for all members of the JNDI Adapter to a single value.
A blank value will map all users found under the JNDI Adapter to the Site.
Excluding these organization mapping attributes will default JNDI Adapter participants to the Site context.
Note: Some companies also use the user filter on Apache to prevent logins. Others just don't assign licensing and the users can't get in anyway.
To summarize, the cleanest solution is to use a 'filter' security group and have IT add only the Windchill users to that group.
That approach may not be practical with thousands of active users and a constantly changing list of Windchill users.
So consider all these mapping attributes to find the correct integration for your environment.