- Q. Is there a limit to the number of users and groups that can be created in DS?
- Q. Can a group be both dynamic and static?
- Q. Can I use static groups for large numbers of users?
- Q. How can I query DS to find the number of user entries?
- Q. Are there any restrictions on the length and characters that can be included in the userid attribute?
- Q. Does DS support attribute encryption?
- Q. Why does DS base64 encode some attributes in LDIF format?
- Q. Can I have Pass Through Authentication (PTA) use a mapped attribute for use with Active Directory®?
- Q. Is Elasticsearch 6 supported for audit logging?
- Q. Why am I seeing a JVM crash log (hs_err_pidxxxx.log)?
- Q. What information do the native-windows.out and server.out log files contain?
- Q. What are the requirements to decommission or retire a DS instance (Pre-DS 7)?
A. The theoretical limits for maximum number of entries are so high that you will almost certainly hit hardware, performance or infrastructure problems before you can reach them. The possible number of users and groups you can support depends on what hardware resources you have available, how well your data is structured and how well crafted the operations your clients make on the database.
We regularly do testing with hundreds of millions of entries.
A. No, a group cannot be both for implementation reasons. See Groups for further information on these group types.
A. It is recommended that you use dynamic groups for large numbers of users as large static groups can cause performance problems. An alternative to using dynamic groups is to invert the logic and have a small static group that only contains the exceptions rather than all users.
See Best practice for managing groups in DS (All versions) and Groups for further information.
A. You can query your LDAP user store to find the number of users. See How do I count the number of users in my ForgeRock deployment? for further information.
Q. Are there any restrictions on the length and characters that can be included in the userid attribute?
Our connection handlers do impose an upper limit on the size of every request received to avoid DoS style attacks. The default is 5MB, so that is indirectly an upper limit on the length of userid.
All unicode characters are permitted for inclusion in the userid attribute.
A. Tools such as ldapsearch and export-ldif that input or output LDIF comply with LDIF escaping rules when attribute values contain non-ASCII characters as well as a few special characters. This means they encode the UTF-8 strings using base64 and add a "::" after the attribute name to indicate this has happened.
This encoding only takes places when reading and writing LDIF. Attributes in DS are still stored in UTF-8.
See RFC 2849 for further information on LDIF escaping.
Q. Can I have Pass Through Authentication (PTA) use a mapped attribute for use with Active Directory?
A. Yes you can map LDAP attributes in DS for PTA using the mapped-search-filter-template property. For example, you can map different attributes, such as uid in DS to sAMAccountName in Active Directory. See Pass-Through Authentication for further information.
Per the Elasticsearch documentation (Removal of mapping types):
Indices created in Elasticsearch 6.0.0 or later may only contain a single mapping type. Indices created in 5.x with multiple mapping types will continue to function as before in Elasticsearch 6.x. Mapping types will be completely removed in Elasticsearch 7.0.0.
A possible workaround is to create the index in Elasticsearch 5 and then upgrade to Elasticsearch 6.
The Elasticsearch audit handler is deprecated in DS 7.1.
This message and the presence of this log file indicate that the crash happened inside the JVM's native code and as such, is nothing to do with DS.
One of the guarantees made by the Java® platform is that a pure Java program cannot crash the JVM. The only ways the JVM can crash are:
- You have loaded some native third-party code, which is being called and is crashing.
- The JVM is failing internal checks (possibly because of a bug in the JVM itself) and is crashing.
- The JVM is calling out to the Operating System (using the libjava.so or libjava.dll native code) and that's crashing.
Therefore, if you see a hs_err file, it means the JVM has crashed and you must contact your JVM vendor for further support. ForgeRock support cannot assist you with this issue.
- The native-windows.out file is generated by the executable that allows DS to run as a Microsoft® Windows® service.
- The server.out file is essentially the STDERR (Standard Errors) for the DS server.
DS currently overwrites these files when they reach 0.5 MB, although they are not expected to grow much. This behavior is discussed in OPENDJ-2706 (OpenDJ overwrites native-windows.out after the file size is reached to 0.5 MB).
A. If you need to retire the system on which the DS instance is running and this DS instance is part of a replication topology, you must first permanently disable replication on this instance only, before decommissioning the system.
See Administration Guide › To Stop Replication Permanently For a Replica for further information on stopping replication.
Failing to permanently disable replication before retiring the system will result in replication connection failures when using the dsreplication status command.
Example dsreplication status command:$ ./dsreplication status --adminUID admin --adminPassword password --hostname ds1.example.com --port 4444 --trustAll
Resulting error if replication was not disabled before retiring the system:The displayed information might not be complete because the following errors were encountered reading the configuration of the existing servers: Error on ds1.example.com:5444: An error occurred connecting to the server. Details: javax.naming.CommunicationException: ds1.example.com:5444 [Root exception is java.net.ConnectException: Connection refused]
If you have already retired the system and are seeing error messages such as the above, please contact ForgeRock Support.