Account can only be used to login one at a time

[Wong Onn Chee]

Hi Jim,

How do you resolve the issues raised by Andrew in your PAM module?

"- 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?"



Jim Potter wrote:
> 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 -)-----
>>>
>>
>>
> 
> 
> 
>