Preventing OES System Groups and Users from being imported in Filr.

  • 7015822
  • 23-Oct-2014
  • 30-Jun-2017


Novell Filr 1 Administration
Novell Filr 2 Administration
Novell Filr 3 Administration
Novell Open Enterprise Server (NetWare 6.5)
Novell Open Enterprise Server 2 (OES 2) Linux
Novell Open Enterprise Server 11 (OES 11) Linux
Novell Open Enterprise Server 2015 (OES 2015) Linux


SUSE Linux Enterprise Server (SLES), creates system users and system groups, for instance, the system groups: at, daemon, games, gdm, ssh, suse-ncc, tomcat. news, www, etcetera, and system users such as: wwwrun, suse-ncc, news, nobody, tomcat, etcetera. On an Open Enterprise Server, several of these become LUM enabled.
Novell Open Enterprise Server (OES), additionally creates a number of proxy users and groups in eDirectory for various services. for instance, LDAP related users and groups, the OESCommonProxy user, the NSS admin user, etc.

There is no need for these to be imported into Novell Filr as they serve no other purpose other than the OES server and services, functionality.

Since the release of Novell Filr 1.1 it is supported to have several groups with the same Common Name (CN).
However, for users it is still only supported to have 1 entry with a unique CN in Filr. If a group with that name already exists, the user is not imported, listing an error in the appserver.log indicating that there is already an entry with that name_principal.

When using iManager Role Based Services, there are also groups named admin, these will not be imported due to the fact that the Filr admin account already has that name_principal taken. In rare cases, if there are several Groups named "admin" it could lead to the LDAP sync to never finish.


To prevent the System related Groups from be imported:
In the LDAP Server Configuration for the OES environment, in the Filter: section of the Base DN for the Groups place the following filter string, all in 1 line:


To prevent the System related Users from be imported:
In the LDAP Server Configuration for the OES environment, in the Filter: section of the Base DN for the Users place the following filter string, all in 1 line:


In case there is a Tomcat-Roles Organizational Unit (OU) created in the tree to facilitate iManager's Role Based Services (RBS), it is also recommended to exclude this OU.
If the eDirectory or Filr setup does not allow the creation of separate BaseDN excluding the RBS OU, there is an option to exclude this OU via the ldap filter
In that case the filter would look like:
For the Groups:

For the Users:


When installing and configuring a Novell Open Enterprise Server (OES), several system and service related groups and (proxy) users are created in the eDirectory, if not trough being LUM-enabled.

Additional Information

To prevent the users and groups, who only provide server functionality, from polluting the Novell Filr user and group list, they should be filtered out.
When this is done properly before the initial LDAP sync, these will never be imported.

In case there are additional administrative or system (LUM-enabled) users that are required to be prevented from being imported into Filr, these can be added to the filter string.
For instance, when Novell Open Enterprise server is not using a OESCommonProxy user, but rather a Proxy User per service. (AFP, CIFS, NetStorage, FTP, NCS ....)

These are prevented from being imported by adding for instance these entries in the string:

This would make the complete string look like:

Modify the string so it is applicable to the back-end environment.

Using the  Preview sync, which is available from Novell Filr 1.1 on should indicate if only the desired users are disabled or prevented from being imported.

In certain cases, users are moved or renamed with an alias for backwards compatibility.
Filr will process the aliases as if they were the user, so it will not update the user objects stored in the Filr databases. This will only occur if the LDAP filter for the users is updated to exclude the objectClass aliasObject.
This is achieved by adding !(objectClass=aliasObject).

The compete user filter will then look something like: