Unblocking existing Drupal user that is added back to AD

Does LDAP reassociate/resync the PUID with the objectGUID?

No. Thu PUID is only set when the account is created.

Is it possible to disable this user in the domain instead of deleting it? I imagine this is not under your control, so I guess it is not an option.

If you clear the user's PUID field the user might be able to log in successfully, enabling the disabled user.

Does this user get disabled when the orphan processor runs next? Without the PUID being changed, I expect the account would be disabled because the PUID value is not found in the domain.

I need to see your settings to say anything more.

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Sorry for the delay in response! First, no, it is not possible to just disable the user in AD, you are correct in assuming we have no control over AD, plus there is no way to know which users might return.

Also when the orphan processor runs next, the user does not get disabled again. Once we set them to active, they sync with their AD account and stay active.

Here are our settings, thanks for taking a look:

PHP LDAP module

'LDAP Support': enabled
'Total Links': 0/unlimited
'API Version': '3001'
'Vendor Name': OpenLDAP
'Vendor Version': '20457'
'SASL Support': Enabled
Directive:
- 'Local Value'
- 'Master Value'
ldap.max_links:
- Unlimited
- Unlimited
LDAP debug configuration
{ }

Users
Currently active Drupal user registration setting: admin_only

LDAP user configuration
_core:
default_config_hash: xxxxxxesw
drupalAcctProvisionServer: xxxxx_ldap
ldapEntryProvisionServer: null
drupalAcctProvisionTriggers:
- drupal_on_login
- drupal_on_update_create
ldapEntryProvisionTriggers: { }
orphanedIncludeDisabledUsers: false
orphanedDrupalAcctBehavior: user_cancel_block
orphanedCheckQty: 1300
orphanedAccountCheckInterval: always
userConflictResolve: resolve
manualAccountConflict: conflict_associate
acctCreation: user_settings_for_ldap
disableAdminPasswordField: false
userUpdateCronQuery: test_users
userUpdateCronInterval: always
userUpdateOnly: false
ldapUserSyncMappings:
drupal:
field-ldap_user_current_dn:
ldap_attr: '[dn]'
user_attr: '[field.ldap_user_current_dn]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-ldap_user_puid_sid:
ldap_attr: xxxxx_ldap
user_attr: '[field.ldap_user_puid_sid]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
field-ldap_user_puid:
ldap_attr: '[objectguid]'
user_attr: '[field.ldap_user_puid]'
convert: true
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-ldap_user_puid_property:
ldap_attr: objectguid
user_attr: '[field.ldap_user_puid_property]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
field-field_user_city_address:
ldap_attr: '[l]'
user_attr: '[field.field_user_city_address]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_dept:
ldap_attr: '[department]'
user_attr: '[field.field_user_dept]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_display_name:
ldap_attr: '[displayname]'
user_attr: '[field.field_user_display_name]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_employee_id:
ldap_attr: '[employeeid]'
user_attr: '[field.field_user_employee_id]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_fax_number:
ldap_attr: '[facsimiletelephonenumber]'
user_attr: '[field.field_user_fax_number]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_first_name:
ldap_attr: '[givenname]'
user_attr: '[field.field_user_first_name]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
field-field_user_job_title:
ldap_attr: '[title]'
user_attr: '[field.field_user_job_title]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_last_name:
ldap_attr: '[sn]'
user_attr: '[field.field_user_last_name]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_phone_ext:
ldap_attr: '[otherTelephone]'
user_attr: '[field.field_user_phone_ext]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_state_address:
ldap_attr: '[st]'
user_attr: '[field.field_user_state_address]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_street_address:
ldap_attr: '[street]'
user_attr: '[field.field_user_street_address]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_tel_number:
ldap_attr: '[telephonenumber]'
user_attr: '[field.field_user_tel_number]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
field-field_user_zip_address:
ldap_attr: '[postalcode]'
user_attr: '[field.field_user_zip_address]'
convert: false
user_tokens: ''
config_module: ldap_user
prov_module: ldap_user
prov_events:
- create_drupal_user
- sync_to_drupal_user
ldap: { }
Drupal LDAP servers
Server xxxx LDAP:
uuid: xxxxxxxxx
langcode: en
status: true
dependencies: { }
id: xxxxx_ldap
label: 'xxxxx LDAP'
type: ad
address: xxx.xxx.xxx
port: 389
timeout: 10
encryption: none
weight: null
bind_method: service_account
binddn: '***'
bindpw: '***'
basedn:
- 'OU=xxxxx,DC=xxxx,DC=gov'
user_attr: samaccountname
account_name_attr: ''
mail_attr: mail
mail_template: ''
picture_attr: ''
unique_persistent_attr: objectguid
unique_persistent_attr_binary: true
user_dn_expression: ''
testing_drupal_username: ''
testing_drupal_user_dn: ''
grp_unused: false
grp_object_cat: group
grp_nested: true
grp_user_memb_attr_exists: true
grp_user_memb_attr: memberof
grp_memb_attr: distinguishedname
grp_memb_attr_match_user_attr: cn
grp_derive_from_dn: true
grp_derive_from_dn_attr: cn
grp_test_grp_dn: ''
grp_test_grp_dn_writeable: ''

A recent feature allows orphan processing of disabled users. I do not know if this will help, but it is worth trying.

✨ Enable orphan processor for blocked users Fixed

So a user is disabled when their account gets removed from AD. They remain in Drupal as blocked, during this time if using this new feature, orphan processing would not update the disabled account account, as there would be no matching account in AD, right? Are you suggesting that once the account is returned to AD with same username/pw, that this new feature might help it resync and automatically reactivate it?

So a user is disabled when their account gets removed from AD. They remain in Drupal as blocked, during this time if using this new feature, orphan processing would not update the disabled account, as there would be no matching account in AD, right?

Yes.

Are you suggesting that once the account is returned to AD with same username/pw, that this new feature might help it resync and automatically reactivate it?

Yes. I don't think the password needs to be the same. I haven't tried reproducing your scenario. I do not know why it works after the account is enabled in Drupal.

Enabling orphan processing on disabled accounts has little risk, the accounts are already disabled.

This is not as elegant as it just working when the user logs in.

Ok we will give this a try and let you know. I will have to wait for a returning employee though, as we have very limited ability to do any testing on AD :(.

(Also i meant to say same username/email - not password).