Differences

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

--- tutorial:adm:manage_ad [2021/02/25 08:45]
apeterova extensionAttribute1
+++ tutorial:adm:manage_ad [2021/06/24 07:07]
soval [Password mapping]
@@ Line 1: / Line 1: @@
 ====== Systems - AD: Manage users ======
 ===== Introduction =====
 This tutorial will show you how to connect AD as a target system for users (their accounts) from CzechIdM. We will use an AD bundle connector from ConnId.
+You can as well use [[tutorial:adm:manage_ad_wizard|newer tutorial to use wizard for AD connection]] - you still will need this page to explain attributes not covered by wizard and troubleshooting.
 ===== Before you start =====
 ==== Adding Active Directory connector ====
 Since CzechIdM 9.2, the [[https://github.com/bcvsolutions/ad-connector|forked ConnId AD connector]] is bundled inside CzechIdM by default. You can use it out of hand to test the basic functionality. However, it is advised to use the [[devel:documentation:adm:systems:winrm_ad_connector|WinRM + AD connector]] for the production-ready integration of CzechIdM <-> AD, as it enables more complex functionality.
@@ Line 166: / Line 165: @@
   * Attribute with password - true
+==== Send additional attributes with password ====
+It's possible to send additional attributes to provisioning, when password is changed (e.g. password expiration in extended attribute). New flag ''sendOnPasswordChange'' was added to system attribute mapping - attribute with this flag checked will be send together with changed password to provisioning. Two ways for provisioning additional attributes are implemented:
+  - send additional attributes together with new password in one provisioning operation
+  - send additional attributes after password is changed in another provisioning operation
+Two ways are be configurable by application configuration ''idm.sec.acc.provisioning.sendPasswordAttributesTogether'':
+    * ''true'': additional password attributes will be send in one provisioning operation together with password
+    * ''false'': additional password attributes will be send in new provisioning operation, after password change operation (some systems doesn't support to change other attributes in the same request with password)
+<note tip>Configuration is effective for all target systems. All target system will be using one configured way (configuration per-system is not implemented, coming soon).</note>
+=== Send attribute only on password change ===
+Since version **11.0.0** a new flag **Send only on password change** was added to the attribute detail.
+If is this flag checked, then the attribute will be send to the system only during change of password operation. It means that this attribute will be ignored in standard provisioning operations (create/update).
+<note important>This checkbox can be use only if attribute has checked flag **Send additional attributes with password**.</note>
 ===== Role for AD =====
@@ Line 178: / Line 194: @@
 From now on, every time user gets the role, it is provisioned into the connected system AD. You can see that on users detail menu tab "Provisioning" or in the audit "Provisioning"
+<note important>Check if the user created in IdM has password according to Active directory password policy, otherwise user can be created in IdM but not provisioned to AD system.</note>
@@ Line 188: / Line 206: @@
   * **Group members reference attribute** - usually **member**. This represents the name of the attribute in AD that is present in Group. Its value is usually a DN of the user in the group.
-Then continue to AD - users Mappings and edit provisioning mapping. Add there a **ldapGroups** attribute. It is not filled from any identity attribute and has no transformation. (It will be filled from the role). Since the attribute is multivalued, its filling strategy must be either **MERGE or AUTHORITATIVE MERGE**.
+Then continue to AD - users Mappings and edit provisioning mapping. Add there a **ldapGroups** attribute. It is not filled from any identity attribute and has no transformation. (It will be filled from the role). Since the attribute is multivalued, its filling strategy must be either **MERGE** (recommended for AD) or AUTHORITATIVE MERGE ([[devel:documentation:adm:systems#synchronizationprovisioning_strategies|info about strategies]]).
-Get back to your role CRM basic user. In the tab **Systems** add a system **AD - users and roles**, save it. Then add an attribute that will be filled by this role - **ldapGroups**. Again choose the filling strategy **MERGE or AUTH.MERGE**. Then **add a transformation** that is the value of DN of the group in AD ' " ' sign on each side of the text.
+Get back to your role CRM basic user. In the tab **Systems** add a system **AD - users and roles**, save it. Then add an attribute that will be filled by this role - **ldapGroups**. Again choose the filling strategy **MERGE** (or AUTH.MERGE, make sure to use the same as in the provisioning mapping). Then **add a transformation** that is the value of DN of the group in AD ' " ' sign on each side of the text.
 Thus every user that has the role assigned is added to the group with provided DN via ldapGroups attribute.
@@ Line 257: / Line 275: @@
 The value of this property must be a proper URL, e.g. ''<nowiki>ldaps://some.hostname:636</nowiki>''. If using multiple values, write each value at a separate line.
 ===== Video Guide =====
 [[https://www.youtube.com/watch?v=ZbQCH_BYd-k&list=PLBeAQt3pe3EcdVE8QpCDEJcDsi_jtNQUb&index=7|How to create role for AD group]] - czech language