Account can only be used to login one at a time

[Jim Potter]

I reckon a way forward here could be PAM - I wrote a pam module that 
looked stuff up out of the session.tdb database - you coiuld do the same 
thing here - if a userid already has more than a specified number of 
entries [like none] in the session database, use pam to make his login 
fail. I don't know how quick session.tdb is updated in a workstation is 
killed - the facility to limit concurrent connections exists on netware 
4, and it took ~1/2 hour to clean up the list if a user pulled the power 
to their machine.

hope this helps

Jim Potter

Wong Onn Chee wrote:

> Hi,
>
> Thanks for all those who replied, especially Andrew.
>
> Let's not go down the "tied to NetBios" name route.
> This is because the purpose is to block multiple logins by the same 
> account, not tying an account to a machine.
> The NetBios method will also "immobilise" the users.
>
> If Samba on its own cannot achieve this, as pointed out by Andrew, I 
> am thinking of using pGINA at the client end, and RADIUS, Samba and 
> OpenLDAP on the server end. This means the Windows client will use the 
> RADIUS plugin in pGINA to authenticate, continue to map the shared 
> drives via Samba and synchronise their profiles via the FTP pGINA 
> plugin. On the server end, both Samba and RADIUS are tied to a common 
> LDAP backend to provide account integrity and ease of management.
>
> I believe RADIUS is a more suitable protocol to provide extensive 
> account monitoring capabilities than NTLM.
>
> Just my two cents worth.
>
> Christopher R. Hertel wrote:
>
>> On Wed, Oct 06, 2004 at 07:56:18AM +1000, Andrew Bartlett wrote:
>>
>>> On Wed, 2004-10-06 at 04:47, Christopher R. Hertel wrote:
>>>
>>>> On Tue, Oct 05, 2004 at 08:39:09PM +1000, Andrew Bartlett wrote:
>>>> :
>>>>
>>>>> On the server-side, we have quite a few problems that make this hard:
>>>>>
>>>>> - How do you tell the client has 'logged out':
>>>>>  - There is no reliable 'logged out' message from the clients.
>>>>>  - There is no connection that the client *must* hold open to remain
>>>>> 'logged on'.
>>>>> - What happens if the client (holding the session) reboots, or 
>>>>> worse is
>>>>> just unplugged?
>>>>
>>>>
>>>> What if there were simply a setting that said "user U may only log 
>>>> in from system S".  Ever.  The sysadmin could change that if/when 
>>>> the user moves to a new desk.
>>>
>>>
>>> This much we already have, on a 'workstation self exclusion' level, 
>>> it's
>>> the 'allowed workstation' (sambaUserWorkstations in LDAP I think)
>>> attribute in the passdb.
>>>
>>> Now, the main failure it is that's set by netbios name, so fails as 
>>> soon
>>> as the user tries to use smbclient, and sets that for themselves.  
>>
>>
>>
>> Right.  I thought we had something like this, but that it used the 
>> NetBIOS name (which is very easily spoofed).  I suppose, however, 
>> that it is a little tiny bit more difficult to spoof a machine name 
>> on a Windows box (using Microsoft's built-in client).
>>
>>
>>> We
>>> could honour the ldap records that pam_ldap uses, that add a DNS/IP 
>>> host
>>> restriction.  (However, this faces problems with member servers, as 
>>> they
>>> do not pass us on that information).
>>
>>
>>
>> It would need to be the member server's job to enforce the 
>> restriction, which does *not* sound like a good approach...
>>
>> Chris -)-----
>>
>
>