Account can only be used to login one at a time

[Jim Potter]

Hi,
   The PAM module I wrote was an attempt at a single sign-on system, 
where a successfull response was given if a user tried to login from an 
ip address with an active samba session for that name (it didn't work 
very well, as most apps do not seem to hand the IP address of the client 
to PAM). To limit concurrent connections, OK, it doesn't directly 
address any of the problems you stated - I got the impression that 
connections closed ~30 seconds after a user logs out. (the holding 
connections open part was not an issue, as I recall... the .tdb files 
keep a list of users with active sessions which do not seem to time out 
unless a connection is lost. See smbstatus - the 
PID/Username/Group/machine bit).
    Using this in conjunction with the client call methods mentioned 
earlier in this thread, you could solve the below problems - when a user 
tries to log in, see if they have a current session - if they have, call 
the client host(s) where they are recorded as already being logged in, 
and find out if they really are still logged in - this would solve the 
remaining 3 of your problems below.

does that make any sense?

Jim Potter

Wong Onn Chee wrote:

> 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 -)-----
>>>>
>>>
>>>
>>
>>
>>
>>              
>
>