Forum Replies Created
March 13, 2020 at 9:15 am #27739
Generally speaking, importing data (as LDIF) with pre-encoded passwords is supported. The passwords will be understood by the server as long as there is a corresponding password storage scheme implemented in DS.
That being said, we do have support for bcrypt today but not scrypt.
To support scrypt, you would need to implement an scrypt password storage scheme, drop the jar in DS and enable it in your
You would have to write a custom password storage scheme for scrypt. You can use the
example-pwdscheme.zipas a base (embedded in
DS-6.5.0.zip). Here is a more general documentation about server plugins:
February 20, 2020 at 12:32 pm #27669
- This reply was modified 2 years, 6 months ago by JnRouvignac.
It has been removed in 6.0: https://backstage.forgerock.com/docs/ds/6/release-notes/
More details here: https://bugster.forgerock.org/jira/browse/OPENDJ-5365
Jean-NoelDecember 9, 2019 at 12:07 pm #27233
Yes, it’s possible and easy to do. This is a standard setup that we use a lot during development.
July 31, 2019 at 4:50 pm #26149
- This reply was modified 2 years, 10 months ago by JnRouvignac.
22.214.171.124.4.1.14126.96.36.199.5is binary syntax, i.e. not what you want.
Json syntax is only implemented since 4.0 if I remember correctly. The OID is
Are the current data using a valid JSON format?
In that case it is possible to change the schema without problem. Note that you may also have to change the equality matching rule: to
Jean-NoelJuly 1, 2019 at 10:09 am #26021
You should have a look at the replication chapter in the administration guide:
Replication servers are fully meshed ; at any moment, Directory Servers are connected to a single Replication Server, targeted replication server may change over time.
Jean-NoelJune 7, 2019 at 11:26 am #25921
Note that the current forum is for directory services, i.e. the LDAP product :)
It is not for OpenBanking Directory.
Although I highly sympathize with you: 1) the naming is ambiguous and 2) there is no forum for OpenBanking.
I have let the relevant people know about your question in our internal communication tool.
Jean-NoelMay 3, 2019 at 9:31 pm #25737
This looks like an AM configuration question.
Better to ask on the OpenAM forum: https://forum.forgerock.com/forum/fr-projects/openam/
Jean-NoelFebruary 13, 2019 at 11:29 pm #24797
I think you have already setup the
monitor-readprivileges, so all you need to do now is to authenticate using the appropriate authentication mechanism (HTTP Basic Auth by default).February 13, 2019 at 4:34 pm #24790
By the way, I can see that datadog has support for prometheus exposition format of metrics:
If you have the possibility, I would strongly advise you to consider using this instead of JMX. Granted, it does not support string metrics, but that’s the only downside. For all the rest, JMX is a very limited subset of the prometheus exposition format. See https://backstage.forgerock.com/docs/ds/6/reference/#monitoring-metrics-prometheus for what DS exposes in this format. It was one of the big features for the whole ForgeRock stack in the 6.0 release.February 13, 2019 at 4:29 pm #24789
Aw no that’s my fault.
I should not have linked to early access docs when final docs exist.
Here is the same content in existing final docs:
– https://backstage.forgerock.com/docs/ds/6/reference/#monitoring-typesFebruary 13, 2019 at 12:45 pm #24784
According to your output, there are only booleans and Strings appearing.
It means everything else is not showing up including LDAP integers. They are currently mapped to
It looks like the Datadog agent only understands java primitive types + String type.
In the past I have been looking at best practices for the “type” of the
MBeanAttributeInfo, but I could not find anything.
Thanks to your report, I found the list of types supported by the Datadog JMX agent: https://github.com/DataDog/jmxfetch/blob/master/src/main/java/org/datadog/jmxfetch/Instance.java#L32-L53
For the LDAP integers, I think we can simply map to
java.lang.BigInteger. That will solve your problem.
We have a number of other types which needs to be remapped and these may need a bit more work.
I have raised https://bugster.forgerock.org/jira/browse/OPENDJ-6007 to track this work.
Thanks again for your very useful report.
Looking at the datadog documentation for the configuration (https://docs.datadoghq.com/integrations/java/), it is possible to a map a
metric_typeto each attribute with either
counter, and this is exactly what we have internally.
Please refer to https://ea.forgerock.com/docs/ds/monitoring-guide/chap-monitoring.html#monitoring-metrics-ldap to identify the correct metric_type.
Attributes using the
Counter metricsyntax can be mapped to
counter, while attributes using the
Integersyntax can be mapped to
I can also see mentions of
Good news is that we have these too! See https://ea.forgerock.com/docs/ds/monitoring-guide/chap-monitoring.html#monitoring-types.
Bad news is that they are mapped to a JMX type of
org.forgerock.json.JsonValue, thus not collected by the agent. We need to find a better way to expose them to JMX.February 12, 2019 at 9:53 am #24766
You have hit https://bugster.forgerock.org/jira/browse/OPENDJ-5727.
Please liaise with support to see if a patch can be delivered to you.
Jean-NoelNovember 2, 2018 at 9:11 pm #23748
999-user.ldifshould not have the same schema definitions as any other schema files. Probably
Jean-NoelOctober 11, 2018 at 1:00 pm #23426
A quick google search returns a lot of interesting results.
I’d suggest you try it.
See the following:
July 23, 2018 at 10:16 am #22585
- This reply was modified 3 years, 11 months ago by JnRouvignac.
There is nothing specific to ForgeRock DS here: you need to correctly configure the machine’s firewall.