We are going to port the intranet web application using proprietary form-based protection in Active Directory. The application logs various user actions, and there is a significant amount of data associated with user accounts. Our plan was to transfer all of these UserId columns to different tables: from a foreign key connecting the proprietary system to the Active Directory GUID. Usernames are identical between the two systems, so migration is not a problem.
However, we identified one serious problem: our security policy dictates that inactive users must be removed from Active Directory. The orphaned GUID in our security logs makes entries completely meaningless to anyone who views them.
How can an application support the generally accepted basics for a person (name, login, etc.) about a GUID that has been removed from Active Directory?
We considered the following options. One of these options may be optimal, but we want to try better:
- Denormalize log tables and save name / login instead of GUID (good for logs, not active data).
- Maintain a "cache" of information about AD objects where records are never deleted.
- Saving AD account, but deactivating / blocking it