> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/administrador-de-onesait-ecosystems-editran-ff/alta-de-perfiles/alta-de-usuarios-de-editran-ff.md).

# Creation of Editran/FF Users

To add a new Editran/FF user, select in the tree the branch *“Users”* and then access the menu “*Operations -> New*” (also from the right mouse button context menu) or press the first button on the toolbar ![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/Oi4pmShYRfR8a3bMyZPh/image1.png) .

In the User dialog that appears, a value will be defined for each of the parameters that make up the configuration profile. They are described below.

![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/Iq4mGGUXZImS0uaUtYob/image2.png)

* **Alias:** user identifier to be created. It is the name the signer will use to access *UserFF.exe.*
* **Type:** this field can have only two values:
  * **Local**: a user of this type will be able to access *UserFF.exe* to view and sign the files of the signing applications to which it is associated and/or to enable their sending. It will also be able to validate and view the content of signatures received in the applications to verify with which it is related.
  * **Remote**: users of this type are those associated with the certificates with which the files of an application whose purpose is to verify signatures will arrive signed. Users of this type cannot access *UserFF.exe.*
* **E-Mail:** user's email address. Notifications from both Editran/FF and communications from other users made from *UserFF.exe*. This is essential data for the user to receive notification of new files available to sign.
* **Certificates:** list that includes three of the fields corresponding to the certificates with which the user will sign (Local user) or of the user whose signatures are to be verified (Remote user): DN or subject of the certificate, issuer DN and serial number. Up to three different certificates can be added for each user. The user will be able to sign or have signed indiscriminately with any of the certificates associated with them.
  * When adding users of type *Local* (they will sign), if the personal certificates are installed on the administration machine, the “*Inst*” button in this dialog will be pressed to access a table that will show all of them and allow selecting those with which the user will sign. This option will be the one applied, for example, to configure the certificate of the Local Automatic user type or that of Local users who are Editran/FF Administrators.
  * If the certificates are not installed on the machine where the profiles are being created, which is the usual case for Local users who are not Automatic or Administrator and for Remote users, the addition can be done in two ways:
    1. If on the users' personal computers where the certificates are installed and from which the signatures will be made the Editran/FF product is already installed, the tool **EnviarDN.exe** included in the product can be used. With this tool the certificate information can be collected in order either to send it by email or to generate a file. The information collected this way will be sent to the administration machine on which the profiles are being created. Next, the “*Paste*” button in this dialog will be used to paste the information copied from the email, or the “*File* button to locate and read on the machine the file generated on the users' machines. **This option is valid for adding Local users. It is also valid for all Remote ones, as long as their company also has Editran/FF in a Windows environment**. The Editran/FF SendDN.exe utility is described in detail in section **7.2.**
    2. On users' personal computers where the certificates are installed and from which the signatures will be made, from an internet browser or by running Windows certmgr.msc, **each certificate to be used will be exported to the .*****cer*** format (export without the private key, it is the appropriate format when the certificate is going to be outside the owner's reach). Once the .cer files have been obtained,*cer*, they will be sent to the server and from this dialog the “*File* button will be used to locate them and read the necessary data. **This option is the only valid one for Remote users who do not have Editran/FF Windows in their companies.**

Pressing “*Save”* the data will be incorporated into the list.

**Whichever option is used, it is essential that the DN, the issuer and the serial number incorporated into the list are exactly the same as those of the certificate (uppercase, lowercase, spaces, value and attribute separators)**. The certificates may be personal or company certificates and may have been issued by any recognized CA.

**The certificates whose data are collected in the profile of each Local user must be correctly installed on the computers on which they will be used to sign and must have a private key.**

* **Administrator:** grants the user permission to access the product configuration. When a user with this property checked accesses *AdminFF*, a window like the following will appear in which they must enter their alias and then the password for their certificate. **If none of the local users in the profiles has this attribute checked, any of them will be able to access profile query and modification.**

![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/g5UmesVYMpSCbPUHO0ab/image3.png)

* **Automatic Signer:** users of this type will always be Local, must have associated a certificate that is installed on the server machine and that does not have secure private key protection enabled nor ask for a password for its use (which is why users with this characteristic should not be Product Administrators). This user will be able and must always sign (any amount), will not be part of groups or joint rules. The function of this type of users is to sign first and immediately each new file detected in the data directory of the applications to which it is associated. Whenever an application has associated a user of this type, no other user associated with the application will be able to sign before this one. To enable this functionality, the parameter “*First automatic signature*” of the dialog shown in the menu *“Administrator -> Automatic updates configuration*”, the Editran/FF Service must be running on the server workstation and, if XAdES mode signatures are to be performed, also the service *Editran Signature Services.* Once this signature has been made, any modification to the data file would be detected by the product, showing this signature as incorrect, so the use of this functionality constitutes a security mechanism over the information to be signed. Usually there will be a single user with this property per installation.

Once the “*Save*” button is pressed, this user will be stored with the parameters defined in the file *“user.cfg*” and will be added as a sub-branch of the tree “*Locals*” or “*Remotes*”, according to the specified type, as well as in the view on the right (list).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/administrador-de-onesait-ecosystems-editran-ff/alta-de-perfiles/alta-de-usuarios-de-editran-ff.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.