ndk at signet.id
Tue May 7 12:21:51 EDT 2019
First off, eduPersonTargetedID has been deprecated a few times. I would switch to persistentId's or the new SAML standard persistent identifier if you can, but that will require coordination with the service.
> We've been monitoring this for some time and have identified that after one of our users is forced to change their AD password their account requires a reset.
I'd guess you've probably been using the objectGUID as the seed for the eduPersonTargetedID. That's typically a perfectly reasonable thing to do, but in this instance...
> We've further identified that when a user changes their AD password it changes their eduPersonTargetedID value. By resetting the account they clear the value set in eduPersonTargetedID and allows a new one to be set.
When you reset the account, the computer is removed from the domain, which makes me suspicious of a new objectGUID(and thus new eduPersonTargetedID) being generated.
"Resetting a computer account breaks that computer's connection to the domain and requires it to rejoin the domain."
> When I read up on this attribute I find that it's made up of a triple tuple, one of which is generated. It's also supposed to be persistent but it's persistence doesn't have to be lifetime.
The most important point is that this is why you should store persistentId's/eduPersonTargetedID's in a database after they've been generated. It allows the source values to change without the identifier itself changing for providers that have already been accessed..
> Can anyone help me understand why this attribute might change after an AD password change?
We would need to see your configuration for the attribute to see which underlying AD attribute you're using to generate it to confirm my hypothesis, but this is a pretty strong hunch.
More information about the users