Agree with SLESKE but to expand on his/her comments, you need to do a couple things first!
In Linux, the libraries that control logging in need to be redirected to use an LDAP backend as oppose to looking things up in /etc/passwd.
If you are using OpenLDAP then you will want to look at two things:
NSCD (Name Server Caching Daemon) which caches the LDAP queries. You will run this on each host where users log in.
NSSLDAP (Name Server Switch for LDAP) this is the glue that causes logins to query NSCD, which in turn, will query LDAP backend or NSSLDAP will query LDAP backend directly if NSCD is stale or not available.
So on each workstation you will need to install OpenLDAP, NSCD, and NSSLDAP if not part of your distribution. OpenLDAP is required to get the client libraries which know how to speak LDAP protocol.
Then you need to make edits to some files:
/etc/nscd.conf
This file controls what gets cached. Here is a dump from one of my systems that acts as a Samba server:
enable-cache passwd yes
positive-time-to-live passwd 10
negative-time-to-live passwd 3
suggested-size passwd 211
check-files passwd yes
persistent passwd yes
shared passwd yes
max-db-size passwd 33554432
auto-propagate passwd yes
enable-cache group yes
positive-time-to-live group 3600
negative-time-to-live group 3
suggested-size group 211
check-files group yes
persistent group yes
shared group yes
max-db-size group 33554432
auto-propagate group yes
enable-cache hosts yes
positive-time-to-live hosts 3600
negative-time-to-live hosts 3
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432
You'll then need to modify your nsswitch.ldap file (read the DOCs on it, too much to go into here).
ONE VERY IMPORTANT THING!!!!
If your LDAP server is down, you want to make sure the local root account can still log in. Or if one of your workstations is having network issues, you'll want to make sure that you can still log in.
So when my Linux boxes boot up, I have a script that always copies a nsswitch.conf file into place that looks as follows:
passwd: compat
group: compat
hosts: files dns
networks: files
services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
and once I'm ready to use LDAP for logins, I replace the nsswitch.conf file with the following:
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files dns
networks: files
services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
The former allows me to login locally and the latter allows both but due to caching by NSCD, it takes time for NSCD to get stale thus causing login delays or issues.
There is much more to be said on this but this hopefully gets you started.
BTW: I'm the developer of Pozix Linux and the Pozix Linux Small Business Server and we have over 400 Samba systems running much this way!
Agreed, TRS80's comments are valid but here is a script we use to create LDIF files from /etc/passwd files. The resulting LDIF file can be used to populate your LDAP database. You'll need to make sure that if you run this script on multiple workstations that you weed out duplicate account names so that you wind up with unique account names with unique UIDs.
cat /etc/passwd | while read i; do
uid=`echo $i | cut -d : -f 1`
uidNumber=`echo $i | cut -d : -f 3`
gidNumber=`echo $i | cut -d : -f 4`
gecos=`echo $i | cut -d : -f 5`
homeDirectory=`echo $i | cut -d : -f 6`
loginShell=`echo $i | cut -d : -f 6`
userPassword=`cat /etc/shadow | grep $uid | cut -d : -f 2`
echo "dn: cn=$gecos,ou=people,dc=mycompany,dc=com"
echo "objectClass: account"
echo "objectClass: posixAccount"
echo "cn: $gecos"
echo "uid: $uid"
echo "uidNumber: $uidNumber"
echo "gidNumber: $gidNumber"
echo "homeDirectory: $homeDirectory"
echo "loginShell: $loginShell"
echo "userPassword: $userPassword"
done
Best Answer
No, that's not possible. A separate session is created per user. UserA can't logon to UserB's session as UserA.
UserA could shadow UserB's session, so why not configure remote control in the RDP-Tcp properties of the server to allow interactive remote control without requiring the user's permission. That way any member of the system team can "shadow" the session in which the batch processes run and then stop "shadowing" the session when they're done.