Why can I still authenticate via lum user even after user is removed from Lum Group

Lum user can still login even after the user has been removed from lum enabled group.

id still shows the user associated to gid/group for a long time even after the user is removed as a member in edirectory.

There is a couple of factors that may contribute to the problem, so the following factors are relevant.

A very important variable that must be considered is the configuration of the nscd daemon.
Stop nscd (rcnscd stop) and if you are not using it for hosts caching, disable it from starting on reboot.
If you are using it for hosts caching, modify /etc/nscd.conf and make "enable-cache passwd no" and
"enable-cache group no" and restart nscd (rcnscd restart).

If you don't do this, then even if persistent-search=yes and cache-only=no, you will still see delays in changes made until this cache resets.

Check the /etc/nam.conf file and look for the following parameters: (If left at the defaults, the following will likely not be a factor)

persistent-search=no
Specifies whether namcd will use LDAP persistent
search feature. This feature will allow namcd to
listen to change events in LDAP related to Posix
groups and will trigger the cache refresh if
change event is relevant. Values can be "yes" or
"no." The default value is "yes."

So if this is set to "NO" changes in edir will not happen as the event is triggered. Events that trigger this refresh are
1. Removing a lum enabled user as a member to a lum enabled group.
2. Removing a group as a member to the unix workstation object.
3. Deleting a lum user
4. Delete a lum enabled group
5. Possibly other events.

cache-only=yes
Specifies whether namcd will use only the cache
for information about users and groups. If the
information about user/group not found in the
cache, namcd will not request this information
from LDAP. Values can be "yes" or "no." The
default value is "no."

persistent-cache-refresh-period=28800 [default: '28800']
Specifies how frequently user and group entries
stored in the persistenr cache are to be
refreshed from eDirectory. A larger value
results in less network traffic and less load on
the server, but the cache might reflect stale
information if the eDirectory database is modi­
fied. The value can range from 1 to 2147483647
seconds. The default period is 28800 seconds (8
hours).

If cache only is set to yes, then this variable becomes a key factor.