Best practices to completely disable LDAP users' access to mixed services with mixed authentication methods?

Background
We use LDAP in our department to authenticate users to various services including web apps as well as Linux servers (via SSH).  When a user leaves the department, we should disable their access to our services but still retain the account and data, for various reasons.

I thought that simply changing their login shell to something like /bin/false was sufficient, but I'm still learning about the different aspects to auth for different services, having inherited a rather old and complex cluster of computers.  I've found one other step to take, mentioned below, but that still doesn't address everything.

Current Process
  1. Like I mentioned, loginShell will be set to /bin/false.
  Concerns: Even though the shell is /bin/false, the password or key is still accepted and access granted for certain amount of clock cycles, since I see things in the security log such as: sshd: Accepted password, Accepted publickey, and pam_unix(sshd:session): session opened for user (immediately followed by Received disconnect and session closed for user).
  Exceptions:
    A. This will not prevent access to password-only services, for example web-based services.
    B. There are some servers that have specified the shell to be used, by way of nslcd for example, overriding the value of loginShell
  2. To address Exception 1A, the pwdAccountLockedTime attribute can be added to the account with value 000001010000Z.

But, Concern-1 and Exception-1B are still not addressed and I'm unsure how to at this point.

Questions

• Is Concern-1 anything to really be concerned about? Is it actually impossible to send any sort of meaningful packet between the 'accepted/session opened' and 'disconnected/session closed' messages?
• For Exception-1B, beside removing the loginShell override from nslcd.conf, what are suggested solutions to address this unauthorized granted access? Are there further modifications that can/should be made to nslcd or other involved software?
• I'm wondering if there is a better, more streamlined approach to this?
• Also, have I covered everything? or, do you see any gaps in these practices once all concerns and exceptions mentioned are addressed?

Thanks so much!

͟F͟o͟r͟ ͟E͟x͟c͟e͟p͟t͟i͟o͟n͟-͟1͟B, I finally figured out I could use AllowGroups option in sshd_config and put a newly created LDAP Group "shellAccess" (for example) there:

AllowGroups shellAccess

Now, when a user retires, I can just remove their membership in the shellAccess group, it doesn't matter what loginShell overrides there are with nslcd.

͟T͟h͟i͟s͟ ͟h͟a͟s͟ ͟a͟l͟s͟o͟ ͟a͟d͟d͟r͟e͟s͟s͟e͟d͟ ͟m͟y͟ ͟C͟o͟n͟c͟e͟r͟n͟-͟1 as sshd now returns messages such as:

sshd: User foo from W.X.Y.Z not allowed because none of user's groups are listed in AllowGroups
sshd: input_userauth_request: invalid user foo
sshd: userauth_pubkey: unsupported public key algorithm: ssh-rsa
sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=W.X.Y.Z  user=foo
sshd: pam_ldap: error trying to bind as user "uid=foo,ou=People,dc=example,dc=com" (Invalid credentials)
sshd: Failed password for invalid user foo from W.X.Y.Z port 666 ssh2
sshd: Connection closed by W.X.Y.Z

Best Regards,