If I log into Phabricator via LDAP, and I am removed from the LDAP server, how does that change propagate through to Phabricator? Does it propagate? I am hoping for: you will be logged out, but I am not confident that this is true. I'm not the LDAP admin so I can't easily test this.
You will not be logged out. They will be unable to establish new sessions, but existing sessions will continue to function indefinitely.
We can not quickly or easily detect that an LDAP account has become disabled.
We would need to store the user's password and make an LDAP request on every page to make sure the account was still active if we wanted to log them out immediately. This has nontrivial security, performance, and scalability implications, and is impractical or impossible for many other types of accounts. In the general case, it would be incorrect: even if your LDAP account is disabled, you may have other valid authentication methods attached to Phabricator and still be a legitimate user.
To prevent a user from accessing Phabricator, disable their Phabricator account. This will immediately disable all authentication methods associated with their account.
There may be more tools for passive synchronization after T5953, but they will probably be limited, and are unlikely to poll every LDAP account every few seconds.
You will be able to disable users via API after user.edit (T10512 is an adjacent task), which would let you build passive synchronization yourself. You can probably do this with user.disable today until user.edit comes online.
I'm not worried about immediate logout. I agree that the effort / reward tradeoff is all wrong there. I was more thinking about the case where you are setup for anonymous search. Every X a check is performed to see if users still exist.
I hadn't considered the general case of multiple auth methods. D'oh!
I will write up some cron stuff to do what I would like, I can see now why it is unreasonable to think that upstream should handle this.
T5953 might have some kind of options for this eventually with a longer timeline between polling checks (e.g., once an hour) but that's probably some ways away and probably wouldn't be a primary focus.
I also don't really want to store passwords, so this could only work in anonymous search cases, which is a subset of a subset of a subset of auth in the general case. Not out of the question, but hard to prioritize.