Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Next revision Both sides next revision
devel:documentation:wizards [2021/02/26 09:32]
svandav [Database table wizard] 		devel:documentation:wizards [2021/02/26 13:10]
svandav [Attributes]
Line 15: Line 15:
 Currently, the following specialized wizards are available in IdM: Currently, the following specialized wizards are available in IdM:
  
-==== CSV wizard ====+===== CSV wizard =====
  
 In the case of a **CSV wizard**, the user does not have to fill in the location of the CSV file on the server, but can simply use the **drag and drop zone** to upload the file. In the case of a **CSV wizard**, the user does not have to fill in the location of the CSV file on the server, but can simply use the **drag and drop zone** to upload the file.
Line 23: Line 23:
 {{ :devel:documentation:csv.png?600 |}} {{ :devel:documentation:csv.png?600 |}}
  
-==== Database table wizard ====+===== Database table wizard =====
  
 Another specialized wizard is used to connect **database tables**. Previously, the user had to configure the attributes that are charged to the database. For example, the name of the database driver, the mask for the composition of the resulting URL, etc. Now the user is exempt from this and **the wizard does this for him**. Another specialized wizard is used to connect **database tables**. Previously, the user had to configure the attributes that are charged to the database. For example, the name of the database driver, the mask for the composition of the resulting URL, etc. Now the user is exempt from this and **the wizard does this for him**.
Line 31: Line 31:
 {{ :devel:documentation:postgresql2.png?600 |}} {{ :devel:documentation:postgresql2.png?600 |}}
  
-==== Microsoft Active Directory (MS AD) wizard ====+===== Microsoft Active Directory (MS AD) wizard =====
 {{tag>MSAD MS wizard}} {{tag>MSAD MS wizard}}
  
Line 43: Line 43:
  
  
-===== Connection to an AD system =====+==== Connection to an AD system ==== 
 +In the first step, choose the **name of the system** as you want it to **appear in IdM**. Next, fill access data to the connected AD. Ie. **host** name, TCP **port**, **user name** and **password**. 
 + 
 +<note important>In this step, you can choose whether you want to communicate with AD using a secure **LDAPS** connection (SSL). This option is preselected. **We strongly recommend using secure communication**. The reason is not only the **security aspect**, but also the **functional consequences** that can result from the use of an unsecured connection. For example: If you use an insecure connection, you will not be able to **create a new account with a password** (restrictions on the AD side).</note>
  
 {{ :devel:documentation:wizard_ad_01.png?600 |}} {{ :devel:documentation:wizard_ad_01.png?600 |}}
  
 +==== Certificate ====
 +
 +In the second step, the wizard can **download the certificate from the AD** and save it to the server. First, the wizard verifies that your IdM server has the correct certificate installed for communication with AD. Next, the certificate is searched directly in AD. The goal is to **find a certificate issued by the highest possible authority**. The found certificate needs to be inserted into the **trusted certificate store** and the IdM restarted. The reason why we do not recommend using a server certificate directly in the trusted certificate store (it would be functionally sufficient) is its shorter validity (typically only 1 year).
 +
 +{{ :devel:documentation:wizard_ad_02.png?600 |}}
 +
 +==== Check of permissions ====
 +
 +In the next step, you have the option to **perform a set of tests for a successful IdM connection**. The most basic test is to **create and delete a user**. This will verify that you have correctly defined the rights for the service account that **IdM accesses to AD** and set the authentication information correctly in the previous steps.
 +
 +Not all tests need to be performed to complete the connection. For example, grouping a user is an optional operation for some deployments
 +
 +{{ :devel:documentation:wizard_ad_03.png?600 |}}
 +
 +==== Additional data ====
 +The next step specifies in which **OUs** users are managed and where **protected** are placed. In the simplest cases, all **OUs** will be the same. The most interesting is the option to create a **synchronization**. This will indicate that you want to **preconfigure pairing synchronization**, which you will use later so that the accounts on the newly connected AD system **link correctly to the identities in CzechIdM**.
 +
 +If you want, you can also **activate protected mode** in this step. This is to **prevent deleting the account in AD**. //For example//: If an identity in IdM ceases to be valid (contract expires), its account in AD will not be deleted, but will be moved to the **OU for deleted accounts**.
 +
 +
 +{{ :devel:documentation:wizard_ad_04.png?600 |}}
 +
 +==== Attributes ====
 +In the penultimate step, the wizard prompts you to specify which attributes of the user account in **AD** you want to manage and from which identity attribute in IdM you want to fulfill them.
 +
 +The wizard automatically offers **the most frequently used attributes and their typical fulfillment from CzechIdM**. If there are some attributes that you do not use in your AD or do not want to fulfill, disable them or remove them from the list altogether.
 +
 +**The wizard automatically sets even the most common transformation rules for fulfillment.** For example, to fill ** DN (_ NAME _) ** or ** displayName **, where it selects the first and last name combination. If you want to perform some attributes with a different transformation than the one listed here, you can now deactivate the attribute and later modify the transformation to your liking.
 +
 +
 +{{ :devel:documentation:wizard_ad_05.png?600 |}}
 +
 +==== Conclusion ====
 +
 +
 +
 +{{ :devel:documentation:wizard_ad_06.png?600 |}}
  • by svandav