Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
devel:documentation:wizards [2021/02/26 13:05] svandav [Additional data] |
devel:documentation:wizards [2021/06/25 07:42] svandav |
||
---|---|---|---|
Line 32: | Line 32: | ||
===== Microsoft Active Directory (MS AD) wizard ===== | ===== Microsoft Active Directory (MS AD) wizard ===== | ||
- | {{tag> | ||
- | The most ambitious is the wizard for connecting the **Microsoft Active Directory** system (AD). Connecting **AD** within **IdM** is very important and at the same time manual connection can be a relatively complex matter for many and more advanced users. | ||
- | |||
- | The complication starts in communication with AD. Here it is very important to use **secure communication** (SSL), which requires the installation of a **correct** **certificate**. It is also important to verify that our service AD account has sufficient privileges. | ||
- | |||
- | However, the biggest difficulties can occur with many rules that must be followed during the connection (**connector settings**) and especially in the way to correctly map the individual attributes of AD. Just choosing the right attributes to be mapped to AD may not be easy for an ignorant user. | ||
- | |||
- | **This guide therefore solves all the mentioned problems** and is based on **our best experience** of how to effectively manage 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> | ||
- | |||
- | {{ : | ||
- | |||
- | ==== 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). | ||
- | |||
- | {{ : | ||
- | |||
- | ==== 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 | ||
- | |||
- | {{ : | ||
- | |||
- | ==== 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**, | ||
- | |||
- | 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**. | ||
- | |||
- | |||
- | {{ : | ||
- | |||
- | ==== Attributes ==== | ||
- | |||
- | |||
- | |||
- | {{ : | ||
- | |||
- | ==== Conclusion ==== | ||
- | |||
- | |||
- | |||
- | {{ : |