You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ended up being a major overhaul of the code that processes Adobe users who don't match users on the customer side. The old code was overly complicated, because it was trying to carefully sequence deleting membership in groups with membership in organizations. But in fact this is not necessary, because removing a user from an organization will remove that user from all the groups in the organization. So the new code just has to be careful to remove users from accessor (aka trustee) orgs before removing or deleting them in the owning org.
Another major piece of cleanup/overhaul had to do with enumerating users in accessor organizations. Since the conceptual framework for accessors vs. owners is that the owner org owns the domains that the users are in, whereas the accessors are just granting entitlements to the users in those domains, the whole structure assumes that all users must be in the owner org and only some of them are in the accessor org. This means that, when we go to enumerate accessors, we want to ignore any dashboard users we find that weren't in the owner org. In addition, we never want to update attributes in the accessor orgs, because trustees are not allowed to do that. Finally, when we find an unmatched user that we want to operate on, we need to keep track which accessors we've actually seen that user in, so that we don't just go trying to remove every user from every accessor. (We could do this, of course, but it's overkill, and currently the server gives errors if you try to delete a user who is not actually in the org.)
The work done here included (in no particular order):
* move to umapi_client 2.1, because it has compatibility fixes for changes in the wire protocol around removing users from organizations and deleting them.
* take advantage of the umapi_client upgrade to correctly delete user accounts.
* update the format of the unmatched users list, so that we also track the org of the unmatched user as well as the user key. This allows being precise about which users need to be removed from which orgs.
* rename "nonexistent" users to be "unmatched" users in all public contexts. @phil-levy may or may not like this change.
* rename "orphan users" (the internal word in the code for unmatched) to be "strays".
* make sure that the default new account type is inherited and used by the ldap and csv connectors.
* fix the stats to make sense in all cases
* rework the way we track excluded and included users so it works for accessors as well as the owner org.
* rework the way we track unmatched users by keeping a global map from organizations to the user keys that were deleted in those organizations. This works even when you haven't loaded the directory or dashboard, as when you are removing users on an input list.
* changed input delete list handling so we don't bother loading directory or dashboard users.
The code now seems dead stable and works with multiple organizations quite well. The one problem is a strange umapi crash on an unexpected server response when you do --remove-entitlements-for-non-existent-users on multiple orgs. The crash happens *after* all the server-side processing has been done, so essentially the run completes successfully and then umapi_client immediately throws a ServerError. I'll have to figure this out for the GM build, but for now testing can proceed on RC2.
Copy file name to clipboardExpand all lines: docs/success-guide/setup_config_files.md
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -112,7 +112,7 @@ A more realistic example is:
112
112
113
113

114
114
115
-
#### Delete Limits
115
+
#### Unmatched User Limits
116
116
117
117
Limits on deletion prevent accidental account deletion in the event of misconfiguration or some other problem that results in User Sync not getting proper data from the directory system.
118
118
@@ -121,8 +121,8 @@ Limits on deletion prevent accidental account deletion in the event of misconfig
121
121
☐ If you expect the number of directory users to drop by more than 200 between User Sync runs, then you will need to raise the max\_missing\_users value. These config file entries are to prevent runaway deletion in case of misconfiguration or other problems.
122
122
123
123
limits:
124
-
max_strays_to_process: 10 # ceiling on disable/remove/delete
125
-
max_strays_hard_limit: 200 # abort if this many directory users disappear
124
+
max_removed_users: 10 # ceiling on disable/remove/delete
125
+
max_unmatched_users: 200 # abort if this many directory users disappear
# (optional) Default country code to use if directory doesn't provide one for a user [Must be two-letter ISO-3166 code - see https://en.wikipedia.org/wiki/ISO_3166-1]
22
+
# (optional) Default country code to use if directory doesn't provide one for a user
23
+
# [Must be a two-letter ISO-3166 code - see https://en.wikipedia.org/wiki/ISO_3166-1]
23
24
#
24
25
# example:
25
26
# default_country_code: US
@@ -87,14 +88,14 @@ directory:
87
88
# - enterpriseID
88
89
# - federatedID
89
90
90
-
limits: # provide processing controls over stray Adobe users (that is, that are unmatched on customer side)
91
-
# these controls only apply when strays are being processed for removal or deletion from the Adobe side;
92
-
# if strays are just being output to a file for later processing, these settings do not apply.
93
-
max_strays_hard_limit: 200# If more than this many stray users are found, no processing of them is done.
94
-
# Instead, user sync will abort at the point it would remove or delete them.
95
-
max_strays_to_process: 10# If more than this many stray users are found, only this many of them will be
96
-
# removed or deleted, and the the run will terminate normally. Later runs
97
-
# can be used to process the next batch of them.
91
+
limits: # provide processing controls over Adobe users that do not match users on the customer side
92
+
# these controls only apply when unmatched users are being removed or deleted from the Adobe side;
93
+
# if the users are just being output to a file for later processing, these settings do not apply.
94
+
max_unmatched_users: 200# If more than this many unmatched users are found, no processing of them is done.
95
+
# Instead, user sync will abort at the point it would remove or delete them.
96
+
max_removed_users: 10# If more than this many stray users are found, only this many of them will be
97
+
# removed or deleted, and the the run will terminate normally. Later runs
98
+
# can be used to process the next batch of them.
98
99
99
100
logging:
100
101
# specifies whether you wish to generate a log file
# (optional) Default country code to use if directory doesn't provide one for a user [Must be two-letter ISO-3166 code - see https://en.wikipedia.org/wiki/ISO_3166-1]
22
+
# (optional) Default country code to use if directory doesn't provide one for a user
23
+
# [Must be a two-letter ISO-3166 code - see https://en.wikipedia.org/wiki/ISO_3166-1]
23
24
#
24
25
# example:
25
26
# default_country_code: US
@@ -121,9 +122,14 @@ extensions:
121
122
elif subco == 'Company 2':
122
123
target_groups.add('Company 2 Users')
123
124
124
-
limits:
125
-
max_strays_to_process: 10# if --remove-nonexistent-users is specified, this is the most users that will be removed. Others will be left for a later run. A critical message will be logged.
126
-
max_strays_hard_limit: 200# if more than this number of user accounts are not found in the directory, user sync will abort with an error and a critical message will be logged.
125
+
limits: # provide processing controls over Adobe users that do not match users on the customer side
126
+
# these controls only apply when unmatched users are being removed or deleted from the Adobe side;
127
+
# if the users are just being output to a file for later processing, these settings do not apply.
128
+
max_unmatched_users: 200# If more than this many unmatched users are found, no processing of them is done.
129
+
# Instead, user sync will abort at the point it would remove or delete them.
130
+
max_removed_users: 10# If more than this many stray users are found, only this many of them will be
131
+
# removed or deleted, and the the run will terminate normally. Later runs
132
+
# can be used to process the next batch of them.
127
133
128
134
logging:
129
135
# specifies whether you wish to generate a log file
0 commit comments