I have Winbind/Samba/LDAP configured for AD user authentication. I have some files in a directory that no longer have a file owner due to the AD account being deleted. The files owner are set as the UID of that old user account that was deleted. When I perform an " ls -l " on that directory, Winbind goes out to all domain controllers trying to match that UID to a user account in my domain which creates a major lag time when wanting to see a directory listing. I can see this happening by using the tcpdump feature. If I manually change the ownership of the files to a valid user in the domain, an " ls -l " is displayed right away.
I’m new to the Winbind/Samba/LDAP configuration and wondering how this can be resolved. We are currently migrating servers from HP-UX to SLES. HP-UX is using NIS and we do not experience this issue but we feel our current setup with Windbind…etc is a better fit for us at this point in time.
Has anyone run into this? My ending goal would be to have an " ls -l " display right away regardless if it can match a UID to the AD account or not.
Wild ideas on this one as I’ve never set this up, though I have
encountered the issue of slow ‘ls -l’ output when the names behind UID/GID
values could not be found quickly using other LDAP backends (eDirectory
specifically).
Do not delete users ;instead, disable them and maybe put them in a
container for inactive users. This has a lot of benefits in general since
it gives you a good record of who has been in the system, allows you to
keep e-mail and other attributes unique forever, and helps ensure if you
have somebody return they can have their username back, instead of a new
one since the old one was taken by some other new user in the meantime.
When you delete somebody, create a disabled, local account on the
server. If nothing else, this should give you the best performance possible.
Perhaps look into using SSSD for authentication. I think you’ll still
need winbind for the file access stuff, but SSSD at least seems to do good
things with authentication, including caching identities.
When you delete a user, fix the user-owner. You can do this easily
with the ‘find’ command which is used to find users owned by a now
non-existent UID and then run a command to change ownership (chown) to
somebody else… maybe a service account made just for this purpose, or
‘root’ if nothing else.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
[QUOTE=ab;23293]4. When you delete a user, fix the user-owner. You can do this easily
with the ‘find’ command which is used to find users owned by a now
non-existent UID and then run a command to change ownership (chown) to
somebody else… maybe a service account made just for this purpose, or
‘root’ if nothing else.[/QUOTE]
This option “4” is what looks like the right approach to me: User management needs properly defined processes both for creating and deleting users. Like when creating a new user, you need to set up stuff like directory entries, home dirs, group memberships and alike, you’ll have to properly “delete” users from your system, in a coordinated way.
Leaving dangling files is definitely the worst option - diverging accounts (leaving independent user entries on single servers) create a high risk of messing up permissions later (i.e. when you centrally re-use the numeric ID for a new account, which would give the new user access to the old files).
Such processes should also take into account that there may be resources that require the old account to be kept (like entries in a history or in backups, which you cannot delete), hence keeping the ID available but disabling its use for logins is the typical (and proper) approach. But this still will not forfeit the necessity to re-own (or delete) those files: If they are kept because their content is needed, a new owner is to be found. If you no longer need the content… delete the files. Proper clean-up process.
Suggestion 1 to 3 will most probably help with the technical problem described by robcase0, but IMO that technical problem is only the consequence of an organizational problem up front. Fix that one and keep the technical problem as a reminder, in case the organizational problem wasn’t fixed for all instances
