Aplication access control

Unfortunately, EMC documentation contains a lot of white spots and application access control is one of the many.
Currently, Content Server has two options that allow restrict access to repository/server from non-authorized clients:

  1. privileged clients (Docbase properties -> Allow only Privileged DFC clients to access the repository)
  2. AAC tokens (Server properties -> Connection requests by a non-superuser must be accompanied by a valid application access control token)

Privileged Clients

Upon first startup DFC generates keystore file (if none already exists), that contains private key and self-signed certificate:

The location of this file could set through dfc.properties using dfc.security.keystore.file parameter (default value – ${dfc.config.dir}/dfc.keystore). When DFC connects to global registry repository it tries to publish its certificate using the following way:

  1. DFC creates dm_public_key_certificate object and sets value of certificate_value attribute to PEM representation of stored certificate
  2. Content Server generates unique identifier (key_identifier) for created dm_public_key_certificate object
  3. After that DFC creates dm_client_registration object with following parameters:
    • client_id = Common Name of certificate subject
    • host_name = machine hostname where DFC resides
    • public_key_identifier = unique identifier, generated at previous step

So, what is privileged client?

Privileged client is a DFC client which has corresponding record in dm_client_rights:

dm_client_rights object could be created through Documentum Administrator: Administration -> Client Rights Management -> Privileged Clients -> Manage Clients -> Add or through DQL/API:

CREATE dm_client_rights OBJECT
SET client_id='<client_id>',
SET object_name =
  (SELECT object_name FROM dm_client_registration 
     WHERE client_id='<client_id>'),
SET public_key_identifier =
  (SELECT public_key_identifier FROM dm_client_registration 
     WHERE client_id='<client_id>'),
SET host_name = 
  (SELECT host_name FROM dm_client_registration 
     WHERE client_id='<client_id>')

Note, that existence of dm_client_rights record is a necessary and sufficient condition to mark DFC client as privileged – Documentum Administrator has confusing action “Approve Privilege” which, actually, grants some extra capabilities:

Finally, if we want to restrict access to our repository from non-privileged DFC clients, we can achieve this requirement using Documentum Administrator:

Please note, some Content Server versions check whether client hostname matches value of host_name attribute in dm_client_rights object (I bet EMC made a decision to remove this check in recent releases rather than write proper documentation), so, in some cases, if you are going to change client’s hostname you should either change value of host_name attribute in dm_client_rights object (not sure whether it’s required to modify dm_client_registration objects too or not) or create another client’s keystore. Also all CS versions check time drift between Content Server and client, by default time drift must not exceed 1800 seconds, this value could be overridden by setting CLIENT_AUTH_SIG_THRESHOLD environment variable on Content Server machine.

Application access control tokens

If we forget about the fact, that all current Documentum releases has vulnerability that allows any user to create dm_client_rights objects, Privileged Clients feature is good enough if we want to restrict access to our repository from non-privileged DFC clients, but what if we want to restrict access to some services (webtop, dfs, rest, etc) for some users? In that case we can use AAC tokens, unfortunately documentation “as always at height” (it’s worth to say that Content Server 5.3 Administrator’s Guide does contain paragraph about dmtkgen utility):

All that we can get from current documentation is:

  • AAC token is represented by xml file inside ${dfc.tokenstorage.dir} directory
  • to enable support of AAC tokens in DFC we should set value of dfc.tokenstorage.enable parameter to true

How to use dmtkgen utility? At first glance it has built-in help:

[dmadmin@docu70dev01 ~]$ dmtkgen
** Option -base <docbase> must be specified
Usage: dmtkgen -username <username> -password <password>
          [-domain <domain>]
          -base <docbase>
          [-a <user/group>]
          [-scope <scope>]
          [-timeout <timeout>]
          [-identifier <application id>]
          [-machine <machine only>]
          [-output <output file>]
  -verbose      - Verbose mode
  -help      - Print this help/usage information


<username>      - username for a superuser.
<password>      - password for the superuser.
<domain>        - NT domain for authentication.
<docbase>       - docbase name where token will be created.
<user/group>    - user or group name constraint.
<scope>         - token scope (docbase or global).
                  The default <scope> is global.
<timeout>       - token timeout value in minutes.
<application id>- application id string.
<machine only>  - token device constraint. (T or F).
                  The default <machine_only> is F.
<output file>   - output file for token data.
                  The default <output file> is <docbase>.tkn

So, some options (username, password, domain, docbase, output file) are self-explanatory, some not. Not obvious options are:

  • scope – specifies whether token is generated for specific docbase only or for multiple docbases in distributed environment, it last case it is possible to create single token file named default.tkn for multiple docbases
  • user/group – specifies whether we want to bind token to specific user or group, because all latest dfc releases have dependency on dm_bof_registry it’s not clear how use this option: if we want to bind token to specific user we should have dedicated global registry repository otherwise dm_bof_registry user won’t be able to connect, if we want to bind token to specific group then group specification should look like DM_GROUP=<group_name>
  • application id – value of string parameter in IDfLoginInfo#setApplicationId(String identifier) method, because it’s not possible to set this parameter through dfc.properties, this parameter is useless
  • machine – value of dfc.machine.id parameter in dfc.properties

Now if we want to prevent some users from consuming some services we should:

  1. generate AAC tokens for all DFC applications except the special one
  2. create group for special application, and add users allowed to use that application to this group (don’t forget about system accounts like dm_bof_registry, dmc_wdk_presets_owner, dmc_wdk_preferences_owner, etc)
  3. generate AAC token for application using group constraint
  4. enable support of AAC tokens in DFC (i.e. copy AAC token file to ${dfc.tokenstorage.dir} directory and set value of dfc.tokenstorage.enable parameter to true)
  5. enable restriction in server config:

4 thoughts on “Aplication access control

  1. Pingback: RPC Commands (draft) | Documentum in a (nuts)HELL
  2. Pingback: Aplication access control | Documentum in a (nuts)HELL | Resilient Management Solutions
  3. Pingback: Dynamic groups. Basics | Documentum in a (nuts)HELL
  4. Pingback: CVE-2014-2507 consequences. Part II | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s